distributed OSGi questions

[John Stump]

We have an iPOJO-based web service working using the DOSGi stuff. After finally getting it working, a couple questions arise:

1)    Why can't the properties specified in OSGI-INF/remote-service/remote-services.xml simply be service properties of the bundle? With the web service connection properties buried deep inside a bundle like this, it is impractical to modify these values after the bundle is deployed. Essentially, these values are "hard-coded". Short of using the Zookeeper discovery services, is there any way to have configurable web service settings?

2)    Using iPOJO I tried to use a filter on my @Requires to select a service based on the value of a service property, but this doesn't seem to work for distributed services. Is there any way around this?

Thanks!

John stump
Senior Software Engineer
NAVSYS Corporation
14960 Woodcarver Road
Colorado Springs, CO 80921

The information contained herein is confidential and intended solely for the use of the addressees. If the reader is not the intended recipient, you are hereby notified that any distribution or copying of this communication is prohibited. Further distribution without the sender's approval is also prohibited.  If you have received this communication in error, please notify us immediately by replying to the message and deleting it entirely from your computer. Thank you. NAVSYS Corporation.

[clement escoffier]

Hi,

I cannot really help on 1), maybe an API is provided to configure  
imported services.

For 2), there is no reason the filters do not work. iPOJO filter are  
just plain LDAP filter. The only things is the used service hooks  
(used by DOSGi). But it should be completely transparent.

I will investigate that deeper.

Regards,

Clement

On 30.10.2009, at 18:30, John Stump wrote:

> We have an iPOJO-based web service working using the DOSGi stuff.  
> After finally getting it working, a couple questions arise:
>
> 1)    Why can't the properties specified in OSGI-INF/remote-service/
> remote-services.xml simply be service properties of the bundle? With  
> the web service connection properties buried deep inside a bundle  
> like this, it is impractical to modify these values after the bundle  
> is deployed. Essentially, these values are "hard-coded". Short of  
> using the Zookeeper discovery services, is there any way to have  
> configurable web service settings?
>
> 2)    Using iPOJO I tried to use a filter on my @Requires to select  
> a service based on the value of a service property, but this doesn't  
> seem to work for distributed services. Is there any way around this?
>
> Thanks!
>
> John stump
> Senior Software Engineer
> NAVSYS Corporation
> 14960 Woodcarver Road
> Colorado Springs, CO 80921
>
> The information contained herein is confidential and intended solely  
> for the use of the addressees. If the reader is not the intended  
> recipient, you are hereby notified that any distribution or copying  
> of this communication is prohibited. Further distribution without  
> the sender's approval is also prohibited.  If you have received this  
> communication in error, please notify us immediately by replying to  
> the message and deleting it entirely from your computer. Thank you.  
> NAVSYS Corporation.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[clement escoffier]

Hi,

I try to used a required filter on an imported service, and it has  
worked.
Well, my filter was quite simple : (service.imported=true) but the  
service is correctly injected.

Here is the result. The instance required twice the same remote  
service. The first requirement is not filtered (only based on the  
specification). The second used a filter... Both are injected.

Specification de.akquinet.gomobile.dynamokos.prediction.Prediction
Id de.akquinet.gomobile.dynamokos.prediction.Prediction
State resolved
Binding Policy dynamic
Optional false
Aggregate false
Matching Services

     * 48

Used Services

Specification de.akquinet.gomobile.dynamokos.prediction.Prediction
Id Prediction
State resolved
Binding Policy dynamic
Optional true
Aggregate false
Filter (service.imported=true)
Matching Services

     * 48

Used Services

Could you explain me in which case the filter does not work on a  
remote service ?

Regards,

Clement

BTW, I'm not sure that remote service properties are propagated.

On 30.10.2009, at 18:30, John Stump wrote:

> We have an iPOJO-based web service working using the DOSGi stuff.  
> After finally getting it working, a couple questions arise:
>
> 1)    Why can't the properties specified in OSGI-INF/remote-service/
> remote-services.xml simply be service properties of the bundle? With  
> the web service connection properties buried deep inside a bundle  
> like this, it is impractical to modify these values after the bundle  
> is deployed. Essentially, these values are "hard-coded". Short of  
> using the Zookeeper discovery services, is there any way to have  
> configurable web service settings?
>
> 2)    Using iPOJO I tried to use a filter on my @Requires to select  
> a service based on the value of a service property, but this doesn't  
> seem to work for distributed services. Is there any way around this?
>
> Thanks!
>
> John stump
> Senior Software Engineer
> NAVSYS Corporation
> 14960 Woodcarver Road
> Colorado Springs, CO 80921
>
> The information contained herein is confidential and intended solely  
> for the use of the addressees. If the reader is not the intended  
> recipient, you are hereby notified that any distribution or copying  
> of this communication is prohibited. Further distribution without  
> the sender's approval is also prohibited.  If you have received this  
> communication in error, please notify us immediately by replying to  
> the message and deleting it entirely from your computer. Thank you.  
> NAVSYS Corporation.
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[John Stump]

