Looks
like you've hit the runtime equivalent of the"multiple
occurences"error.
Basically, the reason XmlBeans can just read a document
and validate it is that it uses the classpath to find a definition for the root
element in a document. So what is happening is that, since you have multiple
Ok, thanks for the information, it's clear now.
Other than facets, the only things that come to mind are model groups
(sequence, all, choice).
For facets, the issue is that the way we expose facets is through the
SchemaType.getFacet(int) API which returns an XmlAnySimpleType, which has no
place
Title: RE: NullPointerException when reading the leaves of the XML data
Hm, I
see what you're saying, but it can't work the way you want, unfortunately,
because when you validate or data bind an instance of the union, the type
assigned to it must be one of the member types of the union.
Peter-Paul,
You can use XmlObject.Factory.parse() if you don't know the type of the message
beforehand. The runtime type of the resulting object will be that of the class
associated with the document, as determined by looking at the root element (as
long as the appropriate scomp-generated jar
written that way),
so the overall document could still look pretty good.
-- Mark Lewis
On Mon, 2005-07-11 at 16:23 -0700, Radu Preotiuc-Pietro wrote:
Well, to be honest, the meaning of pretty print is that you give up
space preservation in order to get a document that's easier to read.
If you
Can you be more specific what flavor of binary XML are you thinking of? There
is some work in progress in W3C around that but it's in very very early stages,
basically they're discussing whether they should even consider it, let alone
have a clear proposal on how to do it.
And then there's
You mean something akin to List.clear(). There is nothing like this, no...
Radu
-Original Message-
From: Joe Favero [mailto:[EMAIL PROTECTED]
Sent: Friday, July 22, 2005 2:26 PM
To: user@xmlbeans.apache.org
Subject: Removing all elements in an Array
Is there a recommended way I am not
Hm, this does sound like a potential bug in the code generator. Any chance you
could post your Schemas, or maybe just the part of your Schema that causes the
problem or some other information to help us repro the problem?
Thanks,
Radu
-Original Message-
From: Johannes Echterhoff
I have looked over it and identified what is the most probable cause for this
NPE, and as it turns out some checks were actually incorrect. Thanks for
reporting this! I'll have a fix checked in SVN shortly.
Radu
-Original Message-
From: Weiler, Frank (KBV) [mailto:[EMAIL PROTECTED]
I have tried to compile the Schemas from that location and I got no errors.
Try using the same command-line that I have used to eliminate differences in
environments as much as possible.
scomp -dl -mx 512M opengis/ (directory where you've downloaded the Schemas)
Now it looks to me like your
This is exactly what XmlCursors are for!
Say you have a car object and an engine object.
You can do
switch (car.newCursor().comparePosition(engine.newCursor()))
{
case -1: // car comes before engine
case 1: // car comes after engine
}
Or, you can do:
XmlCursor c =
Yeah, so it does seem that adding -javasource 1.5 when compiling this
particular Schema causes problems, which is an unfortunate bug :-(. But the
good news is that there is a simple workaround (not generating 1.5-specific
classes) which you can use while we are fixing the problem.
In answer to
Hm, there is not enough information in your message to tell. If you had
xs:element name=DATE_CREATION type=xs:date minOccurs=0/
then I would have been surprised to see a String return type. But since your
type is Date which looks like a user-defined type, then it's possible that it
maps to
Given that XmlBeans does not compile XMLInputStream.java in any of our
build scripts and we have the .class file checked in directly (and also
that I am using jdk1.4.2_03 without problems as I am sure others are
too), I would say what's probably happening is that you guys have some
other version
Sorry, scratch the first part of my comment, I was under the impression
that you were talking about XMLStreamReader, but XMLInputStream is
different, so jsr173_api.jar has no role in this whatsoever.
Radu
-Original Message-
From: Radu Preotiuc-Pietro
Sent: Tuesday, August 16, 2005 1:54
Title: Message
Yes, it does mean that. We repackage
piccolo (so you can use a newer version if youd like) and then include
it as part of xbean.jar. You do not need to do anything to get the advantages
of Piccolo.
Thanks,
Radu
-Original Message-
From: Steve Davis
V2 and
Piccolo
Excellent.
One more question. Is
Piccolo thread-safe ?
Thanks,
Steve
-Original
Message-
From: Radu Preotiuc-Pietro
[mailto:[EMAIL PROTECTED]
Sent: Friday, August 19, 2005 3:56
PM
To: user@xmlbeans.apache.org
Subject: RE: XmlBeans V2
XmlBeans supports this scenario very well. You would probably want to
check out this sample, it seems relevant to what you are trying to do:
http://xmlbeans.apache.org/samples/OrderMatters.html
Radu
-Original Message-
From: Markus Pilzecker [mailto:[EMAIL PROTECTED]
Sent: Tuesday,
Just wanted to point out the XmlObject.documentProperties().setSourceName()
method, which allows you to set the correct xsd name even when you havent
parsed the xsd with XmlBeans.
Radu
From: Eran Chinthaka [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 04, 2005
10:30 PM
Title: Message
I know
it's been over a month since this was asked, but today I finally took some time
and reviewed the rules for keyref validation (there's also been a recent thread
on xmlschema-dev about this very issue).
It
turns out that in a non-intuitive way, XMLSchema is esentially
Hm, not sure why that happened, I would have expected it to work.
Radu
-Original Message-
From: David Jencks [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 12, 2005 5:17 PM
To: user@xmlbeans.apache.org
Subject: Re: Serialization (again)
On Oct 12, 2005, at 3:53 PM, Radu Preotiuc
Noah,
It looks like you already found a way to do this by looking at the name
of the document tag. And in fact, this is what XmlBeans is doing too
when parsing using the generic parse method.
So if you don't know beforehand what kind of document you are going to
receive, do the following:
Unfortunately, the level of customization allowed by .xsdconfig is
currently not finely grained enough to make it possible to rename
enumeration fields, so I am afraid you are stuck using A, B and C.
I wouldn't go to all the trouble of changing the generated code if I
were you, I would just add a
ave no way to put business
operations on these objects without using containment. I'd like to extend or
implement different interfaces on these guys w/o
containment.Shaun.Farrugia. . [EMAIL PROTECTED]perm.
desk.734.887.2148. . .cell.313.363.5006aim.dier0b0t . . ."Radu Preotiuc-Pi
Title: Message
You
are right, I couldn't find it either. I meant to do an update to the information
that's on the website currently;haven't gotten to it yet, but it will be
added.
Thanks,
Radu
-Original Message-From: rabidgremlin
[mailto:[EMAIL PROTECTED] Sent: Monday,
Have you tried the catalog attribute on the ant task? I haven't tried
it myself, but from looking at the code, looks like it's what you want
(of course, we also have this option on the scomp script and I have
successfully used it in that context).
Radu
-Original Message-
From: Johannes
Title: Message
Those
kind of things are very hard to diagnose, especially over e-mail. Since scomp
works correctly, I have to assume that this is ant's doing, maybe some
dependency checking causingsome classes not to get
rebuilt?
Radu
-Original Message-From: rabidgremlin
Also, Christian, could you try using ISO8859_1 rather than
ISO-8859-1 for the encoding string in your code? XmlBeans is using the
Java names for the encodings, which seemed more consistent than using
the IANA names (so you can get the encoding from other Java code and set
it directly etc). Of
Note that the two documents are _different_, XmlBeans will output the
one that you created. Try using XmlOptions.setUseDefaultNamespace() when
you print out the document and see how that looks.
Radu
-Original Message-
From: R. C. Hill [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October
Title: Message
Basically, in your case, we are dealing with an invalid doc, since ""
(empty string) is not in the value space of the "float" type. That being said,
XmlBeans makes efforts to give you access to your data even for invalid
documents. But this case, I think, falls under the
No, but the good news is that there is patch that was submitted to the
list which will allow you to do it. Strangely enough, I can't point you
to it, because that specific e-mail is missing from all our mailing
archives.
Here's a copy. The patch has two parts, one dealing with entities (which
is
Please vote on the release of XmlBeans 2.1.0 as it currently exists on
http://xmlbeans.apache.org/dist as xmlbeans-2.1.0-rc1*. If the vote
turns out positive, these archives are going to become the final release
and be renamed to xmlbeans-2.1.0*, then signed and uploaded to the
download servers.
And probably trashes other valid strings by inserting newlines where
they should not be :-) I'd have to look in more detail, but I believe
your problem is that you are using pretty print, thereby giving XmlBeans
some leeway in changing your document. I would be curious if the problem
persists when
About searching the mail archives: no, the mod_mbox ones don't have
search on them, which is really a shame but that's life, keeping in mind
that the people who are maintaining them are doing so on their own free
time
Radu
-Original Message-
From: Sherman, Dennis (END-CHI)
I think you have answered the question yourself. XML in general cannot
express object graphs, just tree structures. XMLBeans being a generic
XML tool has this constraint too, so you basically need to encode the
graph structure inside your app (and maybe use key/keyref constraints if
you want to
Title: Message
This
feature I think has been deemed out-of-scope for XmlBeans.
The
problem isit would make itimpossible to ensure all the XmlBeans
features work consistently with generated code and pre-existing code, so it
would confuse matters.
XmlBeans does the hard job of creating Java
Yeah, this is actually true, but not bug.
The reason for it is that the rule for transforming URIs into package
names says: if the part after the last slash looks like a file with
extension, then strip the extension, where file with extension is
interpreted as anything + '.' + 3 chars or anything
of dots.
However, I just wanted to make sure whether this was a bug
and could be
fixed in a future version or not.
Thanks,
Johannes
Radu Preotiuc-Pietro wrote:
Yeah, this is actually true, but not bug.
The reason for it is that the rule for transforming URIs
into package
Title: Message
I
think I have answeredthis pretty recently, here it is again: the level of
configuration granularity that .xsdconfig supports only goes to the level of
class, so you can change names of packages and classes, but not of
methods.
Why do
you need the method name to be
Title: Message
Well,
XmlBeans doesn't really know when you meant to call something else and when you
actually need are able to handle null (plus, adding any such code on the
critical path for a 'get' would slow things down noticeably). But, what one can
do when in doubt is call .validate()
Your use-case is quite particular, there isn't something out-of-the-box
that can satisfy it.
Fortunately for you, it seems like you should be able to use
org.xml.sax.XMLFilter + a little custom code to solve this.
Radu
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
That is very strange, seeing something like this just for a specific
load, no more, no less, and very hard to debug. The problem where you
would not get the correct types when using XmlBeans V2 with jars
compiled with an older version is well understood on the other hand, but
seems completely
I have just added a new entry to the FAQ:
http://wiki.apache.org/xmlbeans/XmlBeansV1Faq#scompOutOfMemory
Can you please check it out and see if that solves your problem?
Thanks,
Radu
-Original Message-
From: Alejandro Escalante Medina [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December
)
at
org.apache.xmlbeans.impl.tool.SchemaCompiler.main(SchemaCompiler.java:368)
Seems like I'm running into a limit here because of the size of my schema.
Is there anything to do?
Thanks for your help,
Alex
On 1/2/06, Radu Preotiuc-Pietro [EMAIL PROTECTED] wrote:
I have just added a new entry to the FAQ:
http
ursor). But it's not elegant
and it looks like a hack. I think it would be useful to add following
features:1) Specify preferred namespace prefixes for namespace URI in
xml beans config file or pass with options when creating xml bean instance2)
Have namespace attribute declarations in a new documents
A couple of comments:
- why do you say that you have to use xget/xset some times and set/get
other times? It seems to me you should be able to standardize on one
approach, the one that suits you best
- we have an example of using Velocity + XmlBeans in the samples section
on the website
One thing I can suggest is double-check that you are indeed using the V2
version, using:
scomp -version
V2.0 supports line numbers by default, while V2.1 also has column
numbers on by default
Radu
-Original Message-
From: Quynh-Anh Nguyen [mailto:[EMAIL PROTECTED]
Sent: Friday,
Title: Message
I
think this is a mistake in the Schema, but a very easy one to make since,
unfortunately, this is a VERY non-intuitive part of the spec (I have seen this
situationa few times and it still seems counter-intuitive to me).
What basically happens is that the default
prefix
You can use SchemaTypeVisitorImpl without using the generated sources,
but classes under impl in the xmlbeans package hierarchy are
implementation packages, designed to support the functionality of
XMLBeans, not for direct use.
Check out the (intented for direct use)
Try setting the value to an empty array, I think that's what you really
want.
Radu
-Original Message-
From: Johannes Echterhoff [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 19, 2006 6:39 AM
To: user@xmlbeans.apache.org
Subject: Unsetting an array
Hi.
Question: what is the
This looks like a classloader issue, specifically make sure that all
XmlBeans-generated JARs (including the one containing the .xsb files)
are on junit's classpath.
Radu
-Original Message-
From: Edward Frederick [mailto:[EMAIL PROTECTED]
Sent: Wednesday, February 01, 2006 1:35 PM
To:
I think the Schema is fine and XmlBeans should not error. I have opened
issue XMLBEANS-251 to track this. Thank you,
Radu
-Original Message-
From: johnli121 [mailto:[EMAIL PROTECTED]
Sent: Friday, March 03, 2006 4:21 AM
To: user@xmlbeans.apache.org
Subject: xmlbeans throws exception,
XmlBeans doesn't support canonicalization yet, and I am
fairly sure we never posted anything on mailing lists or website saying that it
does. Where did you get that information from?
We were considering it some time ago, while V2 was still in
development but we never actually invested
I have been thinking about this, but it is tricky to do: it
breaks our "binding should not require validation" rule (it's true that we would
only do it if requested), soit felt to me like one of thosebig
effort/ not so big reward things, esp since there is the XPath workaround
available.
Well, in V2 there is actually an option to remove the
synchronization at runtime when loading, saving and manipulating documents
_except_ when doing so with generated classes, since those are already
generated. We probably ought to look at this option at compile-time also and not
generate
XmlBeans, by default, escapes the minimum number of characters that are
required:
- lt;
- amp;
- quot; (only if inside an attribute value)
Other than this, you can use the XmlOptions to turn on escaping for
other characters, as you correctly pointed out.
If you want to, say, escape every
This is a limitation of the fact that we use SAX to communicate with
Piccolo so there is no opportunity for it to pass line-column info for
attributes.
Thanks,
Radu
-Original Message-
From: Lysander David [mailto:[EMAIL PROTECTED]
Sent: Saturday, March 18, 2006 6:21 PM
To:
;
System.out.println(charEsc.getEscapedString('Y')); //#x59;
System.out.println(charEsc.getEscapedString('Z')); //#x5a;
I don't know if this is what Brian is looking for.
- Wing Yew
-Original Message-
From: Radu Preotiuc-Pietro
Sent: Monday, March 20, 2006 6:20 PM
To: user
Not sure what you are asking. On one hand, XmlBeans is
indeed by default using SAX to interface with the XML parser, but on the other,
XmlBeans is an in-memory XML processing tool, so if you need to process a huge
XML file, you would need a huge amount of (virtual) memory to do
it.
Radu
You are absolutely right, thanks for pointing it out. We have recently
changed the links, and this is a fallout from that change. Should be
fixed shortly.
Radu
-Original Message-
From: Erik van Zijst [mailto:[EMAIL PROTECTED]
Sent: Thursday, March 23, 2006 3:32 PM
To:
Actually, XmlBeans doesn't have specific APIs to deal with
xsi:[noNamespace]schemaLocation attributes (maybe it should) You
would have to set it as an ordinary non-Schema declared attribute, like
that:
XmlCursor c = root.newCursor();
c.insertAttributeWithValue(noNamespaceSchemaLocation,
' attribute of XmlObject xo, what has been
suggested at some point in this thread does in fact work (assuming the
latest fixes and updates):
xo.selectPath(//[EMAIL PROTECTED]/@id])
Radu
-Original Message-
From: Radu Preotiuc-Pietro
Sent: Thursday, March 30, 2006 1:56 PM
To: user
Hard to say where you are wrong, since you give very little detail of
what you are doing ;-)
In fact, what the validate implementation does is parse the document
provided in an XmlObject, then call .validate() on it (in addition to
parsing the Schema files of course).
So what I can suggest is
That can be improved indeed. Currently, the README lists
the kit contents starting with two jars, saying clearly that you need them
(xbean.jar and jsr173_1.0_api.jar). Then it makes the assumption that it's
understood that these are the *only* two you need, but it's not clearly said
Can you call '.validate()' on the root object and see if there are any errors?
I suspect this to be the elementFormDefault problem...
Radu
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 06, 2006 6:09 AM
To: user@xmlbeans.apache.org
Subject:
Hm, is this intermittent, or does it happen consistently? I assume you
don't have any modifications to XmlBeans, I am trying to see if this
could be a synchronization problem...
Thanks,
Radu
-Original Message-
From: Rolf Schumacher [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 06,
I miss something here?
Jürgen
Radu Preotiuc-Pietro schrieb:
Can you call '.validate()' on the root object and see if there are any
errors? I suspect this to be the elementFormDefault problem...
Radu
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent
Well, these relationships between xmlns:tns and targetNamespace and
import namespace are all conventions, they are not in the spec. So
while they may be common, we cannot necessarily assume that what you
want is exactly the behavior that anyone else would want.
But you can implement your own
It's working for me on Linux,
Thanks,
Radu
From: Cezar Andrei Sent: Monday, June
12, 2006 12:45 PMTo: dev@xmlbeans.apache.orgCc:
user@xmlbeans.apache.orgSubject: RE: New release:
v2.2
Here are the files for
XMLBeans v2.2.0-RC1: http://xmlbeans.apache.org/dist/
Please give them a try
Actually there is a JIRA talking about this:
http://issues.apache.org/jira/browse/XMLBEANS-176 (whose priority I have
just updated).
I would want to point out though that conversion is not the right way
to think about it, since XmlBeans doesn't 'remember' whether originally
the text was encoded
You can't alter this limit currently, I'm attaching my
reply to a different thread, I think it also makes sense in this
thread.
Thanks,
Radu
From: Larner, Ross S
[mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006
10:41 AMTo: user@xmlbeans.apache.orgSubject: RE: passing
xml as a
You are very close. Keep in mind that defaults are not
associated with types, but with elements/attributes. Other than that, once you
use it in the context of an enclosing element, it should work like you
expect.
If you're still having trouble, could you post a code
sample and we'll go from
+1 from me.
Radu
-Original Message-
From: Cezar Andrei
Sent: Monday, June 19, 2006 10:12 PM
To: dev@xmlbeans.apache.org; user@xmlbeans.apache.org; XML-Beans PMC
Subject: [VOTE] Release of XMLBeans 2.2.0
Please send your vote for the release of XMLBeans version 2.2.0, as it
currently
Also XmlBeans.compileXmlBeans() is a good place to look at because,
unlike the script, is part of the public API which means
backards-compatbility and better documentation.
Radu
-Original Message-
From: Arif Shaon [mailto:[EMAIL PROTECTED]
Sent: Friday, June 30, 2006 5:09 PM
To:
How about posting the error that you're getting or looking
it up in the FAQ? If you weren't able to get the examples on the site to work
(they *do* work), it's unlikely that sending a new example will make the
difference.
Radu
From: Loiane [mailto:[EMAIL PROTECTED]
Sent: Friday, June 30,
Hm, it's the first time I hear about this, it looks like it's a new
Codehaus project and it has nothing to do with Apache XMLBeans. What
made you think they do the same things?
Radu
-Original Message-
From: SP Liu [mailto:[EMAIL PROTECTED]
Sent: Sunday, July 02, 2006 10:43 PM
To:
The documentation lags behind. I'll make sure it gets fixed.
Radu
-Original Message-
From: Baker, Jon [mailto:[EMAIL PROTECTED]
Sent: Monday, July 03, 2006 5:40 PM
To: user@xmlbeans.apache.org
Subject: RE: XMLBeans 2.2.0 and SaxonB8.6.1 - selectPath() nol longer
working?
Wing Yew,
See my previous post (7/21) for an example provided by Tony
Dean with namespaces in XPaths. Here is the relevant code:
Sring ns = "declare namespace ns='http://tempuri.org/myService';";
String xpath = ns +
"$this/ns:copyintoout/ns:[EMAIL PROTECTED]'Tony']";
XmlObject[] selections =
Mohana,
I would look in the "out" byte array and see what it looks
like. By doing xo.save(...) (by the way, who is "xo"?) you completely bypass
XmlBeans, so it's a matter of whatdocument are you really
loading.
It would be more interesting, from an XmlBeans
perspective,to know what
)
atorg.apache.xmlbeans.impl.values.XmlObjectBase.selectPath(XmlObjectBase.java:415)
atcom.sas.soa.wsdl.impl.RequestImpl.update(RequestImpl.java:244)
... 16 moreAny ideas?Thank you very
much.-Tony-Original Message-From: Radu
Preotiuc-Pietro [mailto:[EMAIL PROTECTED]]Sent: Friday, July 21,
2006 11
I have updated this.
Also, I wanted to remind people that there are a few interesting
examples on the website [http://xmlbeans.apache.org/samples/index.html]
including an XPath/XQuery one; these are very useful to get started.
Radu
-Original Message-
From: Baker, Jon [mailto:[EMAIL
Well, Rao, looks like you are a "victim" of the
elementFormDefault. In XmlSchema, by default, when you declare a
localelement "Server" (like in your Schema) it goes into the "default
namespace" rather than the "target namespace". You can do two
things:
1. if you want to keep the Schema
Hm, I think you mean XMLBeans is not doing the MUST, for compatibility,
be escaped using either gt; or a character reference when it appears
in the string ]] in content, when that string is not marking the end
of a CDATA section part, right? But the rest is done as per spec.
Radu
-Original
Steven,
java.lang.VerifyError indicates that the representation
of the class does not correspond to the constraints in the Java spec, so
basically your .class or .jar file is corrupt. Try re-downloading (or
re-building) XmlBeans and maybe use the md5 sum to verify your
download.
Radu
Looking at the workaround that you say works, I am assuming that your
document is using some entities that are declared in another document.
If that's the case, then what you need to do is use your own XMLReader
and try setting to false the SAX features
Not sure what you are looking for.
If you have an XmlObject o and you don't know what type it is, do
SchemaType type = o.schemaType();
Does your Schema have 200 types that are all extending a base type such
as Shape in the example below? Can all of those types result from the
xquery? Do you
and delete this message. Thank you for
your cooperation.
From: Radu Preotiuc-Pietro
[mailto:[EMAIL PROTECTED] Sent:
Friday, August 04, 2006 5:12 PMTo: user@xmlbeans.apache.orgSubject: RE: Unable to create a soap
message using xmlbeans [2.1.0]
Andrew,
We have done some
experimental work
Were you able to resolve this? I don't really see what you mean, can you
be more specific?
Radu
-Original Message-
From: Michael Fieseler [mailto:[EMAIL PROTECTED]
Sent: Friday, August 04, 2006 4:41 AM
To: user@xmlbeans.apache.org
Subject: Missing addFoo() method
Hi,
for an element
In XmlBeans "Array" gets always appended to the name. If
you need it for a special type, then you can use the extension feature to add
new methods to the generated classes that would be named "getFoo" and delegate
to "getFooArray" but if you need that for every type you are generating, then
That is also a question for Xfire. One test you can try is extract the
body of the soap message to a separate file. Parse the message from that
file using XmlBeans directly and see what you get. Run validation on the
parsed object and see if returns true. It could be that one of your
elements is
Say you have an element as 'XmlObject element' and you are interested in
finding out if attribute 'att' is allowed or not.
SchemaType type = element.schemaType();
boolean isAttAllowed = type.getAttributeProperty(new QName(, att))
!= null;
Note that this will not handle the case in which there
First, let me assume that your Schema declares AbstractClass as the
substitutionGroup for classA and classB and not AbstractElement
like stated in your message. Then, you would write the following code:
RootDocument doc = RootDocument.Factory.newInstance();
RootDocument.Root root =
You can't fix this by using .xsdconfig, you need to get a
new Schema file. If you look carefully at the "include" statement, you can
notice that Liberty-metadata.xsd is asking for the version 2.0 of the included
file, while that file is saying that its version is "2.0-02". My guess is that
I couldn't find the time to look at this in detail, but
here's a suggestion that may help:
TextPad (like Notepad) I think looks at the first bytes in
the file and if it sees something like FF FE decides that the encoding is
unicode. But your file being XML, it relies on the
The JavaDoc for .valueEquals() is fairly detailed but forgets to mention
one thing: that .valueEquals() is only implemented for simple type
values.
Actually, Schema-aware comparison is something that a lot of people find
valuable and XmlBeans has all the foundation work done to support
something
This is one of the things that's up in the air in XMLSchema, as far as
I'm aware, what happens with annotations on refs to elements/attributes.
Because of that we just picked one approach until this becomes clearer.
The approach that we picked was that the annotation be part of the
reference and
What's happening most likely is that you have defined the
approvedDateTime attribute in your Schema as having type xs:date
which means a date _without_ time. As a result, when you set your
calendar using approval.setApprovedDateTime() it only sets the date, and
it loses the time.
To fix it, simply
Hi Ruben,
I think this is handled quite nicely by XmlBeans, within the context set
by the XMLSchema spec. Assuming you have a backwards-compatible Schema
on the server and an older version of that on the client you can either
have extra elements sent by the server, which will of course be
Well, it looks to me that this is a little beyond XMLBeans.
Can you try just using Xerces without XMLBeans to parse the same document? If
you have the same error, then you'll obviously have to fix that before you can
expect that it will work with XMLBeans, if not, then we have to figure out
We have a JIRA issue opened on this, XMLBEANS-282. I have
added a comment on that, the fact that more and more people are hitting this
ismotivation forus to give it higher priority.
Radu
From: Vines, Herbert
[mailto:[EMAIL PROTECTED] Sent: Tuesday, September 26, 2006
11:37 AMTo:
1 - 100 of 291 matches
Mail list logo
