[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook-apps] Resolver Classes (Version 1.1) Cannot find CatalogManager.properties
Hi Steve, I'm having the same problem no matter where I put the resolver classes and the CatalogManager.properties file. I've tried putting them both in /usr/share/java/ (and in local places in my home directory), and _always_ put both on my classpath. The only way I can get the 'Cannot find CatalogManager.properties' message to go away is to specify some of the properties on the command line, but then the entity resolution doesn't work. Ugh. > I found the fix. Have you verified that the fix works? Thanks, Mark > So, this post will record that fix into the > docbook-apps archive. > > Although ~/jre/lib/ext can be a convenient place to put jar files so > that they are automatically included in the CLASSPATH, Resolver > Classes (Version 1.1) may not work as expected if placed there. > > Here is some information I found through google. > from a post just a few days ago at: > http://www.mail-archive.com/server-user@james.apache.org/msg01916.html > ************ > . > . > . > > > I'm curious as to why James doesn't use jars in the ext directory? > The reason is that problems can arise related to the JRE extension > loading. Irrespective of the extension spec, the JRE will add all jar > files in the /ext directory into the system classpath. This can cause > all sort of trouble if you are running some particular version of a > xml parse that's not compatible with something bundled in the JRE ext > directory. The solution in Phoenix is to declare a different ext > directory u default. The solution in Merlin is to use the standard > ext directory but allow the possibility to override this if there is > a problem. > . > . > . > ************ > > The fix? > - Remove resolver.jar from ~/jre/lib/ext > - Place resolver.jar and CatalogManager.properties on the CLASSPATH > > It won't work if one leaves a copy of resolver.jar in ~/jre/lib/ext > > . . . not the best solution . It would be better if the > incompatibilities were eliminated, but at least I know what not to > do. > > > Steve Whitlatch -- _____________________________________ Mark Johnson <mark@dulug.duke.edu> Debian XML/SGML <mrj@debian.org> Home Page: <http://dulug.duke.edu/~mark/> GPG fp: DBEA FA3C C46A 70B5 F120 568B 89D5 4F61 C07D E242
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]