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
China Nanjing JUG Leader
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
−−−−−−−−−−−−−−−−−−−−−−