[wildfly-dev] smaller footprints
David M. Lloyd
david.lloyd at redhat.com
Tue Mar 4 11:39:55 EST 2014
You might want to look at the work described in
https://issues.jboss.org/browse/MODULES-146 which essentially would let
you keep your modules directory completely remote on a server, with
local caching, if you wanted to.
On 03/04/2014 08:35 AM, Bill Burke wrote:
> 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
>>>>
>>>
>>
>
--
- DML
More information about the wildfly-dev
mailing list