I finally got it figured out. I had read your response before back
when I was searching the web for an answer. Just didnt realize
it was from you until I got the exact same response. I guess its something
that comes up a lot.
Anyway, it turned out that I had been setting my classpath variable
too deep down the path. It was an obvious DOH when I finally realized
what it was that I had been doing wrong.
Anyway, thanks yet again. Now I get to play with ant to see if I can
do the same thing I did with scomp.
-----Original Message-----
From: Lawrence Jones [mailto:[EMAIL PROTECTED]
Sent: Thursday, February 02, 2006 9:49 AM
To: [email protected]
Subject: RE: xsdconfig
The TypeSystemHolder class is a generated .class file which represents
the mediator between the world of generated classes representing the
types/elements in your schema (e.g. your Message.class file) and the
.xsb files which are XmlBeans equivalent of .class files but holding
binary, serialized data about the schema from which the type was
generated.
But the TypeSystemHolder class is special in that it is generated in the
_binary_ output directory i.e. the argument to -d (if you use scomp) or
classgendir (if you are using the ant task).
If you are unable to see the TypeSystemHolder class then you probably
just need to include this binary directory on your classpath. This often
happens if people use the -srconly flag and then compile the code
themselves or if they use an IDE to look at the generated .java files.
Every generated class representing a type or element has a public static
variable called 'type'. This variable used to have an explicit mention
of the TypeSystemHolder class. This meant that if you failed to include
the binary directory in your classpath then whatever was looking at the
generated class (e.g. IDE's) would flag that as an unresolved class.
As of SVN # 220181 a change was checked in so that the type variable
refers to TypeSystemHolder via reflection instead of directly. This
should fix any problems with IDE's or compilers and is included in the
latest release (2.1).
Cheers,
Lawrence
> -----Original Message-----
> From: Bartlett, David HLTH:EX [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 01, 2006 4:32 PM
> To: [email protected]
> Subject: RE: xsdconfig
>
>
> Son of a ......
> It was the stupid missing namespace. How odd. I thought I had
> tried that before and it didnt work. I had tried a multitude of
different
> things to get this to work (which is the reason for the missing
> underscores
> in the Qname). sigh. I guess I had my head so deeply buried in the
problem
> that I couldn't see the computer screen for the pixels.
>
> Well, once again thanks. That just leaves my final issue
regarding
> the TypeSystemHolder error I get when I try to run the code after I
> compile
> to source instead of to a jar file.
>
> -----Original Message-----
> From: Lawrence Jones [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, February 01, 2006 3:42 PM
> To: [email protected]
> Subject: RE: xsdconfig
>
>
> Hi David
>
> It looks like you're missing the namespace qualifier for your type and
> also that your QName was missing a few underscores (it must match
> exactly what is in the schema). Try something like this:
>
> <xb:config
> xmlns:xb="http://xml.apache.org/xmlbeans/2004/02/xbean/config";
> xmlns:yourNS="yourNamespaceHere">
> <xb:namespace uri="urn:hl7-org:v3">
>
> <xb:package>com.ibm.sample.xmlbeans.QUPC_IN000001CA</xb:package>
> </xb:namespace>
>
> <xb:qname
> name="yourNS:QUPC_IN000001CA.MCCI_MT000100CA.Message"
> javaname="Message"/>
> </xb:config>
>
> I had a quick look at the code - it doesn't look like its elements
only,
> but it was only a quick look - I could be wrong.
>
> Cheers,
>
> Lawrence
>
> > -----Original Message-----
> > From: Bartlett, David HLTH:EX [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 01, 2006 2:56 PM
> > To: [email protected]
> > Subject: RE: xsdconfig
> >
> >
> >
> > Unfortunately, I've read that one already as well as several
> others
> > very
> > similar to it. And while I was able to change the package name I was
> not
> > able
> > to do the same for the class name. Here is the simple file I had
> created.
> >
> >
> > <xb:config
> > xmlns:xb="http://xml.apache.org/xmlbeans/2004/02/xbean/config";>
> > <xb:namespace uri="urn:hl7-org:v3">
> >
> > <xb:package>com.ibm.sample.xmlbeans.QUPC_IN000001CA</xb:package>
> > </xb:namespace>
> >
> > <xb:qname name="QUPCIN000001C.AMCCIMT000100CA.Message"
> > javaname="Message"/>
> > </xb:config>
> >
> >
> > Have I defined the class name conversion incorrectly?
> >
> >
> > -----Original Message-----
> > From: Lawrence Jones [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, February 01, 2006 2:49 PM
> > To: [email protected]
> > Subject: RE: xsdconfig
> >
> >
> > Hi David
> >
> > You can change both package and class names (and do other useful
> things
> > such as ensure that your generated XmlBeans implement a
user-supplied
> > interface) using an xsdconfig file - see, for instance, the article
at
> > http://dev2dev.bea.com/pub/a/2004/11/Configuring_XMLBeans.html for
> > details on how to do this.
> >
> > Cheers,
> >
> > Lawrence
> >
> > > -----Original Message-----
> > > From: Bartlett, David HLTH:EX [mailto:[EMAIL PROTECTED]
> > > Sent: Wednesday, February 01, 2006 2:30 PM
> > > To: [email protected]
> > > Subject: xsdconfig
> > >
> > >
> > > Since my xml delimiter issue was solved so easily when I thought
> > it
> > > was going
> > > to be a next to impossible task I thought I'd pass on another
issue
> I
> > had
> > > given up on.
> > >
> > > Part of what we want to do with this project is customize the
> > names
> > > of the classes
> > > that are generated because the default names are godawful. I was
> able
> > to
> > > do it with
> > > JAXB no problem (one of the few things that actually worked) but
was
> > not
> > > able to do it
> > > with the xsdconfig file. My guess is that the xsdconfig
> customization
> > only
> > > works on tags declared
> > > as elements in the xsd while the ones we want to change are
defined
> as
> > > complex types.
> > >
> > > For example, currently the the following
> > >
> > > <xs:complexType
> > > name="QUPC_IN000001CA.MCCI_MT000100CA.Message">
> > >
> > > is causing the following classes to be generated
> > >
> > > QUPC_IN000001CAMCCI_MT000100CAMessage
> > >
> > QUPC_IN000001CAMCCI_MT000100CAMessageImpl
> > >
> > > when we would like the following to be created
> > >
> > > Message
> > > MessageImpl
> > >
> > > Is that possible?
> > >
> > >
> > >
> > > David Bartlett
> > > IT Advisory Professional
> > > Contracted Resource to: Managed Operations, KMT
> > > Ministry of Health
> > > Tel: (250) 952-6462 Fax: (250) 952-6893
> > > Email: [EMAIL PROTECTED]
> > >
> > >
> > >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
