parsing string data through castor

[madhununna]

I'm trying to parse string data using castor and it looks like the new
lines are getting lost.

I'm using castor 0.9.4.3

For example:

Input

<INPUT> First line
second line
third line </INPUT>

after marshaling and unmarshaling using castor this becomes

<INPUT> First line second line third line </INPUT>

Is there something I can do to preserve the newlines in the data or is
this a bug in castor.

Thanks in advance for the help

[ernest g allen]

In article <42************ **************@ posting.google. com>,
mn****@telcordi a.com (madhununna) wrote:

I'm trying to parse string data using castor and it looks like the new
lines are getting lost.

I'm using castor 0.9.4.3

For example:

Input

<INPUT> First line
second line
third line </INPUT>

after marshaling and unmarshaling using castor this becomes

<INPUT> First line second line third line </INPUT>

Is there something I can do to preserve the newlines in the data or is
this a bug in castor.

Thanks in advance for the help

I don't know for sure, but it looks like a bug in Castor
to me. It looks similar to a bug I had to deal with a
few years ago.

Before you get any further with Castor, see how the current
version handles

<INPUT> First line
second <b>line</b> with <i>mixed content</i>
third line </INPUT>

A few years back I worked on a project that had already
chosen Castor before I joined the team. They had found
that the marshaling and unmarshaling mangled the order
of leaf node when some of those leaf nodes were PCDATA,
and they would get something like

<INPUT> First line <b>line</b><i>mixed content</i>second with third
line </INPUT>

(one long line)

back from the system. The people at www.castor.org were
contacted to report the bug, and our team was told that
it wasn't a bug since all of the elements were present in
the output, that castor was intended for data-centric
applications instead of text-oriented applications, that
all parts of the object were present, a Java application
wouldn't "care" one way or the other, and that they were
not going to try to "fix" it.

The fix that the team came up with was to encode the sample
above as

<INPUT><text>Fi rst line</text>
<text>second </text><b>line</b><text> with </text><i>mixed content</i>
<text>third line</text></INPUT>

If I remember correctly, it still came back out of the
system as one line, but with all leaf nodes existing
as elements (no mixed content) the ordering survived.

This was all before I joined the team, but as you can
imagine I got an earful about it when I asked why the
hell these <text> elements were being used instead of
traditional mixed content. I could hardly belive it,
but was quickly shown the email correspondence that
documented the whole affair.

Good luck.

- - - -