My requires looks like this:

@Requires(filter="(name=web_service)", optional=true, nullable=false)
MyInterface my;

With the filter in place, my will be null. If I take out the filter,  
my is correctly assigned to the remote service.

The remote service does have a service property called name assigned  
to "web_service".

J

On Oct 31, 2009, at 9:46 AM, "Clement Escoffier" <clement.escoffier@...
 > wrote:

> Hi,
>
> I try to used a required filter on an imported service, and it has
> worked.
> Well, my filter was quite simple : (service.imported=true) but the
> service is correctly injected.
>
> Here is the result. The instance required twice the same remote
> service. The first requirement is not filtered (only based on the
> specification). The second used a filter... Both are injected.
>
> Specification    de.akquinet.gomobile.dynamokos.prediction.Prediction
> Id    de.akquinet.gomobile.dynamokos.prediction.Prediction
> State    resolved
> Binding Policy    dynamic
> Optional    false
> Aggregate    false
> Matching Services
>
>     * 48
>
> Used Services
>
> Specification    de.akquinet.gomobile.dynamokos.prediction.Prediction
> Id    Prediction
> State    resolved
> Binding Policy    dynamic
> Optional    true
> Aggregate    false
> Filter    (service.imported=true)
> Matching Services
>
>     * 48
>
> Used Services
>
> Could you explain me in which case the filter does not work on a
> remote service ?
>
> Regards,
>
> Clement
>
> BTW, I'm not sure that remote service properties are propagated.
>
> On 30.10.2009, at 18:30, John Stump wrote:
>
>> We have an iPOJO-based web service working using the DOSGi stuff.
>> After finally getting it working, a couple questions arise:
>>
>> 1)    Why can't the properties specified in OSGI-INF/remote-service/
>> remote-services.xml simply be service properties of the bundle? With
>> the web service connection properties buried deep inside a bundle
>> like this, it is impractical to modify these values after the bundle
>> is deployed. Essentially, these values are "hard-coded". Short of
>> using the Zookeeper discovery services, is there any way to have
>> configurable web service settings?
>>
>> 2)    Using iPOJO I tried to use a filter on my @Requires to select
>> a service based on the value of a service property, but this doesn't
>> seem to work for distributed services. Is there any way around this?
>>
>> Thanks!
>>
>> John stump
>> Senior Software Engineer
>> NAVSYS Corporation
>> 14960 Woodcarver Road
>> Colorado Springs, CO 80921
>>
>> The information contained herein is confidential and intended solely
>> for the use of the addressees. If the reader is not the intended
>> recipient, you are hereby notified that any distribution or copying
>> of this communication is prohibited. Further distribution without
>> the sender's approval is also prohibited.  If you have received this
>> communication in error, please notify us immediately by replying to
>> the message and deleting it entirely from your computer. Thank you.
>> NAVSYS Corporation.
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[clement escoffier]

On 31.10.2009, at 17:52, John Stump wrote:

> My requires looks like this:
>
> @Requires(filter="(name=web_service)", optional=true, nullable=false)
> MyInterface my;
>
> With the filter in place, my will be null. If I take out the filter,
> my is correctly assigned to the remote service.
>
> The remote service does have a service property called name assigned
> to "web_service".

Well, it's what I feared. Service properties are not propagated by  
DOSGi. So, if the exported service as a service property, this  
property will be not propagated to the 'proxy'.

Your implementation exposed the service property, but on the importer  
side, this property is not there.
For exemple, imagine that I export this service:

component = de.akquinet.gomobile.dynamokos.oracle.Oracle
factory.name = de.akquinet.gomobile.dynamokos.oracle.Oracle
instance.name = de.akquinet.gomobile.dynamokos.oracle.Oracle-0
myProp = this is a remote service   <-- service property
objectClass = de.akquinet.gomobile.dynamokos.prediction.Prediction
osgi.remote.configuration.pojo.address = http://localhost:9090/oracle
osgi.remote.configuration.type = org.apache.cxf.ws
osgi.remote.interfaces = *
service.id = 52

