You are viewing a plain text version of this content. The canonical link for it is here.
Posted to jaxme-dev@ws.apache.org by "Nacho G. Mac Dowell" <ig...@informa.es> on 2004/08/18 12:09:19 UTC
Recursion
Thanks for such a quick answer! (for my comments).
Regarding recursion, you were right! It is quite straight forward to
implement it. I must say at this point that I am quite impressed with your
work: both the generated sources and jaxme itself are pretty legible (I
can't say the same with jaxb...painful...) -- THANKS. (JS framework rocks)
So, to the point now. The first stackOverflowError raises when executing the
ant task (or generating classes, more precisely). When
org.apache.ws.jaxme.generator.sg.impl.JAXBType checks for a default value
(hasDefaultValue(XSType)) it doesn't check for recursion. This can easily be
acheived while looping through the particles checking that they are not
actually from the same type as its parent. So: continue searching for a
default value iff it isn't the same type as its parent:
if (!subElement.getType().equals(type)) {
//continue searching....
}
I am not sure if this would correctly get the default value, though...
You'll have to assist here...
So the modified method would be:
private boolean hasDefaultValue(XSType type) throws SAXException {
..
for (int i = 0; i < particles.length; i++) {
XSElement subElement = particles[i].getElement();
if (!subElement.getType().equals(type)){
....
}
}
return false;
}
The second stackOverflowError raises when trying to marshal the java tree.
The thing is that the Serializer classes creates its child serializers
recursively. If one of the children has the same type as its parent it will
continously create a child serializer even if it has been created (itself is
a child serializer for this type). So, to fix this, we move to
org.apache.ws.jaxme.generator.sg.impl.JAXBGroupSG and make sure the method
getXMLSerializersInitMethod doesn't create a child serializer of its same
type. This is acheived:
private JavaMethod getXMLSerializersInitMethod(GroupSG pController,
JavaSource pSource) throws SAXException {
.....
if (child.getTypeSG().isGlobalClass()) {
if (serializerClass.getClassName().equals(pSource.getClassName())){
jm.addLine(jf, " = this;");
} else {
jm.addLine(jf, " = (", serializerClass, ") ", pFactory,
".getJMXmlSerializer(", elementInterface, ".class);");
}
} else {
jm.addLine(jf, " = new ", serializerClass, "();");
}
if (!serializerClass.getClassName().equals(pSource.getClassName())){
jm.addLine(jf, ".init(pFactory);");
}
}
return jm;
}
As you can see it is now checking if it is the same class as its parent.
Actually I am quite amazed with the ease of adding support to recursive
schemas! I don't see this having any side effects. If you've got comments
regarding this I would appreciate. There is a thing which is getting in my
head: If the child is of the same type, but has been extended: what would
happen?
Do you want me to file these to JIRA? Separate them? They probably should.
Even if they raise the same error, the nature is completely different. Of
course, I'll provide the test cases.
And finally, another question (yes, i am sorry...): When using a Servlet
Container, I create the jaxb context and when restarting the container and
trying to get the context again, it raises a JAXBException:
The object created by
org.apache.ws.jaxme.impl.JAXBContextImpl.createContext(String,ClassLoader)
cannot be casted to javax.xml.bind.JAXBContext.
caused by a ClassCastException. The thing is that I used to get the same
error with JAXB (yes, I am sticking with jaxme now...). Any ideas? I am
pretty sure it's got to do with classloading, but do you have any clue on
how to solve this? A custom implementation of JAXBContext?
PD: For testing purposes (and not only testing) it would be nice to have a
method isEquivalent or just use equals for this purpose. It shouldn't be
difficult once the object is marshalled. What do you think?
PPD: I'll construct a Project Object Model for you and give you some basic
guidelines to see if you're interested in using Maven. I think it suits
specially well projects with external dependencies like yours.
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: Minimum JDK: 1.4
Posted by Jochen Wiedmann <jo...@freenet.de>.
Thanks for bringing this up.
Nacho G. Mac Dowell wrote:
>org.apache.ws.jaxme.generator.sg.impl.JAXBSchemaReader
>86: Throwable t = e.getCause(); //since 1.4
>
>
This is possible even a bug, as e.getTargetException() should be used at
this place. (May be, both methods return the same, though.)
>org.apache.ws.jaxme.xs.util.XsDateTimeFormat
>266: int offset = tz.getOffset(cal.getTimeInMillis()); //since 1.4
>
>
Replaced with getTime().getTime()
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Minimum JDK: 1.4
Posted by "Nacho G. Mac Dowell" <ig...@informa.es>.
I found that the minimum jdk for jaxme at the moment is 1.4 since it uses
methods that are only present since 1.4. I think moving to 1.3 is fairly
simple though. I can check later for all problems (I think the PM uses 1.4
extensively) but for the moment:
org.apache.ws.jaxme.generator.sg.impl.JAXBSchemaReader
86: Throwable t = e.getCause(); //since 1.4
org.apache.ws.jaxme.xs.util.XsDateTimeFormat
266: int offset = tz.getOffset(cal.getTimeInMillis()); //since 1.4
I'll report later this properly (with all the occurences).
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: Recursion
Posted by Jochen Wiedmann <jo...@freenet.de>.
Hi, Nacho,
I have created an issue in Jira (JAXME-26) and attached a slightly
modified version of your patch. Should work against the 0.3 branch as
well as HEAD.
As long as we don't have a test suite that validates a correct function,
I am hesitating to check it in. Would it be possible for you to supply
something?
>PD: Just wondering, what does SG stand for?
>
>
Sourge Generator
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
RE: Recursion
Posted by "Nacho G. Mac Dowell" <ig...@informa.es>.
I made some tests for testing direct recursion, indirect recursion and
potential direct recursion. As you stated before, the second test (indirect
recursion) gives a stackOverflowError. I was thinking on how to solve this
problem and I think it could be pretty straight forward: Initialize the
children serializers on demand (lazily). The problem that arises is that in
some ocasions we need a reference to the JAXBContext to be able to create
some serializers. So what I propose is to hold a reference to the context
setting it in the init method. So the init method will only set this
reference (not creating any objects) and before using any children
serializers we check if it is null and if it's not, create it and initialize
it (to set the reference to jaxbcontext). I can't see a way to initialize
the serializers in the beginning without having cycles with recursion.
I hope I explained myself properly. I changed this behaviour in the
generated classes and it's working just fine. Below are the changes I made
to the generator as well. A few comments:
- By design, when you marshal an object the only exception thrown is
SAXException. The thing is that with lazy initialization we are calling the
init method which throws a JAXBException (I am not sure but I think it is
not necessary anymore since all it does is to set a reference to the
JAXBContext) and getJMXmlSerializer (from JAXBContextImpl) throws a marshal
exception. So right now I am just catching them and do nothing. Have a look
and tell me how you think it would be best to do it. Throw a new
SAXException with the description of the Marshal exception?
Also I ignored the hasDefaultValue (you mentioned it was going to
dissapear?) method to be able to generate the java classes (it gave another
stackOverflowError).
file: src\jaxme\org\apache\ws\jaxme\generator\sg\impl\JAXBGroupSG.java
@@ -244,13 +244,6 @@
Context myClassContext =
child.getTypeSG().getComplexTypeSG().getClassContext();
JavaQName serializerClass = myClassContext.getXMLSerializerName();
JavaField jf = pSource.newJavaField(serializerName, serializerClass,
JavaSource.PRIVATE);
- JavaQName elementInterface = myClassContext.getXMLInterfaceName();
- if (child.getTypeSG().isGlobalClass()) {
- jm.addLine(jf, " = (", serializerClass, ") ", pFactory,
".getJMXmlSerializer(", elementInterface, ".class);");
- } else {
- jm.addLine(jf, " = new ", serializerClass, "();");
- }
- jm.addLine(jf, ".init(pFactory);");
}
return jm;
}
@@ -283,6 +276,21 @@
f.setFinal(true);
f.addLine("new ", QName.class, "(",
JavaSource.getQuoted(objectSG.getName().getNamespaceURI()),
", ",
JavaSource.getQuoted(objectSG.getName().getLocalName()), ");");
+ Context myClassContext =
child.getObjectSG().getTypeSG().getComplexTypeSG().getClassContext();
+ JavaQName serializerClass = myClassContext.getXMLSerializerName();
+ JavaQName elementInterface = myClassContext.getXMLInterfaceName();
+ pMethod.addIf(fieldName + " == null");
+ pMethod.addTry();
+ if (child.getObjectSG().getTypeSG().isGlobalClass()) {
+ pMethod.addLine(fieldName + " = ("+ serializerClass+ ") ",
"getFactory().getJMXmlSerializer(", elementInterface, ".class);");
+ }
+ else {
+ pMethod.addLine(fieldName + " = new ", serializerClass, "();");
+ pMethod.addLine(fieldName + ".init(getFactory());");
+ }
+ pMethod.addCatch(java.lang.Exception.class);
+ pMethod.addEndTry();
+ pMethod.addEndIf();
if (objectSG.getTypeSG().isComplex()) {
pMethod.addLine(fieldName, ".marshal(", data, ", ", f, ", ",
pValue, ");");
} else {
file: org.apache.ws.jaxme.impl.JMXmlSerializerImpl
@@ -36,6 +36,8 @@
public class JMXmlSerializerImpl implements JMXmlSerializer {
private static final Attributes zeroAttributes = new AttributesImpl();
+ private org.apache.ws.jaxme.impl.JAXBContextImpl factory;
+
protected class Data implements JMXmlSerializer.Data {
private int cnt;
private JMMarshaller marshaller;
@@ -73,7 +75,9 @@
}
}
- public void init(JAXBContextImpl pFactory) throws JAXBException {}
+ public void init(JAXBContextImpl pFactory) throws JAXBException {
+ setFactory(pFactory);
+ }
public String getPreferredPrefix(String pURI) {
return null;
@@ -171,5 +175,13 @@
}
handler.endPrefixMapping(prefix);
}
+ }
+
+ protected org.apache.ws.jaxme.impl.JAXBContextImpl getFactory() {
+ return factory;
+ }
+
+ protected void setFactory(org.apache.ws.jaxme.impl.JAXBContextImpl
factory) {
+ this.factory = factory;
}
}
PD: Just wondering, what does SG stand for?
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: Recursion
Posted by Jochen Wiedmann <jo...@freenet.de>.
Ias wrote:
>I also think that "no element, no default" policy would be right. Actually
>what I understand regarding default in XML is that you need to write a
>self-closing element to provide its default value.
>
Agreed 100% :-)
>In other words, as far as
>I'm concerned, there's no requirement to retrieve the default value of an
>element with minOccurs="0" and maxOccurs="1" when it doesn't appear in an
>XML instance. (Please correct me if I'm wrong. I'm also very curious of the
>mechanism in XML :-) [Theoretical viewpoint]
>
>
I am quite sure, that the view of XML schema is the same. Otherwise, the
minOccurs value and the use of default values could be an obvious
contradiction.
>By the way, I'm on my way to Axis Summit 2 in Sri Lanka, so maybe can't
>respond soon. If I'm asked to express my opinion, I'm +0 on changing JaxMe's
>mechanism on default values (slightly on practical side though :-).
>
>
If noone disagrees, I'll remove the method within the next week.
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
RE: Recursion
Posted by Ias <ia...@hotmail.com>.
> Hi, Nacho,
>
> thanks for your excellent analysis. I think we'll be through
> quite shortly with recursion. :-)
>
> Nacho G. Mac Dowell wrote:
>
> >ant task (or generating classes, more precisely). When
> >org.apache.ws.jaxme.generator.sg.impl.JAXBType checks for a default
> >value
> >(hasDefaultValue(XSType)) it doesn't check for recursion.
> >
>
> hmm, I wonder whether that method is actually required?
>
> Ias, please help: If I get it right, then the task of the
> "hasDefaultValue(XSType)" method is as follows:
>
> If a complex child element has an attribute or simple
> element with a default value
> (directly or indirectly, in another complex child
> element), then the complex child
> element is instantiated.
>
> However, I would think that this is wrong. For example:
>
> <xs:element name="foo">
> <xs:complexType>
> <xs:sequence>
> <xs:element name="bar" minOccurs="0">
> <xs:complexType>
> <xs:attribute name="x" type="xs:string" default=""/>
> </xs:complexType>
> </xs:element>
> </xs:sequence>
> </xs:complexType>
> </xs:element>
>
> I agree, that "x" has to be filled, if "bar" is instantiated.
> However, I cannot think of a reason, why "bar" should be
> instantiated, if "foo" is?
Let me explain the rationale of the logic. Here's an example:
[schema]
<xs:element name="foo1">
<xs:complexType>
<xs:element name="bar1" type="xs:string" minOccurs="0" default="OK"/>
</xs:complexType>
</xs:element>
<xs:element name="foo2">
<xs:complexType>
<xs:element ref="foo1" minOccurs="0"/>
<xs:element ref="bar2" type="xs:string"/>
</xs:complexType>
</xs:element>
[instance]
<foo2>
<bar2>
</foo2>
One of my colleagues in my company asked me to get default value of bar1 of
foo1, "OK", when he unmarshalled the above XML instance. That meant foo1
(and bar1 as well) could be omitted, but that omission should lead to the
default value. It's quite common that users leave many "minOccurs zero"
elements out and expect default values. However, JAXB 1.0 doesn't mention
about how its implementation behave for the case. [Practical viewpoint]
I also think that "no element, no default" policy would be right. Actually
what I understand regarding default in XML is that you need to write a
self-closing element to provide its default value. In other words, as far as
I'm concerned, there's no requirement to retrieve the default value of an
element with minOccurs="0" and maxOccurs="1" when it doesn't appear in an
XML instance. (Please correct me if I'm wrong. I'm also very curious of the
mechanism in XML :-) [Theoretical viewpoint]
I'd like to talk about this issue in JAXB 2.0, but now we are in JAXB 1.0,
so it's totally up to implementors' decision.
By the way, I'm on my way to Axis Summit 2 in Sri Lanka, so maybe can't
respond soon. If I'm asked to express my opinion, I'm +0 on changing JaxMe's
mechanism on default values (slightly on practical side though :-).
Thanks,
Ias
>
>
> > This can easily be
> >acheived while looping through the particles checking that
> they are not
> >actually from the same type as its parent. So: continue
> searching for a
> >default value iff it isn't the same type as its parent:
> >
> > if (!subElement.getType().equals(type)) {
> > //continue searching....
> > }
> >
> >
>
> That is, IMO, only sufficient, if the element is referencing
> itself for
> recursion. It is insufficient for indirect references.
> However, using a
> Set would do.
>
>
> >The second stackOverflowError raises when trying to marshal
> the java tree.
> >The thing is that the Serializer classes creates its child
> serializers
> >recursively. If one of the children has the same type as its
> parent it will
> >continously create a child serializer even if it has been
> created (itself is
> >a child serializer for this type). So, to fix this, we move to
> >org.apache.ws.jaxme.generator.sg.impl.JAXBGroupSG and make
> sure the method
> >getXMLSerializersInitMethod doesn't create a child
> serializer of its same
> >type. This is acheived:
> >
> >private JavaMethod getXMLSerializersInitMethod(GroupSG pController,
> >JavaSource pSource) throws SAXException {
> > .....
> > if (child.getTypeSG().isGlobalClass()) {
> > if
> (serializerClass.getClassName().equals(pSource.getClassName())){
> >
> >
>
> Understood the problem. However, the solution is again too simple,
> because it ignores
> the case of an indirect recursion.
>
> >As you can see it is now checking if it is the same class as
> its parent.
> >Actually I am quite amazed with the ease of adding support
> to recursive
> >schemas!
> >
>
> I had recursion in mind when writing that stuff. Never had
> the time to
> test it, though.
>
>
> > I don't see this having any side effects. If you've got comments
> >regarding this I would appreciate. There is a thing which is
> getting in my
> >head: If the child is of the same type, but has been
> extended: what would
> >happen?
> >
> >
>
> Good question, which i delegate for later. ;-)
>
>
> >Do you want me to file these to JIRA? Separate them? They
> probably should.
> >Even if they raise the same error, the nature is completely
> different. Of
> >course, I'll provide the test cases.
> >
> >
>
> A bug report would be excellent. Attach your mail, that'll do. Test
> cases would be
> *extremely welcome*! Ideally two test cases: One of an element
> referencing itself,
> the other of a child element referencing the parent.
>
> >And finally, another question (yes, i am sorry...): When
> using a Servlet
> >Container, I create the jaxb context and when restarting the
> container and
> >trying to get the context again, it raises a JAXBException:
> >The object created by
> >org.apache.ws.jaxme.impl.JAXBContextImpl.createContext(String
> ,ClassLoader)
> >cannot be casted to javax.xml.bind.JAXBContext.
> >caused by a ClassCastException. The thing is that I used to
> get the same
> >error with JAXB (yes, I am sticking with jaxme now...). Any
> ideas? I am
> >pretty sure it's got to do with classloading, but do you
> have any clue on
> >how to solve this? A custom implementation of JAXBContext?
> >
> >
> This sounds *very* much to me like you are having multiple
> instances of
> JAXBContext floating around. Possible ideas:
>
> - The JAXB RI jar files are still in place.
> - The jaxbapi.jar file is both in the web application and in the
> containers class path.
>
> Is either of these possible?
>
> If not, simply do the following: Add statements like the following to
> the relevant places:
>
> System.err.println("URI of JAXBContext: " +
>
> context.getClass().getClassLoader.getRessource("javax/xml/bind
> /JAXBContext.class");
>
> This will clearly tell you, where the classes are loaded from.
>
>
>
> >PD: For testing purposes (and not only testing) it would be
> nice to have a
> >method isEquivalent or just use equals for this purpose. It
> shouldn't be
> >difficult once the object is marshalled. What do you think?
> >
> >
>
> I can't follow you here. Are you talking about the detection
> of recursion?
>
> In the case of global elements, using the equals method should do. (I
> think so, at
> least. ;-)
>
> >PPD: I'll construct a Project Object Model for you and give
> you some basic
> >guidelines to see if you're interested in using Maven. I
> think it suits
> >specially well projects with external dependencies like yours.
> >
> >
>
> Any help is welcome. :-)
>
>
> Jochen
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: jaxme-dev-help@ws.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org
Re: Recursion
Posted by Jochen Wiedmann <jo...@freenet.de>.
Hi, Nacho,
thanks for your excellent analysis. I think we'll be through quite
shortly with recursion. :-)
Nacho G. Mac Dowell wrote:
>ant task (or generating classes, more precisely). When
>org.apache.ws.jaxme.generator.sg.impl.JAXBType checks for a default value
>(hasDefaultValue(XSType)) it doesn't check for recursion.
>
hmm, I wonder whether that method is actually required?
Ias, please help: If I get it right, then the task of the
"hasDefaultValue(XSType)" method is as follows:
If a complex child element has an attribute or simple element with a
default value
(directly or indirectly, in another complex child element), then the
complex child
element is instantiated.
However, I would think that this is wrong. For example:
<xs:element name="foo">
<xs:complexType>
<xs:sequence>
<xs:element name="bar" minOccurs="0">
<xs:complexType>
<xs:attribute name="x" type="xs:string" default=""/>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
I agree, that "x" has to be filled, if "bar" is instantiated. However, I
cannot think of a reason, why "bar" should be instantiated, if "foo" is?
> This can easily be
>acheived while looping through the particles checking that they are not
>actually from the same type as its parent. So: continue searching for a
>default value iff it isn't the same type as its parent:
>
> if (!subElement.getType().equals(type)) {
> //continue searching....
> }
>
>
That is, IMO, only sufficient, if the element is referencing itself for
recursion. It is insufficient for indirect references. However, using a
Set would do.
>The second stackOverflowError raises when trying to marshal the java tree.
>The thing is that the Serializer classes creates its child serializers
>recursively. If one of the children has the same type as its parent it will
>continously create a child serializer even if it has been created (itself is
>a child serializer for this type). So, to fix this, we move to
>org.apache.ws.jaxme.generator.sg.impl.JAXBGroupSG and make sure the method
>getXMLSerializersInitMethod doesn't create a child serializer of its same
>type. This is acheived:
>
>private JavaMethod getXMLSerializersInitMethod(GroupSG pController,
>JavaSource pSource) throws SAXException {
> .....
> if (child.getTypeSG().isGlobalClass()) {
> if (serializerClass.getClassName().equals(pSource.getClassName())){
>
>
Understood the problem. However, the solution is again too simple,
because it ignores
the case of an indirect recursion.
>As you can see it is now checking if it is the same class as its parent.
>Actually I am quite amazed with the ease of adding support to recursive
>schemas!
>
I had recursion in mind when writing that stuff. Never had the time to
test it, though.
> I don't see this having any side effects. If you've got comments
>regarding this I would appreciate. There is a thing which is getting in my
>head: If the child is of the same type, but has been extended: what would
>happen?
>
>
Good question, which i delegate for later. ;-)
>Do you want me to file these to JIRA? Separate them? They probably should.
>Even if they raise the same error, the nature is completely different. Of
>course, I'll provide the test cases.
>
>
A bug report would be excellent. Attach your mail, that'll do. Test
cases would be
*extremely welcome*! Ideally two test cases: One of an element
referencing itself,
the other of a child element referencing the parent.
>And finally, another question (yes, i am sorry...): When using a Servlet
>Container, I create the jaxb context and when restarting the container and
>trying to get the context again, it raises a JAXBException:
>The object created by
>org.apache.ws.jaxme.impl.JAXBContextImpl.createContext(String,ClassLoader)
>cannot be casted to javax.xml.bind.JAXBContext.
>caused by a ClassCastException. The thing is that I used to get the same
>error with JAXB (yes, I am sticking with jaxme now...). Any ideas? I am
>pretty sure it's got to do with classloading, but do you have any clue on
>how to solve this? A custom implementation of JAXBContext?
>
>
This sounds *very* much to me like you are having multiple instances of
JAXBContext floating around. Possible ideas:
- The JAXB RI jar files are still in place.
- The jaxbapi.jar file is both in the web application and in the
containers class path.
Is either of these possible?
If not, simply do the following: Add statements like the following to
the relevant places:
System.err.println("URI of JAXBContext: " +
context.getClass().getClassLoader.getRessource("javax/xml/bind/JAXBContext.class");
This will clearly tell you, where the classes are loaded from.
>PD: For testing purposes (and not only testing) it would be nice to have a
>method isEquivalent or just use equals for this purpose. It shouldn't be
>difficult once the object is marshalled. What do you think?
>
>
I can't follow you here. Are you talking about the detection of recursion?
In the case of global elements, using the equals method should do. (I
think so, at
least. ;-)
>PPD: I'll construct a Project Object Model for you and give you some basic
>guidelines to see if you're interested in using Maven. I think it suits
>specially well projects with external dependencies like yours.
>
>
Any help is welcome. :-)
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org