[ http://issues.apache.org/jira/browse/GERONIMO-155?page=all ]
David Jencks closed GERONIMO-155:
---------------------------------
Resolution: Won't Fix
The runtime system does no xml manipulation, so this proposal is really moving
against the direction geronimo is heading. If you still think this is valuable
please explain why in more detail.
> [proposal] XML resolving for kernel - containerwide Parser
> ----------------------------------------------------------
>
> Key: GERONIMO-155
> URL: http://issues.apache.org/jira/browse/GERONIMO-155
> Project: Geronimo
> Type: Improvement
> Components: core
> Reporter: Kristian Koehler
> Assignee: David Jencks
> Attachments: patch-02-19-2004-2.zip, patch-02-24-2004.zip, patch.zip,
> patch02192004.zip, resolving-for-kernel.zip, things-in-action.txt
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
