|
| Re: Remote service registration using OSGi Blueprint [message #528037 is a reply to message #527930] |
Mon, 19 April 2010 02:25  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Raj,
Raj Saini wrote:
> Hi,
>
> I have been looking for some example/samples to register remove services
> using OSGi blueprint. The Hello sample does this through Activator and
> it uses ECF specific artifacts. Below is the sample service registration
> and this works in CXF.
>
> <bean id="omsServiceFacade"
> class="com.viithiisys.oms.services.impl.OmsServiceImpl">
> <property name="accountManager" ref="accountManager"/>
> </bean>
>
> <service ref="omsServiceFacade"
> interface="com.viithiisys.oms.services.OmsService">
> <service-properties>
> <entry key="osgi.jndi.service.name" value="oms/facadeService"/>
> <entry key="service.exported.interfaces"
> value="com.viithiisys.oms.services.OmsService"/>
> <entry key="org.apache.cxf.ws.address"
> value="http://localhost:9090/greeter"/>
> </service-properties>
> </service>
>
> Reason I am asking this question is that the hello example says, I need
> to create the ECF container which may not be possible or desirable when
> registering services dynamically.
This limitation (clients having to create an ECF container instance
prior to remote service registration and discovery has been removed.
See bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=303979
The reason this was put in place to begin with was security concerns of
automation...but the comments on bug 303979 convinced me that having the
default be to automatically create the container will make things more
accessible for everyone.
Also, BTW, as you can see from the discussion on bug 303979, it's
possible to customize/extend the behavior of the
DefaultProxyContainerFinder if desired...by creating an
IProxyContainerFinder implementation (e.g. by extending
DefaultProxyContainerFinder classes), and registering it as a service
with the whiteboard pattern. See here for more info about doing this:
http://wiki.eclipse.org/Customizing_and_Extending_ECF_Remote _Services
This should make it possible to have your client containers created
completely dynamically...either using the DefaultProxyContainerFinder
(i.e. what's in HEAD and to be released with ECF 3.3/Helios), or
creating your own impl of IProxyContainerFinder.
If you would like more support with this please consider moving the
discussion to ecf-dev at eclipse.org mailing list (see here to join:
https://dev.eclipse.org/mailman/listinfo/ecf-dev
as the ecf-dev mailing list is more frequently read by more committers
and other community members.
Thanks,
Scott
|
|
|
| Re: Remote service registration using OSGi Blueprint [message #625203 is a reply to message #527930] |
Mon, 19 April 2010 02:25 |
Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Raj,
Raj Saini wrote:
> Hi,
>
> I have been looking for some example/samples to register remove services
> using OSGi blueprint. The Hello sample does this through Activator and
> it uses ECF specific artifacts. Below is the sample service registration
> and this works in CXF.
>
> <bean id="omsServiceFacade"
> class="com.viithiisys.oms.services.impl.OmsServiceImpl">
> <property name="accountManager" ref="accountManager"/>
> </bean>
>
> <service ref="omsServiceFacade"
> interface="com.viithiisys.oms.services.OmsService">
> <service-properties>
> <entry key="osgi.jndi.service.name" value="oms/facadeService"/>
> <entry key="service.exported.interfaces"
> value="com.viithiisys.oms.services.OmsService"/>
> <entry key="org.apache.cxf.ws.address"
> value="http://localhost:9090/greeter"/>
> </service-properties>
> </service>
>
> Reason I am asking this question is that the hello example says, I need
> to create the ECF container which may not be possible or desirable when
> registering services dynamically.
This limitation (clients having to create an ECF container instance
prior to remote service registration and discovery has been removed.
See bug
https://bugs.eclipse.org/bugs/show_bug.cgi?id=303979
The reason this was put in place to begin with was security concerns of
automation...but the comments on bug 303979 convinced me that having the
default be to automatically create the container will make things more
accessible for everyone.
Also, BTW, as you can see from the discussion on bug 303979, it's
possible to customize/extend the behavior of the
DefaultProxyContainerFinder if desired...by creating an
IProxyContainerFinder implementation (e.g. by extending
DefaultProxyContainerFinder classes), and registering it as a service
with the whiteboard pattern. See here for more info about doing this:
http://wiki.eclipse.org/Customizing_and_Extending_ECF_Remote _Services
This should make it possible to have your client containers created
completely dynamically...either using the DefaultProxyContainerFinder
(i.e. what's in HEAD and to be released with ECF 3.3/Helios), or
creating your own impl of IProxyContainerFinder.
If you would like more support with this please consider moving the
discussion to ecf-dev at eclipse.org mailing list (see here to join:
https://dev.eclipse.org/mailman/listinfo/ecf-dev
as the ecf-dev mailing list is more frequently read by more committers
and other community members.
Thanks,
Scott
|
|
|
Powered by
FUDForum. Page generated in 0.02965 seconds
] 
Search
Help
Register
Login
Home
