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, [EMAIL PROTECTED] wrote:
The following issue has been updated:
Updater: Kristian Koehler (mailto:[EMAIL PROTECTED])
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
