Quite right, thanks for the walkthrough though.
I was able to find that the problem was some configuration properties
were being mangled.
I had got to the difficult situation that the properties last
generated were almost what I was trying to test but not quite.
Sorry for wasting your time. I will concentrate on the customisable
loader idea as it should minimise these occurrences!
Andrew
On 27 Oct 2009, at 22:00, Richard S. Hall wrote:
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
