You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@servicemix.apache.org by Guillaume Nodet <gn...@gmail.com> on 2007/08/24 17:29:41 UTC
Spring extensions to OSGi (was Re: ServiceMix 4.0)
>
>
> One topic not covered in this excellent post is a standard mechanism
> to provide access to other endpoint metadata (e.g. the WSDL file) -
> having that as a standard OSGi metadata would be cool (e.g. a WSDL
> URI)
>
> Yeah, I have had a closer look at how OSGi provides URL handlers.
> This is not as simple as I thought it would be. OSGI defines
> a "bundle:" protocol that can be used to access resources in the bundle.
> Unfortunately, the url has to contain the bundle id, which means that
> the URLs have to be built dynamically. I'm sure we can create a spring
> bean factory to create those dynamically though...
> Or a post factory processor that would process the URIs to rewrite them
> and include the bundle id.
>
> This way, the service could contain a WSDL_URL property associated
> with it (when registered in the OSGi registry) that would be a bundle url
> pointing to the wsdl inside the bundle. This would solve one of JBI
> limitation
> which is the ability to have complex WSDLs definitions including other
> WSDL or XSD.
>
I've been thinking about that a bit more.
It seems to me that using a kind of PropertyPlaceHolder (i.e. a
BeanFactoryPostProcessor) sounds like a good idea.
It could check all properties and perform replacement of an url like:
bundle-ext://org/test/dummy.wsdl
to
bundle://7.0/org/test/dummy.wsdl
where 7.0 is the bundle id.
Another extension could be a spring bean factory that expose a blob of
xml to an url
for other bundles to consume. Inside your spring definition file, one
would have:
<smx-osgi:export-xml url="org/test/dummy.wsdl>
<wsdl:description ...>
...
</wsdl:description>
</smx:osgi>
Thus a single configuration file (the spring one) could contain blob
of xml (well,
not only xml i guess) that could be exposed as an url.
I think the first idea will prove really useful to expose a WSDL to
other bundles.
I'm not so sure about the second one...
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
Re: Spring extensions to OSGi (was Re: ServiceMix 4.0)
Posted by Bruce Snyder <br...@gmail.com>.
On 8/24/07, Brian O'Neill <bo...@alumni.brown.edu> wrote:
> Guillaume,
>
> Just getting grounded...
>
> Would SM 4.0 leverage Felix to get OSGi capabilities?
>
> I took a grep through the code, it doesn't look like it uses it at all
> right now:
> bone@tower:~/dev/apache.org/servicemix-> grep -r "elix" *
> and osgi appears only in the eclipse plugins.
>
> Just verifying, OSGi is a brand new dependency for SM, right?
>
> Which leads me to my second question, do you think the dependency
> would be a hard dependency (on the actual felix impl), or would it be
> implementation agnostic? (e.g. able to run on Equinox as well)
>
> I am going to pull felix now and start playing around with it.
The idea is to leverage the OSGi spec so that SMX can run on any OSGi
compliant container. The first stab Guillaume and I took at
experimenting with OSGi back in May was using Felix and we'd probably
use Felix by default. But the idea is not to depend directly on the
Felix implementation.
Bruce
--
perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"
);'
Apache ActiveMQ - http://activemq.org/
Apache ServiceMix - http://servicemix.org/
Apache Geronimo - http://geronimo.apache.org/
Castor - http://castor.org/
Re: Spring extensions to OSGi (was Re: ServiceMix 4.0)
Posted by Nodet Guillaume <gn...@gmail.com>.
In my mind, ServiceMix will be agnostic wrt to the OSGi
implementation used.
At the same time, I'm thinking about creating a distribution for
ServiceMix that
would include Felix runtime...
And yeah, OSGi has never been a dependency so far.
I suggest to take a look at spring-osgi too.
See http://www.springframework.org/osgi
I really think we should use it.
Cheers,
Guillaume Nodet
On Aug 24, 2007, at 7:10 PM, Brian O'Neill wrote:
> Guillaume,
>
> Just getting grounded...
>
> Would SM 4.0 leverage Felix to get OSGi capabilities?
>
> I took a grep through the code, it doesn't look like it uses it at all
> right now:
> bone@tower:~/dev/apache.org/servicemix-> grep -r "elix" *
> and osgi appears only in the eclipse plugins.
>
> Just verifying, OSGi is a brand new dependency for SM, right?
>
> Which leads me to my second question, do you think the dependency
> would be a hard dependency (on the actual felix impl), or would it be
> implementation agnostic? (e.g. able to run on Equinox as well)
>
> I am going to pull felix now and start playing around with it.
>
> -brian
>
> On 8/24/07, Guillaume Nodet <gn...@gmail.com> wrote:
>>>
>>>
>>> One topic not covered in this excellent post is a standard mechanism
>>> to provide access to other endpoint metadata (e.g. the WSDL file) -
>>> having that as a standard OSGi metadata would be cool (e.g. a WSDL
>>> URI)
>>>
>>> Yeah, I have had a closer look at how OSGi provides URL handlers.
>>> This is not as simple as I thought it would be. OSGI defines
>>> a "bundle:" protocol that can be used to access resources in the
>>> bundle.
>>> Unfortunately, the url has to contain the bundle id, which means
>>> that
>>> the URLs have to be built dynamically. I'm sure we can create a
>>> spring
>>> bean factory to create those dynamically though...
>>> Or a post factory processor that would process the URIs to
>>> rewrite them
>>> and include the bundle id.
>>>
>>> This way, the service could contain a WSDL_URL property associated
>>> with it (when registered in the OSGi registry) that would be a
>>> bundle url
>>> pointing to the wsdl inside the bundle. This would solve one of JBI
>>> limitation
>>> which is the ability to have complex WSDLs definitions including
>>> other
>>> WSDL or XSD.
>>>
>>
>> I've been thinking about that a bit more.
>> It seems to me that using a kind of PropertyPlaceHolder (i.e. a
>> BeanFactoryPostProcessor) sounds like a good idea.
>> It could check all properties and perform replacement of an url like:
>> bundle-ext://org/test/dummy.wsdl
>> to
>> bundle://7.0/org/test/dummy.wsdl
>> where 7.0 is the bundle id.
>>
>> Another extension could be a spring bean factory that expose a
>> blob of
>> xml to an url
>> for other bundles to consume. Inside your spring definition file,
>> one
>> would have:
>>
>> <smx-osgi:export-xml url="org/test/dummy.wsdl>
>> <wsdl:description ...>
>> ...
>> </wsdl:description>
>> </smx:osgi>
>>
>> Thus a single configuration file (the spring one) could contain blob
>> of xml (well,
>> not only xml i guess) that could be exposed as an url.
>>
>> I think the first idea will prove really useful to expose a WSDL to
>> other bundles.
>> I'm not so sure about the second one...
>>
>> --
>> Cheers,
>> Guillaume Nodet
>> ------------------------
>> Blog: http://gnodet.blogspot.com/
>>
>
>
> --
> Brian ONeill
> Source Equity (http://www.sourceequity.com)
> jBIZint (http://www.jbizint.org)
> Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
> mobile:215.588.6024
Re: Spring extensions to OSGi (was Re: ServiceMix 4.0)
Posted by Brian O'Neill <bo...@alumni.brown.edu>.
Guillaume,
Just getting grounded...
Would SM 4.0 leverage Felix to get OSGi capabilities?
I took a grep through the code, it doesn't look like it uses it at all
right now:
bone@tower:~/dev/apache.org/servicemix-> grep -r "elix" *
and osgi appears only in the eclipse plugins.
Just verifying, OSGi is a brand new dependency for SM, right?
Which leads me to my second question, do you think the dependency
would be a hard dependency (on the actual felix impl), or would it be
implementation agnostic? (e.g. able to run on Equinox as well)
I am going to pull felix now and start playing around with it.
-brian
On 8/24/07, Guillaume Nodet <gn...@gmail.com> wrote:
> >
> >
> > One topic not covered in this excellent post is a standard mechanism
> > to provide access to other endpoint metadata (e.g. the WSDL file) -
> > having that as a standard OSGi metadata would be cool (e.g. a WSDL
> > URI)
> >
> > Yeah, I have had a closer look at how OSGi provides URL handlers.
> > This is not as simple as I thought it would be. OSGI defines
> > a "bundle:" protocol that can be used to access resources in the bundle.
> > Unfortunately, the url has to contain the bundle id, which means that
> > the URLs have to be built dynamically. I'm sure we can create a spring
> > bean factory to create those dynamically though...
> > Or a post factory processor that would process the URIs to rewrite them
> > and include the bundle id.
> >
> > This way, the service could contain a WSDL_URL property associated
> > with it (when registered in the OSGi registry) that would be a bundle url
> > pointing to the wsdl inside the bundle. This would solve one of JBI
> > limitation
> > which is the ability to have complex WSDLs definitions including other
> > WSDL or XSD.
> >
>
> I've been thinking about that a bit more.
> It seems to me that using a kind of PropertyPlaceHolder (i.e. a
> BeanFactoryPostProcessor) sounds like a good idea.
> It could check all properties and perform replacement of an url like:
> bundle-ext://org/test/dummy.wsdl
> to
> bundle://7.0/org/test/dummy.wsdl
> where 7.0 is the bundle id.
>
> Another extension could be a spring bean factory that expose a blob of
> xml to an url
> for other bundles to consume. Inside your spring definition file, one
> would have:
>
> <smx-osgi:export-xml url="org/test/dummy.wsdl>
> <wsdl:description ...>
> ...
> </wsdl:description>
> </smx:osgi>
>
> Thus a single configuration file (the spring one) could contain blob
> of xml (well,
> not only xml i guess) that could be exposed as an url.
>
> I think the first idea will prove really useful to expose a WSDL to
> other bundles.
> I'm not so sure about the second one...
>
> --
> Cheers,
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
>
--
Brian ONeill
Source Equity (http://www.sourceequity.com)
jBIZint (http://www.jbizint.org)
Technical Architect, Gestalt LLC (http://www.gestalt-llc.com)
mobile:215.588.6024