Hi Bill,
Thanks detailed reply!
Bill Shannon wrote:
> Tang, I can't comment on Liberty since I know nothing about it.
Surly, I have realised that I shoud only foucs on GF, :)
>
> 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.
Yes, I can understand the point, Eg. if user has deployed an app with
EJB, he should not turn off the EJB Container.
A litter different opinion from me is that, if GF offered the option of
"trun off", once the user selects turning off EJB container and causes
the app can not work normally, then, I think that such behavior is on
his own responsibility.
For the above my judgment,the prerequisite is why we needs to offer the
option of "trun off", this is also most important question I must spend
more time to verify and confirm, otherwise, I myself can not accept the
"turn off", :)
Continue.
>
> 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.
Just like WebProfile.
Bill, whether you think of the following or not?
Whether WebProfile or FullProfile is all defined based on the view of
JavaEE Spec, maybe should have more profiles...
Well, for a java application server, its constitution should be made up
of the three parts(my immatural thinking),
1. JavaEE Spec Implementation(core value)
2. itself's Infrastructure(core value + add-on value)
1) core parts in order to support 1
2) add-on parts(eg. Cluster Support, Monitoring, Logging...)
3. extension capability(add-on value)
Eg. GlassFish OSGi-JavaEE, integration with the third part FW,...
Then, for 2.2 and 3, whether should also have some profiles similar to
WebProfile and FullProfile?
I agree with you that by "distributions" approach, this must be done.
However, just like Roman said, I think this approach is a fixed
approach. From an user,I think this approach is less convenient than
having some way to switch these profiles dynamiclly.
>
> 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.
Yes. just as you said, doing different distributions is reasonable only
if these distros can pass themself's TCKs. An additional supplementary
is as following:
[Scene]
An user who originally uses Tomcat starts to migrate into GlassFish
distro with Servlet. Some day, he found that he also needs EJB to deploy
another app. Then, how he will do? Maybe he will swich into GlassFish
distro with Servlet and EJB. Then, the cost of switching is that he will
re-deploy previous app. If the previous app is mission-critical, ...
>
> 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.
Surly, it seems that this divergence is hard to resolve, :)
>
> 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?
What you said belongs to lazy loading field. For the field, CDI 1.1 has
gave some doing, eg, by scanning annotation or others, lazy loading
container.
I agree with you the point "why", and I needs to give more powerful
proofs and spend more time. Indeedly, such proofs will be more useful
for GF, whether finally GF team will agree my solution.
>
> 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.
Surly, this will be more hard work.
Finally, although we sticks to our own view, by astracting common value,
this will benifit GF!
Best Regards
Tang
>
>
>
> 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
>>
>
>
>
--
－－－－－－－－－－－－－－－－－－－－－－
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
－－－－－－－－－－－－－－－－－－－－－－