Using feature packs for custom distributions

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Using feature packs for custom distributions

Marko Strukelj

For Keycloak we’ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don’t need many of the subsystems. We’ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we’ll reconsider, but for now we don’t see much sense in basing our Keycloak distribution on servlet-feature-pack.

There are two big isues for us:

1) Big module dependency trees

Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don’t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn’t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That’s a lot just to get datasources support.

What’s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that’s how intertwined the dependencies currently are.

Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution’s disk footprint.

There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool


2) Staying in-sync with changes in full-feature-pack

Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like:

<module id=”org.jboss.as.connector” from=”full-feature-pack” include-dependencies=”true” skip-optional=”true”/>

And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync.

For our use-case this would also be addressed by wildfly providing a feature-pack definition that’s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support ...


Another thing is provisioning of feature packs, which I address in another email.


- marko

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using feature packs for custom distributions

jtgreene
Administrator

> On Jul 9, 2015, at 8:57 AM, Marko Strukelj <[hidden email]> wrote:
>
>
> For Keycloak we’ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don’t need many of the subsystems. We’ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we’ll reconsider, but for now we don’t see much sense in basing our Keycloak distribution on servlet-feature-pack.
>
> There are two big isues for us:
>
> 1) Big module dependency trees
>
> Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don’t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn’t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That’s a lot just to get datasources support.
>
> What’s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that’s how intertwined the dependencies currently are.
>
> Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution’s disk footprint.
>
> There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool

Yes it sounds like some work needs to be done here to reduce the dependency chain in this area. Pulling in JCA will require transactions, and currently transactions pulls in weld and web services related items. The former is likely due to the new JTA bean support in EE7, but that should be optional for sure.

>
> 2) Staying in-sync with changes in full-feature-pack
>
> Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like:
>
> <module id=”org.jboss.as.connector” from=”full-feature-pack” include-dependencies=”true” skip-optional=”true”/>
>
> And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync.
>
> For our use-case this would also be addressed by wildfly providing a feature-pack definition that’s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support …

I think this is a good idea, to skip optional deps.

>
> Another thing is provisioning of feature packs, which I address in another email.
>
>
> - marko
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using feature packs for custom distributions

Tomaž Cerar-2

On Thu, Jul 9, 2015 at 5:13 PM, Jason Greene <[hidden email]> wrote:
> For our use-case this would also be addressed by wildfly providing a feature-pack definition that’s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support …

I think this is a good idea, to skip optional deps.


Should we add another feature pack "wildfly-web" that would be near EE web profile?
We could only have feature pack without corresponding distribution.
This would allow downstream projects like keycloak to easier build custom distribution using such feature pack.

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using feature packs for custom distributions

Stian Thorgersen
As I see it the main issue with using core or servlets is the fact that we have to redefine modules.

Currently AFAIK when pulling in a feature pack you end up pulling in all modules for that feature pack even if you disable subsystems/extensions that rely on those modules. Would it not be better to have individual subsystems define what modules they require and only pull in the required modules for the enabled subsystems/extensions? That would allow us to build on WF full and get all module definitions from there, while still reducing the size of our distribution.

----- Original Message -----

> From: "Tomaž Cerar" <[hidden email]>
> To: "Jason Greene" <[hidden email]>
> Cc: [hidden email], "keycloak dev" <[hidden email]>
> Sent: Monday, 13 July, 2015 2:53:26 PM
> Subject: Re: [wildfly-dev] Using feature packs for custom distributions
>
>
> On Thu, Jul 9, 2015 at 5:13 PM, Jason Greene < [hidden email] >
> wrote:
>
>
>
> > For our use-case this would also be addressed by wildfly providing a
> > feature-pack definition that’s somewhere between servlet-feature-pack and
> > full-feature-pack - as long as it contains datasources support, and jaxrs
> > support …
>
> I think this is a good idea, to skip optional deps.
>
>
> Should we add another feature pack "wildfly-web" that would be near EE web
> profile?
> We could only have feature pack without corresponding distribution.
> This would allow downstream projects like keycloak to easier build custom
> distribution using such feature pack.
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using feature packs for custom distributions

Bob McWhirter
In reply to this post by jtgreene
For our use-case this would also be addressed by wildfly providing a feature-pack definition that’s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support …

I think this is a good idea, to skip optional deps.

This is what wildfly-swarm does.

We consume the WF feature-packs, but only solve the tree from a few root module.xml’s to extract only the subset we need.

And if it’s optional=“true”, we pretend we don’t need it.  That helps a lot.

Also, as soon as something pulls in weld, you’re pretty screwed, since weld then depends on most everything else, many times non-optionally.

-Bob





Another thing is provisioning of feature packs, which I address in another email.


- marko

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev

--
Jason T. Greene
WildFly Lead / JBoss EAP Platform Architect
JBoss, a division of Red Hat


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using feature packs for custom distributions

Tristan Tarrant
In reply to this post by Marko Strukelj
Hi Marko,

I ran into the same issue recently and there is a thread on this mailing
list about it [1].
I ended up working my way "down" from wildfly-full to infinispan server,
since it involved less work and less trial and error.
In our case we don't even want any of the servlet and web related stuff
(i.e. undertow) since our frontend is Netty, but I'd much rather use
wildfly-web as a base than our current solution (less stuff to remove ==
less things that can go wrong). One potential solution is to "fork" the
upstream subsystems, even just for tweaking the module.xml (I know it's
dangerous practice, but it has proven quite effective).

Tristan

[1] http://lists.jboss.org/pipermail/wildfly-dev/2015-May/003984.html

On 09/07/2015 14:57, Marko Strukelj wrote:

