Larry,
Your observation is correct, but description is not. It is not that
bundle cache is managed on a per bundle basis, it's that GlassFish
uninstalls any bundle deployed using "asadmin deploy --type=osgi" when
server goes down and reinstalls them upon restart. Don't ask me why it
is done that way, but I can change it to do the right thing. File a bug
against GlassFish please. It would have been enough to just stop and
start. "asadmin deploy --type=osgi" is sort of half cooked in GlassFish,
so I encourage people to use FileInstall or OSGi Web Console to deploy
bundles.
Since the bundles get uninstalled, next time they get installed, their
start level is reset to 1, which is the initial start level of newly
installed bundles in GlassFish. On the contrary, if you deploy your
bundles to one of the FileInstalled monitored directories such as
domain1/autodeploy/bundles/, you won't face any such issues. This should
explain your observed behavior.
Having said that, I do not understand what is the ordering issue you are
trying to solve and how the current implementation impacts your
application bundles. Next time when the server starts, it should install
and start them in the same order that you had earlier deployed. Is that
not happening? Can you elaborate please? I do feel this issue is more
appropriate to be discussed in GlassFish forum. Move it to GlassFish
forum where more people may be interested in this discussion.
Thanks,
Sahoo
On Friday 15 October 2010 05:56 AM, Larry Touve wrote:
Some more information...
When you install a bundle using 'asadmin deploy...', the bundle cache is
removed when stopping the framework. This seems contrary to normal practice.
How can you persist anything this way? When you install by copying to
autodeploy/bundles, the bundle cache is persisted between framework restarts.
We were originally deploying by using autodeply/bundles, but changed over to
using asadmin so we could deploy easily to a remote server. I will do some
more testing with the StartupManager using autodeploy.
Larry
Subject: Start Level lost on framework restart
I've been trying to figure out how to manage the startup of our
application bundles (~25). There are some dependencies between bundles
and we can get them running by deploying them (using asadmin -type=osgi)
in the order we want. Everything runs fine, except when we restart the
framework (we're using Glassfish 3.0.1 which has Felix 2.0.2). It
doesn't seem to happen all the time, but occasionally we get severe
startup errors.
I attempted to install a startup manager, by using the StartLevel
service and a BundleListener. When one of my bundles was installed, I
would set the startlevel. That appeared to work on the initial
deployment. When the bundles were examined through the Felix Web
Console, they showed the correct Start Level (3). However, when the
framework was restarted, the bundles reverted to the default Start Level
(1). It seemed that either they were started up prior to my Manager
(which was at Start Level 1), or they weren't triggering an INSTALL
event, just a STARTUP event, since they were already deployed. I
noticed that one of the bundles that I started by dropping in the
autostart/bundles directory did retain the Start Level, since that is
recorded in the bundle's cache directory, but it looks like the bundles
that are started via 'asadmin deploy' behave differently.
Has anyone had any luck developing their own Startup Manager?
Thanks,
Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
