Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: geronimo-dev@incubator.apache.org
Message-ID: <3F742929.7010301@hp.com>
Date: Fri, 26 Sep 2003 13:55:21 +0200
From: Jacek Laskowski <jacek.laskowski@hp.com>
Organization: HP Consulting & Integration, Poland
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.0) Gecko/20020530
MIME-Version: 1.0
To: geronimo-dev@incubator.apache.org
Subject: o.a.g.client.Launcher and its LocalEntityResolver
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hi,

Yesterday I worked on the sample files Jeremy had sent recently and the 
problem with xml parsing hit me again. That's because I worked offline, 
so LocalEntityResolver wasn't able to handle 
http://www.w3.org/2001/xml.xsd and 
http://www.ibm.com/webservices/xsd/j2ee_web_services_client_1_1.xsd. 
They're not file:// urls and are not stored in Geronimo's local store of 
schema files, so when Geronimo couldn't resolve it it handed it over to 
a XML parser that in turn tried to fetch the files from the original 
location.

Currently, Geronimo can resolve only the most known schemas, but I think 
we should introduce a configuration file where a user will be able to 
map a publicId to systemId. That solution would have at least two 
benefits over the present LocalEntityResolver:

   1. it would differentiate between http://x.com/xml.xsd and 
http://y.com/xml.xsd

   2. a user wouldn't have to copy a schema to the schemas' directory, 
but would have it elsewhere

Here's a bit more explanation:

The 1st benefit is crucial as now Geronimo looks up a schema by 
stripping off the last part of systemId (e.g. 
http://x.com/a/path/xml.xsd --> xml.xsd) and tries to get at the file in 
the local repository. Doing so, it doesn't care about the location of 
the systemId, so http://x.com/a/path/xml.xsd and 
http://y.com/foo/xml.xsd point to the same file - xml.xsd.

The 2nd one makes working offline a bit easier. Beside what's already 
said we could map any URL to a local file and wouldn't have to change 
anything, but the mapping file.

If we all agree with the outlined solution, LocalEntityResolver's ctor 
would change its signature and accept a file reference to the 
configuration file instead of directory.

How do I handle the parsing - xmlbeans, xbeans or what?

Also, shouldn't o.a.g.xml.deployment.EntityResolverTest (core module) 
change its name to o.a.g.xml.deployment.LocalEntityResolverTest? I'm 
going to create a few unit tests, but it would be much easier if I could 
already be working on the class with the valid name. Am I supposed to 
send a patch for it?

Pozdrawiam,
-Jacek