Eclipse Community Forums: EMF » EMF code fails parsing XML string when run inside Tomcat

Home » Modeling » EMF » EMF code fails parsing XML string when run inside Tomcat

EMF code fails parsing XML string when run inside Tomcat [message #413623]

Fri, 05 October 2007 02:30

Eclipse User

We are having great problems here with some EMF generated code. What the
code does is rather simple: it reads a model (passed in as an XML
(String), does a few manipulations to the model (in essence some
filtering) and then serializes it back into an XML (String) and returns
that. The EMF code was generated from the model's .xsd file (which is
rather big, so the generated code is substantial).

When run inside a test program the code runs perfectly. When executing
the very same code inside Tomcat (v6.0.13) then parsing the XML string
into a model fails giving error messages "Feature '<something>' not
found" (see partial stack trace below).

org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'<name here>' not found. (<URL here>, 19, 68)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:81)
at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:189)
at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
...

The strange thing is, that the "Feature" (corresponding or an XML
element) that can not be found changes practically with each build, i.e.
one build fails, if the passed-in XML contains, say, an element 'A',
after the slightest modification (e.g. adding a println() statement to
the code somewhere) it then suddenly fails, if the code contains an
element 'B', but happily works if it contains one or more element(s)
'A'.

We investigated all kinds of suspicions, even weird and unlikely ones
like eg. that Tomcat runs class-intialization and actual calls in
different threads, such that the class initialization is not yet fully
completed when the code is called, etc. but none of these wild shots
into the dark showed yielded any result or solution. Running our
stand-alone test program with the very same input always works without
any hickup. After chasing this for en entire day now, we ran out of
steam and ideas what could cause this. Any ideas? Has someone else seen
similar effects or a clue what could be going on here or why some
Features are missing while others are found and work fine and why the
Feature missing always changes?

The EMF code used to generate the model code is the Europa version.

Michael

Re: EMF code fails parsing XML string when run inside Tomcat [message #413629 is a reply to message #413623]

Fri, 05 October 2007 06:58

Eclipse User

This is a multi-part message in MIME format.
--------------060608060201000501040607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Micahel,

Even the title is already making me think, you're going to need to do
some registrations if you aren't running on OSGi. More comments below...

Michael Moser wrote:
> We are having great problems here with some EMF generated code.
And by great you don't me good do you!
> What the code does is rather simple: it reads a model (passed in as an
> XML (String), does a few manipulations to the model (in essence some
> filtering) and then serializes it back into an XML (String) and
> returns that. The EMF code was generated from the model's .xsd file
> (which is rather big, so the generated code is substantial).
>
> When run inside a test program the code runs perfectly. When executing
> the very same code inside Tomcat (v6.0.13) then parsing the XML string
> into a model fails giving error messages "Feature '<something>' not
> found" (see partial stack trace below).
>
> org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
> '<name here>' not found. (<URL here>, 19, 68)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:81)
>
> at
> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:189)
> at
> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
>
> at
> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>
> ...
Sounds highly likely to be an issue which having the right resource
factory (the generated one) with the right options (like the ones in the
generated one) registered.
>
> The strange thing is, that the "Feature" (corresponding or an XML
> element) that can not be found changes practically with each build,
> i.e. one build fails, if the passed-in XML contains, say, an element
> 'A', after the slightest modification (e.g. adding a println()
> statement to the code somewhere) it then suddenly fails, if the code
> contains an element 'B', but happily works if it contains one or more
> element(s) 'A'.
That sounds a little psycho...
>
> We investigated all kinds of suspicions, even weird and unlikely ones
> like eg. that Tomcat runs class-intialization and actual calls in
> different threads, such that the class initialization is not yet fully
> completed when the code is called, etc. but none of these wild shots
> into the dark showed yielded any result or solution. Running our
> stand-alone test program with the very same input always works without
> any hickup. After chasing this for en entire day now, we ran out of
> steam and ideas what could cause this. Any ideas? Has someone else
> seen similar effects or a clue what could be going on here or why some
> Features are missing while others are found and work fine and why the
> Feature missing always changes?
Maybe the issue is related to having a class loader scoped registry.
Normally that would make an EPackage not be found, but maybe these
different elements that aren't being found are global elements matching
wildcards so it is package visibility related. It's worth to set

-Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=org.eclip se.emf.ecore.impl.EPackageRegistryImpl
to force EMF to use the same registry implementation used when running
in OGSi (where all packages are visible to the whole JVM) rather than
the default standalone one (where packages are visible only in the scope
of the class loader that loaded them). Here's how it's initialized:

public static EPackage.Registry createGlobalRegistry()
{
try
{
String className =
System.getProperty("org.eclipse.emf.ecore.EPackage.Registry.INSTANCE ");
if (className == null)
{
if (EcorePlugin.getDefaultRegistryImplementation() != null)
{
return EcorePlugin.getDefaultRegistryImplementation();
}
else if (!EMFPlugin.IS_ECLIPSE_RUNNING)
{
return new Delegator();
}
else
{
return new EPackageRegistryImpl();
}
}
else
{
return
(EPackage.Registry)Class.forName(className).newInstance();
}
}
catch (Exception exception)
{
EcorePlugin.INSTANCE.log(exception);
return new EPackageRegistryImpl();
}
}

> The EMF code used to generate the model code is the Europa version.
>
> Michael
>

--------------060608060201000501040607
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Micahel, 
 
Even the title is already making me think, you're going to need to do
some registrations if you aren't running on OSGi.  More comments
below... 
 
Michael Moser wrote:
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite">We
are having great problems here with some EMF generated code.</blockquote>
And by great you don't me good do you! 
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite"> What
the code does is rather simple: it reads a model (passed in as an XML
(String), does a few manipulations to the model (in essence some
filtering) and then serializes it back into an XML (String) and returns
that. The EMF code was generated from the model's .xsd file (which is
rather big, so the generated code is substantial).
 
 
When run inside a test program the code runs perfectly. When executing
the very same code inside Tomcat (v6.0.13) then parsing the XML string
into a model fails giving error messages "Feature '<something>'
not found" (see partial stack trace below).
 
 
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'<name here>' not found. (<URL here>, 19, 68)
 
       at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:81)
 
       at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:189)
 
       at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
 
       at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
 
       ...
 
</blockquote>
Sounds highly likely to be an issue which having the right resource
factory (the generated one) with the right options (like the ones in
the generated one) registered. 
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite"> 
The strange thing is, that the "Feature" (corresponding or an XML
element) that can not be found changes practically with each build,
i.e. one build fails, if the passed-in XML contains, say, an element
'A', after the slightest modification (e.g. adding a println()
statement to the code somewhere) it then suddenly fails, if the code
contains an element 'B', but happily works if it contains one or more
element(s) 'A'.
 
</blockquote>
That sounds a little psycho... 
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite"> 
We investigated all kinds of suspicions, even weird and unlikely ones
like eg. that Tomcat runs class-intialization and actual calls in
different threads, such that the class initialization is not yet fully
completed when the code is called, etc. but none of these wild shots
into the dark showed yielded any result or solution. Running our
stand-alone test program with the very same input always works without
any hickup. After chasing this for en entire day now, we ran out of
steam and ideas what could cause this. Any ideas? Has someone else seen
similar effects or a clue what could be going on here or why some
Features are missing while others are found and work fine and why the
Feature missing always changes?
 
</blockquote>
Maybe the issue is related to having a class loader scoped registry. 
Normally that would make an EPackage not be found, but maybe these
different elements that aren't being found are global elements matching
wildcards so it is package visibility related. It's worth to set 
 
-Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=org.eclip se.emf.ecore.impl.EPackageRegistryImpl
to force EMF to use the same registry implementation used when running
in OGSi (where all packages are visible to the whole JVM) rather than
the default standalone one (where packages are visible only in the
scope of the class loader that loaded them).  Here's how it's
initialized: 

<blockquote>  public static EPackage.Registry
createGlobalRegistry() 
  { 
    try 
    { 
      String className =
System.getProperty("org.eclipse.emf.ecore.EPackage.Registry.INSTANCE "); 
      if (className == null) 
      { 
          if (EcorePlugin.getDefaultRegistryImplementation() !=
null) 
          { 
            return
EcorePlugin.getDefaultRegistryImplementation(); 
          } 
          else if (!EMFPlugin.IS_ECLIPSE_RUNNING) 
          { 
            return new Delegator(); 
          } 
          else 
          { 
            return new EPackageRegistryImpl(); 
          } 
      } 
      else 
      { 
          return
(EPackage.Registry)Class.forName(className).newInstance(); 
      } 
    } 
    catch (Exception exception) 
    { 
      EcorePlugin.INSTANCE.log(exception); 
      return new EPackageRegistryImpl(); 
    } 
  } 
