Werner,
I am not sure if you see my post to this thread. The source generator is
broken when dealing with xsd:enumeration with the base type xsd:NMTOKEN
and xsd:inteter. There may be others but I only encountered these two. I
filed a bug on this (CASTOR-1267). Can you verify if this is the same
bug here?
thanks
Bill
Werner Guttmann wrote:
Stefan,
Can you please create a new issue at
http://jira.codehaus.org/browse/CASTOR, and attach all relevant files to
replay your problem. Iow, at least the mapping file (relevant portions
only) and the Java class as generated. If you could follow the bug
submission guidelines available at
http://www.castor.org/how-to-submit-a-bug.html
that would really help us
FYI, I think I know what the problem is, but I need a test case to play
with, and I'd appreciate your help here (hence me asking you to file a
new bug report).
Thanks
Werner
-----Original Message-----
From: Stefan Lober [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 23. November 2005 12:51
To: [email protected]
Subject: RE: [castor-user] [XML/JDO] Problems using
ClassDescriptors and a mapping file
Werner,
I have attached the stack trace.
Regards,
Stefan
--- Werner Guttmann <[EMAIL PROTECTED]>
schrieb:
Stefan,
Based upon Keith's comment, can you please post the complete stack
trace ?
Werner
-----Original Message-----
From: Keith Visco [mailto:[EMAIL PROTECTED]
Sent: Mittwoch, 23. November 2005 06:19
To: [email protected]
Subject: Re: [castor-user] [XML/JDO] Problems
using
ClassDescriptors and a mapping file
Stefan,
Type-safe enum style classes are generated without
a default
constructor. Castor XML handles these types of
classes, I
believe some work recently went into Castor JDO
for
supporting them as well, but I don't know the
extent of their support.
http://castor.codehaus.org/xml-mapping.html#7.5-Type-safe-enum
eration-mapping
You can use descriptors with a mapping, but the
mapping will
take precedence, so I recommend you remove any
items from the
mapping file that you don't want to customize and
then let
the descriptors handle the rest.
If you want to override just one field and let the
generated
descriptor do the rest, you can do the following:
<class name="Foo" auto-complete="true">
<field name="bar" handler="BarHandler"/>
</class>
Castor will load the FooDescriptor and then
override the
associated bar FieldDescriptor with the above
mapping.
You can also specify a GeneralizedFieldHandler
without a
mapping file if you use a binding-file during
source generation.
--Keith
Stefan Lober wrote:
Hello,
I have built my project around Castor using an
XML Schema
as starting
point for my development.
The development process is planned to be as
follows:
XSD => Java source (via SourceGenerator) Java
source =>
Java classes
(Java compiler) Java classes => mapping file for
XML&JDO
(MappingTool)
I have modified the MappingTool class, so that
it also
integrates JDO
mapping information in my mapping file.
The intention is to unmarshal an XML document
(described by
the XSD)
and persist it in the database.
Unfortunately, a construct in the XSD causes
some problems. This is
it:
<element name="state">
<complexType mixed="true">
<attribute name="id" type="int" use="optional"
/>
<attribute name="state-moment" use="required">
<simpleType>
<restriction base="NMTOKEN">
<enumeration value="Unknown" />
<enumeration value="StateEnd" />
<enumeration value="StateBegin" />
</restriction>
</simpleType>
</attribute>
<attribute name="stamptime" type="string"
use="required" />
</complexType>
</element>
This element is referenced from a another
element in the schema.
First, I had let the SourceGenerator generate
ONLY the
classes and NO
class descriptors (with -gen-mapping and
-nodesc).
I get this mapping back from MappingTool:
<class cst:name="log.State"
cst:depends="log.Systemstates" cst:identity="id"
cst:key-generator="MAX">
<description>Default mapping for class
log.State</description>
<map-to cst:table="State" cst:xml="state" />
<field
cst:name="valid"
cst:type="boolean">
<sql name="valid" dirty="check" />
<bind-xml name="valid" node="attribute" />
</field>
<field cst:name="id" cst:type="integer">
<sql name="id" type="integer" dirty="check" />
<bind-xml name="id" node="attribute" />
</field>
<field cst:name="content" cst:type="string">
<sql name="content" type="char" dirty="check"
/>
<bind-xml name="content" node="element" />
</field>
<field cst:name="stamptime" cst:type="string">
<sql name="stamptime" type="char"
dirty="check" />
<bind-xml name="stamptime" node="element" />
</field>
</class>
This gives me the following error when the
unmarshal method
is called:
Illegal Text data found as child of: state
value: "INIT"{file: [not available]; line: 5;
column: 85}
at
org.exolab.castor.xml.Unmarshaller.unmarshal(Unmarshaller.java:671)
The according XML line ist this:
<state state-moment="StateBegin"
stamptime="2005-10-25T11:46:09" >INIT</state>
---------------------------------
So I tried using the class descriptors.
Unmarshalling the
XML document
works now. But as soon as I try to persist the
data in the
DB, I have
to use the generated mapping (form MappingTool).
The call of
JDOManager.loadConfiguration results in the
following
exception:
org.exolab.castor.mapping.MappingException: The
Java class
log.types.StateStateMomentType is not
constructable -- it does not
contain a default public constructor
at
org.exolab.castor.mapping.loader.ClassDescriptorImpl.<init>(ClassDescr
iptorImpl.java:161)
Is my approach of using class descriptors AND a
mapping file the
reason for this problem?
Is it possible to solve this?
Another question: Is it possible to use a
GerealizedFieldHandler
WITHOUT a mapping file?
Any hint would be appreciated.
Stefan
=== message truncated ===
___________________________________________________________
Gesendet von Yahoo! Mail - Jetzt mit 1GB Speicher kostenlos -
Hier anmelden: http://mail.yahoo.de
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
-------------------------------------------------
If you wish to unsubscribe from this list, please
send an empty message to the following address:
[EMAIL PROTECTED]
-------------------------------------------------
