You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Andrew Williams <an...@handyande.co.uk> on 2009/10/27 21:15:13 UTC
auto deploy bundles after starting dependencies
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?
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?
Any tips appreciated,
Andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: auto deploy bundles after starting dependencies
Posted by Andrew Williams <an...@handyande.co.uk>.
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: users-unsubscribe@felix.apache.org
>>>> For additional commands, e-mail: users-help@felix.apache.org
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: auto deploy bundles after starting dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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: users-unsubscribe@felix.apache.org
>>> For additional commands, e-mail: users-help@felix.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: auto deploy bundles after starting dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
-> 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: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: auto deploy bundles after starting dependencies
Posted by "Richard S. Hall" <he...@ungoverned.org>.
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.
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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org