geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject [jira] Commented: (GERONIMO-133) [PATCH] LocalEntity Resolver and LoaderUtil Enhancements
Date Fri, 02 Jan 2004 19:47:39 GMT
The following comment has been added to this issue:

     Author: Kristian Koehler
    Created: Fri, 2 Jan 2004 1:47 PM
Hi David

I applied your patch and made some changes to the code. I will attach the new patch. Here
are some comments for that:

* LocalEntityResolver
You made the LocalEntityResolver a GeronimoMBean and hat it set a static EntityResolver on
the loader/storer. I think the static approach is much simpler than the "MBean way" i did,
but this couples the LocalEntityResolver with the LoaderUtil. I think they should stay "independent"
and use the JMX bus. 

* LoaderUtil parseXML Method
The "not jaxp compliant way" does also validate XML files with a DTD statements. I added a
test into the LoaderUtilTest for that. If you change the method call to parseXML2 you will
see the "problem".

* LocalEntityResolverTest
Inside the testLocalRepository Method there are to calls to the resolver with two systemids
("c:\\work\\some.xsd", "/home/kkoehler/some.xsd"). The files referenced are not needed for
the test. The call tests the getSystemIdFileName method inside the LocalEntityResolver witch
is called while resolving an entity with the local repository.

* AbstractLoaderUtilTest
paranoia. Just set the entityresolver to null in teardown method. 

* boot-service.xml
changed to use the new constructor.

* Connector files test files.
I think they are not valid (see also other tests).

* other tests
I encountered problems while running the tests. I think the LocalEntityResolver doesn't "cause"
these failures. I wasn't able to validate the used xml files with any tool (especially XMLSpy).
It seems that there are other problems with the schemas. I get the following exceptions: 

src-resolve: Cannot resolve the name 'j2ee:java-identifierType' to a(n) simpleType definition

src-redefine.1: The component ',ejb-refType' occurs in a schema
different from that which was redefined.

s4s-att-invalid-value: Invalid attribute value for 'type' in element 'attribute': UndeclaredPrefix.

cvc-complex-type.2.4.a: Invalid content starting with element
'resourceadapter'. One of '{"":description,
"":vendor-name}' is expected.

* running geronimo
You changed the LocalEntityResolver to a GeronimoMBean. When starting Geronimo i get the following
[java] org.apache.geronimo.kernel.deployment.DeploymentException: [geronimo.xml:role=EntityResolver] MBean is not compliant

View the issue:

Here is an overview of the issue:
        Key: GERONIMO-133
    Summary: [PATCH] LocalEntity Resolver and LoaderUtil Enhancements
       Type: Improvement

     Status: Open
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Apache Geronimo

   Assignee: David Jencks
   Reporter: Kristian Koehler

    Created: Fri, 26 Dec 2003 10:21 AM
    Updated: Fri, 2 Jan 2004 1:47 PM


this is a patch for the LocalEntity Resolver and LoaderUtil Classes. 

Why i think this patch should be applied:

* There were some complaints about working or developing offline with Apache Geronimo. Most
problems arises from remote resolving of entities. 
If someone develops a piece a code which requires some external DTDs or Schemas it may work
for him because we works online. The "new" Implementation offers a flag indicating if the
resolver may return null or throw an exception. Returning null is a signal to the parser to
open a regular URI connection to the given system identifier. 
With this flag it's possible to disable all remote lookups and prevent different online/offline

* Validating of DTDs and Schema.
The current Implementation of the LoaderUtil doesn't validate schema and DTDs and there is
no ErrorHandler to report the failures.
The "new" LoaderUtil ueses a DOMParser Implementation which supports DTD and Schema validation.
(ok it's a Xerces feature - if someone knows how to use this the "standard way" please let
me know. ;-) )

* The current EntityResolver is implemented as MBean. The LoaderUtil class which uses the
LocalEntityResolver instantiates the EntityResolver every time rather then using it over the
JMX bus.
You may add new Mappings to the LocalEntityResolver but they will never be used. 
The "new" LoaderUtil Implementation uses the LocalEntity Resolver over JMX.

* The current LocalEntity Resolver uses a property file for mapping a PublicID to a SystemID.

This approach is useful but doesn't work. Property files must not contain spaces in there
key values. 

-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN=c:/work/dummy/web.dtd

is not a valid entry.

  OASIS has published a Catalog standard to define such mappings. 
  Apache provides an appropriate Java library.

The "new" LocalEntiotyResolver uses this catalog standard to determine the PublicID/SystemID

* There are new Unit Tests which tests the functionality of the
  I have adjusted the other tests accordingly.

How the LocalEntityResolver works:

First of all the Resolver is registered as MBean
(geronimo.xml:role=EntityResolver). It is configured with:
* CatalogFile (OASIS Catalog file)
* LocalRepository (local directory where to lookup dtd and schema)
* FailOnUnresolvable

When resolving an entity the resolver first checks the catalog file to determine a PublicID
or SystemID mapping. If there is now mapping configured the Resolver tries to resolve via
a local directory where dtd and schema files are present(LocalRepository). If no dtd or schema
is found a lookup into the classpath is done. If nothing is found the FailOnUnresolvable signals
if an exception should be thrown.


This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:

If you want more information on JIRA, or have a bug to report see:

View raw message