</blockquote>
 
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite">The
EMF code used to generate the model code is the Europa version.
 
 
Michael
 
 
</blockquote>
 
</body>
</html>

--------------060608060201000501040607--

Re: EMF code fails parsing XML string when run inside Tomcat [message #413633 is a reply to message #413623]

Fri, 05 October 2007 07:44

Eclipse User

hi michael,

>>org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
>>'<name here>' not found. (<URL here>, 19, 68)

does the URL really exist when you get that error? i once had a problem
where everything worked just fine in my junit testsuite, but not on the
server. in the end i found out it was because some of the objects/files
referenced by the object to be loaded, where available in my testing
environment but not on the server.

chris

Re: EMF code fails parsing XML string when run inside Tomcat [message #413640 is a reply to message #413629]

Fri, 05 October 2007 10:54

Eclipse User

This is a multi-part message in MIME format.

------=_NextPart_000_000E_01C80770.76CA9A60
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Ed - you did it again! You are my hero!

Not only did the suggested =
" -Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=3Dorg.ecl ipse.emf.eco=
re.impl.EPackageRegistryImpl" fix these odd "Feature <...> not found" =
problem, but also another issue I hadn't even reported, namely that the =
first two calls into EMF generated code (after starting/loading the =
code) ALWAYS failed, only the third (and all subsequent calls) worked. =
We actually had written a loop around that first call that did it three =
times, because EACH time after initialization the first two calls into =
the EMF code failed and afterwards things worked (well - mostly - except =
for the bug I reported here). These startup problems were also the =
reasons why we had suspected some startup timing or race conditions...

Anyway, this now works reliably and without any startup hickup. But =
frankly: Why is this odd behavior the default? How is anyone without =
such intimate knowledge of EMF as yours supposed to detect and solve =
such issues???=20

Cheers, Michael

"Ed Merks" <merks@ca.ibm.com> wrote in message =
news:fe55cm$tka$1@build.eclipse.org...
Micahel,

Even the title is already making me think, you're going to need to do =
some registrations if you aren't running on OSGi. More comments =
below...

Michael Moser wrote:=20
We are having great problems here with some EMF generated code.
And by great you don't me good do you!

What the code does is rather simple: it reads a model (passed in as =
an XML (String), does a few manipulations to the model (in essence some =
filtering) and then serializes it back into an XML (String) and returns =
that. The EMF code was generated from the model's .xsd file (which is =
rather big, so the generated code is substantial).=20

When run inside a test program the code runs perfectly. When =
executing the very same code inside Tomcat (v6.0.13) then parsing the =
XML string into a model fails giving error messages "Feature =
'<something>' not found" (see partial stack trace below).=20

org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature =
'<name here>' not found. (<URL here>, 19, 68)=20
at =
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:=
81)=20
at =
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:189)=20
at =
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.jav=
a:180)=20
at =
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1=
354)=20
...=20

Sounds highly likely to be an issue which having the right resource =
factory (the generated one) with the right options (like the ones in the =
generated one) registered.

The strange thing is, that the "Feature" (corresponding or an XML =
element) that can not be found changes practically with each build, i.e. =
one build fails, if the passed-in XML contains, say, an element 'A', =
after the slightest modification (e.g. adding a println() statement to =
the code somewhere) it then suddenly fails, if the code contains an =
element 'B', but happily works if it contains one or more element(s) =
'A'.=20

That sounds a little psycho...

We investigated all kinds of suspicions, even weird and unlikely =
ones like eg. that Tomcat runs class-intialization and actual calls in =
different threads, such that the class initialization is not yet fully =
completed when the code is called, etc. but none of these wild shots =
into the dark showed yielded any result or solution. Running our =
stand-alone test program with the very same input always works without =
any hickup. After chasing this for en entire day now, we ran out of =
steam and ideas what could cause this. Any ideas? Has someone else seen =
similar effects or a clue what could be going on here or why some =
Features are missing while others are found and work fine and why the =
Feature missing always changes?=20

