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