Home » Archived » XML Schema Definition (XSD) » Registered resource factory problem
|
Re: Registered resource factory problem [message #38955 is a reply to message #38930] |
Tue, 16 March 2004 16:30 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
I've never seen a "zip:" protocol before. I've seen "jar:", which is maybe the same? In any event, our URI
implementation has special support for treating "jar:" as a hierarchical URI even though it doesn't conform to the grammar
for a hierarchical URI, i.e., there's no leading "/" after the scheme. This special support is not there for "zip:", so
that will be treated as non-hierarchical and hence it has no file extension that can be used to find a resource factory.
Where did this "zip:" thing come from? Can you use "jar:" instead? You could use the URIConverter to normalize "zip:" to
"jar:"...
Hayden Marchant wrote:
> I am trying to run the Eclipse XSD parser within Weblogic 8.1 App Server.
> I am using XSD 1.1.1 and this version has worked fine in all other
> execution environments.
>
> In my code, I register the xsd resource factory with the following code:
>
> ResourceSet resourceSet = new ResourceSetImpl();
>
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> new XSDResourceFactoryImpl());
>
> I use the wildcard '*' since I want all files that go through this parser
> to be treated as xsd's to allow for bad file names.
>
> I am getting the following exception when trying to read an xsd which is
> called a few lines after the resource factory registry:
>
> java.lang.RuntimeException: Cannot create a resource for
> 'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> a registered resource factory is needed
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> at
> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> at
> org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> at
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> at
> org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
>
> Thanks,
> Hayden Marchant
|
|
|
Re: Registered resource factory problem [message #39002 is a reply to message #38955] |
Wed, 17 March 2004 11:29 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
I took a different approach to solving this problem by unzipping the
xsd.resources.jar and putting the files in the classpath (and removing the
jar). I now get a different but similar exception. Note that there is a
'directory' called plugin.properties that the code is looking for which
does not exist in the directory hierarchy. Where is this extra
plugin.properties 'directory' coming from?
java.lang.RuntimeException: Cannot create a resource for
'file:E:/bea/user_projects/domains/unicorn/applications/unic orn
/WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
a registered resource factory is needed
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
at
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
at
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
Ed Merks wrote:
> Hayden,
> I've never seen a "zip:" protocol before. I've seen "jar:", which is maybe
the same? In any event, our URI
> implementation has special support for treating "jar:" as a hierarchical URI
even though it doesn't conform to the grammar
> for a hierarchical URI, i.e., there's no leading "/" after the scheme. This
special support is not there for "zip:", so
> that will be treated as non-hierarchical and hence it has no file extension
that can be used to find a resource factory.
> Where did this "zip:" thing come from? Can you use "jar:" instead? You
could use the URIConverter to normalize "zip:" to
> "jar:"...
> Hayden Marchant wrote:
> > I am trying to run the Eclipse XSD parser within Weblogic 8.1 App Server.
> > I am using XSD 1.1.1 and this version has worked fine in all other
> > execution environments.
> >
> > In my code, I register the xsd resource factory with the following code:
> >
> > ResourceSet resourceSet = new ResourceSetImpl();
> >
> >
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> > new XSDResourceFactoryImpl());
> >
> > I use the wildcard '*' since I want all files that go through this parser
> > to be treated as xsd's to allow for bad file names.
> >
> > I am getting the following exception when trying to read an xsd which is
> > called a few lines after the resource factory registry:
> >
> > java.lang.RuntimeException: Cannot create a resource for
> >
'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> >
es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> > a registered resource factory is needed
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > at
> >
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> > at
> > org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> > at
> > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> > at
> > org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> > at
> >
org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> > at
> >
org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> > at
> > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> > at
> >
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> > at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> > at
> > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
> >
> > Thanks,
> > Hayden Marchant
|
|
|
Re: Registered resource factory problem [message #39026 is a reply to message #39002] |
Wed, 17 March 2004 11:49 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
Hayden,
This is another version of the it's not a hierarchical URI problem. The URI should be file:/E:/..., file://E:/..., or even
file:///E:/..., but file:E:/... is not hierarchical, which is not a good thing. I'm still curious where the "zip:" came
from. Is that something produced by some particular JDK classpath lookup, instead of using "jar:" as I've been seeing?
Hayden Marchant wrote:
> I took a different approach to solving this problem by unzipping the
> xsd.resources.jar and putting the files in the classpath (and removing the
> jar). I now get a different but similar exception. Note that there is a
> 'directory' called plugin.properties that the code is looking for which
> does not exist in the directory hierarchy. Where is this extra
> plugin.properties 'directory' coming from?
>
> java.lang.RuntimeException: Cannot create a resource for
> 'file:E:/bea/user_projects/domains/unicorn/applications/unic orn
> /WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
> a registered resource factory is needed
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
>
> Ed Merks wrote:
>
> > Hayden,
>
> > I've never seen a "zip:" protocol before. I've seen "jar:", which is maybe
> the same? In any event, our URI
> > implementation has special support for treating "jar:" as a hierarchical URI
> even though it doesn't conform to the grammar
> > for a hierarchical URI, i.e., there's no leading "/" after the scheme. This
> special support is not there for "zip:", so
> > that will be treated as non-hierarchical and hence it has no file extension
> that can be used to find a resource factory.
> > Where did this "zip:" thing come from? Can you use "jar:" instead? You
> could use the URIConverter to normalize "zip:" to
> > "jar:"...
>
> > Hayden Marchant wrote:
>
> > > I am trying to run the Eclipse XSD parser within Weblogic 8.1 App Server.
> > > I am using XSD 1.1.1 and this version has worked fine in all other
> > > execution environments.
> > >
> > > In my code, I register the xsd resource factory with the following code:
> > >
> > > ResourceSet resourceSet = new ResourceSetImpl();
> > >
> > >
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> > > new XSDResourceFactoryImpl());
> > >
> > > I use the wildcard '*' since I want all files that go through this parser
> > > to be treated as xsd's to allow for bad file names.
> > >
> > > I am getting the following exception when trying to read an xsd which is
> > > called a few lines after the resource factory registry:
> > >
> > > java.lang.RuntimeException: Cannot create a resource for
> > >
> 'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> > >
> es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> > > a registered resource factory is needed
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > > at
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> > > at
> > > org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> > > at
> > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> > > at
> > > org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> > > at
> > >
> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> > > at
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> > > at
> > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> > > at
> > >
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> > > at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> > > at
> > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
> > >
> > > Thanks,
> > > Hayden Marchant
|
|
|
Re: Registered resource factory problem [message #39053 is a reply to message #39026] |
Thu, 18 March 2004 14:49 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
After some research I have pinned down the problem to one method in
Eclipse. There are 3 methods in XSDSchemaImpl that return XSDSchema
instances that are loaded from the xsd.resources.jar :
getMagicSchemaForSchema(), getSchemaForSchema(), getSchemaInstance(). They
all call XSDPlugin.INSTANCE.getBaseURL().toString(). This method
basically does the following:
1. load plugin.properties resource using class loader.
2. create a URI from it.
3. call segments(1) on it in order to chop of the plugin.properties from
the URI.
4. The returned URI is really a base URI.
Now, when runnning in the Weblogic 8.1, the URL returned in stage 1 is of
the form file:E:/a/b/c instead of file:/E:/a/b/c. therefore, when calling
segments(), since it is NOT hierarchical, does not work and therefore the
baseURL is not at all a baseURL and therefore everything else goes wrong
after that.
I had to put a hack into the 3 methods in XSDSchemaImpl to ensure that the
baseURL is really a baseURL - I removed the offending plugin.properties,
and made the URI hierarchical by adding the '/'.
I'm really not sure why this happens? Does it have anything to do with the
fact that the call to getClass().getResource("plugin.properties") is with
a relative path to plugin.properties and not an absolute path like
"/org/eclipse/xsd/plugin.properties" ?
By the way, this problem happens also when I unzip the xsd.resources.jar
into the classes folder of the WEB-INF of the webapp. i.e. it's not
related to the fact that the resource is jar'ed.
I do not feel comfortable hacking Eclipse libraries, even if it is very
small local change. Can you suggest a better way of analyzing what went
wrong?
Thanks,
Hayden
Ed Merks wrote:
> Hayden,
> This is another version of the it's not a hierarchical URI problem. The URI
should be file:/E:/..., file://E:/..., or even
> file:///E:/..., but file:E:/... is not hierarchical, which is not a good
thing. I'm still curious where the "zip:" came
> from. Is that something produced by some particular JDK classpath lookup,
instead of using "jar:" as I've been seeing?
> Hayden Marchant wrote:
> > I took a different approach to solving this problem by unzipping the
> > xsd.resources.jar and putting the files in the classpath (and removing the
> > jar). I now get a different but similar exception. Note that there is a
> > 'directory' called plugin.properties that the code is looking for which
> > does not exist in the directory hierarchy. Where is this extra
> > plugin.properties 'directory' coming from?
> >
> > java.lang.RuntimeException: Cannot create a resource for
> > 'file:E:/bea/user_projects/domains/unicorn/applications/unic orn
> >
/WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
> > a registered resource factory is needed
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > at
> >
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
> > at
> >
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > I've never seen a "zip:" protocol before. I've seen "jar:", which is
maybe
> > the same? In any event, our URI
> > > implementation has special support for treating "jar:" as a hierarchical
URI
> > even though it doesn't conform to the grammar
> > > for a hierarchical URI, i.e., there's no leading "/" after the scheme.
This
> > special support is not there for "zip:", so
> > > that will be treated as non-hierarchical and hence it has no file
extension
> > that can be used to find a resource factory.
> > > Where did this "zip:" thing come from? Can you use "jar:" instead? You
> > could use the URIConverter to normalize "zip:" to
> > > "jar:"...
> >
> > > Hayden Marchant wrote:
> >
> > > > I am trying to run the Eclipse XSD parser within Weblogic 8.1 App
Server.
> > > > I am using XSD 1.1.1 and this version has worked fine in all other
> > > > execution environments.
> > > >
> > > > In my code, I register the xsd resource factory with the following
code:
> > > >
> > > > ResourceSet resourceSet = new ResourceSetImpl();
> > > >
> > > >
> >
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> > > > new XSDResourceFactoryImpl());
> > > >
> > > > I use the wildcard '*' since I want all files that go through this
parser
> > > > to be treated as xsd's to allow for bad file names.
> > > >
> > > > I am getting the following exception when trying to read an xsd which
is
> > > > called a few lines after the resource factory registry:
> > > >
> > > > java.lang.RuntimeException: Cannot create a resource for
> > > >
> >
'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> > > >
> >
es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> > > > a registered resource factory is needed
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > > > at
> > > >
> >
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> > > > at
> > > >
org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> > > > at
> > > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> > > > at
> > > >
org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> > > > at
> > > >
> >
org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> > > > at
> > > >
> >
org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> > > > at
> > > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> > > > at
> > > >
> >
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> > > > at
org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> > > > at
> > > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
> > > >
> > > > Thanks,
> > > > Hayden Marchant
|
|
|
Re: Registered resource factory problem [message #39087 is a reply to message #39053] |
Thu, 18 March 2004 15:42 |
Eclipse User |
|
|
|
Originally posted by: merks.ca.ibm.com
--------------9CC46910E1656C802F139E75
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hayden,
All this strange behavior will keep prompting me to ask what JDK you are using. The JDKs I've been using produce
"file:/..." not "file:..." and "jar:" not "zip:". Both the Sun and the IBM JDKs I use produce this:
baseURL=jar:file:/D:/sandbox/unpackage1_3.0M7/eclipse/plugin s/org.eclipse.xsd/runtime/xsd.resources.jar!/org/eclipse/xsd /
Have a look yourself at the different forms that XSDPlugin.INSTANCE.getBaseURL returns for different JDKs. If we can pin
down a pattern of behavior here, we could consider transforming the baseURL in the basic EMFPlugin implementation to
massage the URL it into an acceptable form even if the JDK doesn't yield it in that form originally.
Hayden Marchant wrote:
> After some research I have pinned down the problem to one method in
> Eclipse. There are 3 methods in XSDSchemaImpl that return XSDSchema
> instances that are loaded from the xsd.resources.jar :
> getMagicSchemaForSchema(), getSchemaForSchema(), getSchemaInstance(). They
> all call XSDPlugin.INSTANCE.getBaseURL().toString(). This method
> basically does the following:
>
> 1. load plugin.properties resource using class loader.
> 2. create a URI from it.
> 3. call segments(1) on it in order to chop of the plugin.properties from
> the URI.
> 4. The returned URI is really a base URI.
>
> Now, when runnning in the Weblogic 8.1, the URL returned in stage 1 is of
> the form file:E:/a/b/c instead of file:/E:/a/b/c. therefore, when calling
> segments(), since it is NOT hierarchical, does not work and therefore the
> baseURL is not at all a baseURL and therefore everything else goes wrong
> after that.
>
> I had to put a hack into the 3 methods in XSDSchemaImpl to ensure that the
> baseURL is really a baseURL - I removed the offending plugin.properties,
> and made the URI hierarchical by adding the '/'.
>
> I'm really not sure why this happens? Does it have anything to do with the
> fact that the call to getClass().getResource("plugin.properties") is with
> a relative path to plugin.properties and not an absolute path like
> "/org/eclipse/xsd/plugin.properties" ?
>
> By the way, this problem happens also when I unzip the xsd.resources.jar
> into the classes folder of the WEB-INF of the webapp. i.e. it's not
> related to the fact that the resource is jar'ed.
>
> I do not feel comfortable hacking Eclipse libraries, even if it is very
> small local change. Can you suggest a better way of analyzing what went
> wrong?
>
> Thanks,
> Hayden
>
> Ed Merks wrote:
>
> > Hayden,
>
> > This is another version of the it's not a hierarchical URI problem. The URI
> should be file:/E:/..., file://E:/..., or even
> > file:///E:/..., but file:E:/... is not hierarchical, which is not a good
> thing. I'm still curious where the "zip:" came
> > from. Is that something produced by some particular JDK classpath lookup,
> instead of using "jar:" as I've been seeing?
>
> > Hayden Marchant wrote:
>
> > > I took a different approach to solving this problem by unzipping the
> > > xsd.resources.jar and putting the files in the classpath (and removing the
> > > jar). I now get a different but similar exception. Note that there is a
> > > 'directory' called plugin.properties that the code is looking for which
> > > does not exist in the directory hierarchy. Where is this extra
> > > plugin.properties 'directory' coming from?
> > >
> > > java.lang.RuntimeException: Cannot create a resource for
> > > 'file:E:/bea/user_projects/domains/unicorn/applications/unic orn
> > >
> /WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
> > > a registered resource factory is needed
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > > at
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
> > > at
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > I've never seen a "zip:" protocol before. I've seen "jar:", which is
> maybe
> > > the same? In any event, our URI
> > > > implementation has special support for treating "jar:" as a hierarchical
> URI
> > > even though it doesn't conform to the grammar
> > > > for a hierarchical URI, i.e., there's no leading "/" after the scheme.
> This
> > > special support is not there for "zip:", so
> > > > that will be treated as non-hierarchical and hence it has no file
> extension
> > > that can be used to find a resource factory.
> > > > Where did this "zip:" thing come from? Can you use "jar:" instead? You
> > > could use the URIConverter to normalize "zip:" to
> > > > "jar:"...
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > I am trying to run the Eclipse XSD parser within Weblogic 8.1 App
> Server.
> > > > > I am using XSD 1.1.1 and this version has worked fine in all other
> > > > > execution environments.
> > > > >
> > > > > In my code, I register the xsd resource factory with the following
> code:
> > > > >
> > > > > ResourceSet resourceSet = new ResourceSetImpl();
> > > > >
> > > > >
> > >
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> > > > > new XSDResourceFactoryImpl());
> > > > >
> > > > > I use the wildcard '*' since I want all files that go through this
> parser
> > > > > to be treated as xsd's to allow for bad file names.
> > > > >
> > > > > I am getting the following exception when trying to read an xsd which
> is
> > > > > called a few lines after the resource factory registry:
> > > > >
> > > > > java.lang.RuntimeException: Cannot create a resource for
> > > > >
> > >
> 'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> > > > >
> > >
> es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> > > > > a registered resource factory is needed
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > > > > at
> > > > >
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> > > > > at
> > > > >
> org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> > > > > at
> > > > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> > > > > at
> > > > >
> org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> > > > > at
> > > > >
> > >
> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> > > > > at
> > > > >
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> > > > > at
> > > > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> > > > > at
> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> > > > > at
> > > > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
> > > > >
> > > > > Thanks,
> > > > > Hayden Marchant
--------------9CC46910E1656C802F139E75
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>All this strange behavior will keep prompting me to ask what JDK you
are using. The JDKs I've been using produce "file:/..." not "file:..."
and "jar:" not "zip:". Both the Sun and the IBM JDKs I use produce
this:
<blockquote>baseURL=jar:<A HREF=" file:/D:/sandbox/unpackage1_3.0M7/eclipse/plugins/org.eclips e.xsd/runtime/xsd.resources.jar!/org/eclipse/xsd/ "> file:/D:/sandbox/unpackage1_3.0M7/eclipse/plugins/org.eclips e.xsd/runtime/xsd.resources.jar!/org/eclipse/xsd/ </A></blockquote>
Have a look yourself at the different forms that XSDPlugin.INSTANCE.getBaseURL
returns for different JDKs. If we can pin down a pattern of behavior
here, we could consider transforming the baseURL in the basic EMFPlugin
implementation to massage the URL it into an acceptable form even if the
JDK doesn't yield it in that form originally.
<br>
<p>Hayden Marchant wrote:
<blockquote TYPE=CITE>After some research I have pinned down the problem
to one method in
<br>Eclipse. There are 3 methods in XSDSchemaImpl that return XSDSchema
<br>instances that are loaded from the xsd.resources.jar :
<br>getMagicSchemaForSchema(), getSchemaForSchema(), getSchemaInstance().
They
<br>all call XSDPlugin.INSTANCE.getBaseURL().toString(). This method
<br>basically does the following:
<p>1. load plugin.properties resource using class loader.
<br>2. create a URI from it.
<br>3. call segments(1) on it in order to chop of the plugin.properties
from
<br>the URI.
<br>4. The returned URI is really a base URI.
<p>Now, when runnning in the Weblogic 8.1, the URL returned in stage 1
is of
<br>the form <a href="file:E:/a/b/c">file:E:/a/b/c</a> instead of <a href="file:/E:/a/b/c">file:/E:/a/b/c</a>.
therefore, when calling
<br>segments(), since it is NOT hierarchical, does not work and therefore
the
<br>baseURL is not at all a baseURL and therefore everything else goes
wrong
<br>after that.
<p>I had to put a hack into the 3 methods in XSDSchemaImpl to ensure that
the
<br>baseURL is really a baseURL - I removed the offending plugin.properties,
<br>and made the URI hierarchical by adding the '/'.
<p>I'm really not sure why this happens? Does it have anything to do with
the
<br>fact that the call to getClass().getResource("plugin.properties") is
with
<br>a relative path to plugin.properties and not an absolute path like
<br>"/org/eclipse/xsd/plugin.properties" ?
<p>By the way, this problem happens also when I unzip the xsd.resources.jar
<br>into the classes folder of the WEB-INF of the webapp. i.e. it's not
<br>related to the fact that the resource is jar'ed.
<p>I do not feel comfortable hacking Eclipse libraries, even if it is very
<br>small local change. Can you suggest a better way of analyzing what
went
<br>wrong?
<p>Thanks,
<br>Hayden
<p>Ed Merks wrote:
<p>> Hayden,
<p>> This is another version of the it's not a hierarchical URI problem.
The URI
<br>should be <a href="file:/E:/">file:/E:/</a>..., <a href="file://E:/">file://E:/</a>...,
or even
<br>> <a href="file:///E:/">file:///E:/</a>..., but <a href="file:E:/">file:E:/</a>...
is not hierarchical, which is not a good
<br>thing. I'm still curious where the "zip:" came
<br>> from. Is that something produced by some particular JDK classpath
lookup,
<br>instead of using "jar:" as I've been seeing?
<p>> Hayden Marchant wrote:
<p>> > I took a different approach to solving this problem by unzipping
the
<br>> > xsd.resources.jar and putting the files in the classpath (and removing
the
<br>> > jar). I now get a different but similar exception. Note that there
is a
<br>> > 'directory' called plugin.properties that the code is looking for
which
<br>> > does not exist in the directory hierarchy. Where is this extra
<br>> > plugin.properties 'directory' coming from?
<br>> >
<br>> > java.lang.RuntimeException: Cannot create a resource for
<br>> > '<a href=" file:E:/bea/user_projects/domains/unicorn/applications/unico rn "> file:E:/bea/user_projects/domains/unicorn/applications/unico rn </a>
<br>> >
<br> /WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
<br>> > a registered resource factory is needed
<br>> > at
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
<br>> > at
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
<br>> > at
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
<br>> >
<br>> > Ed Merks wrote:
<br>> >
<br>> > > Hayden,
<br>> >
<br>> > > I've never seen a "zip:" protocol before. I've seen "jar:",
which is
<br>maybe
<br>> > the same? In any event, our URI
<br>> > > implementation has special support for treating "jar:" as a hierarchical
<br>URI
<br>> > even though it doesn't conform to the grammar
<br>> > > for a hierarchical URI, i.e., there's no leading "/" after the
scheme.
<br>This
<br>> > special support is not there for "zip:", so
<br>> > > that will be treated as non-hierarchical and hence it has no
file
<br>extension
<br>> > that can be used to find a resource factory.
<br>> > > Where did this "zip:" thing come from? Can you use "jar:"
instead? You
<br>> > could use the URIConverter to normalize "zip:" to
<br>> > > "jar:"...
<br>> >
<br>> > > Hayden Marchant wrote:
<br>> >
<br>> > > > I am trying to run the Eclipse XSD parser within Weblogic 8.1
App
<br>Server.
<br>> > > > I am using XSD 1.1.1 and this version has worked fine in all
other
<br>> > > > execution environments.
<br>> > > >
<br>> > > > In my code, I register the xsd resource factory with the following
<br>code:
<br>> > > >
<br>> > > >
ResourceSet resourceSet = new ResourceSetImpl();
<br>> > > >
<br>> > > >
<br>> >
<br> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
<br>> > > >
new XSDResourceFactoryImpl());
<br>> > > >
<br>> > > > I use the wildcard '*' since I want all files that go through
this
<br>parser
<br>> > > > to be treated as xsd's to allow for bad file names.
<br>> > > >
<br>> > > > I am getting the following exception when trying to read an
xsd which
<br>is
<br>> > > > called a few lines after the resource factory registry:
<br>> > > >
<br>> > > > java.lang.RuntimeException: Cannot create a resource for
<br>> > > >
<br>> >
<br> 'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
<br>> > > >
<br>> >
<br> es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
<br>> > > > a registered resource factory is needed
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
<br>> > > > at
<br>> > > >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
<br>> > > > at
<br>> > > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
<br>> > > > at
<br>> > > >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
<br>> > > > at
<br>> > > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
<br>> > > > at
<br> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
<br>> > > > at
<br>> > > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
<br>> > > >
<br>> > > > Thanks,
<br>> > > > Hayden Marchant</blockquote>
</html>
--------------9CC46910E1656C802F139E75--
|
|
|
Re: Registered resource factory problem [message #584244 is a reply to message #38930] |
Tue, 16 March 2004 16:30 |
Ed Merks Messages: 33133 Registered: July 2009 |
Senior Member |
|
|
Hayden,
I've never seen a "zip:" protocol before. I've seen "jar:", which is maybe the same? In any event, our URI
implementation has special support for treating "jar:" as a hierarchical URI even though it doesn't conform to the grammar
for a hierarchical URI, i.e., there's no leading "/" after the scheme. This special support is not there for "zip:", so
that will be treated as non-hierarchical and hence it has no file extension that can be used to find a resource factory.
Where did this "zip:" thing come from? Can you use "jar:" instead? You could use the URIConverter to normalize "zip:" to
"jar:"...
Hayden Marchant wrote:
> I am trying to run the Eclipse XSD parser within Weblogic 8.1 App Server.
> I am using XSD 1.1.1 and this version has worked fine in all other
> execution environments.
>
> In my code, I register the xsd resource factory with the following code:
>
> ResourceSet resourceSet = new ResourceSetImpl();
>
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> new XSDResourceFactoryImpl());
>
> I use the wildcard '*' since I want all files that go through this parser
> to be treated as xsd's to allow for bad file names.
>
> I am getting the following exception when trying to read an xsd which is
> called a few lines after the resource factory registry:
>
> java.lang.RuntimeException: Cannot create a resource for
> 'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> a registered resource factory is needed
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> at
> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> at
> org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> at
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> at
> org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
>
> Thanks,
> Hayden Marchant
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Registered resource factory problem [message #584257 is a reply to message #38955] |
Wed, 17 March 2004 11:29 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
I took a different approach to solving this problem by unzipping the
xsd.resources.jar and putting the files in the classpath (and removing the
jar). I now get a different but similar exception. Note that there is a
'directory' called plugin.properties that the code is looking for which
does not exist in the directory hierarchy. Where is this extra
plugin.properties 'directory' coming from?
java.lang.RuntimeException: Cannot create a resource for
'file:E:/bea/user_projects/domains/unicorn/applications/unic orn
/WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
a registered resource factory is needed
at
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
at
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
at
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
Ed Merks wrote:
> Hayden,
> I've never seen a "zip:" protocol before. I've seen "jar:", which is maybe
the same? In any event, our URI
> implementation has special support for treating "jar:" as a hierarchical URI
even though it doesn't conform to the grammar
> for a hierarchical URI, i.e., there's no leading "/" after the scheme. This
special support is not there for "zip:", so
> that will be treated as non-hierarchical and hence it has no file extension
that can be used to find a resource factory.
> Where did this "zip:" thing come from? Can you use "jar:" instead? You
could use the URIConverter to normalize "zip:" to
> "jar:"...
> Hayden Marchant wrote:
> > I am trying to run the Eclipse XSD parser within Weblogic 8.1 App Server.
> > I am using XSD 1.1.1 and this version has worked fine in all other
> > execution environments.
> >
> > In my code, I register the xsd resource factory with the following code:
> >
> > ResourceSet resourceSet = new ResourceSetImpl();
> >
> >
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> > new XSDResourceFactoryImpl());
> >
> > I use the wildcard '*' since I want all files that go through this parser
> > to be treated as xsd's to allow for bad file names.
> >
> > I am getting the following exception when trying to read an xsd which is
> > called a few lines after the resource factory registry:
> >
> > java.lang.RuntimeException: Cannot create a resource for
> >
'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> >
es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> > a registered resource factory is needed
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > at
> >
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> > at
> > org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> > at
> > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> > at
> > org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> > at
> >
org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> > at
> >
org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> > at
> > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> > at
> >
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> > at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> > at
> > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
> >
> > Thanks,
> > Hayden Marchant
|
|
|
Re: Registered resource factory problem [message #584273 is a reply to message #39002] |
Wed, 17 March 2004 11:49 |
Ed Merks Messages: 33133 Registered: July 2009 |
Senior Member |
|
|
Hayden,
This is another version of the it's not a hierarchical URI problem. The URI should be file:/E:/..., file://E:/..., or even
file:///E:/..., but file:E:/... is not hierarchical, which is not a good thing. I'm still curious where the "zip:" came
from. Is that something produced by some particular JDK classpath lookup, instead of using "jar:" as I've been seeing?
Hayden Marchant wrote:
> I took a different approach to solving this problem by unzipping the
> xsd.resources.jar and putting the files in the classpath (and removing the
> jar). I now get a different but similar exception. Note that there is a
> 'directory' called plugin.properties that the code is looking for which
> does not exist in the directory hierarchy. Where is this extra
> plugin.properties 'directory' coming from?
>
> java.lang.RuntimeException: Cannot create a resource for
> 'file:E:/bea/user_projects/domains/unicorn/applications/unic orn
> /WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
> a registered resource factory is needed
> at
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
> at
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
>
> Ed Merks wrote:
>
> > Hayden,
>
> > I've never seen a "zip:" protocol before. I've seen "jar:", which is maybe
> the same? In any event, our URI
> > implementation has special support for treating "jar:" as a hierarchical URI
> even though it doesn't conform to the grammar
> > for a hierarchical URI, i.e., there's no leading "/" after the scheme. This
> special support is not there for "zip:", so
> > that will be treated as non-hierarchical and hence it has no file extension
> that can be used to find a resource factory.
> > Where did this "zip:" thing come from? Can you use "jar:" instead? You
> could use the URIConverter to normalize "zip:" to
> > "jar:"...
>
> > Hayden Marchant wrote:
>
> > > I am trying to run the Eclipse XSD parser within Weblogic 8.1 App Server.
> > > I am using XSD 1.1.1 and this version has worked fine in all other
> > > execution environments.
> > >
> > > In my code, I register the xsd resource factory with the following code:
> > >
> > > ResourceSet resourceSet = new ResourceSetImpl();
> > >
> > >
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> > > new XSDResourceFactoryImpl());
> > >
> > > I use the wildcard '*' since I want all files that go through this parser
> > > to be treated as xsd's to allow for bad file names.
> > >
> > > I am getting the following exception when trying to read an xsd which is
> > > called a few lines after the resource factory registry:
> > >
> > > java.lang.RuntimeException: Cannot create a resource for
> > >
> 'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> > >
> es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> > > a registered resource factory is needed
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > > at
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> > > at
> > > org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> > > at
> > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> > > at
> > > org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> > > at
> > >
> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> > > at
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> > > at
> > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> > > at
> > >
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> > > at org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> > > at
> > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
> > >
> > > Thanks,
> > > Hayden Marchant
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Re: Registered resource factory problem [message #584288 is a reply to message #39026] |
Thu, 18 March 2004 14:49 |
Hayden Marchant Messages: 90 Registered: July 2009 |
Member |
|
|
After some research I have pinned down the problem to one method in
Eclipse. There are 3 methods in XSDSchemaImpl that return XSDSchema
instances that are loaded from the xsd.resources.jar :
getMagicSchemaForSchema(), getSchemaForSchema(), getSchemaInstance(). They
all call XSDPlugin.INSTANCE.getBaseURL().toString(). This method
basically does the following:
1. load plugin.properties resource using class loader.
2. create a URI from it.
3. call segments(1) on it in order to chop of the plugin.properties from
the URI.
4. The returned URI is really a base URI.
Now, when runnning in the Weblogic 8.1, the URL returned in stage 1 is of
the form file:E:/a/b/c instead of file:/E:/a/b/c. therefore, when calling
segments(), since it is NOT hierarchical, does not work and therefore the
baseURL is not at all a baseURL and therefore everything else goes wrong
after that.
I had to put a hack into the 3 methods in XSDSchemaImpl to ensure that the
baseURL is really a baseURL - I removed the offending plugin.properties,
and made the URI hierarchical by adding the '/'.
I'm really not sure why this happens? Does it have anything to do with the
fact that the call to getClass().getResource("plugin.properties") is with
a relative path to plugin.properties and not an absolute path like
"/org/eclipse/xsd/plugin.properties" ?
By the way, this problem happens also when I unzip the xsd.resources.jar
into the classes folder of the WEB-INF of the webapp. i.e. it's not
related to the fact that the resource is jar'ed.
I do not feel comfortable hacking Eclipse libraries, even if it is very
small local change. Can you suggest a better way of analyzing what went
wrong?
Thanks,
Hayden
Ed Merks wrote:
> Hayden,
> This is another version of the it's not a hierarchical URI problem. The URI
should be file:/E:/..., file://E:/..., or even
> file:///E:/..., but file:E:/... is not hierarchical, which is not a good
thing. I'm still curious where the "zip:" came
> from. Is that something produced by some particular JDK classpath lookup,
instead of using "jar:" as I've been seeing?
> Hayden Marchant wrote:
> > I took a different approach to solving this problem by unzipping the
> > xsd.resources.jar and putting the files in the classpath (and removing the
> > jar). I now get a different but similar exception. Note that there is a
> > 'directory' called plugin.properties that the code is looking for which
> > does not exist in the directory hierarchy. Where is this extra
> > plugin.properties 'directory' coming from?
> >
> > java.lang.RuntimeException: Cannot create a resource for
> > 'file:E:/bea/user_projects/domains/unicorn/applications/unic orn
> >
/WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
> > a registered resource factory is needed
> > at
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > at
> >
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
> > at
> >
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
> >
> > Ed Merks wrote:
> >
> > > Hayden,
> >
> > > I've never seen a "zip:" protocol before. I've seen "jar:", which is
maybe
> > the same? In any event, our URI
> > > implementation has special support for treating "jar:" as a hierarchical
URI
> > even though it doesn't conform to the grammar
> > > for a hierarchical URI, i.e., there's no leading "/" after the scheme.
This
> > special support is not there for "zip:", so
> > > that will be treated as non-hierarchical and hence it has no file
extension
> > that can be used to find a resource factory.
> > > Where did this "zip:" thing come from? Can you use "jar:" instead? You
> > could use the URIConverter to normalize "zip:" to
> > > "jar:"...
> >
> > > Hayden Marchant wrote:
> >
> > > > I am trying to run the Eclipse XSD parser within Weblogic 8.1 App
Server.
> > > > I am using XSD 1.1.1 and this version has worked fine in all other
> > > > execution environments.
> > > >
> > > > In my code, I register the xsd resource factory with the following
code:
> > > >
> > > > ResourceSet resourceSet = new ResourceSetImpl();
> > > >
> > > >
> >
resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> > > > new XSDResourceFactoryImpl());
> > > >
> > > > I use the wildcard '*' since I want all files that go through this
parser
> > > > to be treated as xsd's to allow for bad file names.
> > > >
> > > > I am getting the following exception when trying to read an xsd which
is
> > > > called a few lines after the resource factory registry:
> > > >
> > > > java.lang.RuntimeException: Cannot create a resource for
> > > >
> >
'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> > > >
> >
es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> > > > a registered resource factory is needed
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > > > at
> > > >
> >
org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> > > > at
> > > >
org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> > > > at
> > > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> > > > at
> > > >
org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> > > > at
> > > >
> >
org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> > > > at
> > > >
> >
org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> > > > at
> > > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> > > > at
> > > >
> >
org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> > > > at
org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> > > > at
> > > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> > > > at
> > > >
> >
org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
> > > >
> > > > Thanks,
> > > > Hayden Marchant
|
|
|
Re: Registered resource factory problem [message #584303 is a reply to message #39053] |
Thu, 18 March 2004 15:42 |
Ed Merks Messages: 33133 Registered: July 2009 |
Senior Member |
|
|
--------------9CC46910E1656C802F139E75
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Hayden,
All this strange behavior will keep prompting me to ask what JDK you are using. The JDKs I've been using produce
"file:/..." not "file:..." and "jar:" not "zip:". Both the Sun and the IBM JDKs I use produce this:
baseURL=jar:file:/D:/sandbox/unpackage1_3.0M7/eclipse/plugin s/org.eclipse.xsd/runtime/xsd.resources.jar!/org/eclipse/xsd /
Have a look yourself at the different forms that XSDPlugin.INSTANCE.getBaseURL returns for different JDKs. If we can pin
down a pattern of behavior here, we could consider transforming the baseURL in the basic EMFPlugin implementation to
massage the URL it into an acceptable form even if the JDK doesn't yield it in that form originally.
Hayden Marchant wrote:
> After some research I have pinned down the problem to one method in
> Eclipse. There are 3 methods in XSDSchemaImpl that return XSDSchema
> instances that are loaded from the xsd.resources.jar :
> getMagicSchemaForSchema(), getSchemaForSchema(), getSchemaInstance(). They
> all call XSDPlugin.INSTANCE.getBaseURL().toString(). This method
> basically does the following:
>
> 1. load plugin.properties resource using class loader.
> 2. create a URI from it.
> 3. call segments(1) on it in order to chop of the plugin.properties from
> the URI.
> 4. The returned URI is really a base URI.
>
> Now, when runnning in the Weblogic 8.1, the URL returned in stage 1 is of
> the form file:E:/a/b/c instead of file:/E:/a/b/c. therefore, when calling
> segments(), since it is NOT hierarchical, does not work and therefore the
> baseURL is not at all a baseURL and therefore everything else goes wrong
> after that.
>
> I had to put a hack into the 3 methods in XSDSchemaImpl to ensure that the
> baseURL is really a baseURL - I removed the offending plugin.properties,
> and made the URI hierarchical by adding the '/'.
>
> I'm really not sure why this happens? Does it have anything to do with the
> fact that the call to getClass().getResource("plugin.properties") is with
> a relative path to plugin.properties and not an absolute path like
> "/org/eclipse/xsd/plugin.properties" ?
>
> By the way, this problem happens also when I unzip the xsd.resources.jar
> into the classes folder of the WEB-INF of the webapp. i.e. it's not
> related to the fact that the resource is jar'ed.
>
> I do not feel comfortable hacking Eclipse libraries, even if it is very
> small local change. Can you suggest a better way of analyzing what went
> wrong?
>
> Thanks,
> Hayden
>
> Ed Merks wrote:
>
> > Hayden,
>
> > This is another version of the it's not a hierarchical URI problem. The URI
> should be file:/E:/..., file://E:/..., or even
> > file:///E:/..., but file:E:/... is not hierarchical, which is not a good
> thing. I'm still curious where the "zip:" came
> > from. Is that something produced by some particular JDK classpath lookup,
> instead of using "jar:" as I've been seeing?
>
> > Hayden Marchant wrote:
>
> > > I took a different approach to solving this problem by unzipping the
> > > xsd.resources.jar and putting the files in the classpath (and removing the
> > > jar). I now get a different but similar exception. Note that there is a
> > > 'directory' called plugin.properties that the code is looking for which
> > > does not exist in the directory hierarchy. Where is this extra
> > > plugin.properties 'directory' coming from?
> > >
> > > java.lang.RuntimeException: Cannot create a resource for
> > > 'file:E:/bea/user_projects/domains/unicorn/applications/unic orn
> > >
> /WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
> > > a registered resource factory is needed
> > > at
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > > at
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
> > > at
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
> > >
> > > Ed Merks wrote:
> > >
> > > > Hayden,
> > >
> > > > I've never seen a "zip:" protocol before. I've seen "jar:", which is
> maybe
> > > the same? In any event, our URI
> > > > implementation has special support for treating "jar:" as a hierarchical
> URI
> > > even though it doesn't conform to the grammar
> > > > for a hierarchical URI, i.e., there's no leading "/" after the scheme.
> This
> > > special support is not there for "zip:", so
> > > > that will be treated as non-hierarchical and hence it has no file
> extension
> > > that can be used to find a resource factory.
> > > > Where did this "zip:" thing come from? Can you use "jar:" instead? You
> > > could use the URIConverter to normalize "zip:" to
> > > > "jar:"...
> > >
> > > > Hayden Marchant wrote:
> > >
> > > > > I am trying to run the Eclipse XSD parser within Weblogic 8.1 App
> Server.
> > > > > I am using XSD 1.1.1 and this version has worked fine in all other
> > > > > execution environments.
> > > > >
> > > > > In my code, I register the xsd resource factory with the following
> code:
> > > > >
> > > > > ResourceSet resourceSet = new ResourceSetImpl();
> > > > >
> > > > >
> > >
> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
> > > > > new XSDResourceFactoryImpl());
> > > > >
> > > > > I use the wildcard '*' since I want all files that go through this
> parser
> > > > > to be treated as xsd's to allow for bad file names.
> > > > >
> > > > > I am getting the following exception when trying to read an xsd which
> is
> > > > > called a few lines after the resource factory registry:
> > > > >
> > > > > java.lang.RuntimeException: Cannot create a resource for
> > > > >
> > >
> 'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
> > > > >
> > >
> es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
> > > > > a registered resource factory is needed
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
> > > > > at
> > > > >
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
> > > > > at
> > > > >
> org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
> > > > > at
> > > > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
> > > > > at
> > > > >
> org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
> > > > > at
> > > > >
> > >
> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
> > > > > at
> > > > >
> > >
> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
> > > > > at
> > > > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
> > > > > at
> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
> > > > > at
> > > > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
> > > > > at
> > > > >
> > >
> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
> > > > >
> > > > > Thanks,
> > > > > Hayden Marchant
--------------9CC46910E1656C802F139E75
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hayden,
<p>All this strange behavior will keep prompting me to ask what JDK you
are using. The JDKs I've been using produce "file:/..." not "file:..."
and "jar:" not "zip:". Both the Sun and the IBM JDKs I use produce
this:
<blockquote>baseURL=jar:<A HREF=" file:/D:/sandbox/unpackage1_3.0M7/eclipse/plugins/org.eclips e.xsd/runtime/xsd.resources.jar!/org/eclipse/xsd/ "> file:/D:/sandbox/unpackage1_3.0M7/eclipse/plugins/org.eclips e.xsd/runtime/xsd.resources.jar!/org/eclipse/xsd/ </A></blockquote>
Have a look yourself at the different forms that XSDPlugin.INSTANCE.getBaseURL
returns for different JDKs. If we can pin down a pattern of behavior
here, we could consider transforming the baseURL in the basic EMFPlugin
implementation to massage the URL it into an acceptable form even if the
JDK doesn't yield it in that form originally.
<br>
<p>Hayden Marchant wrote:
<blockquote TYPE=CITE>After some research I have pinned down the problem
to one method in
<br>Eclipse. There are 3 methods in XSDSchemaImpl that return XSDSchema
<br>instances that are loaded from the xsd.resources.jar :
<br>getMagicSchemaForSchema(), getSchemaForSchema(), getSchemaInstance().
They
<br>all call XSDPlugin.INSTANCE.getBaseURL().toString(). This method
<br>basically does the following:
<p>1. load plugin.properties resource using class loader.
<br>2. create a URI from it.
<br>3. call segments(1) on it in order to chop of the plugin.properties
from
<br>the URI.
<br>4. The returned URI is really a base URI.
<p>Now, when runnning in the Weblogic 8.1, the URL returned in stage 1
is of
<br>the form <a href="file:E:/a/b/c">file:E:/a/b/c</a> instead of <a href="file:/E:/a/b/c">file:/E:/a/b/c</a>.
therefore, when calling
<br>segments(), since it is NOT hierarchical, does not work and therefore
the
<br>baseURL is not at all a baseURL and therefore everything else goes
wrong
<br>after that.
<p>I had to put a hack into the 3 methods in XSDSchemaImpl to ensure that
the
<br>baseURL is really a baseURL - I removed the offending plugin.properties,
<br>and made the URI hierarchical by adding the '/'.
<p>I'm really not sure why this happens? Does it have anything to do with
the
<br>fact that the call to getClass().getResource("plugin.properties") is
with
<br>a relative path to plugin.properties and not an absolute path like
<br>"/org/eclipse/xsd/plugin.properties" ?
<p>By the way, this problem happens also when I unzip the xsd.resources.jar
<br>into the classes folder of the WEB-INF of the webapp. i.e. it's not
<br>related to the fact that the resource is jar'ed.
<p>I do not feel comfortable hacking Eclipse libraries, even if it is very
<br>small local change. Can you suggest a better way of analyzing what
went
<br>wrong?
<p>Thanks,
<br>Hayden
<p>Ed Merks wrote:
<p>> Hayden,
<p>> This is another version of the it's not a hierarchical URI problem.
The URI
<br>should be <a href="file:/E:/">file:/E:/</a>..., <a href="file://E:/">file://E:/</a>...,
or even
<br>> <a href="file:///E:/">file:///E:/</a>..., but <a href="file:E:/">file:E:/</a>...
is not hierarchical, which is not a good
<br>thing. I'm still curious where the "zip:" came
<br>> from. Is that something produced by some particular JDK classpath
lookup,
<br>instead of using "jar:" as I've been seeing?
<p>> Hayden Marchant wrote:
<p>> > I took a different approach to solving this problem by unzipping
the
<br>> > xsd.resources.jar and putting the files in the classpath (and removing
the
<br>> > jar). I now get a different but similar exception. Note that there
is a
<br>> > 'directory' called plugin.properties that the code is looking for
which
<br>> > does not exist in the directory hierarchy. Where is this extra
<br>> > plugin.properties 'directory' coming from?
<br>> >
<br>> > java.lang.RuntimeException: Cannot create a resource for
<br>> > '<a href=" file:E:/bea/user_projects/domains/unicorn/applications/unico rn "> file:E:/bea/user_projects/domains/unicorn/applications/unico rn </a>
<br>> >
<br> /WEB-INF/classes/org/eclipse/xsd/plugin.properties/cache/www .w3.org/2001/XMLSchema.xsd';
<br>> > a registered resource factory is needed
<br>> > at
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
<br>> > at
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
<br>> > at
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:708)
<br>> >
<br>> > Ed Merks wrote:
<br>> >
<br>> > > Hayden,
<br>> >
<br>> > > I've never seen a "zip:" protocol before. I've seen "jar:",
which is
<br>maybe
<br>> > the same? In any event, our URI
<br>> > > implementation has special support for treating "jar:" as a hierarchical
<br>URI
<br>> > even though it doesn't conform to the grammar
<br>> > > for a hierarchical URI, i.e., there's no leading "/" after the
scheme.
<br>This
<br>> > special support is not there for "zip:", so
<br>> > > that will be treated as non-hierarchical and hence it has no
file
<br>extension
<br>> > that can be used to find a resource factory.
<br>> > > Where did this "zip:" thing come from? Can you use "jar:"
instead? You
<br>> > could use the URIConverter to normalize "zip:" to
<br>> > > "jar:"...
<br>> >
<br>> > > Hayden Marchant wrote:
<br>> >
<br>> > > > I am trying to run the Eclipse XSD parser within Weblogic 8.1
App
<br>Server.
<br>> > > > I am using XSD 1.1.1 and this version has worked fine in all
other
<br>> > > > execution environments.
<br>> > > >
<br>> > > > In my code, I register the xsd resource factory with the following
<br>code:
<br>> > > >
<br>> > > >
ResourceSet resourceSet = new ResourceSetImpl();
<br>> > > >
<br>> > > >
<br>> >
<br> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
<br>> > > >
new XSDResourceFactoryImpl());
<br>> > > >
<br>> > > > I use the wildcard '*' since I want all files that go through
this
<br>parser
<br>> > > > to be treated as xsd's to allow for bad file names.
<br>> > > >
<br>> > > > I am getting the following exception when trying to read an
xsd which
<br>is
<br>> > > > called a few lines after the resource factory registry:
<br>> > > >
<br>> > > > java.lang.RuntimeException: Cannot create a resource for
<br>> > > >
<br>> >
<br> 'zip:E:/bea/user_projects/domains/unicorn/myserver/.wlnotdel ete/extract/myserver_unicorn_unicorn/jarfil
<br>> > > >
<br>> >
<br> es/WEB-INF/lib/xsd.resources36809.jar!/org/eclipse/xsd/plugi n.properties/cache/www.w3.org/2001/XMLSchema-instance.xsd';
<br>> > > > a registered resource factory is needed
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
<br>> > > > at
<br>> > > >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
<br>> > > > at
<br>> > > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
<br>> > > > at
<br>> > > >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
<br>> > > > at
<br>> > > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
<br>> > > > at
<br> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
<br>> > > > at
<br>> > > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
<br>> > > > at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:286)
<br>> > > >
<br>> > > > Thanks,
<br>> > > > Hayden Marchant</blockquote>
</html>
--------------9CC46910E1656C802F139E75--
Ed Merks
Professional Support: https://www.macromodeling.com/
|
|
|
Goto Forum:
Current Time: Thu Apr 18 11:10:57 GMT 2024
Powered by FUDForum. Page generated in 0.02455 seconds
|