(I got this thanks to the inspect command of Felix (felix s p x where  
x the bundle id)).


On the importer side...
objectClass = de.akquinet.gomobile.dynamokos.prediction.Prediction
org.apache.cxf.remote.dsw.client = Distributed OSGi Distribution  
Software Single-Bundle Distribution, version : 1.1.0.SNAPSHOT
org.apache.cxf.ws.address = http://localhost:9090/oracle
osgi.remote.endpoint.id = 6874d604-c944-4020-998b-c14b23ed340e
osgi.remote.service.interfaces = <unknown value type>
service.id = 48
service.imported = true
service.imported.configs = org.apache.cxf.ws


The service is there, but the service property 'myProp' is not there...


Regards,

Clement

>
> J
>
> On Oct 31, 2009, at 9:46 AM, "Clement Escoffier" <clement.escoffier@...
>> wrote:
>
>> Hi,
>>
>> I try to used a required filter on an imported service, and it has
>> worked.
>> Well, my filter was quite simple : (service.imported=true) but the
>> service is correctly injected.
>>
>> Here is the result. The instance required twice the same remote
>> service. The first requirement is not filtered (only based on the
>> specification). The second used a filter... Both are injected.
>>
>> Specification    de.akquinet.gomobile.dynamokos.prediction.Prediction
>> Id    de.akquinet.gomobile.dynamokos.prediction.Prediction
>> State    resolved
>> Binding Policy    dynamic
>> Optional    false
>> Aggregate    false
>> Matching Services
>>
>>    * 48
>>
>> Used Services
>>
>> Specification    de.akquinet.gomobile.dynamokos.prediction.Prediction
>> Id    Prediction
>> State    resolved
>> Binding Policy    dynamic
>> Optional    true
>> Aggregate    false
>> Filter    (service.imported=true)
>> Matching Services
>>
>>    * 48
>>
>> Used Services
>>
>> Could you explain me in which case the filter does not work on a
>> remote service ?
>>
>> Regards,
>>
>> Clement
>>
>> BTW, I'm not sure that remote service properties are propagated.
>>
>> On 30.10.2009, at 18:30, John Stump wrote:
>>
>>> We have an iPOJO-based web service working using the DOSGi stuff.
>>> After finally getting it working, a couple questions arise:
>>>
>>> 1)    Why can't the properties specified in OSGI-INF/remote-service/
>>> remote-services.xml simply be service properties of the bundle? With
>>> the web service connection properties buried deep inside a bundle
>>> like this, it is impractical to modify these values after the bundle
>>> is deployed. Essentially, these values are "hard-coded". Short of
>>> using the Zookeeper discovery services, is there any way to have
>>> configurable web service settings?
>>>
>>> 2)    Using iPOJO I tried to use a filter on my @Requires to select
>>> a service based on the value of a service property, but this doesn't
>>> seem to work for distributed services. Is there any way around this?
>>>
>>> Thanks!
>>>
>>> John stump
>>> Senior Software Engineer
>>> NAVSYS Corporation
>>> 14960 Woodcarver Road
>>> Colorado Springs, CO 80921
>>>
>>> The information contained herein is confidential and intended solely
>>> for the use of the addressees. If the reader is not the intended
>>> recipient, you are hereby notified that any distribution or copying
>>> of this communication is prohibited. Further distribution without
>>> the sender's approval is also prohibited.  If you have received this
>>> communication in error, please notify us immediately by replying to
>>> the message and deleting it entirely from your computer. Thank you.
>>> NAVSYS Corporation.
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[David Bosschaert]

If you use the remote-services.xml approach, you have to list all the
properties to be applied to the proxy in that remote-service.xml file.
If you use a real discovery system (e.g. the zookeeper one) all the service
properties should be sent across automatically.

On the question about embedding the remote-service.xml in a bundle... It
doesn't have to reside in the client bundle, you can put this file in any
bundle, so one way to give you flexibility is to put this file in a bundle
of its own, a proxy configuration bundle if you like. That way you don't
need to change your client bundle if your proxy configuration changes.

Hope this helps,

David


2009/10/31 Clement Escoffier <clement.escoffier@...>

