Another thing to think about in the writeup - how will this be quality-tested? Per Bill's comment, by providing (Java EE compliant) distributions, we can still deliver a Java EE compliant appserver. Providing fixed distributions will also constrain quality testing. However, it is still an added burden. For example, testing with/without clustering adds more testing, like performance testing, Java EE compatibility (CTS) testing, performance testing, etc.
Also along Bill's line of thought, I do like the idea of first decomposing existing modules into more fine-grained modules because it will (potentially) reduce startup time and reduce runtime footprint. We can do this while maintaining Java EE compatibility. However, modularity will require close co-ordination with each of the module leads. IMHO, improve the core modularization piece and then prioritize the containers and tackle them in order.
Also, I think of these improvements in two contexts - traditional standalone appserver and then embedded usage. One thing we are thinking about for Java EE 8 is how to improve embedded usage, with the prime use case (IMHO) being testing (unit tests, CI test phase, etc). In Java EE 6 & 7 we have the embedded EJB container, and now we are thinking of additional embedded containers or even a more encompassing "Java EE embedded API". A more modular appserver will definitely improve *either* embedded approach. This is a much more broad-based pain point, IMHO, than coming up with ad-hoc GlassFish distributions. Of course, anyone can feel free to "correct" me :-)
Hope this helps, and THANK YOU for your continued contributions!
On Dec 4, 2013, at 11:14 AM, Bill Shannon <bill.shannon_at_oracle.com> wrote:
> Our goal with GlassFish has been to load and start modules only on demand,
> without any explicit request from the user. In addition to providing a
> better user experience, this approach meets the Java EE compatibility
> requirements for all Java EE features to always be available.
>
> For the features you list below, what is the cost of having these features
> available if no application is using them? If the cost is excessive, could
> the cost be minimized by moving to a more "lazy" initialization approach?
>
> If what you're really concerned with is the download or installation size
> of GlassFish, it would be reasonable to create "distributions" of GlassFish
> that don't include some of these features. For example, distribution of
> GlassFish without clustering support could be considered. But each such
> distribution needs to meet the Java compatibility requirements for the
> technologies included in the distribution. The package manager could be
> used to install additional packages into such a distribution to increase
> its capabilities, but I still wouldn't expect the user to need to "enable"
> the new capability before using it.
>
>
> Tang Yong wrote on 12/03/13 20:15:
>> Sahoo
>> CC: Team
>>
>> I and Jeremy are incubating an new function for next generation of
>> GlassFish:
>>
>> "adding modules/features for GlassFish dynamiclly"
>>
>> Pl. allowing me to introduce what we want to do,
>>
>> 1. We abstract minimized modules for starting GF domain
>> 2. For features liking web, ejb, cdi,cluster, OSGi-javaee...
>>
>> firstly, we only install and start these minimized modules from 1 while
>> starting GF domain
>>
>> secondly, we offer a command liking "asadmin subsystem-add <feature
>> name>", and after starting GF, based on user's demand, he/she can use
>> the above command to add features dynamiclly.
>>
>> What we are doing is placed on the following,
>>
>> https://github.com/ElasticFish/subsystem-builder
>>
>> If you are interested in the topic/field, pl. free to contribute it and
>> any comment or idea is good for us. our aim is for "lightweight GlassFish!"
>>
>> Best Regards
>> Tang
>>
>