You should be able to create a new instance of CatalogManager and either set a path to your properties file or set the values you require on CatalogManager explicitly (catalog file, etc.) . Then pass this to your CatalogResolver instance, and so on...
This will all occur in the classloader of your bundle so something along these lines should work. Chris -- Chris Custine FUSESource :: http://fusesource.com My Blog :: http://blog.organicelement.com Apache ServiceMix :: http://servicemix.apache.org Apache Directory Server :: http://directory.apache.org On Wed, Mar 11, 2009 at 2:10 PM, Guillaume Nodet <[email protected]> wrote: > 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: > > > > > > > > <!DOCTYPE MPRequestCredit SYSTEM "file://MPReqCredit.dtd"> > > > > > > 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 >