>
> On 31.10.2009, at 17:52, John Stump wrote:
>
>  My requires looks like this:
>>
>> @Requires(filter="(name=web_service)", optional=true, nullable=false)
>> MyInterface my;
>>
>> With the filter in place, my will be null. If I take out the filter,
>> my is correctly assigned to the remote service.
>>
>> The remote service does have a service property called name assigned
>> to "web_service".
>>
>
> Well, it's what I feared. Service properties are not propagated by DOSGi.
> So, if the exported service as a service property, this property will be not
> propagated to the 'proxy'.
>
> Your implementation exposed the service property, but on the importer side,
> this property is not there.
> For exemple, imagine that I export this service:
>
> component = de.akquinet.gomobile.dynamokos.oracle.Oracle
> factory.name = de.akquinet.gomobile.dynamokos.oracle.Oracle
> instance.name = de.akquinet.gomobile.dynamokos.oracle.Oracle-0
> myProp = this is a remote service   <-- service property
> objectClass = de.akquinet.gomobile.dynamokos.prediction.Prediction
> osgi.remote.configuration.pojo.address = http://localhost:9090/oracle
> osgi.remote.configuration.type = org.apache.cxf.ws
> osgi.remote.interfaces = *
> service.id = 52
>
> (I got this thanks to the inspect command of Felix (felix s p x where x the
> bundle id)).
>
>
> On the importer side...
> objectClass = de.akquinet.gomobile.dynamokos.prediction.Prediction
> org.apache.cxf.remote.dsw.client = Distributed OSGi Distribution Software
> Single-Bundle Distribution, version : 1.1.0.SNAPSHOT
> org.apache.cxf.ws.address = http://localhost:9090/oracle
> osgi.remote.endpoint.id = 6874d604-c944-4020-998b-c14b23ed340e
> osgi.remote.service.interfaces = <unknown value type>
> service.id = 48
> service.imported = true
> service.imported.configs = org.apache.cxf.ws
>
>
> The service is there, but the service property 'myProp' is not there...
>
>
> Regards,
>
> Clement
>
>
>
>
>> J
>>
>> On Oct 31, 2009, at 9:46 AM, "Clement Escoffier" <
>> clement.escoffier@...
>>
>>> wrote:
>>>
>>
>>  Hi,
>>>
>>> I try to used a required filter on an imported service, and it has
>>> worked.
>>> Well, my filter was quite simple : (service.imported=true) but the
>>> service is correctly injected.
>>>
>>> Here is the result. The instance required twice the same remote
>>> service. The first requirement is not filtered (only based on the
>>> specification). The second used a filter... Both are injected.
>>>
>>> Specification    de.akquinet.gomobile.dynamokos.prediction.Prediction
>>> Id    de.akquinet.gomobile.dynamokos.prediction.Prediction
>>> State    resolved
>>> Binding Policy    dynamic
>>> Optional    false
>>> Aggregate    false
>>> Matching Services
>>>
>>>   * 48
>>>
>>> Used Services
>>>
>>> Specification    de.akquinet.gomobile.dynamokos.prediction.Prediction
>>> Id    Prediction
>>> State    resolved
>>> Binding Policy    dynamic
>>> Optional    true
>>> Aggregate    false
>>> Filter    (service.imported=true)
>>> Matching Services
>>>
>>>   * 48
>>>
>>> Used Services
>>>
>>> Could you explain me in which case the filter does not work on a
>>> remote service ?
>>>
>>> Regards,
>>>
>>> Clement
>>>
>>> BTW, I'm not sure that remote service properties are propagated.
>>>
>>> On 30.10.2009, at 18:30, John Stump wrote:
>>>
>>>  We have an iPOJO-based web service working using the DOSGi stuff.
>>>> After finally getting it working, a couple questions arise:
>>>>
>>>> 1)    Why can't the properties specified in OSGI-INF/remote-service/
>>>> remote-services.xml simply be service properties of the bundle? With
>>>> the web service connection properties buried deep inside a bundle
>>>> like this, it is impractical to modify these values after the bundle
>>>> is deployed. Essentially, these values are "hard-coded". Short of
>>>> using the Zookeeper discovery services, is there any way to have
>>>> configurable web service settings?
>>>>
>>>> 2)    Using iPOJO I tried to use a filter on my @Requires to select
>>>> a service based on the value of a service property, but this doesn't
>>>> seem to work for distributed services. Is there any way around this?
>>>>
>>>> Thanks!
>>>>
>>>> John stump
>>>> Senior Software Engineer
>>>> NAVSYS Corporation
>>>> 14960 Woodcarver Road
>>>> Colorado Springs, CO 80921
>>>>
>>>> The information contained herein is confidential and intended solely
>>>> for the use of the addressees. If the reader is not the intended
>>>> recipient, you are hereby notified that any distribution or copying
>>>> of this communication is prohibited. Further distribution without
>>>> the sender's approval is also prohibited.  If you have received this
>>>> communication in error, please notify us immediately by replying to
>>>> the message and deleting it entirely from your computer. Thank you.
>>>> NAVSYS Corporation.
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[clement escoffier]

