The following issue has been updated:

    Updater: Kristian Koehler (mailto:[EMAIL PROTECTED])
       Date: Thu, 19 Feb 2004 3:56 AM
    Comment:
new patch including GBean code for ServiceFilterClassLoader and 
LocalEntityResolver. These two beans get now registered in server on 
configuration startup. 

Modifications to "configuration-inheritance" will follow ;-) (the child config 
should use the parent config if nothing else is specified for the child)
    Changes:
             Attachment changed to patch02192004.zip
    ---------------------------------------------------------------------
For a full history of the issue, see:

  
http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=GERONIMO-155&page=history

---------------------------------------------------------------------
View the issue:
  http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=GERONIMO-155

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: GERONIMO-155
    Summary: [proposal] resolving for kernel
       Type: Improvement

     Status: Unassigned
   Priority: Major

    Project: Apache Geronimo
 Components: 
             core

   Assignee: 
   Reporter: Kristian Koehler

    Created: Mon, 2 Feb 2004 1:42 PM
    Updated: Thu, 19 Feb 2004 3:56 AM

Description:
Hi

Building and running Geronimo offline or behind a firewall is nearly 
impossible. 
Most problems araise from the fact that there are code requiring remote entity 
resolving. The current LocalEntityResolver solves that problem for "Geronimo 
code". Every other module/ service could cause a similar problem. 
Currently I have problems with the Jetty Module requiring a SUN schema file 
which is not found by the SAXParser.

One possible solution IMO is a ParserWrapper implementation which wraps the 
"normal" implemention. This Wrapper should be made available to all services 
deployed in Geronimo. A call to 

        SAXParserFactory.newInstance();

should return a Wrapper implementation which returns all other Wrapper 
implementations (SAXParserWrapper, XMLReaderWrapper, ...). 

The normal lookup mechanism in the SAXParserFactory is as follows:

* test SystemProperty "javax.xml.parsers.SAXParserFactory"
* lookup in java.home jax.properties
* test META-INF/services/javax.xml.parsers.SAXParserFactory file

The last call could be redirected to the wrapper implementation ("ClassLoader 
hack"). The other both calls couldn't be redirected. But I think if a user had 
set a implementation via SystemProperty or jaxp.properties file the wrapper 
implementation should be skipped (warning message for the user).

IMO all services/modules should be deployed with a ClassLoaderWrapper which 
redirects all Parser lookups to a wrapper implementation which wraps the 
"normal implementation". This "normal implementation" could be determined via 
the "normal lookup mechanism".

something like that
------ 8< ------

InputStream stream = 
localClassLoader.getResourceAsStream("META-INF/services/javax.xml.parsers.SAXParserFactory");
 if (stream != null) {
   InputStreamReader isr = new InputStreamReader(stream);
   BufferedReader reader = new BufferedReader(isr);
   factoryClassName = reader.readLine();
 } else {
   factoryClassName = "org.apache.crimson.jaxp.SAXParserFactoryImpl";
 }

------ 8< ------

So all resolving could be redirected to a LocalEntityResolver. 

Something like the following code could be included in the doStart() method of 
the Configuration class. So all deployed Beans should use the wrapper.

------ 8< ------

Class clazz =  
  wrappedClassLoader.loadClass(SAXParserFactoryWrapper.class.getName());
Method setDelegate = clazz.getMethod("setDelegate", 
                           new Class[]{String.class});
        
if (parent == null) {
  setDelegate.invoke(clazz, new Object[]{...)});
} else {
  setDelegate.invoke(clazz, new Object[]{...)});
}

------ 8< ------

I hope my idea is understandable ;-)
Comments?

        Kristian



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://nagoya.apache.org/jira/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