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/17 09:59:48 UTC
Easing JaxMe development
Hi there!
I have a few comments that might help with JaxMe development:
- Don't include documentation in the src folder. Instead, provide an ant
build for generating docs. When synchronizing cvs it gets quite tedious at
first to have to download all docs. This could probably get more people
involved.
- Use dependency for JAXB-API. In know it is a pain to have to include three
jars (jaxb, namespace and qname) but this is particularly useful if I would
like to use jaxb and jaxme together.
- Use Maven for project management. Maven is particularly useful for
dependency management. You could use the maven generated site or use a
wonderful forrest plugin they have built. (I can help here, I can provide
you a ready configured POM). You would probably like multi-project support.
Just ask if you need help here.
- Move the build/pm/src to a src folder. It makes it quite confusing to have
completely different src folders.
- Remove from src distribution not compilable code (or provide classes -
this is probably much better). An example would be
org.apache.ws.jaxme.examples.misc.address or org.apache.ws.jaxme.junit.
I think solving this issues would encourage a lot more people to give a hand
to this project.
I havn't seen these issues documented so I'll comment them to check (should
I file bugs?):
- Version 0.2's ant task doesn't take the package property, making it quite
inconvenient when building multiple object mappings.
- Version 0.3's ant task takes the package property, but complains if it
isn't set in jaxb bindings.
- Neither 0.2 and 0.3 seem to take seriously the xjc:serialize global
binding.
- We've talked about recursion (and I know it is documented). Should I open
a bug before trying to solve?
Thanks for your attention,
Nacho G. Mac Dowell
PD: What is the minimum jdk for this project?
---------------------------------------------------------------------
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
Recursion
Posted by "Nacho G. Mac Dowell" <ig...@informa.es>.
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: Easing JaxMe development
Posted by Jochen Wiedmann <jo...@freenet.de>.
Hi,
thanks for your comments. Here are my comments:
Nacho G. Mac Dowell wrote:
>- Don't include documentation in the src folder. Instead, provide an ant
>build for generating docs. When synchronizing cvs it gets quite tedious at
>first to have to download all docs. This could probably get more people
>involved.
>
>
+0: AFAIK, this is standard behaviour for Apache projects. I am
basically fine with you and dislike the giant documentation folder a lot
(hope to reduce it soon by packing some static documents into a zipped
archive), but I think we have to stick with it.
>- Use dependency for JAXB-API. In know it is a pain to have to include three
>jars (jaxb, namespace and qname) but this is particularly useful if I would
>like to use jaxb and jaxme together.
>
>
-1: I understand, that you want us to use the JAXB RI jar files? AFAIK,
this is still impossible, due to the RI license. If the RI changes its
license at any point (for example to BSD license, like JavaCC), I'll
follow you here.
>- Use Maven for project management. Maven is particularly useful for
>dependency management. You could use the maven generated site or use a
>wonderful forrest plugin they have built. (I can help here, I can provide
>you a ready configured POM). You would probably like multi-project support.
>Just ask if you need help here.
>
>
+0: Never used Maven. If anyone does the work (you?), then its fine with
me. Personally, I must admit that I do not even know, what it could help us.
>- Move the build/pm/src to a src folder. It makes it quite confusing to have
>completely different src folders.
>
>
-1: IMO it is very important to have all generated files below "build".
Otherwise, we wouldn't be able to have a clean separation between
manually written and generated sources.
>- Remove from src distribution not compilable code (or provide classes -
>this is probably much better). An example would be
>org.apache.ws.jaxme.examples.misc.address or org.apache.ws.jaxme.junit.
>
>
These are compilable, after you are running "ant test". I must admit,
though, that this is nonobvious. Open for any suggestions, how to
document the fact.
>- Version 0.2's ant task doesn't take the package property, making it quite
>inconvenient when building multiple object mappings.
>
>
Known bug, it used to be called "packageName" here.
>- Version 0.3's ant task takes the package property, but complains if it
>isn't set in jaxb bindings.
>
>
This sounds like JAXME-18 in Jira? If so, it ought to be fixed in CVS.
>- Neither 0.2 and 0.3 seem to take seriously the xjc:serialize global
>binding.
>
>
Possible. If so, please file a bug report.
>- We've talked about recursion (and I know it is documented). Should I open
>a bug before trying to solve?
>
>
I think to remember asking for a stack trace that explains the
StackOverflow error?
>PD: What is the minimum jdk for this project?
>
>
In theory 1.2. However, this is untested and no one ensures, that the
classes can be built with 1.2 or that the prerequisite jar files depend
on 1.2. Definite is 1.4. Everything else is "give it a try".
Jochen
---------------------------------------------------------------------
To unsubscribe, e-mail: jaxme-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: jaxme-dev-help@ws.apache.org