Hi Sahoo,
Now, I need to correct some previous my writing as following,
> After setting "glassfish.osgi.ondemand=true", the location of
> installed bundles still came from the following positions:
> 1) modules/endorsed/
> 2) modules/
> 3) modules/autostart/
On "glassfish.osgi.ondemand=true" mode, the locations of installed
bundles come from two places:
1) the value of "glassfish.osgi.auto.start"
${core.bundles} \
${osgi-ee.bundles} \
${osgi-shell.bundles}
2) the uris of Fragment JARs which are searched based on the value of
"glassfish.osgi.auto.install"
> start with "obr://..." . I want to know whether having some rule to do
> it or not?
The rule should be:
1) firstly, using MinimalBundleProvisioner to install those bundles that
are required to be started or those bundles that are fragments.
2) secondly, using ObrHandler which is on osgi-adapter module to deploy
other bundles on "com.sun.enterprise.hk2.repositories" other than
previous installed bundles by MinimalBundleProvisioner.
>In addition, I guess that because of setting
> "glassfish.osgi.ondemand=true" , the value of
> "com.sun.enterprise.hk2.obrEnabled " is also true, so Glassfish(HK2
> Layer) used OBR to provision some bundles. But I have not seen created
> obr.xml.
Not obr.xml. It is obr-modules.xml on osgi-cache\felix and is generated
by ObrHandler when setuping osgi bundle repository. And, currently,
glassfish used felix Bundle Repository Implementation to resolve
resouces and deploy bundles.
Finally, I have a problem about start of bundles.
[Problem]
I have known that bundles installed by MinimalBundleProvisioner must be
started, however, I do not know that on bundles installed by ObrHandler,
why some bundles are started, the other bundles(not fragment jars) are
still in Installed status because start level of these bundles is
default 1.
--Best Regard!
--Tang
Tang Yong wrote:
> Hi Sahoo
>
> Please tolerate following my long contents.
>
> Remembering on previous thread, Sahoo ever said:
>
>> This is a work in progress. I have implemented this to some extent in
>> trunk. I call this "on demand" mode. You can try it out by setting
>> glassfish.osgi.ondemand=true in glassfish/config/osgi.properties.
>
> Today, I have tried the mode and found some interesting topics and some
> problems and want to discuss with you.
>
> Firstly, let us see the running result after setting
> "glassfish.osgi.ondemand=true".
>
> 1 About provisioned bundles
>
> After setting "glassfish.osgi.ondemand=true", the location of installed
> bundles still came from the following positions:
>
> 1) modules/endorsed/
> 2) modules/
> 3) modules/autostart/
>
> However, I found a interesting problem after diffing the results of
> "glassfish.osgi.ondemand=true" and "glassfish.osgi.ondemand=false",
>
> After setting "glassfish.osgi.ondemand=true", the bundle of
> modules/exception-annotation-processor.jar (0.0.0) has been not
> installed. Is it a bug?
>
> In addition, After entering felix shell and executing lb command, I
> found that there are two bundles[1][2] which display the same bundle
> description("Admin Console Integration (4.0.0.SNAPSHOT)").
> [1]gf-admingui-connector.jar
> [2]console-plugin-service.jar
> As a litter suggestion, I wish team can improve "Bundle Name" of the two
> bundles in order not to confuse the user.
>
> 2 About the provisioning.properties
>
> Default, Glassfish has not offered such a file, however, after setting
> "glassfish.osgi.ondemand=true" and executing start-domain command, under
> osgi-cache\felix\bundle0 directory which hosts system bundle, a
> provisioning.properties file will be auto-generated and records some
> important configurations, such as "lassfish.osgi.auto.install",
> "glassfish.osgi.start.level.final" ....
>
> However, I found that the value[3] of "glassfish.osgi.auto.install"
> seemed to be a litter strange. Why osgi-resource-locator.jar needs to be
> listed alone?
>
> [3]glassfish.osgi.auto.install=file\:/.../modules/endorsed/
> file\:/.../modules/osgi-resource-locator.jar file\:/.../modules/
> file\:/...modules/autostart/
>
> 3 About location of provisioned bundles
>
> After setting "glassfish.osgi.ondemand=true", I found that under
> osgi-cache\felix dirctory, some bundles's locations(recorded in
> bundle.info file) start with "file:/..." , other bundles's locations
> start with "obr://..." . I want to know whether having some rule to do
> it or not? In addition, I guess that because of setting
> "glassfish.osgi.ondemand=true" , the value of
> "com.sun.enterprise.hk2.obrEnabled " is also true, so Glassfish(HK2
> Layer) used OBR to provision some bundles. But I have not seen created
> obr.xml.
>
> Secondly, I want to say my understanding of "Ondemand Provisioning".
> I wish to implement such a mode:
>
> When starting glassfish domain, only loading（install and start)
> Glassfish Kernel related modules(including HK2...), and Admin related
> modules used to control domain, and user specified modules.
>
> If user has not specified more modules other than Kernel and Admin
> related modules, glassfish only loads Kernel and Admin related modules.
> Such a way maybe improve performance of staring glassfish and save more
> resouces greatly which maybe meet some demands of cloud scene.
>
> Then, after starting glassfish, glassfish should also offer a means to
> load more modules on demand if lately a user wants to use the
> modules-related technology. For example, if lately the user want to use
> ejb-related technology, glassfish should offer a means (for example,
> start ejb container related modules alone, using deploy command with
> more options or a provisioning related file to provioning dynamiclly... ) .
>
> In order to reach the mode, I think that we need to divide each
> technology related bundles and dependent bundles, then make some
> configurations, of course, it is not a simple thing.
>
> I have seen a trend that if glassfish will integrate more and more other
> frameworks(etc. Apache DCXF,...) which depend on more third-party
> bundles, installed and started bundles will become more and more...
>
> --Tang
>
>