Maybe the issue is related to having a class loader scoped registry. =
Normally that would make an EPackage not be found, but maybe these =
different elements that aren't being found are global elements matching =
wildcards so it is package visibility related. It's worth to set

=
-Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=3Dorg.ecl ipse.emf.ecor=
e.impl.EPackageRegistryImpl to force EMF to use the same registry =
implementation used when running in OGSi (where all packages are visible =
to the whole JVM) rather than the default standalone one (where packages =
are visible only in the scope of the class loader that loaded them). =
Here's how it's initialized:

public static EPackage.Registry createGlobalRegistry()
{
try
{
String className =3D =
System.getProperty("org.eclipse.emf.ecore.EPackage.Registry.INSTANCE ");
if (className =3D=3D null)
{
if (EcorePlugin.getDefaultRegistryImplementation() !=3D =
null)
{
return EcorePlugin.getDefaultRegistryImplementation();
}
else if (!EMFPlugin.IS_ECLIPSE_RUNNING)
{
return new Delegator();
}
else
{
return new EPackageRegistryImpl();
}
}
else
{
return =
(EPackage.Registry)Class.forName(className).newInstance();
}
}
catch (Exception exception)
{
EcorePlugin.INSTANCE.log(exception);
return new EPackageRegistryImpl();
}
}

The EMF code used to generate the model code is the Europa version.=20

Michael=20

------=_NextPart_000_000E_01C80770.76CA9A60
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type =
content=3Dtext/html;charset=3DISO-8859-1>
<META content=3D"MSHTML 6.00.6000.16525" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY text=3D#000000 bgColor=3D#ffffff>
<DIV>Ed - you did it again! You are my hero!</DIV>
<DIV> </DIV>
<DIV>Not only did the suggested "<FONT=20
face=3D"Times New Roman"=20
size=3D3> -Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=3Dorg.ecl ipse=
..emf.ecore.impl.EPackageRegistryImpl"=20
fix these odd "Feature <...> not found" problem, but also another =
issue I=20
hadn't even reported, namely that the first two calls into EMF =
generated=20
code (after starting/loading the code) ALWAYS failed, only the =
third (and=20
all subsequent calls) worked. We =
actually had=20
written a loop around that first call that did it three times, because =
EACH time=20
after initialization the first two calls into the EMF code failed and =
afterwards=20
things worked (well - mostly - except for the bug I reported here). =
These=20
startup problems were also the reasons why we had suspected some startup =
timing=20
or race conditions...</DIV>
<DIV> </DIV>
<DIV>Anyway, this now works reliably and =
without any=20
startup hickup. But frankly: Why is =
this odd=20
behavior the default? How is anyone without such intimate knowledge of =
EMF as=20
yours supposed to detect and solve such issues??? </DIV>
<DIV> </DIV>
<DIV>Cheers, Michael</DIV>
<DIV> </DIV>
<DIV> </DIV>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV>"Ed Merks" <<A =
href=3D"mailto:merks@ca.ibm.com">merks@ca.ibm.com</A>>=20
wrote in message <A=20
=
href=3D"news:fe55cm$tka$1@build.eclipse.org">news:fe55cm$tka$1@build.ecli=
pse.org</A>...</DIV>Micahel, Even=20
the title is already making me think, you're going to need to do some=20
registrations if you aren't running on OSGi.  More comments=20
below... Michael Moser wrote:=20
<BLOCKQUOTE cite=3Dmid:fe4lm6$9kn$1@build.eclipse.org type=3D"cite">We =
are=20
having great problems here with some EMF generated =
code.</BLOCKQUOTE>And by=20
great you don't me good do you! 
<BLOCKQUOTE cite=3Dmid:fe4lm6$9kn$1@build.eclipse.org =
type=3D"cite">What the=20
code does is rather simple: it reads a model (passed in as an XML =
(String),=20
does a few manipulations to the model (in essence some filtering) =
and then=20
serializes it back into an XML (String) and returns that. The EMF =
code was=20
generated from the model's .xsd file (which is rather big, so the =
generated=20
code is substantial). When run inside a test program the =
code runs=20
perfectly. When executing the very same code inside Tomcat (v6.0.13) =
then=20
parsing the XML string into a model fails giving error messages =
"Feature=20
'<something>' not found" (see partial stack trace below).=20
 org.eclipse.emf.ecore.resource.Resource$IOWrappedException: =
