geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <da...@coredevelopers.net>
Subject Re: [jira] Updated: (GERONIMO-155) [proposal] resolving for kernel
Date Mon, 02 Feb 2004 22:21:10 GMT
I have been well aware of this problem for quite a while, but have not  
done much (such as applying all of your previous patches) to fix it  
because I have been working on using xmlbeans to read all the xml  
files.  This xmlbeans solution would not require geronimo to be able to  
access the schemas at runtime at all, as the generated xmlbeans code  
validates while reading xml.

I've just committed an initial implementation of this plan for the  
connector module.  It reads the necessary dds fine, but needs some more  
integration into the deployment framework.  So far I like this xml  
solution the best of any I have tried.

At the moment, the schemas are still required, and some network access  
is still required, to generate the xmlbeans classes.  Looking at the  
xmlbeans cvs, it appears that the somewhat experimental v2 code allows  
you to set an entity resolver or catalog, but v1 doesn't.  I wonder if  
we could encourage them to add this useful feature into their v1 code  
base.

Anyway, all comments on my alternate suggestion would be greatly  
appreciated.

many thanks,
david jencks

On Monday, February 2, 2004, at 01:44 PM, jira@apache.org wrote:

> The following issue has been updated:
>
>     Updater: Kristian Koehler (mailto:Kristian.Koehler@gmx.de)
>        Date: Mon, 2 Feb 2004 1:42 PM
>     Comment:
> file
>     Changes:
>              Attachment changed to resolving-for-kernel.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: Mon, 2 Feb 2004 1:42 PM
>
> 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
>


Mime
View raw message