You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Craig Schaefer <cr...@prodyna.com> on 2009/02/04 17:04:34 UTC
OCM DTD resolution
Hello,
We have written a Jackrabbit based Content Repository. We are using OCM
exclusively, which I should say is a great object mapping layer that makes
using JCR less painless. We have even managed to extend the Collection and
Bean converters a little to allow for more cascading style inserts and
deletes for object graphs that you find with classical ORM software like
hibernate.
Jackrabbit which works brilliantly when an internet connection exists upon
repository startup/OCM session creation, but not so an environment without a
net connection. For example a mobile device such as a laptop does not
always have a net connection.
Everytime I start Jackrabbit using OCM with no net connection I get the
error below (UnknownHostException). Basically the Jackrabbit OCM
DigesterDescriptorReader is attempting to load the OCM mapping files and the
underlying parser (Xerces with a SAXParser) is attempting to resolve the
DOCTYPE clauses. (BTW if I have no DOCTYPE clause then another error appears
about being unable to validate the file).
Here is my ocm mapping document (the top at least)
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE jackrabbit-ocm PUBLIC "-//The Apache Software Foundation//DTD
Jackrabbit OCM 1.4//EN"
"http://jackrabbit.apache.org/dtd/jackrabbit-ocm-1.4.dtd">
<jackrabbit-ocm>
...
I have tried the OASIS Catalog trick, where you have a
CatalogManager.properties in the classpath along with a catalog.xml, which
maps the DTD publicID or systemID to the stored DTD. However, this also
doesnt work. The catalog is never detected. The contents of both files are
also below.
I was then hoping to instantiate a XMLCatalogResolver and attach it the the
XMLReader myself as described in
http://xerces.apache.org/xerces2-j/faq-xcatalogs.html#faq-3. But after
reading the Jackrabbit OCM code this doesnt appear to be possible as I
cannot get to the reader. Looking in
org.apache.jackrabbit.ocm.mapper.impl.digester.DigestorDescriptorReader#loadClassDescriptors
I see
Digester digester = new Digester();
digester.setValidating(this.validating);
if (null != this.dtdResolver)
{
digester.register("-//The Apache Software Foundation//DTD
Repository//EN",
this.dtdResolver.toString());
}
...
How can I load in the XMLCatalogResolver, or how can I register more URIs to
the contained digester? I would to at least extend
org.apache.jackrabbit.ocm.mapper.impl.digester.DigestMapperImpl but it is
closed to setting ones own
org.apache.jackrabbit.ocm.mapper.impl.digester.DigestorDescriptorReader. But
even then the DigestorDescriptorReader doesn't allow an XMLCatalogResolver
to be registered. There are no hooks!
Am I missing something or is there anyway to control the XML DTD resolution
behaviour when Jackrabbit OCM runs without an internet connection to the
outside world? I already know about using a SYSTEM clause instead of PUBLIC
but that will not do for a production solution. At the moment I staring at a
parralell implementation of both DigesterMapperImpl and
DigestorDescriptorReader. Is this avoidable?
I would like to be able defer DTD resolution for the ocm mappings files with
an OASIS catalog as follows:
CatalogManager.properties:
catalogs=catalog.xml
relative-catalogs=false
static-catalog=yes
prefer=public
catalog-class-name=org.apache.xml.resolver.Resolver
verbosity=99
catalog.xml
<?xml version='1.0'?>
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"
prefer="public">
<public publicId="-//The Apache Software Foundation//DTD Jackrabbit
1.4//EN"
uri="repository-1.4.dtd"/>
<public publicId="-//The Apache Software Foundation//DTD Jackrabbit OCM
1.4//EN"
uri="jackrabbit-ocm-1.4.dtd"/>
<uri name="http://jackrabbit.apache.org/dtd/repository-1.4.dtd"
uri="repository-1.4.dtd"/>
<uri name="http://jackrabbit.apache.org/dtd/jackrabbit-ocm-1.4.dtd"
uri="jackrabbit-ocm-1.4.dtd"/>
</catalog>
This is what happens if htere is no current net connection upon repository
startup (session creation).
Exception stack:
at
org.springframework.beans.BeanUtils.instantiateClass(BeanUtils.java:100)
... 18 more
Cuassed by: java.net.UnknownHostException: jackrabbit.apache.org
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:177)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:519)
at java.net.Socket.connect(Socket.java:469)
at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:394)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:529)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:233)
at sun.net.www.http.HttpClient.New(HttpClient.java:306)
at sun.net.www.http.HttpClient.New(HttpClient.java:323)
at
sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:837)
at
sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:778)
at
sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:703)
at
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1026)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:677)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startEntity(XMLEntityManager.java:1315)
at
com.sun.org.apache.xerces.internal.impl.XMLEntityManager.startDTDEntity(XMLEntityManager.java:1282)
at
com.sun.org.apache.xerces.internal.impl.XMLDTDScannerImpl.setInputSource(XMLDTDScannerImpl.java:283)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.dispatch(XMLDocumentScannerImpl.java:1192)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$DTDDriver.next(XMLDocumentScannerImpl.java:1089)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl$PrologDriver.next(XMLDocumentScannerImpl.java:1002)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:648)
at
com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:510)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:807)
at
com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:737)
at
com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:107)
at
com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1205)
at
com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:522)
at org.apache.commons.digester.Digester.parse(Digester.java:1666)
at
org.apache.jackrabbit.ocm.mapper.impl.digester.DigesterDescriptorReader.loadClassDescriptors(DigesterDescriptorReader.java:169)
... 25 more
--
View this message in context: http://www.nabble.com/OCM-DTD-resolution-tp21833477p21833477.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.
Re: OCM DTD resolution
Posted by Marcel Reutegger <ma...@gmx.net>.
Hi Craig,
I think that's something that should be fixed in jackrabbit-ocm. do you mind
creating a patch that implements your changes right in jackrabbit-ocm and attach
it to a jira issue? Thanks.
regards
marcel
Craig Schaefer wrote:
> I have had to write a parrallel implementation of DigesterDescriptorReader as
> the JR OCM impl doesn't let me get at the Digester. It also means I have to
> have a parrallel implementation of DigesterMapperImpl.
>
> It would be good to refactor the JCR OCM code a bit to allow either
> 1) custom DigesterDescriptorReaders. The code in
> DigesterDescriptorReader#loadClassDescriptors needs to be split a bit to
> call out to a hook method for the digester which can be over-ridden or which
> in turn hooks out to get an EntityResolver if necessary.
>
> 2) a EntityResolver e.g. CatalogResolver, to be added to the
> DigesterMapperImpl and therefore the delegated DigesterDescriptorReader
> which would then need to attach it to the digester upon instantiation
>
> The parrallel impl works great ... I can cache the DTD files locally and
> just let the CatalogManager.properties stored in the jar direct the Resolver
> on where to find the Jackrabbit DTDs within the jar itself.
Re: OCM DTD resolution
Posted by Craig Schaefer <cr...@prodyna.com>.
I have had to write a parrallel implementation of DigesterDescriptorReader as
the JR OCM impl doesn't let me get at the Digester. It also means I have to
have a parrallel implementation of DigesterMapperImpl.
It would be good to refactor the JCR OCM code a bit to allow either
1) custom DigesterDescriptorReaders. The code in
DigesterDescriptorReader#loadClassDescriptors needs to be split a bit to
call out to a hook method for the digester which can be over-ridden or which
in turn hooks out to get an EntityResolver if necessary.
2) a EntityResolver e.g. CatalogResolver, to be added to the
DigesterMapperImpl and therefore the delegated DigesterDescriptorReader
which would then need to attach it to the digester upon instantiation
The parrallel impl works great ... I can cache the DTD files locally and
just let the CatalogManager.properties stored in the jar direct the Resolver
on where to find the Jackrabbit DTDs within the jar itself.
--
View this message in context: http://www.nabble.com/OCM-DTD-resolution-tp21833477p21855395.html
Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.