[wildfly-dev] smaller footprints
Brian Stansberry
brian.stansberry at redhat.com
Tue Mar 4 12:27:43 EST 2014
It's an interesting question how a particular child server build will be
able to override a standard config snippet from a depended upon server
build. I know Stuart was thinking about that a bit. It's been at least
28 hours so I'm sure he has it sorted. ;)
On 3/4/14, 10:46 AM, David M. Lloyd wrote:
> As long as we don't break deployments which use the container
> dependencies, anything is fine.
>
> On 03/04/2014 10:28 AM, James R. Perkins wrote:
>> Since the logging subsystem is in the core distro, I'm wondering if the
>> default DUP's to add logging dependencies and search for logging
>> configuration files in deployments should be disabled. There are
>> attributes to disable these now which are should remain enabled in
>> WildFly, but it seems the opposite might be preferable in a core-distro.
>> I've not really thought about how to do that or looked over Stuarts
>> branch with great detail, but just kind of throwing it out there to get
>> opinions on it.
>>
>> On 03/03/2014 10:37 PM, 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
>>>>>
>>
>
>
--
Brian Stansberry
Senior Principal Software Engineer
JBoss by Red Hat
More information about the wildfly-dev
mailing list