cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Angelo zerr <angelo.z...@gmail.com>
Subject Re: How to avoid hard-coded the "endpoint.id" for DOSGI client?
Date Wed, 21 Mar 2012 12:37:10 GMT
Hi Sergey,

Many thanks for your answer. I think I will use REST client to consume my
DOSGi exported on server side.

I find it's shame endpoint-descriptions xmlns="
http://www.osgi.org/xmlns/rsa/v1.0.0" cannot be configured by a properties
file or another mean.
URL server depends on where OSGI bundles are deployed, so I think it's a
bad idea to set the URL in the XML descriptor. If we have a lot of services
you must change URLs for each endpoint-descriptions?

Regards Angelo

Le 19 mars 2012 23:27, Sergey Beryozkin <sberyozkin@gmail.com> a écrit :

> Hi
>
> On 15/03/12 14:00, Angelo zerr wrote:
>
>> Hi,
>>
>> I would like use CXF- DOSGi in our Eclipse RCP/RAP XDocReport application
>> http://xdocreport-rap.**opensagres.cloudbees.net/**xdocreport?startup=fr.
>> **opensagres.xdocreport.eclipse.**ui.applicationto<http://xdocreport-rap.opensagres.cloudbees.net/xdocreport?startup=fr.opensagres.xdocreport.eclipse.ui.applicationto>
>> manage too Eclispe RCP which calls services with remoting.
>> We have started that and for Server side it's OK (we espose our services
>> with REST). But for client I have a question about the URL (endpoint.id)
>> :
>>
>> If I follow the docs
>> http://cxf.apache.org/dosgi-**spring-dm-demo-page.htmlwe<http://cxf.apache.org/dosgi-spring-dm-demo-page.htmlwe>must
write this
>>
>> XML file:
>>
>> ------------------------------**----------------------------
>> <endpoint-descriptions xmlns="http://www.osgi.org/**xmlns/rsa/v1.0.0<http://www.osgi.org/xmlns/rsa/v1.0.0>
>> ">
>>
>>   <endpoint-description>
>>     <property name="objectClass">
>>       <array>
>>
>>         <value>org.apache.cxf.dosgi.**samples.springdm.**
>> DinnerService</value>
>>       </array>
>>     </property>
>>
>>     <property name="endpoint.id">http://**localhost:9000/org/apache/cxf/*
>> *dosgi/samples/springdm/**DinnerService<http://localhost:9000/org/apache/cxf/dosgi/samples/springdm/DinnerService>
>> </property>
>>
>>     <property name="service.imported.**configs">org.apache.cxf.rs
>> <http://org.apache.cxf.ws></**property>
>>
>>
>>   </endpoint-description>
>> </endpoint-descriptions>
>> ------------------------------**----------------------------
>>
>> My problem is that URL is hard coded in the XML file:
>>
>> ------------------------------**----------------------------
>> <property name="endpoint.id">http://**localhost:9000/org/apache/cxf/**
>> dosgi/samples/springdm/**DinnerService<http://localhost:9000/org/apache/cxf/dosgi/samples/springdm/DinnerService>
>> </property>
>>
>> ------------------------------**----------------------------
>>
>> I would like avoid to hard-coded the base URL "http://localhost:9000"
>> for each services that I expose. This URL depends on where the
>> services are deployed.
>>
>> My question is : exists it a solution to set the base URL in a properties
>> file?
>>
>>
> The DOSGi solution is to use the Zookeeper-based Discovery mechanism.
> However, I'm wondering, if the host/port is known at the build time then
> may this resource can be simply filtered at the build time ?
>
> By the way, there could be the way to use Declarative Services to enable
> the DOSGi client proxies, judging by this unresolved JIRA issue reported by
> David :-)
> https://issues.apache.org/**jira/browse/DOSGI-73<https://issues.apache.org/jira/browse/DOSGI-73>
>
>
>
>  If it's not possible, I thugh I could use jaxrs:client and benefits
>> from the Spring EL to set the base URL.
>>
>> ------------------------------**----------------------------
>> <jaxrs:client id="restClient"
>>          address="${baseURL}/test/**services/rest"
>>          serviceClass="org.apache.cxf.**dosgi.samples.springdm.**
>> DinnerService"
>>          inheritHeaders="true">
>>   </jaxrs:client>
>> ------------------------------**----------------------------
>>
>>  This will bypass the DOSGI client runtime...But may be it can be
> acceptable for your project ?
>
> Thanks, Sergey
>
>
>  Many thanks for your help.
>>
>> Regards Angelo
>>
>>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message