Clingan,
Thanks your comments very much!
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.
Surly, this must be considered carefully.
>
> 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.
I agree with you and I have also mentioned the point in the thread
replying Bill.
>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.
IMHO, this will divide into four steps:
1) splitting core and minimized modules
2) generating GF module's dependency mapping file
3) using smarting provisioning skill(currently, I uses Apache Felix OBR)
to install modules for different features
4) by HK2's smart parsing inhabitat, on-demand starting provisioned modules
>
> 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 :-)
For embedded usage, I am not still familar it, thanks for telling me
this direction!
>
> Hope this helps, and THANK YOU for your continued contributions!
Thanks!
Tang
>
> 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
>>>
>
>
>
--
−−−−−−−−−−−−−−−−−−−−−−
Tang Yong
Senior Engineer
GlassFish Committer (OSGi & OSGi-JavaEE)
OSGi Alliance Supporter
Blog: http://osgizone.typepad.com/tangyong/
Nanjing Fujitsu NanDa Software Tec CO.,LTD
http://www.fujitsu.com/cn/fnst
Tel: +86-25-86630566-8310
Fax: +86-25-83317685
−−−−−−−−−−−−−−−−−−−−−−