Feature=20
'<name here>' not found. (<URL here>, 19, 68)=20
        at=20
=
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:=
81)=20
        at=20
=
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:189)=20
        at=20
=
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.jav=
a:180)=20
        at=20
=
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1=
354)=20
        ... </BLOCKQUOTE>Sounds =
highly=20
likely to be an issue which having the right resource factory (the =
generated=20
one) with the right options (like the ones in the generated one)=20
registered. 
<BLOCKQUOTE cite=3Dmid:fe4lm6$9kn$1@build.eclipse.org =
type=3D"cite"> The=20
strange thing is, that the "Feature" (corresponding or an XML =
element) that=20
can not be found changes practically with each build, i.e. one build =
fails,=20
if the passed-in XML contains, say, an element 'A', after the =
slightest=20
modification (e.g. adding a println() statement to the code =
somewhere) it=20
then suddenly fails, if the code contains an element 'B', but =
happily works=20
if it contains one or more element(s) 'A'. </BLOCKQUOTE>That =
sounds a=20
little psycho... 
<BLOCKQUOTE cite=3Dmid:fe4lm6$9kn$1@build.eclipse.org =
type=3D"cite"> We=20
investigated all kinds of suspicions, even weird and unlikely ones =
like eg.=20
that Tomcat runs class-intialization and actual calls in different =
threads,=20
such that the class initialization is not yet fully completed when =
the code=20
is called, etc. but none of these wild shots into the dark showed =
yielded=20
any result or solution. Running our stand-alone test program with =
the very=20
same input always works without any hickup. After chasing this for =
en entire=20
day now, we ran out of steam and ideas what could cause this. Any =
ideas? Has=20
someone else seen similar effects or a clue what could be going on =
here or=20
why some Features are missing while others are found and work fine =
and why=20
the Feature missing always changes? </BLOCKQUOTE>Maybe the issue =
is=20
related to having a class loader scoped registry.  Normally that =
would=20
make an EPackage not be found, but maybe these different elements that =
aren't=20
being found are global elements matching wildcards so it is package =
visibility=20
related. It's worth to=20
=
set -Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=3Dorg.ecl ip=
se.emf.ecore.impl.EPackageRegistryImpl=20
to force EMF to use the same registry implementation used when running =
in OGSi=20
(where all packages are visible to the whole JVM) rather than the =
default=20
standalone one (where packages are visible only in the scope of the =
class=20
loader that loaded them).  Here's how it's=20
initialized: 
<BLOCKQUOTE>  public static EPackage.Registry=20
createGlobalRegistry()  =20
{    =20
try    =20
{       String className =
=3D=20
=
System.getProperty("org.eclipse.emf.ecore.EPackage.Registry.INSTANCE ");</=
SMALL>      =20
if (className =3D=3D =
null)      =20
{          if=20
(EcorePlugin.getDefaultRegistryImplementation() !=3D=20
null)         =20
=
{          &nbsp=
;=20
return=20
=
EcorePlugin.getDefaultRegistryImplementation();  &=
nbsp;     =20
}          else =
if=20
=
(!EMFPlugin.IS_ECLIPSE_RUNNING)    &nbsp=
;   =20
=
{          &nbsp=
;=20
return new=20
=
Delegator();         =
=20
}         =20
else         =20
=
{          &nbsp=
;=20
return new=20
=
EPackageRegistryImpl();      &=
nbsp; =20
}      =20
}      =20
else      =20
{          =
return=20
=
(EPackage.Registry)Class.forName(className).newInstance(); <SM=
ALL>     =20
}    =20
}     catch (Exception=20
exception)    =20
{      =20
=
EcorePlugin.INSTANCE.log(exception);    =
  =20
return new =
EPackageRegistryImpl();    =20
}   } </BLOCKQUOTE> 
<BLOCKQUOTE cite=3Dmid:fe4lm6$9kn$1@build.eclipse.org =
type=3D"cite">The EMF code=20
used to generate the model code is the Europa version. =
 Michael=20
 </BLOCKQUOTE> </BLOCKQUOTE></BODY></HTML>

------=_NextPart_000_000E_01C80770.76CA9A60--

Re: EMF code fails parsing XML string when run inside Tomcat [message #413641 is a reply to message #413640]

Fri, 05 October 2007 15:32

Eclipse User

This is a multi-part message in MIME format.
--------------070602010807000402080304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael,

I regret the day that I ever offered to help provide an alternative
implementation directly :'( In my defense, I was trying to be
helpful. No good deed goes unpunished. My thinking was that generally
stand alone users would not be doing funky class loader games so they
wouldn't even notice that a class loader scoped implementation was being
used (which has generally proven to be a good assumption) and that if
they did have funky class loaders and played with
Thread.getContentClassLoader(), the way web servers tend to do, then the
solution the WAS folks wanted would be useful for them too. The latter
is kind of a bad assumption. I should have forced users to use a flag
to get the class loader scoped one so that they would always have JVM
scoped package visibility unless they knowingly requested otherwise.
But I bowed to the pressure of "it's so hard to set the flag
consistently everywhere". I should have pointed out that if that's so
hard, that problem should be solved, because users will likely have
other reasons for consistently wanting to set a flag everywhere. See,
you have me ranting again!

Michael Moser wrote:
> Ed - you did it again! You are my hero!
>
> Not only did the
> suggested " -Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=org.eclip se..emf.ecore.impl.EPackageRegistryImpl "
> fix these odd "Feature <...> not found" problem, but also another
> issue I hadn't even reported, namely that the first two calls into EMF
> generated code (after starting/loading the code) ALWAYS failed, only
> the third (and all subsequent calls) worked. We actually had written a
> loop around that first call that did it three times, because EACH time
> after initialization the first two calls into the EMF code failed and
> afterwards things worked (well - mostly - except for the bug I
> reported here). These startup problems were also the reasons why we
> had suspected some startup timing or race conditions...
>
> Anyway, this now works reliably and without any startup hickup. But
> frankly: Why is this odd behavior the default? How is anyone without
> such intimate knowledge of EMF as yours supposed to detect and solve
> such issues???
>
> Cheers, Michael
>
>
>
> "Ed Merks" <merks@ca.ibm.com <mailto:merks@ca.ibm.com>> wrote in
> message news:fe55cm$tka$1@build.eclipse.org...
> Micahel,
>
> Even the title is already making me think, you're going to need to
> do some registrations if you aren't running on OSGi. More
> comments below...
>
> Michael Moser wrote:
>> We are having great problems here with some EMF generated code.
> And by great you don't me good do you!
>> What the code does is rather simple: it reads a model (passed in
>> as an XML (String), does a few manipulations to the model (in
>> essence some filtering) and then serializes it back into an XML
>> (String) and returns that. The EMF code was generated from the
>> model's .xsd file (which is rather big, so the generated code is
>> substantial).
>>
>> When run inside a test program the code runs perfectly. When
>> executing the very same code inside Tomcat (v6.0.13) then parsing
>> the XML string into a model fails giving error messages "Feature
>> '<something>' not found" (see partial stack trace below).
>>
>> org.eclipse.emf.ecore.resource.Resource$IOWrappedException:
>> Feature '<name here>' not found. (<URL here>, 19, 68)
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:81)
>>
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:189)
>>
>> at
>> org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
>>
>> at
>> org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
>>
>> ...
> Sounds highly likely to be an issue which having the right
> resource factory (the generated one) with the right options (like
> the ones in the generated one) registered.
>>
>> The strange thing is, that the "Feature" (corresponding or an XML
>> element) that can not be found changes practically with each
>> build, i.e. one build fails, if the passed-in XML contains, say,
>> an element 'A', after the slightest modification (e.g. adding a
>> println() statement to the code somewhere) it then suddenly
>> fails, if the code contains an element 'B', but happily works if
>> it contains one or more element(s) 'A'.
> That sounds a little psycho...
>>
>> We investigated all kinds of suspicions, even weird and unlikely
>> ones like eg. that Tomcat runs class-intialization and actual
>> calls in different threads, such that the class initialization is
>> not yet fully completed when the code is called, etc. but none of
>> these wild shots into the dark showed yielded any result or
>> solution. Running our stand-alone test program with the very same
>> input always works without any hickup. After chasing this for en
>> entire day now, we ran out of steam and ideas what could cause
>> this. Any ideas? Has someone else seen similar effects or a clue
>> what could be going on here or why some Features are missing
>> while others are found and work fine and why the Feature missing
>> always changes?
> Maybe the issue is related to having a class loader scoped
> registry. Normally that would make an EPackage not be found, but
> maybe these different elements that aren't being found are global
> elements matching wildcards so it is package visibility related.
> It's worth to set
>
> -Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=org.eclip se.emf.ecore.impl.EPackageRegistryImpl
> to force EMF to use the same registry implementation used when
> running in OGSi (where all packages are visible to the whole JVM)
> rather than the default standalone one (where packages are visible
> only in the scope of the class loader that loaded them). Here's
> how it's initialized:
>
> public static EPackage.Registry createGlobalRegistry()
> {
> try
> {
> String className =
> System.getProperty("org.eclipse.emf.ecore.EPackage.Registry.INSTANCE ");
> if (className == null)
> {
> if (EcorePlugin.getDefaultRegistryImplementation() !=
> null)
> {
> return EcorePlugin.getDefaultRegistryImplementation();
> }
> else if (!EMFPlugin.IS_ECLIPSE_RUNNING)
> {
> return new Delegator();
> }
> else
> {
> return new EPackageRegistryImpl();
> }
> }
> else
> {
> return
> (EPackage.Registry)Class.forName(className).newInstance();
> }
> }
> catch (Exception exception)
> {
> EcorePlugin.INSTANCE.log(exception);
> return new EPackageRegistryImpl();
> }
> }
>
>
>> The EMF code used to generate the model code is the Europa version.
>>
>> Michael
>>
>

--------------070602010807000402080304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Michael, 
 
I regret the day that I ever offered to help provide an alternative
implementation directly  :'(   
In my defense, I was trying to be helpful.   No good deed goes
unpunished.  My thinking was that generally stand alone users would not
be doing funky class loader games so they wouldn't even notice that a
class loader scoped implementation was being used (which has generally
proven to be a good assumption) and that if they did have funky class
loaders and played with Thread.getContentClassLoader(), the way web
servers tend to do, then the solution the WAS folks wanted would be
useful for them too.  The latter is kind of a bad assumption.  I should
have forced users to use a flag to get the class loader scoped one so
that they would always have JVM scoped package visibility unless they
knowingly requested otherwise.  But I bowed to the pressure of "it's so
hard to set the flag consistently everywhere".  I should have pointed
out that if that's so hard, that problem should be solved, because
users will likely have other reasons for consistently wanting to set a
flag everywhere.  See, you have me ranting again! 
 
 
Michael Moser wrote:
<blockquote cite="mid:fe5j82$hb0$1@build.eclipse.org" type="cite">
<meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
<meta content="MSHTML 6.00.6000.16525" name="GENERATOR">
<style></style>
<div>Ed - you did it again! You are my hero!</div>
<div> </div>
<div>Not only did the suggested " -Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=org.eclip se..emf.ecore.impl.EPackageRegistryImpl "
fix these odd "Feature <...> not found" problem, but also another
issue I hadn't even reported, namely that the first two calls into EMF
generated code (after starting/loading the code) ALWAYS failed, only
the third (and all subsequent calls) worked. We actually had written a loop around that first call that
did it three times, because EACH time after initialization the first
two calls into the EMF code failed and afterwards things worked (well -
mostly - except for the bug I reported here). These startup problems
were also the reasons why we had suspected some startup timing or race
conditions...</div>
<div> </div>
<div>Anyway, this now works reliably and
without any startup hickup. But
frankly: Why is this odd behavior the default? How is anyone without
such intimate knowledge of EMF as yours supposed to detect and solve
such issues??? </div>
<div> </div>
<div>Cheers, Michael</div>
<div> </div>
<div> </div>
<blockquote
style="border-left: 2px solid rgb(0, 0, 0); padding-right: 0px; padding-left: 5px; margin-left: 5px; margin-right: 0px;">
<div>"Ed Merks" <<a moz-do-not-send="true"
href="mailto:merks@ca.ibm.com">merks@ca.ibm.com</a>> wrote in
message <a moz-do-not-send="true"
href="news:fe55cm$tka$1@build.eclipse.org">news:fe55cm$tka$1@build.eclipse.org</a>...</div>
Micahel, 
 
Even the title is already making me think, you're going to need to do
some registrations if you aren't running on OSGi.  More comments
below... 
 
Michael Moser wrote:
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite">We
are having great problems here with some EMF generated code.</blockquote>
And by great you don't me good do you! 
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite">What
the code does is rather simple: it reads a model (passed in as an XML
(String), does a few manipulations to the model (in essence some
filtering) and then serializes it back into an XML (String) and returns
that. The EMF code was generated from the model's .xsd file (which is
rather big, so the generated code is substantial). 
 
When run inside a test program the code runs perfectly. When executing
the very same code inside Tomcat (v6.0.13) then parsing the XML string
into a model fails giving error messages "Feature '<something>'
not found" (see partial stack trace below). 
 
org.eclipse.emf.ecore.resource.Resource$IOWrappedException: Feature
'<name here>' not found. (<URL here>, 19, 68) 
       at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.handleErrors(XMLL oadImpl.java:81)
 
       at
org.eclipse.emf.ecore.xmi.impl.XMLLoadImpl.load(XMLLoadImpl. java:189) 
       at
org.eclipse.emf.ecore.xmi.impl.XMLResourceImpl.doLoad(XMLRes ourceImpl.java:180)
 
       at
org.eclipse.emf.ecore.resource.impl.ResourceImpl.load(Resour ceImpl.java:1354)
 
       ... 
</blockquote>
Sounds highly likely to be an issue which having the right resource
factory (the generated one) with the right options (like the ones in
the generated one) registered. 
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite"> 
The strange thing is, that the "Feature" (corresponding or an XML
element) that can not be found changes practically with each build,
i.e. one build fails, if the passed-in XML contains, say, an element
'A', after the slightest modification (e.g. adding a println()
statement to the code somewhere) it then suddenly fails, if the code
contains an element 'B', but happily works if it contains one or more
element(s) 'A'. 
</blockquote>
That sounds a little psycho... 
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite"> 
We investigated all kinds of suspicions, even weird and unlikely ones
like eg. that Tomcat runs class-intialization and actual calls in
different threads, such that the class initialization is not yet fully
completed when the code is called, etc. but none of these wild shots
into the dark showed yielded any result or solution. Running our
stand-alone test program with the very same input always works without
any hickup. After chasing this for en entire day now, we ran out of
steam and ideas what could cause this. Any ideas? Has someone else seen
similar effects or a clue what could be going on here or why some
Features are missing while others are found and work fine and why the
Feature missing always changes? 
</blockquote>
Maybe the issue is related to having a class loader scoped registry. 
Normally that would make an EPackage not be found, but maybe these
different elements that aren't being found are global elements matching
wildcards so it is package visibility related. It's worth to set 
 
-Dorg.eclipse.emf.ecore.EPackage.Registry.INSTANCE=org.eclip se.emf.ecore.impl.EPackageRegistryImpl
to force EMF to use the same registry implementation used when running
in OGSi (where all packages are visible to the whole JVM) rather than
the default standalone one (where packages are visible only in the
scope of the class loader that loaded them).  Here's how it's
initialized: 

<blockquote>  public static EPackage.Registry
createGlobalRegistry() 
  { 
    try 
    { 
      String className =
System.getProperty("org.eclipse.emf.ecore.EPackage.Registry.INSTANCE "); 
      if (className == null) 
      { 
          if (EcorePlugin.getDefaultRegistryImplementation()
!= null) 
          { 
            return
EcorePlugin.getDefaultRegistryImplementation(); 
          } 
          else if (!EMFPlugin.IS_ECLIPSE_RUNNING) 
          { 
            return new Delegator(); 
          } 
          else 
          { 
            return new EPackageRegistryImpl(); 
          } 
      } 
      else 
      { 
          return
(EPackage.Registry)Class.forName(className).newInstance(); 
      } 
    } 
    catch (Exception exception) 
    { 
      EcorePlugin.INSTANCE.log(exception); 
      return new EPackageRegistryImpl(); 
    } 
  } 
</blockquote>
 
<blockquote cite="mid:fe4lm6$9kn$1@build.eclipse.org" type="cite">The
EMF code used to generate the model code is the Europa version. 
 
Michael 
 
</blockquote>
 
</blockquote>
</blockquote>
 
</body>
</html>

--------------070602010807000402080304--

Previous Topic:	Does EMF.Edit supports notification for TextViewer?
Next Topic:	RecordingCommand makes editor dirty even when there is no change

Goto Forum:

-=] Back to Top [=-

Current Time: Mon Jul 28 04:47:42 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter