>
>
> 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/
