I haven't looked at the xml resolver code, but is there any other way to
load the catalog list while not using the classloader from xmlresolver
itself ?

On Wed, Mar 11, 2009 at 20:31, wbustraan <[email protected]> wrote:

>
> I'm stumped on an OSGi issue with ServiceMix and the way the ClassLoaders
> load resources. Here's some background:
>
>
> I have to deal with some legacy XML messages that it's difficult to change
> the format for. To workaround that limitation, I'm trying to run an XSL
> transform with Camel to convert the legacy format to the proper format for
> a
> web service call.
>
>
> Sounds good in theory. Unfortunately, the XML files have a DTD declaration
> that is incorrect. Here's a snippet:
>
>
>
> &lt;!DOCTYPE MPRequestCredit SYSTEM "file://MPReqCredit.dtd"&gt;
>
>
> When I runs this through the XSLT, the underlying parser tries to contact a
> host named "MPReqCredit.dtd" and everything fails.
>
>
> After much research, I discovered that the proper way to handle this is to
> implement an "EntityHandler" and pass that to the XML parser. The
> EntityHandler then handles locating and retrieving the resource.
>
>
> I discovered the Apache
> http://xml.apache.org/commons/components/resolver/index.html xml-commons
> resolver  library and it seemed like it would do the trick. I just supply
> it
> with a catalog file that maps the (incorrect) system uri's to valid local
> paths.
>
>
> I did end up having to extend several Camel components to get the XSLT
> transform properly configured with the Apache CatalogResolver, but
> everything seems to be working fine in my proof of concept.
>
>
> So, now I'm at the point where I want to extract the new Camel components
> and the resolver setup into a separate bundle for general use by other
> bundles.
>
>
> I discovered that ServiceMix already has xml-commons resolver installed in
> the form of the "org.apache.servicemix.bundles.xmlresolver" bundle, so I
> figured I could just import the classes and use that.
>
>
> That's when I started encountering problems.
>
>
> The Apache CatalogResolver class looks for a file named
> "CatalogManager.properties" on the classpath. In particular, the code looks
> like:
>
>
>
> propertyFileURI = CatalogManager.class.getResource("/"+propertyFile);
> InputStream in =
> CatalogManager.class.getResourceAsStream("/"+propertyFile);
>
>
> Where 'propertyFile' == "CatalogManager.properties"
>
>
> The problem is that "CatalogManager.properties" file that I want it to load
> exists in my bundle. But, as far as I can tell, this code causes it to look
> in the bundle that the class was loaded from, aka
> 'org.apache.servicemix.bundles.xmlresolver', where the necessary files are
> not present.
>
>
> I had thought maybe I could maybe solve the problem by creating a fragment
> bundle and then attaching it to org.apache.servicemix.bundles.xmlresolver
> so
> that the required files would then show up on the classpath, but I get the
> error message in ServiceMix:
>
>
>
> org.osgi.framework.BundleException: Unresolved constraint in bundle 172:
> host; (bundle-symbolic-name=org.apache.servicemix.bundles.xmlresolver)
>
>
> Any ideas on how to solve this?
>
> --
> View this message in context:
> http://www.nabble.com/OSGi-Resource-loading-conundrum-tp22462718p22462718.html
> Sent from the ServiceMix - User mailing list archive at Nabble.com.
>



-- 
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com

Reply via email to