Sahoo
JJ
As a side effect, I have found some issues related to modules
exports/imports as following:
Remembering the following jira?
->
https://java.net/jira/browse/GLASSFISH-20450
While using felix OBR to deploy an resource(eg.
org.glassfish.main.web.core), it needs the resource which exports
'javax.inject' package.
However, in current GF modules, there are two modules which all exports
'javax.inject'.
1) weld-osgi-bundle.jar
2) javax.inject.jar
So, as for the issue, how do you think? My thinking is as following:
1. seperating Weld API from implementation
changing weld-osgi-bundle.jar
2. removing javax.inject.jar
this is reasonable?
Thanks
Tang
Tang Yong wrote:
> 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
−−−−−−−−−−−−−−−−−−−−−−