On 10/27/09 16:33, Richard S. Hall wrote:
On 10/27/09 16:28, Richard S. Hall wrote:
On 10/27/09 16:15, Andrew Williams wrote:
Hi there,
I am getting to know felix a little more now and appreciating much
that it has to offer.
One thing that has me puzzled though is how to use the auto
deployment at a particular startlevel.
And for that matter - how to iterate through the startlevels on load.
The first problem is that I would like to load a set of dependencies
that make up my framework before
auto-deploying bundles that make use of these bundles.
I can make this work if I know in advance all the bundles, but I
would like to make it more dynamic.
Does anyone know the right way to do this?
If you have all of your bundles in the auto-deploy directory, then
the launcher will install them all first in one pass, then start them
all in another pass. If your bundles are written correct to listen
for service availability (or if you use something like DS or iPOJO),
then this ordering should be sufficient.
If your bundles are more brittle than that and simply expect some
services to be available, then you could use the felix.auto.start.<n>
property to install and start a set of bundles into the <n> start
level, which you would likely set to 1. The other dependent bundles
could stay in the auto-deploy directory, but you'd need to configire
felix.startlevel.bundle to be 2 and
org.osgi.framework.startlevel.beginning to be 2.
This should get everything going correctly, I believe.
I just double-checked the source code for AutoProcessor and I think
what I said is not correct. We actually process the auto-deploy
directory before the auto-start property, which means my approach does
not work. I think we could easily argue that we should reverse the
processing of these two for situations like you describe.
If you want to open a JIRA issue for this, I will do it for the next
release. In the meantime, you could try it out by reversing the two
lines in AutoProcessor.process() and compiling a customer launcher to
see if it does actually work for you.
I take it back again! :-)
Looking at the code further, we do the following in Main.main():
m_fwk = factory.newFramework(configProps);
// Initialize the framework, but don't start it yet.
m_fwk.init();
// Use the system bundle context to process the auto-deploy
// and auto-install/auto-start properties.
AutoProcessor.process(configProps, m_fwk.getBundleContext());
// Start the framework.
m_fwk.start();
So we first initialize the framework instance, then we do all of the
auto processing while the framework is in the STARTING state, then we
start the framework which should correctly transition through the start
levels.
So, even though we process auto properties after the auto-deploy
directory, this shouldn't matter since the framework is not yet started
so no bundles will actually start yet until the framework is started,
which happens last. Thus, I think my first suggestion should work.
Try it and let me know.
-> richard
-> richard
If you want something more fancy or specific than this, you will
likely have to write your own launcher code.
Also, If I set org.osgi.framework.startlevel.beginning=2 I still
find that the container is booted only to start level 1.
Am I expecting the wrong behaviour or somehow incorrectly starting
things?
Looking at the code, it looks like it is doing the right thing. The
framework should go to start level 2 if you have this set; I tested
it and is appears to work for me. Just make sure you have the
property spelled correctly and a proper parseable integer value.
-> richard
Any tips appreciated,
Andrew
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
