Details
-
Sub-task
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
4.0
-
None
-
None
Description
refer the discussion about this issue from the dev mailing list
> > What would be awesome is if we can deploy various things (JAX-WS, EJB3
> > and so forth) using Spring+OSGi and we have a way to auto-discover
> > things and expose them on the OSGi NMR type stuff (and so in JBI too).
> >
> > i.e. rather than folks having to put their JAX-WS / EJB3 / SCA stuff
> > into a service engine; it'd be nice if we had a way of kinda binding
> > to them direclty via OSGi. Maybe wishful thinking though - I'm just
> > wondering if we can kinda make the OSGiNMR/JBI stuff invisible and for
> > it to auto-hook into whatever folks are actually using. Even if we can
> > just find a way of getting CXF services when deployed as OSGi bundles
> > to be discoverable so we can export 'em on the OSGi NMR thingy it'd be
> > a big win for CXF users.
>
> Agreed. What I was thinking was along those lines. That's the main
> reason why the ServiceMix api does not have any notion of "component"
> as in JBI. Instead we would create OSGi deployers (baically a bundle
> listener or service listener). For example to activate a ServiceMix
> endpoint, it's just a matter of registering it in the OSGi registry.
> For JAX-WS, we could add a spring extension for deploying a bean,
> kinda like the jaxws namespace for cxf
> (http://cwiki.apache.org/CXF20DOC/jax-ws-configuration.html).
>
> So exposing a bean in that way would perform all the necessary steps
> to register on as a JBI endpoint and make it available remotely (maybe
> we need a boolean to say if we want to export it remotely or not)