Hi, romain:
-----Original Message-----
From: Romain Grecourt [mailto:romain.grecourt_at_oracle.com]
Sent: Friday, December 06, 2013 11:01 PM
To: dev_at_glassfish.java.net
Subject: Re: About adding modules/features for GlassFish dynamiclly
>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 ?
The idea you have mentioned is quite excellent, We will take it into
consideration during the development.
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
>>> name>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
>>>