Hi there,
Let me first state that, wow, xmlbeans really rocks. I'm loving it.
Well done again Apache community.
I have two sets of schemas - each set relating to the separate
generation of xmlbean classes representing the xsds.
Both sets of generated classes are on my classpath.
In one
Hey.
I am currently developing a software under java to query data from
exist and put the results into XMLBeans.
my collection consits of 1 document. this document has some
xsi:type attributes. (for example ContentCollectionType)
I'm using the xml:db api through java and I'm getting the
Hey.
I am currently developing a software under java to query data from
exist and put the results into XMLBeans.
my collection consits of 1 document. this document has some
xsi:type attributes. (for example ContentCollectionType)
I'm using the xml:db api through java and I'm getting the
Hi
We are migrating our applications from Weblogic 8.1 / xbean (?) to
Weblogic 9.2 / apache xbean 2.2.9-r540734 .
We compiled our schema successfully with new version after making changes
recommended by bea (replaced all com.bea.xml occurrences to
org.apache.xmlbeans ) along with ant task
Hi Shikhar,
Have you recompiled all of your schemas? Are there any conflicting
jars still on the classpath?
-jacobd
On Wed, Jun 4, 2008 at 7:57 AM, [EMAIL PROTECTED] wrote:
Hi
We are migrating our applications from Weblogic 8.1 / xbean (?) to Weblogic
9.2 / apache xbean 2.2.9-r540734 .
Yes, we recompiled the schema. Schema goes into a separate jar.
BEA ships two versions of xbean in 9.2 . The server/lib version is no good
for us and documentation says to use apache_xbean version that ships in
common/lib.
The only problem I am seeing is that at compile time, it creates
When old xmlbeans jars were compiled, the user may have been used an
.xsdconfig file that modified the generated package of the xbean classes
and interfaces.
You should use the same .xsdconfig file, or modify the code that
references those intf/classes to match the ones in the new xbean jars.
Unfortunately, there is a known limitation: both the head element and
the substitution have to be in the same jar file (i.e. compiled at the
same time). See http://issues.apache.org/jira/browse/XMLBEANS-299
Radu
From: Christopher Hunt [mailto:[EMAIL
Hi Klaus,
After you go to the first Element after the existing result element, as
you say, why do you call getDomNode() and parse it again into XmlObject?
This seems redundant, why not just use the result of
XmlCursor.getObject()?
Radu
-Original Message-
From: Klaus Dobbler
9 matches
Mail list logo