[wildfly-dev] smaller footprints
Bill Burke
bburke at redhat.com
Tue Mar 4 09:35:22 EST 2014
Great work Stuart! I'm really happy somebody is taking initiative on
this because I really think it will help a lot with Wildfly adoption.
Is it ready to use? I'm willing to try it out RIGHT NOW.
I've expressed some of these thoughts months ago when I introduced the
JBoss Modules artifact features, but here was my vision:
* maven repos would become to Wildfly as /lib /usr/local/lib directory
structures are to unix.
* The JBoss Module artifact feature would become the preferred way to
deploy Wildfly/JBoss. This would make it really easy to support
multiple versions as well as different distro's of JBoss/Wildfly on the
same machine and save huge amounts of disk space. If we could get a JVM
that could share JAR instances between processes to save on RAM, the win
would be even bigger! Think of the cloud implications!
* JBoss Module definitions could eventually be defined in one large XML
file. We would have maven/ant plugins to help build this large XML file.
* This single JBoss Module XML file could be bundled within a
JBoss/Wildfly "executable jar".
* This "executable jar" could be overlayed with external JBoss Module
XML files or directory structures.
* Finally, you could create this "executable jar" for any Java project.
On 3/4/2014 1:37 AM, Stuart Douglas wrote:
> I have made a start on this split, and I think the solution I am working
> on will meet all the use cases, including users that want to cut down an
> existing server, and users that want to re-use the jars in their maven
> repo using Bill's changes to JBoss Modules. It still needs a bit more
> work and a lot of cleanup, however it seems to work:
>
> https://github.com/stuartwdouglas/wildfly/compare/wildfly-build-plugin
>
> So basically the core of it is a maven plugin that builds a Wildfly
> distribution, either from scratch or use other distributions as a base.
>
> It also supports building servers that use the new <artifact>
> functionality in jboss modules, and cutting down an existing server into
> a smaller server with only the specified modules (and their transitive
> dependencies).
>
> The way this will work in practice is that each Wildfly sub project will
> produce two different server artifacts, one of which is a server without
> any jars using artifact references, and a more traditional version with
> jars packaged in the module directory. Downstream projects will consume
> the smaller version without all the jars, so when a version changes the
> download should be less than 5mb rather than larger than 100mb (the
> plugin has the ability to turn a server that uses artifact references
> into a server that contains the jars in the modules dir).
>
> Basically the upshot is that it should be basically possible to build
> whatever configuration of server you want once this is part of our build
> process, and we should also be publishing lightweight server artifacts
> that use the jars in the maven repo as well as our traditional
> 'everything and the kitchen sink' build.
>
> It is anticipated that 3rd party projects build on Wildfly would also
> use this plugin (I think at the moment the standard approach has been to
> copy and modify our ant scripts).
>
> This is still very much a work in progress, so nothing is set in stone
> yet and any comments are welcome.
>
> Stuart
>
>
> Bill Burke wrote:
>> A lot of users want that ability, would you rather have them roll Netty
>> + whatever?
>>
>> On 2/23/2014 9:10 PM, Stuart Douglas wrote:
>>> No, because that means we essentially have to support and test every
>>> possible combination that someone might select.
>>>
>>> Stuart
>>>
>>>
>>> On Mon, Feb 24, 2014 at 7:13 AM, Misty Stanley-Jones<misty at redhat.com
>>> <mailto:misty at redhat.com>> wrote:
>>>
>>> I know you guys aren’t there yet, but can we think about wrapping a
>>> GUI around this, so that the developer only needs to tick the boxes
>>> for what he does/doesn’t want, with dependencies sorted out
>>> automatically? Maybe some default profiles that select a group of
>>> things, but the ability to go in and add or remove individual
>>> subsystems as needed? Maybe this could be part of the installer but
>>> could optionally be run post-install as well.
>>>
>>> On Feb 22, 2014, at 2:01 AM, Brian Stansberry
>>> <brian.stansberry at redhat.com<mailto:brian.stansberry at redhat.com>>
>>> wrote:
>>>
>>> > When I said "Web" I meant the thing described on that wiki
>>> page Tomaz
>>> > linked:
>>> >
>>> > "Web
>>> >
>>> > Undertow subsystem, and all related dependencies, including
>>> a small
>>> > subset of EE and JNDI. This is basically just a Servlet
>>> container, and
>>> > will provide a platform for people that want to create web
>>> based
>>> > appliances or applications, and don't need all the additional
>>> > functionality that Wildfly provides. We should end up with
>>> something as
>>> > lightweight as Tomcat or Jetty, but with all our advanced
>>> management
>>> > functionality."
>>> >
>>> > On 2/21/14, 9:40 AM, Bill Burke wrote:
>>> >> Its also "Web" minus some stuff. For my project I want just
>>> Servlet,
>>> >> JAX-RS, JPA, and datasources. Its very very hard to
>>> figure out
>>> how to
>>> >> remove a subsystem and all its associated modules.
>>> >>
>>> >> BTW, I think my maven artifact thing got into JBoss
>>> Modules. So it
>>> >> would be possible to load jars on demand, or at least use
>>> it as
>>> a way to
>>> >> figure out which modules aren't being used ;).
>>> >>
>>> >>
>>> >> On 2/21/2014 10:22 AM, Brian Stansberry wrote:
>>> >>> This will move things in the right direction, but not all the
>>> way there
>>> >>> yet. Note the set of capabilities Bill mention: web, CDI,
>>> JAX-RS, JPA.
>>> >>> That sounds like our "Web" variant, plus some stuff. It's the
>>> easy "plus
>>> >>> some stuff" part that needs sorting at some point.
>>> >>>
>>> >>> On 2/21/14, 9:08 AM, Tomaž Cerar wrote:
>>> >>>> Bill,
>>> >>>>
>>> >>>> that is exactly idea we have in mind of 9.
>>> >>>> We already started with producing WildFly core
>>> distribution in
>>> that is
>>> >>>> WildFly with no subsystems, upon which you can build you own
>>> wildfly.
>>> >>>> It is only 15mb and contains whole mgmt capabilites (CLI,
>>> standalone,
>>> >>>> domain,...) you can grab it at:
>>> >>>>
>>>
>>> http://download.jboss.org/wildfly/8.0.0.Final/core/wildfly-core-8.0.0.Final.zip
>>>
>>> >>>>
>>> >>>> For 9 we have plans to move things bit further and have
>>> decided that we
>>> >>>> will also do split codebase for core, ee, web, .. and other
>>> distributions.
>>> >>>>
>>> >>>> Current idea on code split up is here
>>> >>>>
>>> https://community.jboss.org/wiki/SplittingUpTheWildflyCodeBase
>>> >>>>
>>> >>>> --
>>> >>>> tomaz
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> On Fri, Feb 21, 2014 at 3:00 PM, Bill
>>> Burke<bburke at redhat.com
>>> <mailto:bburke at redhat.com>
>>> >>>> <mailto:bburke at redhat.com<mailto:bburke at redhat.com>>>
>>> wrote:
>>> >>>>
>>> >>>> On Resteasy list I have a few people "rolling their own
>>> app server"
>>> >>>> using Netty, Weld, Resteasy and JPA. I asked one of
>>> them
>>> "I don't
>>> >>>> understand why you are rolling your own app server"
>>> response:
>>> >>>>
>>> >>>> "It's actually a lot more lightweight. The minimum
>>> I can
>>> run the
>>> >>>> equivalent on AS7 on is ~ 180 mb in binaries, but
>>> throwing this
>>> >>>> together is about 32 mb (and compresses further when
>>> its
>>> packaged).
>>> >>>> I'm able to start the JVM on the bare minimum
>>> (~100mb on
>>> my linux VM)
>>> >>>> but AS7 with all I need is about 756mb. When
>>> rolling out
>>> in the
>>> >>>> cloud, where all of my REST APIs are stateless, running
>>> with this
>>> >>>> configuration helps us get a lot more per node."
>>> >>>>
>>> >>>> I'm not complaining :), just something to think
>>> about. It
>>> might be
>>> >>>> really valuable to focus a bit in Wildfly 9 to make it
>>> easier to create
>>> >>>> custom profiles or even different packaging options for
>>> the app server
>>> >>>> instead of the exploded style we currently have.
>>> >>>> --
>>> >>>> Bill Burke
>>> >>>> JBoss, a division of Red Hat
>>> >>>> http://bill.burkecentral.com
>>> >>>> _______________________________________________
>>> >>>> wildfly-dev mailing list
>>> >>>> wildfly-dev at lists.jboss.org
>>> <mailto:wildfly-dev at lists.jboss.org>
>>> <mailto:wildfly-dev at lists.jboss.org
>>> <mailto:wildfly-dev at lists.jboss.org>>
>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> wildfly-dev mailing list
>>> >>>>
>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>> >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>> >>>>
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>> > --
>>> > Brian Stansberry
>>> > Senior Principal Software Engineer
>>> > JBoss by Red Hat
>>> > _______________________________________________
>>> > wildfly-dev mailing list
>>> > wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>> Misty Stanley-Jones, RHCE
>>> Manager, Content Services (Middleware)
>>> Direct: + 61 7 3514 8105<tel:%2B%2061%207%203514%208105> / Mobile:
>>> +61 429 595 932<tel:%2B61%20429%20595%20932> (TZ: GMT+10)
>>> IRC: misty (Freenode / RH)
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org<mailto:wildfly-dev at lists.jboss.org>
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> wildfly-dev mailing list
>>> wildfly-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>>>
>>
>
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
More information about the wildfly-dev
mailing list