BTW: you can use my generated OBR mapping file for GF modules repository
to search modules capability.
-> Search "<p n='package' v='javax.inject'/>" , you will find two results.
This file can check current GF modules's importing/exporting.
Tang
Tang Yong wrote:
> 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
−−−−−−−−−−−−−−−−−−−−−−