Hi,


On 01.11.2009, at 16:50, David Bosschaert wrote:

> If you use the remote-services.xml approach, you have to list all the
> properties to be applied to the proxy in that remote-service.xml file.
> If you use a real discovery system (e.g. the zookeeper one) all the  
> service
> properties should be sent across automatically.

Cool, I was not aware about the list of properties inside the XML files.

>
> On the question about embedding the remote-service.xml in a  
> bundle... It
> doesn't have to reside in the client bundle, you can put this file  
> in any
> bundle, so one way to give you flexibility is to put this file in a  
> bundle
> of its own, a proxy configuration bundle if you like. That way you  
> don't
> need to change your client bundle if your proxy configuration changes.

As far as I understand, I think that Johan is looking for another way  
to import service which is neither based on XML files nor on  
discovery. (Something like an API). But, I may be completely wring :-)

Clement

>
> Hope this helps,
>
> David
>
>
> 2009/10/31 Clement Escoffier <clement.escoffier@...>
>
>>
>> On 31.10.2009, at 17:52, John Stump wrote:
>>
>> My requires looks like this:
>>>
>>> @Requires(filter="(name=web_service)", optional=true,  
>>> nullable=false)
>>> MyInterface my;
>>>
>>> With the filter in place, my will be null. If I take out the filter,
>>> my is correctly assigned to the remote service.
>>>
>>> The remote service does have a service property called name assigned
>>> to "web_service".
>>>
>>
>> Well, it's what I feared. Service properties are not propagated by  
>> DOSGi.
>> So, if the exported service as a service property, this property  
>> will be not
>> propagated to the 'proxy'.
>>
>> Your implementation exposed the service property, but on the  
>> importer side,
>> this property is not there.
>> For exemple, imagine that I export this service:
>>
>> component = de.akquinet.gomobile.dynamokos.oracle.Oracle
>> factory.name = de.akquinet.gomobile.dynamokos.oracle.Oracle
>> instance.name = de.akquinet.gomobile.dynamokos.oracle.Oracle-0
>> myProp = this is a remote service   <-- service property
>> objectClass = de.akquinet.gomobile.dynamokos.prediction.Prediction
>> osgi.remote.configuration.pojo.address = http://localhost:9090/oracle
>> osgi.remote.configuration.type = org.apache.cxf.ws
>> osgi.remote.interfaces = *
>> service.id = 52
>>
>> (I got this thanks to the inspect command of Felix (felix s p x  
>> where x the
>> bundle id)).
>>
>>
>> On the importer side...
>> objectClass = de.akquinet.gomobile.dynamokos.prediction.Prediction
>> org.apache.cxf.remote.dsw.client = Distributed OSGi Distribution  
>> Software
>> Single-Bundle Distribution, version : 1.1.0.SNAPSHOT
>> org.apache.cxf.ws.address = http://localhost:9090/oracle
>> osgi.remote.endpoint.id = 6874d604-c944-4020-998b-c14b23ed340e
>> osgi.remote.service.interfaces = <unknown value type>
>> service.id = 48
>> service.imported = true
>> service.imported.configs = org.apache.cxf.ws
>>
>>
>> The service is there, but the service property 'myProp' is not  
>> there...
>>
>>
>> Regards,
>>
>> Clement
>>
>>
>>
>>
>>> J
>>>
>>> On Oct 31, 2009, at 9:46 AM, "Clement Escoffier" <
>>> clement.escoffier@...
>>>
>>>> wrote:
>>>>
>>>
>>> Hi,
>>>>
>>>> I try to used a required filter on an imported service, and it has
>>>> worked.
>>>> Well, my filter was quite simple : (service.imported=true) but the
>>>> service is correctly injected.
>>>>
>>>> Here is the result. The instance required twice the same remote
>>>> service. The first requirement is not filtered (only based on the
>>>> specification). The second used a filter... Both are injected.
>>>>
>>>> Specification    
>>>> de.akquinet.gomobile.dynamokos.prediction.Prediction
>>>> Id    de.akquinet.gomobile.dynamokos.prediction.Prediction
>>>> State    resolved
>>>> Binding Policy    dynamic
>>>> Optional    false
>>>> Aggregate    false
>>>> Matching Services
>>>>
>>>>  * 48
>>>>
>>>> Used Services
>>>>
>>>> Specification    
>>>> de.akquinet.gomobile.dynamokos.prediction.Prediction
>>>> Id    Prediction
>>>> State    resolved
>>>> Binding Policy    dynamic
>>>> Optional    true
>>>> Aggregate    false
>>>> Filter    (service.imported=true)
>>>> Matching Services
>>>>
>>>>  * 48
>>>>
>>>> Used Services
>>>>
>>>> Could you explain me in which case the filter does not work on a
>>>> remote service ?
>>>>
>>>> Regards,
>>>>
>>>> Clement
>>>>
>>>> BTW, I'm not sure that remote service properties are propagated.
>>>>
>>>> On 30.10.2009, at 18:30, John Stump wrote:
>>>>
>>>> We have an iPOJO-based web service working using the DOSGi stuff.
>>>>> After finally getting it working, a couple questions arise:
>>>>>
>>>>> 1)    Why can't the properties specified in OSGI-INF/remote-
>>>>> service/
>>>>> remote-services.xml simply be service properties of the bundle?  
>>>>> With
>>>>> the web service connection properties buried deep inside a bundle
>>>>> like this, it is impractical to modify these values after the  
>>>>> bundle
>>>>> is deployed. Essentially, these values are "hard-coded". Short of
>>>>> using the Zookeeper discovery services, is there any way to have
>>>>> configurable web service settings?
>>>>>
>>>>> 2)    Using iPOJO I tried to use a filter on my @Requires to  
>>>>> select
>>>>> a service based on the value of a service property, but this  
>>>>> doesn't
>>>>> seem to work for distributed services. Is there any way around  
>>>>> this?
>>>>>
>>>>> Thanks!
>>>>>
>>>>> John stump
>>>>> Senior Software Engineer
>>>>> NAVSYS Corporation
>>>>> 14960 Woodcarver Road
>>>>> Colorado Springs, CO 80921
>>>>>
>>>>> The information contained herein is confidential and intended  
>>>>> solely
>>>>> for the use of the addressees. If the reader is not the intended
>>>>> recipient, you are hereby notified that any distribution or  
>>>>> copying
>>>>> of this communication is prohibited. Further distribution without
>>>>> the sender's approval is also prohibited.  If you have received  
>>>>> this
>>>>> communication in error, please notify us immediately by replying  
>>>>> to
>>>>> the message and deleting it entirely from your computer. Thank  
>>>>> you.
>>>>> NAVSYS Corporation.
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@...
>>>> For additional commands, e-mail: users-help@...
>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

