You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by ji...@apache.org on 2004/02/02 22:44:51 UTC
[jira] Updated: (GERONIMO-155) [proposal] resolving for kernel
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
Re: [jira] Updated: (GERONIMO-155) [proposal] resolving for kernel
Posted by Kristian Köhler <Kr...@gmx.de>.
Hi
Kristian Köhler wrote:
> I think that's only one part of the problem. While using xmlbeans
> geronimo doesn't need the grammar files during deployment. But what
> about other services like jetty? If they call
>
> SAXParserFactory.newInstance();
>
> for any reason they still get a regular implementation probably not
> doing any entity resolving. This could again trigger a remote connection.
>
> I think it would be useful to have serverwide catalog/ repository. This
> could also include things like caching and runtime config.
This still remains.
>> Anyway, all comments on my alternate suggestion would be greatly
>> appreciated.
The xmlbeans based approach seems to work very nicely. However is there
a special reason for putting the information in two documents, e.g.
ra.xml and geronimo-ra.xml? Maybe if the geronimos could be adjusted via
namespace magic so that only document is required which could then serve
as the base for a xmlbeans class creation? If really necessary the
relevant information (sun vs. geronimo specific) could still be easily
separated and changed via sax xmlfilters.
When using one document the generated classes could be also used as
model classes and no additional data shifting like
geronimoConnectorDocument =
GeronimoConnectorLoader.load(geronimoConnectorDoc, connectorDocument);
is needed.
We are interested in your opinion on this ;-)
Steffen and Kristian
Re: [jira] Updated: (GERONIMO-155) [proposal] resolving for kernel
Posted by Kristian Köhler <Kr...@gmx.de>.
Yes. It is currently used in the LocalEntityResolver. There's also a
catalog file in CVS. (modules/core/src/conf/resolver-catalog.xml)
The idea is to set this LocalEntityResolver for all Parsers in Container.
thanks,
Kristian
Davanum Srinivas wrote:
> Has anyone looked into using xml commons catalog resolver? -
> http://xml.apache.org/commons/components/resolver/index.html
>
> thanks,
> dims
>
> --- Kristian_Köhler <Kr...@gmx.de> wrote:
>
>>Hi
>>
>>David Jencks wrote:
>>
>>>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 think that's only one part of the problem. While using xmlbeans
>>geronimo doesn't need the grammar files during deployment. But what
>>about other services like jetty? If they call
>>
>> SAXParserFactory.newInstance();
>>
>>for any reason they still get a regular implementation probably not
>>doing any entity resolving. This could again trigger a remote connection.
>>
>>I think it would be useful to have serverwide catalog/ repository. This
>>could also include things like caching and runtime config.
>>
>>
>>>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.
>>
>>I will try to look into it ASAP.
>>
>> Kristian
>
>
>
> =====
> Davanum Srinivas - http://webservices.apache.org/~dims/
>
>
--
Kristian Köhler
Re: [jira] Updated: (GERONIMO-155) [proposal] resolving for kernel
Posted by Davanum Srinivas <di...@yahoo.com>.
Has anyone looked into using xml commons catalog resolver? -
http://xml.apache.org/commons/components/resolver/index.html
thanks,
dims
--- Kristian_K�hler <Kr...@gmx.de> wrote:
> Hi
>
> David Jencks wrote:
> > 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 think that's only one part of the problem. While using xmlbeans
> geronimo doesn't need the grammar files during deployment. But what
> about other services like jetty? If they call
>
> SAXParserFactory.newInstance();
>
> for any reason they still get a regular implementation probably not
> doing any entity resolving. This could again trigger a remote connection.
>
> I think it would be useful to have serverwide catalog/ repository. This
> could also include things like caching and runtime config.
>
> > 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.
>
> I will try to look into it ASAP.
>
> Kristian
=====
Davanum Srinivas - http://webservices.apache.org/~dims/
Re: [jira] Updated: (GERONIMO-155) [proposal] resolving for kernel
Posted by Kristian Köhler <Kr...@gmx.de>.
Hi
David Jencks wrote:
> 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 think that's only one part of the problem. While using xmlbeans
geronimo doesn't need the grammar files during deployment. But what
about other services like jetty? If they call
SAXParserFactory.newInstance();
for any reason they still get a regular implementation probably not
doing any entity resolving. This could again trigger a remote connection.
I think it would be useful to have serverwide catalog/ repository. This
could also include things like caching and runtime config.
> 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.
I will try to look into it ASAP.
Kristian
Re: [jira] Updated: (GERONIMO-155) [proposal] resolving for kernel
Posted by David Jencks <da...@coredevelopers.net>.
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
>