Thinking of dynamic distributions VS fixed distributions and JavaEE
compliance.
Could we think of such feature(s) (that could possibly break the
compliance), as disabled out of the box, and users could enable it at
their own risk ?
Thanks,
Romain
On 12/04/2013 10:30 PM, John Clingan wrote:
> 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
>>>