You might not have to include it in the one bundle... but then you have CM issues with an entirely different bundle which actually makes the problem that much worse. Embedding it in a different bundle doesn't get around the configuration issues... it just moves them.

The DOSGi does use the service properties on the service side to expose any particular service as a web service just by including the osgi.remote.configuration.type & such as service properties. In the iPojo world these can be run-time configured in conjunction with FileInstaller in a simple cfg name=value properties file. This makes it much simpler to CM and then distribute and change from one run to the next. I wish that DOSGi would work exactly the same way on the client side when using the service. It just seems odd that it would be inconsistent.

- Joel

________________________________________
From: David Bosschaert [david.bosschaert@...]
Sent: Sunday, November 01, 2009 8:50 AM
To: users@...
Subject: Re: distributed OSGi questions

If you use the remote-services.xml approach, you have to list all the
properties to be applied to the proxy in that remote-service.xml file.
If you use a real discovery system (e.g. the zookeeper one) all the service
properties should be sent across automatically.

On the question about embedding the remote-service.xml in a bundle... It
doesn't have to reside in the client bundle, you can put this file in any
bundle, so one way to give you flexibility is to put this file in a bundle
of its own, a proxy configuration bundle if you like. That way you don't
need to change your client bundle if your proxy configuration changes.

Hope this helps,

David


2009/10/31 Clement Escoffier <clement.escoffier@...>