>
> For Keycloak we’ve been trying to create a trimmed down distribution of Keycloak server, basing it on servlet-feature-pack rather than full-feature-pack, since we don’t need many of the subsystems. We’ve encountered some issues though that made us step back and stick to using full-feature-pack as a basis for Keycloak server distribution. If we find a way to address these issues in the future we’ll reconsider, but for now we don’t see much sense in basing our Keycloak distribution on servlet-feature-pack.
>
> There are two big isues for us:
>
> 1) Big module dependency trees
>
> Our goal was to reduce the distribution size by reducing the number of subsystems, and modules shipped. We guessed that since we don’t use EJB, JMS, WS - but basically just JAX-RS and datasources, the resulting distribution based on servlet-feature-pack wouldn’t get a lot bigger than OOTB servlet-feature-pack. But it turns out that enabling virtually any additional subsystem - in our case we want to use datasources, which are provided by org.jboss.as.connector - that pulls in around 90Mb of non-optional dependencies. That’s a lot just to get datasources support.
>
> What’s interesting is that adding a different subsystem support e.g. org.jboss.as.jaxrs pulls in the same dependency tree - i.e. adding JAXRS support pulls in the same dependency tree as adding Datasources support - that’s how intertwined the dependencies currently are.
>
> Using servlet-feature-pack for distributions that require some additional subsystems from full-feature-set is thus not very effective to significantly reduce custom distribution’s disk footprint.
>
> There is a tool I wrote as part of my analysis that I used to analyze the size of dependency trees: https://github.com/mstruk/keycloak-moduletool
>
>
> 2) Staying in-sync with changes in full-feature-pack
>
> Creating a custom feature pack that is a subset of full-feature-pack requires copying module.xml files from wildfly/feature-pack source tree into custom feature pack source tree. Adding org.jboss.as.connector means copying over hundreds of modules (186 to be precise). As Wildfly development moves on, any changes to module.xml files have to be synced into the custom feature pack. That has the potential to be a huge maintenance burden, and a source of errors. One way to address this would be extended syntax somewhere in feature pack definition project to say something like:
>
> <module id=”org.jboss.as.connector” from=”full-feature-pack” include-dependencies=”true” skip-optional=”true”/>
>
> And that would replace copying over module directories, and module.xml files. And guarantee that things remain in-sync.
>
> For our use-case this would also be addressed by wildfly providing a feature-pack definition that’s somewhere between servlet-feature-pack and full-feature-pack - as long as it contains datasources support, and jaxrs support ...
>
>
> Another thing is provisioning of feature packs, which I address in another email.
>
>
> - marko
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
Tristan Tarrant
Infinispan Lead
JBoss, a division of Red Hat
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using feature packs for custom distributions

Marko Strukelj
In reply to this post by Bob McWhirter
Thanks Bob for confirming that skipping optionals should work.

My initial attempts at that were still pulling in the whole world, but I found it was due to a tiny bug in the tool I used that skipped some optionals but not all of them. Things look much more promising now ...

----- Original Message -----

> >> For our use-case this would also be addressed by wildfly providing a
> >> feature-pack definition that’s somewhere between servlet-feature-pack and
> >> full-feature-pack - as long as it contains datasources support, and jaxrs
> >> support …
> >
> > I think this is a good idea, to skip optional deps.
>
> This is what wildfly-swarm does.
>
> We consume the WF feature-packs, but only solve the tree from a few root
> module.xml’s to extract only the subset we need.
>
> And if it’s optional=“true”, we pretend we don’t need it.  That helps a lot.
>
> Also, as soon as something pulls in weld, you’re pretty screwed, since weld
> then depends on most everything else, many times non-optionally.
>
> -Bob
>
>
>
> >
> >>
> >> Another thing is provisioning of feature packs, which I address in another
> >> email.
> >>
> >>
> >> - marko
> >>
> >> _______________________________________________
> >> wildfly-dev mailing list
> >> [hidden email] <mailto:[hidden email]>
> >> https://lists.jboss.org/mailman/listinfo/wildfly-dev
> >> <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
> >
> > --
> > Jason T. Greene
> > WildFly Lead / JBoss EAP Platform Architect
> > JBoss, a division of Red Hat
> >
> >
> > _______________________________________________
> > wildfly-dev mailing list
> > [hidden email] <mailto:[hidden email]>
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> > <https://lists.jboss.org/mailman/listinfo/wildfly-dev>
>

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using feature packs for custom distributions

Marko Strukelj
In reply to this post by Tristan Tarrant


----- Original Message -----
> Hi Marko,
>
> I ran into the same issue recently and there is a thread on this mailing
> list about it [1].
> I ended up working my way "down" from wildfly-full to infinispan server,
> since it involved less work and less trial and error.

Thanks for feedback. I also tried 'manually working down from full' approach but it was still too tedious and error prone. Best way to do this is to remove the human factor :)
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|

Re: Using feature packs for custom distributions

Bob McWhirter
I agree.  Building up is much more successful, if you have a tool that can solve the graph.

Start with the modules that match the <extension> modules you need, and walk from there, adding whatever is required, and you should get a good solution that is the minimum (modulo over-zealous dependencies) for what you’re trying to do.

        -Bob


> On Jul 15, 2015, at 6:25 AM, Marko Strukelj <[hidden email]> wrote:
>
>
>
> ----- Original Message -----
>> Hi Marko,
>>
>> I ran into the same issue recently and there is a thread on this mailing
>> list about it [1].
>> I ended up working my way "down" from wildfly-full to infinispan server,
>> since it involved less work and less trial and error.
>
> Thanks for feedback. I also tried 'manually working down from full' approach but it was still too tedious and error prone. Best way to do this is to remove the human factor :)
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev


_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev