Jim,
We could scan-ahead before we pass the characters off to Xerces however
there are many drawbacks, this would add additional overhead, the entire
contents of the "XML String" would be need to be base64 encoded, and the
entire string becomes no longer human readable.
If we added such a behavior (assuming someone has the time to work on
it), it would need to be configurable so that it only happens by user
choice and not by default.
As for automatic reference tracking, it's not as glamorous as it sounds,
we (Castor) would either have to keep an additional reference list of
every object already marshalled, which will be be scanned each time any
piece any object value is being marshalled, or repeatedly scan the
original object model. I believe the performance for marshalling would
take a significant hit. The scanning would be exponential, unless I'm
missing something obvious here.
When you are able to tell Castor something is a reference, it greatly
reduces the overhead, because it doesn't have to do any checking.
Now coming up with automatic references is something we could certainly
do (given that someone actually has the time to do it) to prevent having
to write a mapping which specifies a specific identity field for objects
you may want automatically introspected, but you'd still need to tell
Castor that the vector is full of references.
A mixed vector (some references, some non-references) would be just as
bad as a full vector of non-references subject to lots of comparisons.
So I'm against that as well, unless you have a more glamorous solution.
If so, I'm open to listening.
--Keith
Jim Redman wrote:
>
> Keith,
>
> Thanks for your input in this and other mail. The lack of reference
> tracking seems to be a huge drawback since with any non-trivial object
> tree there will be more than one reference to any given instance. I
> suppose that it's possible that I could create Vector of all the live
> objects and then archive the graph as references, but that seems like a
> huge hack.
>
> One more comment below:
>
> On 05/24/04 15:44:19, Keith Visco wrote:
> > The XMLSerializer is correct in throwing an error with (char)0 since
> > it's not a valid XML character.
>
> True it's not a valid XML character, but it _is_ a valid Java
> character.
>
> > There is little we can do about that, the character simply cannot
> > exist in an xml document.
>
> What this says is that in order to use Castor as an archiver the
> programmer has to ensure that any getChar method returns a valid XML
> character - quite a restriction. I think that it would be reasonable
> for a user to expect that Java-valid, but XML-invalid characters would
> be encoded.
>
> I haven't tested Strings, but most non-English languages produce
> characters that are not valid XML and so must be Base64 encoded to be
> stored in a valid XML file. Is this something Castor does, or is this
> also passed back to the user (sorry for this newbie question).
>
> Jim
>
> > >
> > > There seems to be a problem with archiving characters that are not
> > > valid XML characters. For example, and object with this (and it's
> > set
> > > sibling):
> > >
> > > [...]
> > > public char getCharValue () {
> > > return (char)0;
> > > }
> > > [...]
> > >
> > > generates and error from the XMLSerializer.
> > >
> > > I also hit an error that I notice has been reported elsewhere,
> > >where validation generates a NullPointerException (I'd get you the
> > >exact error, but non-Castor problems prevent me for running the
> > >app). If I can find more details, I'll pass them along.
>
> --
> Jim Redman
> (505) 662 5156 x85
> http://www.ergotech.com
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