>
> On 31.10.2009, at 17:52, John Stump wrote:
>
>  My requires looks like this:
>>
>> @Requires(filter="(name=web_service)", optional=true, nullable=false)
>> MyInterface my;
>>
>> With the filter in place, my will be null. If I take out the filter,
>> my is correctly assigned to the remote service.
>>
>> The remote service does have a service property called name assigned
>> to "web_service".
>>
>
> Well, it's what I feared. Service properties are not propagated by DOSGi.
> So, if the exported service as a service property, this property will be not
> propagated to the 'proxy'.
>
> Your implementation exposed the service property, but on the importer side,
> this property is not there.
> For exemple, imagine that I export this service:
>
> component = de.akquinet.gomobile.dynamokos.oracle.Oracle
> factory.name = de.akquinet.gomobile.dynamokos.oracle.Oracle
> instance.name = de.akquinet.gomobile.dynamokos.oracle.Oracle-0
> myProp = this is a remote service   <-- service property
> objectClass = de.akquinet.gomobile.dynamokos.prediction.Prediction
> osgi.remote.configuration.pojo.address = http://localhost:9090/oracle
> osgi.remote.configuration.type = org.apache.cxf.ws
> osgi.remote.interfaces = *
> service.id = 52
>
> (I got this thanks to the inspect command of Felix (felix s p x where x the
> bundle id)).
>
>
> On the importer side...
> objectClass = de.akquinet.gomobile.dynamokos.prediction.Prediction
> org.apache.cxf.remote.dsw.client = Distributed OSGi Distribution Software
> Single-Bundle Distribution, version : 1.1.0.SNAPSHOT
> org.apache.cxf.ws.address = http://localhost:9090/oracle
> osgi.remote.endpoint.id = 6874d604-c944-4020-998b-c14b23ed340e
> osgi.remote.service.interfaces = <unknown value type>
> service.id = 48
> service.imported = true
> service.imported.configs = org.apache.cxf.ws
>
>
> The service is there, but the service property 'myProp' is not there...
>
>
> Regards,
>
> Clement
>
>
>
>
>> J
>>
>> On Oct 31, 2009, at 9:46 AM, "Clement Escoffier" <
>> clement.escoffier@...
>>
>>> wrote:
>>>
>>
>>  Hi,
>>>
>>> I try to used a required filter on an imported service, and it has
>>> worked.
>>> Well, my filter was quite simple : (service.imported=true) but the
>>> service is correctly injected.
>>>
>>> Here is the result. The instance required twice the same remote
>>> service. The first requirement is not filtered (only based on the
>>> specification). The second used a filter... Both are injected.
>>>
>>> Specification    de.akquinet.gomobile.dynamokos.prediction.Prediction
>>> Id    de.akquinet.gomobile.dynamokos.prediction.Prediction
>>> State    resolved
>>> Binding Policy    dynamic
>>> Optional    false
>>> Aggregate    false
>>> Matching Services
>>>
>>>   * 48
>>>
>>> Used Services
>>>
>>> Specification    de.akquinet.gomobile.dynamokos.prediction.Prediction
>>> Id    Prediction
>>> State    resolved
>>> Binding Policy    dynamic
>>> Optional    true
>>> Aggregate    false
>>> Filter    (service.imported=true)
>>> Matching Services
>>>
>>>   * 48
>>>
>>> Used Services
>>>
>>> Could you explain me in which case the filter does not work on a
>>> remote service ?
>>>
>>> Regards,
>>>
>>> Clement
>>>
>>> BTW, I'm not sure that remote service properties are propagated.
>>>
>>> On 30.10.2009, at 18:30, John Stump wrote:
>>>
>>>  We have an iPOJO-based web service working using the DOSGi stuff.
>>>> After finally getting it working, a couple questions arise:
>>>>
>>>> 1)    Why can't the properties specified in OSGI-INF/remote-service/
>>>> remote-services.xml simply be service properties of the bundle? With
>>>> the web service connection properties buried deep inside a bundle
>>>> like this, it is impractical to modify these values after the bundle
>>>> is deployed. Essentially, these values are "hard-coded". Short of
>>>> using the Zookeeper discovery services, is there any way to have
>>>> configurable web service settings?
>>>>
>>>> 2)    Using iPOJO I tried to use a filter on my @Requires to select
>>>> a service based on the value of a service property, but this doesn't
>>>> seem to work for distributed services. Is there any way around this?
>>>>
>>>> Thanks!
>>>>
>>>> John stump
>>>> Senior Software Engineer
>>>> NAVSYS Corporation
>>>> 14960 Woodcarver Road
>>>> Colorado Springs, CO 80921
>>>>
>>>> The information contained herein is confidential and intended solely
>>>> for the use of the addressees. If the reader is not the intended
>>>> recipient, you are hereby notified that any distribution or copying
>>>> of this communication is prohibited. Further distribution without
>>>> the sender's approval is also prohibited.  If you have received this
>>>> communication in error, please notify us immediately by replying to
>>>> the message and deleting it entirely from your computer. Thank you.
>>>> NAVSYS Corporation.
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[David Bosschaert]

