Howto communicate with Sling bundles/services from outside OSGi?

[Clemens Wyss <cl...@mysign.ch>]

Looks like my initial post ("sling@tomcat : howto communicate with Sling bundles/services?") had a missleading/deterrent subject ;-) The topic/question "per se" has nothing to with Tomcat :-)

We are trying to deploy Sling within Tomcat in a project which has a lot of
legacy code running in parallel (within the same container). Basically new
features/components  shall be implemented in Sling (as bundles). BUT pretty
sure we need to build up a "communication channel" between the legacy
code and the Sling bundles/services.
 
Is there a slight chance (given the "protecting" LaunchClassLoader) to get
hold of the felix (interface org.osgi.framework.launch.Framework) member
within the Sling class?
 
Any other ideas (besides http requests :-( ) on how to build up  a "communication channel" without big
overhead or leaking classloaders.
 
Kind regards
Clemens

Re: Howto communicate with Sling bundles/services from outside OSGi?

[Carsten Ziegeler <cz...@apache.org>]

Clemens Wyss  wrote
> Looks like my initial post ("sling@tomcat : howto communicate with Sling bundles/services?") had a missleading/deterrent subject ;-) The topic/question "per se" has nothing to with Tomcat :-)
> 
> We are trying to deploy Sling within Tomcat in a project which has a lot of
> legacy code running in parallel (within the same container). Basically new
> features/components  shall be implemented in Sling (as bundles). BUT pretty
> sure we need to build up a "communication channel" between the legacy
> code and the Sling bundles/services.
>  
> Is there a slight chance (given the "protecting" LaunchClassLoader) to get
> hold of the felix (interface org.osgi.framework.launch.Framework) member
> within the Sling class?
>  
> Any other ideas (besides http requests :-( ) on how to build up  a "communication channel" without big
> overhead or leaking classloaders.
>  
I guess it depends a little bit on what you want to communicate and
when. Not sure about the Framework stuff, but what I did in another
project is to pass objects from the outside into the OSGi framework -
through the webapp context - these objects were loaded by a shared class
loader (the webapp classloader in this case and I had a fragment bundle
for this) and then I could call these objects from within OSGi services.
But obviously this is a very special solution which was fine in my case
but is maybe not suited for a general case :)

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org