Tim
Thanks your comments and suggestion!
Tim Quinn wrote:
> Tang (and others),
>
> There is another aspect of this work I would like to mention.
>
> Some - certainly not all - GlassFish users make use of the GlassFish app client container (ACC) to launch Java EE app clients. (This includes the built-in support for launching app clients using Java Web Start.)
>
> The footprint of the ACC is very large compared to what it really needs to be because of what classes are in the GlassFish JARs and because of the interdependencies among the existing GlassFish modules.
I see. If you have a concrete sample for displaying such large footprint
and send me, I will see whether I can find what.
>
> If your work had the side-effect of shrinking the footprint of the app client container, I and every app client user would be delighted.
I truly wish I can help what, :)
Best Regard!
Tang
>
> - Tim
>
> On Dec 5, 2013, at 1:36 AM, Tang Yong wrote:
>
>> 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
>> −−−−−−−−−−−−−−−−−−−−−−
>>
>
>
>
--
−−−−−−−−−−−−−−−−−−−−−−
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
−−−−−−−−−−−−−−−−−−−−−−