Hi Joel,

2009/11/2 Joel Schuster <joels@...>

> You might not have to include it in the one bundle... but then you have CM
> issues with an entirely different bundle which actually makes the problem
> that much worse. Embedding it in a different bundle doesn't get around the
> configuration issues... it just moves them.
>

Well, the idea is that this other bundle could effectively just be a
configuration file. Granted, it's packaged as a bundle, but you could make
it such that it only contains a config file. I would think that this does
have some extra benefits as it would only have to exist for the deployer...

>
> The DOSGi does use the service properties on the service side to expose any
> particular service as a web service just by including the
> osgi.remote.configuration.type & such as service properties. In the iPojo
> world these can be run-time configured in conjunction with FileInstaller in
> a simple cfg name=value properties file. This makes it much simpler to CM
> and then distribute and change from one run to the next. I wish that DOSGi
> would work exactly the same way on the client side when using the service.
> It just seems odd that it would be inconsistent.
>
> - Joel
>

I'm not sure how you could take the exact same approach on the client side.
Would you manually create a service on the client side that represents the
client proxy and then expect the DOSGi implementation to use that? That
would be quite tricky.
One idea that we did actually support somewhat in CXF-DOSGi is to configure
your client side oroxies using the OSGi Config Admin Service. I'm not sure
how well this works today, but it certainly makes sense to me. If you think
it would be worth pursuing that, please file an enhancement bug for it.

And again, if you use a Discovery system like the Zookeeper-based one that
comes with CXF-DOSGi, none of these problems should exist. Your remote
service will just appear on the client side with all its properties through
the Discovery system...

Cheers,

David

Yeah, zookeeper sounds like it's a good way to go. And it seems that zookeeper itself can now also an osgi bundle: http://issues.apache.org/jira/browse/ZOOKEEPER-425

It's kind of a chicken an egg issue. You have to have zookeeper running out on the network somewhere in some osgi context, then you have to configure the connector/discovery bundle elsewhere to point to where it's running.

Luckily the zookeeper discovery bundle can be configured via fileinstall cfg file/config admin unlike clients. So this would solve some of the problem.

Thanks!

- Joel

> -----Original Message-----
> From: David Bosschaert [mailto:david.bosschaert@...]
> Sent: Monday, November 02, 2009 4:55 AM
> To: users@...
> Subject: Re: distributed OSGi questions
>
> Hi Joel,
>
> 2009/11/2 Joel Schuster <joels@...>
>
> > You might not have to include it in the one bundle... but then you have
> CM
> > issues with an entirely different bundle which actually makes the
> problem
> > that much worse. Embedding it in a different bundle doesn't get around
> the
> > configuration issues... it just moves them.
> >
>
> Well, the idea is that this other bundle could effectively just be a
> configuration file. Granted, it's packaged as a bundle, but you could make
> it such that it only contains a config file. I would think that this does
> have some extra benefits as it would only have to exist for the
> deployer...
>
>
>
> >
> > The DOSGi does use the service properties on the service side to expose
> any
> > particular service as a web service just by including the
> > osgi.remote.configuration.type & such as service properties. In the
> iPojo
> > world these can be run-time configured in conjunction with FileInstaller
> in
> > a simple cfg name=value properties file. This makes it much simpler to
> CM
> > and then distribute and change from one run to the next. I wish that
> DOSGi
> > would work exactly the same way on the client side when using the
> service.
> > It just seems odd that it would be inconsistent.
> >
> > - Joel
> >
>
> I'm not sure how you could take the exact same approach on the client
> side.
> Would you manually create a service on the client side that represents the
> client proxy and then expect the DOSGi implementation to use that? That
> would be quite tricky.
> One idea that we did actually support somewhat in CXF-DOSGi is to
> configure
> your client side oroxies using the OSGi Config Admin Service. I'm not sure
> how well this works today, but it certainly makes sense to me. If you
> think
> it would be worth pursuing that, please file an enhancement bug for it.
>
> And again, if you use a Discovery system like the Zookeeper-based one that
> comes with CXF-DOSGi, none of these problems should exist. Your remote
> service will just appear on the client side with all its properties
> through
> the Discovery system...
>
> Cheers,
>
> David

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...