The following comment has been added to this issue:
Author: Kristian Koehler
Created: Fri, 2 Jan 2004 1:47 PM
Body:
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 component.
in
org.apache.geronimo.security.EjbModuleConfigurationTest
org.apache.geronimo.xml.deployment.GeronimoEjbJarLoaderTest
org.apache.geronimo.xml.deployment.GeronimoEjbJarStorerTest
src-redefine.1: The component 'http://java.sun.com/xml/ns/j2ee,ejb-refType'
occurs in a schema different from that which was redefined.
in
org.apache.geronimo.security.WebModuleConfigurationTest
s4s-att-invalid-value: Invalid attribute value for 'type' in element
'attribute': UndeclaredPrefix.
in
org.apache.geronimo.xml.deployment.GeronimoAppClientLoaderTest
cvc-complex-type.2.4.a: Invalid content starting with element
'resourceadapter'. One of '{"http://java.sun.com/xml/ns/j2ee":description,
"http://java.sun.com/xml/ns/j2ee":display-name,
"http://java.sun.com/xml/ns/j2ee":icon,
"http://java.sun.com/xml/ns/j2ee":vendor-name}' is expected.
in
org.apache.geronimo.xml.deployment.GeronimoConnectorLoaderTest
* running geronimo
You changed the LocalEntityResolver to a GeronimoMBean. When starting Geronimo
i get the following exception:
[java] org.apache.geronimo.kernel.deployment.DeploymentException:
[geronimo.xml:role=EntityResolver] javax.management.NotCompliantMBeanException:
MBean is not compliant
Kristian
---------------------------------------------------------------------
View the issue:
http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-133
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
Components:
core
Assignee: David Jencks
Reporter: Kristian Koehler
Created: Fri, 26 Dec 2003 10:21 AM
Updated: Fri, 2 Jan 2004 1:47 PM
Description:
Hi
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 behaviour.
* 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.
Example:
-//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.
(see http://www.oasis-open.org/specs/a401.htm)
Apache provides an appropriate Java library.
(http://xml.apache.org/commons/components/resolver/index.html)
The "new" LocalEntiotyResolver uses this catalog standard to determine the
PublicID/SystemID mappings.
* There are new Unit Tests which tests the functionality of the
LocalEntityResolver.
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.
Kristian
---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
