The following comment has been added to this issue:
Author: Kristian Koehler
Created: Tue, 17 Feb 2004 1:22 PM
Body:
Hi
here is the second version of the patch.
The basic idea can be found here:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=6411
What's done "inside":
* a configuration file (system-config.xml etc) could now contain a xml-parser
element which defines a Parser Wrapper for this configuration.
<xml-parser>
<entity-resolver>
<catalogFile>work/resolver-catalog.xml</catalogFile>
<localRepository>work</localRepository>
<failOnUnresolvable>true</failOnUnresolvable>
</entity-resolver>
</xml-parser>
* each configuration checks inside the doStart() method if a XMLParserWrapper
should be configured.
* Configuring a XMLParserWrapper means
* a ClassloaderFilter is created and all subsequent lookups to DOM or
SAXParserFactories are redirected to a wrapper implementation which is
configured with a LocalEntityResolver.
* BTW nothing is done if the user has set System properties for the factories
or has set up the jaxp.properties file.
Hope someone will apply this patch ;-)
Kristian
---------------------------------------------------------------------
View this comment:
http://nagoya.apache.org/jira/secure/ViewIssue.jspa?key=GERONIMO-155&page=comments#action_16258
---------------------------------------------------------------------
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: Tue, 17 Feb 2004 1:22 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
