Tang, I can't comment on Liberty since I know nothing about it.
For GlassFish, we need to make sure that the product is always compatible
with the Java specification requirements. For example, that means a full
Java EE application server may not have an option to "turn off" the EJB
container, such that applications using EJBs fail to deploy or fail to run.
The only way to support subsets of the Java EE specification is to produce
separate products that don't carry the Java EE brand, but that still do
conform to all the Java specification requirements for the Java technologies
they do include. This is the "distributions" approach I suggested earlier.
You can, of course, take multiple, independent, compatible Java EE
technology implementations and combine them together yourself, or allow
the customer to combine them, again assuming the result meets all the
appropriate Java compatibility requirements.
You could, for example, produce a distribution that contains only the Servlet
container from GlassFish, and no other Java technologies, test it with the
Servlet TCK, and release it as a (non-Java EE branded) product.
Such a product could be combined with the standalone JAX-RS implementation
from the GlassFish Jersey project, for example.
If there's things we can do in the GlassFish project to enable you to
produce, test, and distribute such products, those are worth considering.
But we can't consider for the GlassFish product itself the approach you've
suggested that allows turning on and off subsystems that support Java EE
specifications.
But again, as I said previously, we're very interested in finding ways to
reduce the cost of having a subsystem installed that no application is
using, as long as doing so is completely transparent to the user. If,
for example, you find that startup with the EJB container "turned off"
is significantly faster than startup with the EJB container turned on
but not used by any application, we'd like to understand why. What is
the EJB container doing during startup when no application is using it?
Can we find a way to defer that work until the first application uses
the EJB container?
Similarly for CDI or other subsystems that you determine take a lot of
time at startup.
Clearly this is more work than just "turning off" the subsystem and letting
the user deal with the issues, but we believe it provides a better user
experience, and it meets the Java compatibility requirements.
Tang Yong wrote on 12/04/13 22:54:
> Bill
>
> Thanks detailed comments very much!
>
> Firstly, pl. allowing me to state the motivation/background in detail:
>
> 1. Starting Performance
>
> I have ever seen an article[1], and in the article, liberty's starting
> performance makes me surprised(only 2 sec), then, while I
> investigated/evaluated liberty, I have found the fact that liberty is a
> light-weight appserver and while starting it defaultly, it only loads
> jsp/web related feature, and by implementing OSGi 5's subsystem spec,
> liberty splits the whole Java EE features into many more fine-grained
> features. Eg. for servlet,ejb,and cdi, there are the following combination:
>
> 1) servlet
> 2) servlet + ejb
> 3) servlet + cdi
> 4) servlet + ejb + cdi
> ...
>
> Thus, for an user, he/she will have more selection free.
>
> Deeply, I have done an experiment that after I installed/started
> minimized modules of gf on demand, starting time is about 1.34
> sec(greatly improving gf starting).
>
> [1]:
> http://zeroturnaround.com/rebellabs/the-great-java-application-server-debate-with-tomcat-jboss-glassfish-jetty-and-liberty-profile/6/
>
> 2. GlassFish Itself
>
> As is well known, GlassFish is as open source refrence implementation of
> Java EE. All are focused on Java EE spec. This is naturally be natural
> and right. However, dedicating to being a leading appserver(at least I
> think so), other than Java EE, what gf still brings us? whether meaning
> "without any explicit request from the user", we do not move forward it?
> so far, I think that liberty's design philosophy is a great trend for
> appserver's future.
>
> Additionally, for current gf distribution, there are two main
> distributions: one is for web profile and the other is for full profile.
>
> Why we need to create two distributions for user? Instead, I think that
> if only having a distribution and by some way making user to freely add
> what he/she want, then, this will be more convenient and *on demand*.
>
> Since speaking *on demand*, I want to say that this is very excellent
> due to hk2(exactly osgi-adapter), and here *on demand* which I consider
> is based on user's behavior(he/she want what or not want what, whether
> being more convenient) rathen than only module level.
>
> 3. About Integration
>
> If an user wants to integrate a third framework into GF, how he/she will
> do? There are two ways:
>
> 1) one by one installing these bundles into GF using "asadmin osgi ..."
> command
>
> 2) manually putting these bundles into modules or autostart directory
> and still needing to check whether having duplicated or not-meeting
> dependencies and etc.
>
> What I want to do is that having a more simple way to integreate a third
> framework by implementing some smart provisioning based on the concept
> of bundle repository. As a first step, I select to provision gf itself,
> and in the future, I have a plan to provision user-defined bundles.
> Maybe this goal also meets some cloud scene for GF.
>
> Secondly, I want to say my opinion for the following comments,
>
> Bill Shannon 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?
> pl. seeing the above my comments, and I think that what I am doing
> should be a more "lazy" approach.
>
>>
>> If what you're really concerned with is the download or installation size
>> of GlassFish,
> My current plan is not concerned with the download or installation size,
> and in fact, no any module will be removed from GF installation. I only
> make modules directory be a provisioning repository.
>
>> 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.
> I am sorry that I do not agree with you about the point. I have said
> that Java EE is very important , however, it is not all for an leading
> appserver. What's more, in my plan, by some way, we can reach different
> distributions(web profile and full profile).Eg. I can define the
> following features:
>
> <subsystems name="GlassFish Subsystems">
>
> <subsystem name="Web Profile" description="...">
> <module name="org.glassfish.main.web.core" />
> ...
> </subsystem>
>
> <subsystem name="Full Profile" description="...">
> <subsystem name="Web Profile" />
> ...
> </subsystem>
>
> </subsystems>
>
> Finally, pl. not mind what I said above, if having any error, pl.
> correct me.
>
> Thanks
> Tang
>