The following issue has been updated:

    Updater: Kristian Koehler (mailto:[EMAIL PROTECTED])
       Date: Fri, 26 Dec 2003 10:24 AM
    Comment:
The xml-commons-resolver-1.1.jar which is not present at Ibiblio.
(http://xml.apache.org/commons/components/resolver/index.html)
    Changes:
             Attachment changed to xml-commons-resolver-1.1.jar
    ---------------------------------------------------------------------
For a full history of the issue, see:

  http://jira.codehaus.org/secure/ViewIssue.jspa?key=GERONIMO-133&page=history

---------------------------------------------------------------------
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: Unassigned
   Priority: Major

 Original Estimate: Unknown
 Time Spent: Unknown
  Remaining: Unknown

    Project: Apache Geronimo
 Components: 
             core

   Assignee: 
   Reporter: Kristian Koehler

    Created: Fri, 26 Dec 2003 10:21 AM
    Updated: Fri, 26 Dec 2003 10:24 AM

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

Reply via email to