Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » XML Schema Definition (XSD) » Registered resource factory problem
Registered resource factory problem [message #38930] Tue, 16 March 2004 15:47 Go to next message
Hayden Marchant is currently offline Hayden MarchantFriend
Messages: 90
Registered: July 2009
Member
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 #38955 is a reply to message #38930] Tue, 16 March 2004 16:30 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Hayden Marchant is currently offline Hayden MarchantFriend
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 Go to previous messageGo to next message
Eclipse UserFriend
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 Go to previous messageGo to next message
Hayden Marchant is currently offline Hayden MarchantFriend
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 Go to previous message
Eclipse UserFriend
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.&nbsp; The JDKs I've been using produce "file:/..." not "file:..."
and "jar:" not "zip:".&nbsp; 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.&nbsp; 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>&nbsp;
<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&nbsp; 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.&nbsp;
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.&nbsp;&nbsp; I'm still curious where the "zip:" came
<br>> from.&nbsp; 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>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; 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.&nbsp; I've seen "jar:",
which is
<br>maybe
<br>> > the same?&nbsp;&nbsp; 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?&nbsp; Can you use "jar:"
instead?&nbsp; 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>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
ResourceSet resourceSet = new ResourceSetImpl();
<br>> > > >
<br>> > > >
<br>> >
<br> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
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>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; 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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31557
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 Go to previous message
Hayden Marchant is currently offline Hayden MarchantFriend
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31557
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 Go to previous message
Hayden Marchant is currently offline Hayden MarchantFriend
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 Go to previous message
Ed Merks is currently offline Ed MerksFriend
Messages: 31557
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.&nbsp; The JDKs I've been using produce "file:/..." not "file:..."
and "jar:" not "zip:".&nbsp; 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.&nbsp; 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>&nbsp;
<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&nbsp; 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.&nbsp;
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.&nbsp;&nbsp; I'm still curious where the "zip:" came
<br>> from.&nbsp; 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>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaForSchema(XSDSch emaImpl.java:633)
<br>> > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; 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.&nbsp; I've seen "jar:",
which is
<br>maybe
<br>> > the same?&nbsp;&nbsp; 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?&nbsp; Can you use "jar:"
instead?&nbsp; 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>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;
ResourceSet resourceSet = new ResourceSetImpl();
<br>> > > >
<br>> > > >
<br>> >
<br> resourceSet.getResourceFactoryRegistry().getExtensionToFacto ryMap().put( "*",
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
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>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.getResou rce(ResourceSetImpl.java:282)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.getSchemaInstance(XSDSche maImpl.java:710)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.resolveSchema(XSDSchemaIm pl.java:2039)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > > org.eclipse.xsd.impl.XSDSchemaImpl.patch(XSDSchemaImpl.java: 1485)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.changeAttribute(XSDSchema Impl.java:2240)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDConcreteComponentImpl.eNotify(XSDCon creteComponentImpl.java:1205)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.xsd.impl.XSDSchemaImpl.setSchemaLocation(XSDSche maImpl.java:842)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > > org.eclipse.xsd.util.XSDResourceImpl.attached(XSDResourceImp l.java:410)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl$ContentsELi st.inverseAdd(ResourceImpl.java:326)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.common.notify.impl.NotifyingListImpl.addUniq ue(NotifyingListImpl.java:233)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br> org.eclipse.emf.common.util.BasicEList.add(BasicEList.java:5 88)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > > org.eclipse.xsd.util.XSDResourceImpl.doLoad(XSDResourceImpl. java:374)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:881)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:755)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; at
<br>> > > >
<br>> >
<br> org.eclipse.emf.ecore.resource.impl.ResourceSetImpl.demandLo ad(ResourceSetImpl.java:220)
<br>> > > > &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp; 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/
Previous Topic:Registered resource factory problem
Next Topic:Schema Validation Problem
Goto Forum:
  


Current Time: Thu Oct 29 02:49:51 GMT 2020

Powered by FUDForum. Page generated in 0.02727 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top