Sorry.  I went a reply via email last week but looks like it never
made it into the system.

Here is a copy of that email:


Here is the message from JSX while running on the HP's.
      [java] ---ATTENTION!---  JSX could not recognize your
implementation of java, which is:
      [java]     implVendor="Hewlett-Packard Co."
      [java]     specVersion="1.5"
      [java]     implVersion=" 1.5.0.05"
      [java] In the meantime, JSX2 will try the standard
implementation for Java 1.4 - which will probably work
      [java] Please post the above information to: jsx-
ideas@yahoogroups.com
      [java]  - in particular, please state whether the standard
implementation worked or not, for both writing and reading.  Please
do a few tests before you post.

      [java]     If JSX's guess really does work, it can be fixed with:
      [java]     if (implVendor.equals("Hewlett-Packard Co.") &&
specVersion.equals("1.5") && implVersion.equals ("1.5.0.02"))
      [java]     magicName = "JSX.magic.MagicClass14";

Also, I wont post the URL that I downloaded the file from, but could
you send it to me privately since the URL that i used last time no
longer works.

















--- In JSX-ideas@yahoogroups.com, Brendan <melbourne.research@...>
wrote:
>
> Hi James,
>
> Did the current download work for you?
>
> When you get a chance, could you send the version info that JSX
outputs. I
> need the exact strings to be able to check for them, so I can
remove these
> messages for you  It would also help me determine how best to avoid
you
> seeing these messages in future.
>
> I hope you're feeling reassured.
>
>
> cheers,
> Brendan
>
> On 27/12/06, Brendan <melbourne.research@...> wrote:
> >
> > Hi James,
> >
> > We should be able to fix these hassles up quickly.
> >
> > Expired:
> > I just checked the purchase version now, and confirmed that it is
working
> > normally (ie. not expired, and not giving the message you saw).
> >
> >   (1) Could you download it again, and confirm whether this fixes
the
> > problem? This would be a simple fix.
> >
> > BTW: I have been working on our release system over the past few
weeks, so
> > it is possible you got an incorrect version at the exact time you
> > downloaded. Seems unlikely, but that would explain what you are
seeing. The
> > purchased version of the jar has a few extra characters appended
to the
> > filename, relative to the trial version.
> >
> >
> > JVM:
> > The immediate solution to your problem is to add your specific
JVM to the
> > next release.
> >
> >   (2) JSX should write out a detailed report on the JVM version
etc -
> > could you include that, please?
> >
> > This release should happen within a day of getting that info from
you.
> >
> > Yes, you're right that I'd decided to disable the JVM check - but
this
> > caused problems for other users. Managing the targetting of
multiple JVM
> > versions and manufacturers is difficult.
> >
> >
> > cheers,
> > Brendan
> > PS: It's late here right now, so I'll revisit the JVM problem in
detail
> > tomorrow. The problem is to target your JVM so that you won't get
your logs
> > filled up when you upgrade your JVM next time; and that won't
interfere with
> > JSX detecting a JVM it hasn't seen before. The difficulty is that
whenever a
> > JVM is upgraded, it is a "JVM it hasn't seen before", as it is
*possible*
> > the internal implementation of the JVM's serialization has been
changed (ie,
> > of JOS, Java Object Serialization) - and JSX relies on this
internal
> > implementation.
> >
> > But in reality, JOS doesn't change very often; I've only seen it
change
> > between major version releases of the specification (Java 1.2,
1.3, 1.4,
> > 1.5) - implementation versions haven't changed the implementation
at all,
> > in fact. It's not something that other manufacturers want to mess
around
> > with either.
> >
> >
> > On 27/12/06, James Maes <jjmaes@...> wrote:
> > >
> > >   Good Morning All.
> > >
> > > I have two issues that I am hoping someone can help us address.
We
> > > purchased JSX around 9 months ago and have been very happy but
have
> > > noticed a couple of little issues recently.
> > >
> > > First, we upgraded our version of Java (we run on HP-UX PA-RISC
> > > systems) to 1.5.5 and now JSX is complaining about not being
able to
> > > determine the version of the JVM it is running for and says it
is
> > > defaulting to a 1.4 version. I am happy to report that this is
still
> > > working fine, it's just filling up our logs and causing the
Systems
> > > Admins to yell at my team a little.
> > >
> > > I remember this issue coming up around 4 or 5 months ago, and I
> > > thought the new version of JSX removed this check. Working under
> > > that assumption, we downloaded a new version of JSX (from a URL
that
> > > we downloaded our purchased version from, just incremented the
> > > version number as needed) but now we are seeing this.
> > >
> > > [java] Thanks for evaluating JSX for 30 days.
> > > [java] Thanks for evaluating JSX for 30 days.
> > > [java] If you need more time, please contact
company@...<company%40jsx.org>
> > > (for work)
> > > [java] If you need more time, please contact
company@...<company%40jsx.org>
> > > (for work)
> > > [java] For students, an academic version is avaiable at:
> > > www.jsx.org/academic
> > > [java] For students, an academic version is avaiable at:
> > > www.jsx.org/academic
> > > [java] Buy JSX at www.jsx.org/buy.html
> > > [java] Buy JSX at www.jsx.org/buy.html
> > >
> > > We just downloaded the new version 2 weeks ago, plus we have
what I
> > > thought was the proper purchased version so I am really
confused and
> > > scared.
> > >
> > > Right now this only happens on our test box, but if it starts in
> > > production, things could get bad.
> > >
> > > In addition to this error, the new JSX jar (JSX2.2.5.2) is still
> > > complaining about the JVM version.
> > >
> > > For now I am rolling back our version of JSX from JSX2.2.5.2 to
> > > JSX2.2.5.1, but would like to know how to address the issues
above
> > > and where to get a proper jar for the upgraded version
(hopefully
> > > without the JVM check).
> > >
> > > Details:
> > > OS: HP-UX PA-RISC
> > > JVM: HP's JVM 1.5.5
> > > JSX Version: JSX2.2.5.1 and JSX2.2.5.2
> > >
> > > Thanks
> > > -JM
> > >
> > >
> > >
> >
> >
>

Good Morning All.

I have two issues that I am hoping someone can help us address.  We
purchased JSX around 9 months ago and have been very happy but have
noticed a couple of little issues recently.

First, we upgraded our version of Java (we run on HP-UX PA-RISC
systems) to 1.5.5 and now JSX is complaining about not being able to
determine the version of the JVM it is running for and says it is
defaulting to a 1.4 version.  I am happy to report that this is still
working fine, it's just filling up our logs and causing the Systems
Admins to yell at my team a little.

I remember this issue coming up around 4 or 5 months ago, and I
thought the new version of JSX removed this check.  Working under
that assumption, we downloaded a new version of JSX (from a URL that
we downloaded our purchased version from, just incremented the
version number as needed) but now we are seeing this.

      [java] Thanks for evaluating JSX for 30 days.
      [java] Thanks for evaluating JSX for 30 days.
      [java] If you need more time, please contact company@...
(for work)
      [java] If you need more time, please contact company@...
(for work)
      [java] For students, an academic version is avaiable at:
www.jsx.org/academic
      [java] For students, an academic version is avaiable at:
www.jsx.org/academic
      [java] Buy JSX at www.jsx.org/buy.html
      [java] Buy JSX at www.jsx.org/buy.html

We just downloaded the new version 2 weeks ago, plus we have what I
thought was the proper purchased version so I am really confused and
scared.

Right now this only happens on our test box, but if it starts in
production, things could get bad.

In addition to this error, the new JSX jar (JSX2.2.5.2) is still
complaining about the JVM version.


For now I am rolling back our version of JSX from JSX2.2.5.2 to
JSX2.2.5.1, but would like to know how to address the issues above
and where to get a proper jar for the upgraded version (hopefully
without the JVM check).

Details:
OS: HP-UX PA-RISC
JVM: HP's JVM 1.5.5
JSX Version: JSX2.2.5.1 and JSX2.2.5.2


Thanks
-JM

Hi Stephen,

> What tools/approaches can I use to modify all of my XML files to
> include the new attribute 'c' with a certain value
> say 'newattrvalue'.

You can modify XML with XSLT; tho here you may be better off doing it within the
class.

Both are discussed in the JSX manual:
http://jsx.org/pdf/JSXmanual.pdf



XSLT
----
The JSX manual (see above, or link at top of www.jsx.org/support.html)
has examples of accessing the JSX XML format in terms of classes and fields
(pp.20-25).


Within the class
----------------
But for this case, I would suggest putting this evolution code within the
classes themselves - this is because that is where the
evolution occurred in the first place, and the person making the change will
know what value to use.

JSX uses the same hooks as JOS (Java Object Serialization - standard part of
java, in java.io.*) for this kind of evolution. It
enables your objects to look at the fields that are in the stream, and if
something is missing, to supply the correct value. (you
could also do this by testing for null, 0 or false, but then you can't
distinguish between the field being absent, or the field
being present and actually having that value).

This is discussed on page 10 of the JSX manual - but because it is the same as
JOS, there are also several tutorials about it.
"serialPersistentFields" is probably the best search term for this.


> I need this tool to be fairly powerful but easy to use because
> we are in a commercial environment and can add/remove
> complex attributes from existing classes that are not of
> simple types String, int, boolean, etc.

Adding complex types is probably simpler to do within the classes.
You can also do it with XSLT and XML: I'd suggest generating the XML you need
(by writing code to create the object you need, and
then serializing it), and then writing an XSLT script to insert it into the XML
for each object of that class.

Deleting is automatic, because when reading, JSX silently discards a value if
its field does not appear in the current version of
the class (same as JOS).


cheers,
Brendan

--- In JSX-ideas@yahoogroups.com, "Stephen Kurlow" <skurlow@...> wrote:
>
> Lets say for example I have:
>
> class foo1 {
>    String a;
>    String b;
> }
>
> and I have literally hundreds of different objects of class foo1
> serialised to different XML files. Now I need to modify class foo1 to
> include a new attribute so its class definition is now:
>
> class foo1 {
>    String a;
>    String b;
>    String c;
> }
>
> What tools/approaches can I use to modify all of my XML files to
> include the new attribute 'c' with a certain value say 'newattrvalue'.
>  I need this tool to be fairly powerful but easy to use because we are
> in a commercial environment and can add/remove complex attributes from
> existing classes that are not of simple types String, int, boolean, etc.
>
> Thanks,
> Stephen
>

Hi Stephen,

> What tools/approaches can I use to modify all of my XML files to
> include the new attribute 'c' with a certain value
> say 'newattrvalue'.

You can modify XML with XSLT; tho here you may be better off doing it
within the class.

Both are discussed in the JSX manual:
http://jsx.org/pdf/JSXmanual.pdf



XSLT
----
The JSX manual (see above, or link at top of www.jsx.org/support.html)
has examples of accessing the JSX XML format in terms of classes and
fields (pp.20-25).


Within the class
----------------
But for this case, I would suggest putting this evolution code within
the classes themselves - this is because that is where the evolution
occurred in the first place, and the person making the change will
know what value to use.

JSX uses the same hooks as JOS (Java Object Serialization - standard
part of java, in java.io.*) for this kind of evolution. It enables
your objects to look at the fields that are in the stream, and if
something is missing, to supply the correct value. (you could also do
this by testing for null, 0 or false, but then you can't distinguish
between the field being absent, or the field being present and
actually having that value).

This is discussed on page 10 of the JSX manual - but because it is the
same as JOS, there are also several tutorials about it.
"serialPersistentFields" is probably the best search term for this.


> I need this tool to be fairly powerful but easy to use because
> we are in a commercial environment and can add/remove
> complex attributes from existing classes that are not of
> simple types String, int, boolean, etc.

Adding complex types is probably simpler to do within the classes.
You can also do it with XSLT and XML: I'd suggest generating the XML
you need (by writing code to create the object you need, and then
serializing it), and then writing an XSLT script to insert it into the
XML for each object of that class.

Deleting is automatic, because when reading, JSX silently discards a
value if its field does not appear in the current version of the class
(same as JOS).


cheers,
Brendan

--- In JSX-ideas@yahoogroups.com, "Stephen Kurlow" <skurlow@...> wrote:
>
> Lets say for example I have:
>
> class foo1 {
>    String a;
>    String b;
> }
>
> and I have literally hundreds of different objects of class foo1
> serialised to different XML files. Now I need to modify class foo1 to
> include a new attribute so its class definition is now:
>
> class foo1 {
>    String a;
>    String b;
>    String c;
> }
>
> What tools/approaches can I use to modify all of my XML files to
> include the new attribute 'c' with a certain value say 'newattrvalue'.
>  I need this tool to be fairly powerful but easy to use because we are
> in a commercial environment and can add/remove complex attributes from
> existing classes that are not of simple types String, int, boolean, etc.
>
> Thanks,
> Stephen
>

Lets say for example I have:

class foo1 {
    String a;
    String b;
}

and I have literally hundreds of different objects of class foo1
serialised to different XML files. Now I need to modify class foo1 to
include a new attribute so its class definition is now:

class foo1 {
    String a;
    String b;
    String c;
}

What tools/approaches can I use to modify all of my XML files to
include the new attribute 'c' with a certain value say 'newattrvalue'.
  I need this tool to be fairly powerful but easy to use because we are
in a commercial environment and can add/remove complex attributes from
existing classes that are not of simple types String, int, boolean, etc.

Thanks,
Stephen

Hi, (forwarded to mailing list)

You can pass in a classloader as the second arg to ObjectReader (first arg can
be InputStream or Reader):
http://jsx.org/docs/JSX/ObjectReader.html#ObjectReader(java.io.InputStream,%20ja\
va.lang.ClassLoader)
http://jsx.org/docs/JSX/ObjectReader.html#ObjectReader(java.io.Reader,%20java.la\
ng.ClassLoader)

Or, you can use setContextClassLoader on the current thread:
    
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Thread.html#setContextClassLoa\
der(java.lang.ClassLoader)
eg:
     Thread.currentThread().setContextClassLoader(myCL);

There's some discussion in the mailing list archives:
    
http://tech.groups.yahoo.com/group/JSX-ideas/msearch?query=setcontextclassloader\
&submit=Search&charset=ISO-8859-1


cheers,
Brendan

> I have one problem I might be able to resolve by using the -D option of java
> to change the default system class loader...the problem is that Jtest when
> running unit tests uses its own class loader but because the sun class
> loader is the default it means JSX uses Sun's but Jtest uses its own which
> means the same class is loaded twice and I get a class cast exception when
> casting an object i read from an xml file and pass as input to a junit test
> case.
>
> Is there any way for me to tell JSX to use a particular class loader apart
> from the default class loader?

jsx.org is back!

The story:
As you may recall, our old domain name of "jsx.org" was taken by the
registrar when we were 10 days late to renew.

We then shifted to "javaserializationtoxml.com", but of course even
though we announced the change here, many users expected us at
"jsx.org", and so it seemed that we were gone.

A couple of days ago, we managed to reacquire "jsx.org", and today it
has been set to refer to our site again - there may be propagation
delays before it is visible everywhere.

We will keep the long name "javaserializationtoxml.com" as well as
"jsx.org", so as not to cause further confusion.

We are taking steps to ensue we are not late in renewing again!


cheers,
Brendan Macmillan

> That works for me.
Great.

> BTW, were you ever able to implement support for BEA JRockit?

No.

From memory, I got hold of the source, but they didn't leave any
accidental hooks to access their serialization internals. It's a testiment
to how well-written and secure it is.

Of course, I'd be very happy to be proven wrong.

I'm sure BEA would provide hooks for access, if enough of their customers
requested it...

     - Brendan

That works for me.

BTW, were you ever able to implement support for BEA JRockit?

  -- Damien

> -----Original Message-----
> From: Brendan Macmillan
> Sent: Wednesday, September 13, 2006 10:01 PM
> To: Damien Evans
> Cc: JSX-ideas@yahoogroups.com
> Subject: Re: JSX on IBM 1.5 JVM
>
> Hi Damien,
>
>             [ cc'ed the mailing list - please reply there. ]
>
> Thanks a lot for that - I'll disable it in the next release, and get
> the new version to you before then.
>
> The reason for this warning is because JSX needs to rely
> on private implementation details of the JVM (not public
> methods), which the JVM supplier could change without
> warning.
>
> But perhaps this warning is not really needed? It's never
> actually helped find a bug, and it annoys people.
>
> If there is a bug with a new JVM version, it will be
> reported as such. In fact, these aspects of the JVM change
> only rarely (only 3 different versions for Sun's JVM, since Java 1.2),
> and any problem will be immediately apparent. I like the idea
> of safety, in warning people that there *could* be a problem -
> but problems will be apparent, anyway; unless an insidious bug,
> which is not easily detected, anyway. In other words - this
> warning doesn't  help detect those problems, anyway.
>
> To rectify this, I will remove this check on JVM versions altogether.
>
> Is that OK with you (and everyone else)?
>
>
> cheers,
> Brendan
>
> PS: jsx-ideas@yahoogroups.com
> [ cc'ed the mailing list - please reply there. ]
>
> ----- Original Message -----
> From: "Damien Evans"
> To: "Brendan Macmillan"
> Sent: Thursday, September 14, 2006 7:17 AM
> Subject: JSX on IBM 1.5 JVM
>
>
> > Hi Brendan,
> >
> > We're getting this again after updating our JDK on AIX systems:
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 | ---ATTENTION!---  JSX could
> > not recognize your implementation of java, which is:
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 |       implVendor="IBM
> > Corporation"
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 |       specVersion="1.5"
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 |       implVersion="1.5.0"
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 | In the meantime, JSX2 will try
> > the standard implementation for Java 1.4 - which will probably work
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 | Please post the above
> > information to: jsx-ideas@yahoogroups.com
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 |  - in particular, please state
> > whether the standard implementation worked or not, for both writing and
reading.
> > Please do a few tests before you post.
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 |
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 |       If JSX's guess really
> > does work, it can be fixed with:
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 |       if
> > (implVendor.equals("IBM Corporation")
> > && specVersion.equals("1.5") && implVersion.equals("1.5.0"))
> >
> > INFO   | jvm 1    | 2006/09/13 03:08:51 |       magicName =
> > "JSX.magic.MagicClass14"
> >
> > Things work fine so you can go ahead and add support for this JVM (if
> > you haven't already).
> >
> > -- Damien
> >

Hi Damien,

             [ cc'ed the mailing list - please reply there. ]

Thanks a lot for that - I'll disable it in the next release, and get
the new version to you before then.

The reason for this warning is because JSX needs to rely
on private implementation details of the JVM (not public
methods), which the JVM supplier could change without
warning.

But perhaps this warning is not really needed? It's never
actually helped find a bug, and it annoys people.

If there is a bug with a new JVM version, it will be
reported as such. In fact, these aspects of the JVM change
only rarely (only 3 different versions for Sun's JVM, since Java 1.2),
and any problem will be immediately apparent. I like the idea
of safety, in warning people that there *could* be a problem -
but problems will be apparent, anyway; unless an insidious bug,
which is not easily detected, anyway. In other words - this
warning doesn't  help detect those problems, anyway.

To rectify this, I will remove this check on JVM versions altogether.

Is that OK with you (and everyone else)?


cheers,
Brendan

PS: jsx-ideas@yahoogroups.com
[ cc'ed the mailing list - please reply there. ]

----- Original Message -----
From: "Damien Evans" <devans@...>
To: "Brendan Macmillan" <Brendan.Macmillan@...>
Sent: Thursday, September 14, 2006 7:17 AM
Subject: JSX on IBM 1.5 JVM


> Hi Brendan,
>
>
>
> We're getting this again after updating our JDK on AIX systems:
>
>
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 | ---ATTENTION!---  JSX could
> not recognize your
>
> implementation of java, which is:
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 |       implVendor="IBM
> Corporation"
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 |       specVersion="1.5"
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 |       implVersion="1.5.0"
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 | In the meantime, JSX2 will try
> the standard im
>
> plementation for Java 1.4 - which will probably work
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 | Please post the above
> information to: jsx-idea
>
> s@yahoogroups.com
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 |  - in particular, please state
> whether the sta
>
> ndard implementation worked or not, for both writing and reading.
> Please do a few tests
>
> before you post.
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 |
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 |       If JSX's guess really
> does work, it can
>
> be fixed with:
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 |       if
> (implVendor.equals("IBM Corporation")
>
> && specVersion.equals("1.5") && implVersion.equals("1.5.0"))
>
> INFO   | jvm 1    | 2006/09/13 03:08:51 |       magicName =
> "JSX.magic.MagicClass14"
>
>
>
> Things work fine so you can go ahead and add support for this JVM (if
> you haven't already).
>
>
>
> -- Damien
>
>
>
> Damien Evans
>
> Lead Architect
>
> TeraMedica Healthcare Technology
>
> 10400 Innovation Dr,
>
> Suite 200
>
> Milwaukee, WI 53226
>
> + 1 414 908 7723 office
>
> + 1 414 839 3568 cell
>
> devans@... <mailto:devans@...>
>
>
>
>
>
>

This email is to inform you about the release of version '2.2.5.2' of 'Java
Serialization to XML' through freshmeat.net. All URLs and other useful
information can be found at

     http://freshmeat.net/projects/jsx/

The changes in this release are as follows:
Minor bugfixes.

Release focus:
6 - Minor bugfixes

Project added:
Tue, Oct 10th 2000 01:06 (5 years, 11 months ago)

Project description:
Java Serialization to XML (JSX) translates between Java and XML,
making it possible to search, test, profile, and audit your object
data with ordinary XML and text processing tools. Your data can be
migrated to new application versions, to C++, and to other
applications by transforming the XML. Unlike other Java XML
serializers, JSX is accurate for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

If you would like to cancel subscription to releases of this project,
login to freshmeat.net and choose 'home' from the personal menubar at the
top of the page. You'll be presented with a list of projects and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

The JSX website is now available again, at:

     http://www.javaserializationtoxml.com/

cheers,
Brendan

Hi all,

We've had some trouble with the domain name "jsx.org", but the website
is still there, at this IP address:

http://66.70.223.72/


cheers,
Brendan

Hi all,http://66.70.223.72/

This email is to inform you about the release of version '2.2.5.1' of 'Java
Serialization to XML' through freshmeat.net. All URLs and other useful
information can be found at

     http://freshmeat.net/projects/jsx/

The changes in this release are as follows:
Memory and performance were improved for serialization in Java 1.4 and
1.5.

Release focus:
4 - Minor feature enhancements

Project added:
Tue, Oct 10th 2000 01:06 (4 years, 11 months ago)

Project description:
Java Serialization to XML (JSX) translates between Java and XML,
making it possible to search, test, profile, and audit your object
data with ordinary XML and text processing tools. Your data can be
migrated to new application versions, to C++, and to other
applications by transforming the XML. Unlike other Java XML
serializers, JSX is accurate for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

If you would like to cancel subscription to releases of this project,
login to freshmeat.net and choose 'home' from the personal menubar at the
top of the page. You'll be presented with a list of projects and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

____________________________| Advertising |____________________________
Tame your development challenges

with Apache's Geronimo App Server. Download it for free--and be entered to
win a 42" plasma tv or your very own Sony(tm)PSP. Click here to play:

http://sourceforge.net/geronimo.php
____________________________| Advertising |____________________________

This email is to inform you about the release of version '2.2.5.0' of 'Java
Serialization to XML' through freshmeat.net. All URLs and other useful
information can be found at

     http://freshmeat.net/projects/jsx/

The changes in this release are as follows:
The "superclasses" attribute of the <object> tag is now optional for
backward compatibility with version 2.0. Generation of JSX XML from
non-JSX sources was made easier.

Release focus:
4 - Minor feature enhancements

Project added:
Tue, Oct 10th 2000 01:06 (4 years, 10 months ago)

Project description:
Java Serialization to XML (JSX) translates between Java and XML,
making it possible to search, test, profile, and audit your object
data with ordinary XML and text processing tools. Your data can be
migrated to new application versions, to C++, and to other
applications by transforming the XML. Unlike other Java XML
serializers, JSX is accurate for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

If you would like to cancel subscription to releases of this project,
login to freshmeat.net and choose 'home' from the personal menubar at the
top of the page. You'll be presented with a list of projects and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

Hi,

I have a constant worry with class evolution. I use Brendan's default method
but I make each class implement Repairable which has a single void method:
repair(). Seializable fields must never change type or name - I just invent
new fields (brutal discipline). The repair method checks to see if the new
fields are null and then assigns a sensible value to them (usually a new
class instance). The repair method does tend to grow but once in place it
can be neglected until you need to amend it again. This is similar to
readResolve but I can call the repair methods in the order that I want and
allow cross class reference.
The repair methods are called immediately after deserialization.

Regards

Mike
~~~~~~~~~~~~~~
Mike Goldwater




>From: Brendan Macmillan <Brendan.Macmillan@...>
>Reply-To: JSX-ideas@yahoogroups.com
>To: JSX-ideas@yahoogroups.com
>Subject: Re: [JSX] Advice on old JSX version 1
>Date: Wed, 17 Aug 2005 17:03:17 +1000
>
>I think that's JSX version "0".
>
>I think you are talking about class evolution, and that you can't read in
>XML you have that used the old classes (before you evolved your classes
>from
>using just a String to a "bit more complex pojo"). It's not clear to me
>from
>your email if that's the case, but that's my guess.
>
>Class evolution is a big and serious problem. Some aspects are trivial to
>handle; some are not.
>
>Basically, it sounds like the version of your classes you were writing with
>was not the same as the version you were reading with. The XML format for
>JSX (1 and 0) is determined by your java classes. Change them, and you
>change the XML format. For many simple changes, this is automatically
>accounted for (see the JOS spec for details) - but for more complex
>changes,
>such as yours, the following is the way to approach it:
>
>You can update your XML (from old format to new format), by reading the old
>XML into the old version of your classes, translate those objects into
>objects of the new version, and then write out those classes.
>
>The tricky bit is the translation, and there are many approaches.
>
>Perhaps the simplest way is in the JOS spec, and it's the way that all of
>the standard Java classes handle evolution using serialization. It's far
>from perfect, but it works and it's standard:
>
>There is a way to make "virtual fields" in the new class (so that looks
>like
>the old version of the class), and then in the "readObject" method of the
>class (this method is called *by* JSX), have code that reads that field and
>fills in the other fields accordingly. This "virtual field" technique uses
>"getField" and "serialPersistentFields".
>
>For a short-cut: if the old field name is unique (ie, you use all different
>field names in the new version of the class), then you don't need a
>"virtual
>field" - you can just check to see if that field has a non-null value, and
>if so, calculate the other fields from it (again, within the classes
>"readObject" method).
>
>Of course, this short-cut gets a bit messy over time, with ancient fields
>remaining - but once all the old XML has been upgraded, you can delete
>them,
>so it's not too bad in practice.
>
>The above technique is usally called "customization", and is from JOS (Java
>Object Serialization) which JSX implements, is usually called
>"customization". There are several tutorials on the web about it. The JOS
>spec has some examples in it.
>
>The "JSX Manual" is mostly about object evolution, and although it is for
>JSX2, the above JOS technique is the same. (the link is in the top line of
>the support page, for JSX2: www.jsx.org).
>
>
>BTW:  It might seem "nicer" OO to have a separate object altogether to do
>the translation, but it won't have access to private fields (unless its an
>inner class), and you'll need to have both the old version of the class and
>the new version (which is awkard if they have the same name - even if using
>separate classloaders).
>
>I reccommend you look for an example of a classes' "readObject", and:
>1. have all fields in the class (both old and new).
>
>2. have logic in the readObject to detect which version has been read in
>(eg. the new fields will all be null when reading in an old version - but
>make sure they are never null when reading in a new version.  Or, you could
>check to see if the old field was null or not) Don't worry too much, you
>only need to get this right for the actual upgrade. You could always add an
>explicit "version" field. Note that primitive fields that didn't exist get
>the default value of 0 or false (which is even more ambigous than using
>null
>as a flag).
>
>3. if you want to be fancier, using "getField" allows you to explicitly
>check for whether a field exists or not. This overcomes the ambiguity of
>using null (in 2 above), that null might mean the field didn't exist
>before... or simply that it did exist before and had the value null.
>Another advantage of "getField" is that because this field doens't really
>exist, its value isn't written out in the new XML.
>
>4. if it is the old version of the class, execute code to calculate the
>values of the new fields, and set them appropriately. If you are using the
>old field value as a version flag (as in 2 above), you might want to get
>the
>old field to null when you are finished.
>
>5. use JSX to read in the old XML
>
>6. use JSX to write out the new XML - this will include the old field (if
>using 2 above), but it doesn't matter, and if you delete that field in the
>class, the next time you read and write the XML, it will disappear.
>
>Class evolution is a very difficult topic. The above is a simple way to
>cope
>with a simple evolution. I think it will solve your specific problem, but
>it
>won't solve every evolution problem.
>
>
>cheers,
>Brendan
>PS: I've repeated myself a lot in the above. You can use this to check that
>you've understood what I meant the first time. Evolution is a confusing
>area.
>
>----- Original Message -----
>From: "lpcarmed" <ggindele@...>
>To: <JSX-ideas@yahoogroups.com>
>Sent: Wednesday, August 17, 2005 6:08 AM
>Subject: [JSX] Advice on old JSX version 1
>
>
>I still use 0.9.8.2. After I changed a String type on the object model
>to a bit more complex pojo and let the application run in production
>for a while, I got about 1000 chunks of JSX XML I could not
>desterilize back to Java. What's the recommended way up fixing this?
>Preserving the data from that String is not critical. I'd like to have
>a programmatic way handling this. Your help is appreciated.
>
>Cheers,
>Gabe
>
>
>
>
>
>
>Yahoo! Groups Links
>
>
>
>
>
>

I think that's JSX version "0".

I think you are talking about class evolution, and that you can't read in
XML you have that used the old classes (before you evolved your classes from
using just a String to a "bit more complex pojo"). It's not clear to me from
your email if that's the case, but that's my guess.

Class evolution is a big and serious problem. Some aspects are trivial to
handle; some are not.

Basically, it sounds like the version of your classes you were writing with
was not the same as the version you were reading with. The XML format for
JSX (1 and 0) is determined by your java classes. Change them, and you
change the XML format. For many simple changes, this is automatically
accounted for (see the JOS spec for details) - but for more complex changes,
such as yours, the following is the way to approach it:

You can update your XML (from old format to new format), by reading the old
XML into the old version of your classes, translate those objects into
objects of the new version, and then write out those classes.

The tricky bit is the translation, and there are many approaches.

Perhaps the simplest way is in the JOS spec, and it's the way that all of
the standard Java classes handle evolution using serialization. It's far
from perfect, but it works and it's standard:

There is a way to make "virtual fields" in the new class (so that looks like
the old version of the class), and then in the "readObject" method of the
class (this method is called *by* JSX), have code that reads that field and
fills in the other fields accordingly. This "virtual field" technique uses
"getField" and "serialPersistentFields".

For a short-cut: if the old field name is unique (ie, you use all different
field names in the new version of the class), then you don't need a "virtual
field" - you can just check to see if that field has a non-null value, and
if so, calculate the other fields from it (again, within the classes
"readObject" method).

Of course, this short-cut gets a bit messy over time, with ancient fields
remaining - but once all the old XML has been upgraded, you can delete them,
so it's not too bad in practice.

The above technique is usally called "customization", and is from JOS (Java
Object Serialization) which JSX implements, is usually called
"customization". There are several tutorials on the web about it. The JOS
spec has some examples in it.

The "JSX Manual" is mostly about object evolution, and although it is for
JSX2, the above JOS technique is the same. (the link is in the top line of
the support page, for JSX2: www.jsx.org).


BTW:  It might seem "nicer" OO to have a separate object altogether to do
the translation, but it won't have access to private fields (unless its an
inner class), and you'll need to have both the old version of the class and
the new version (which is awkard if they have the same name - even if using
separate classloaders).

I reccommend you look for an example of a classes' "readObject", and:
1. have all fields in the class (both old and new).

2. have logic in the readObject to detect which version has been read in
(eg. the new fields will all be null when reading in an old version - but
make sure they are never null when reading in a new version.  Or, you could
check to see if the old field was null or not) Don't worry too much, you
only need to get this right for the actual upgrade. You could always add an
explicit "version" field. Note that primitive fields that didn't exist get
the default value of 0 or false (which is even more ambigous than using null
as a flag).

3. if you want to be fancier, using "getField" allows you to explicitly
check for whether a field exists or not. This overcomes the ambiguity of
using null (in 2 above), that null might mean the field didn't exist
before... or simply that it did exist before and had the value null.
Another advantage of "getField" is that because this field doens't really
exist, its value isn't written out in the new XML.

4. if it is the old version of the class, execute code to calculate the
values of the new fields, and set them appropriately. If you are using the
old field value as a version flag (as in 2 above), you might want to get the
old field to null when you are finished.

5. use JSX to read in the old XML

6. use JSX to write out the new XML - this will include the old field (if
using 2 above), but it doesn't matter, and if you delete that field in the
class, the next time you read and write the XML, it will disappear.

Class evolution is a very difficult topic. The above is a simple way to cope
with a simple evolution. I think it will solve your specific problem, but it
won't solve every evolution problem.


cheers,
Brendan
PS: I've repeated myself a lot in the above. You can use this to check that
you've understood what I meant the first time. Evolution is a confusing
area.

----- Original Message -----
From: "lpcarmed" <ggindele@...>
To: <JSX-ideas@yahoogroups.com>
Sent: Wednesday, August 17, 2005 6:08 AM
Subject: [JSX] Advice on old JSX version 1


I still use 0.9.8.2. After I changed a String type on the object model
to a bit more complex pojo and let the application run in production
for a while, I got about 1000 chunks of JSX XML I could not
desterilize back to Java. What's the recommended way up fixing this?
Preserving the data from that String is not critical. I'd like to have
a programmatic way handling this. Your help is appreciated.

Cheers,
Gabe






Yahoo! Groups Links

I still use 0.9.8.2. After I changed a String type on the object model
to a bit more complex pojo and let the application run in production
for a while, I got about 1000 chunks of JSX XML I could not
desterilize back to Java. What's the recommended way up fixing this?
Preserving the data from that String is not critical. I'd like to have
a programmatic way handling this. Your help is appreciated.

Cheers,
Gabe

This email is to inform you about the release of version '2.2.4.1' of 'Java
Serialization to XML' through freshmeat.net. All URLs and other useful
information can be found at

     http://freshmeat.net/projects/jsx/

The changes in this release are as follows:
A bugfix was made for the "java.lang.Enum class not found" error on
Windows 2000.

Release focus:
6 - Minor bugfixes

Project added:
Tue, Oct 10th 2000 01:06 (4 years, 9 months ago)

Project description:
Java Serialization to XML (JSX) translates between Java and XML,
making it possible to search, test, profile, and audit your object
data with ordinary XML and text processing tools. Your data can be
migrated to new application versions, to C++, and to other
applications by transforming the XML. Unlike other Java XML
serializers, JSX is accurate for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

If you would like to cancel subscription to releases of this project,
login to freshmeat.net and choose 'home' from the personal menubar at the
top of the page. You'll be presented with a list of projects and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

____________________________| Advertising |____________________________
Reap the benefits of migrating from Solaris to Linux on IBM's POWER
Architecture.


Get free Resources:  Porting guides, Roadmaps, workshops, white papers,
forums, access to hardware and technical support.
Get started today!

http://ads.osdn.com/?ad_id=7443&alloc_id=16416&op=click
____________________________| Advertising |____________________________

Hi Antonio,

Thanks very much for the excellent bug report - only thing missing was the OS,
which surprisingly
happens to be relevant in this case (please see bug report guide at
http://www.jsx.org/support.html).

A fixed version is now available on the website (www.jsx.org)
(email from www.freshmeat.net should appear within 2 hours or so).

The bug only appears on some platforms - the only such platform that it has been
currently tested on
is Windows 2000. However, it should fix the problem on them all.

Please let me know (reply on this list) if you see any problems.


cheers,
Brendan Macmillan

----- Original Message -----
From: "Antonio" <yoguipeludodelinfierno@...>
To: <JSX-ideas@yahoogroups.com>
Sent: Tuesday, August 02, 2005 7:08 PM
Subject: [JSX] Problem with JSX 2.2.4.0


> Hi,
> I'm migrating from JSX 0.8.14.2 to JSX 2.2.4.0.
> When I try to read a serialized XML, I see the following error:
>
> java.lang.NoClassDefFoundError: java/lang/Enum
[snip]

Hi,
I'm migrating from JSX 0.8.14.2 to JSX 2.2.4.0.
When I try to read a serialized XML, I see the following error:

java.lang.NoClassDefFoundError: java/lang/Enum
	 at JSX.Enum15.resolveEnum(Enum15.java:11)
	 at JSX.ObjectReader.object(ObjectReader.java:1310)
	 at JSX.ObjectReader.fillDefault(ObjectReader.java:1582)
	 at JSX.ObjectReader.fillDeclaredClass(ObjectReader.java:1506)
	 at JSX.ObjectReader.object(ObjectReader.java:1140)
	 at JSX.ObjectReader.readObject(ObjectReader.java:584)
	 at JSX.ObjectReader.readObjectOverride(ObjectReader.java:512)
	 at java.io.ObjectInputStream.readObject
(ObjectInputStream.java:318)
	 at com.cys.mBoss.beans.ServidorKb.leerKBClientes
(ServidorKb.java:1191)
	 at com.cys.mBoss.Estratega.ReglasPerfil.service
(ReglasPerfil.java:90)
	 at javax.servlet.http.HttpServlet.service
(HttpServlet.java:853)
	 at
weblogic.servlet.internal.ServletStubImpl$ServletInvocationAction.run
(ServletStubImpl.java:1006)
	 at weblogic.servlet.internal.ServletStubImpl.invokeServlet
(ServletStubImpl.java:419)
	 at weblogic.servlet.internal.ServletStubImpl.invokeServlet
(ServletStubImpl.java:315)
	 at
weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction
.run(WebAppServletContext.java:6718)
	 at weblogic.security.acl.internal.AuthenticatedSubject.doAs
(AuthenticatedSubject.java:321)
	 at weblogic.security.service.SecurityManager.runAs
(SecurityManager.java:121)
	 at
weblogic.servlet.internal.WebAppServletContext.invokeServlet
(WebAppServletContext.java:3764)
	 at weblogic.servlet.internal.ServletRequestImpl.execute
(ServletRequestImpl.java:2644)
	 at weblogic.kernel.ExecuteThread.execute
(ExecuteThread.java:219)
	 at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:178)


To read XML file I use the following code:


  FileReader fi = new FileReader(PathToFile);
  JSX.ObjectReader in = new JSX.ObjectReader(fi);
  myObject= (MyObject) in.readObject();

Where MyObject is an object that I've previously serialized using the
following code:

FileWriter fw=new FileWriter(PathToFile);
ObjectOutputStream out2 = new JSX.ObjectWriter(fw);
out2.writeObject(myObject);

I've seen that Enum class is part of the new j2sdk 1.5, but in the
JSX.org page says that works with versions 1.2,1.3,1.4 and 1.5. I'm
working with j2sdk 1.4.2_05.

Can anybody helps me?

Best Regards.

This email is to inform you about the release of version '2.2.4.0' of 'Java
Serialization to XML' through freshmeat.net. All URLs and other useful
information can be found at

     http://freshmeat.net/projects/jsx/

The changes in this release are as follows:
The program is now available again.

Release focus:
4 - Minor feature enhancements

Project added:
Tue, Oct 10th 2000 01:06 (4 years, 9 months ago)

Project description:
Java Serialization to XML (JSX) translates between Java and XML,
making it possible to search, test, profile, and audit your object
data with ordinary XML and text processing tools. Your data can be
migrated to new application versions, to C++, and to other
applications by transforming the XML. Unlike other Java XML
serializers, JSX is accurate for all objects.

Trove categories:
[Development Status  ] 5 - Production/Stable
[Environment         ] Console (Text Based), MacOS X, Other Environment,
Web Environment, Win32 (MS Windows)
[Intended Audience   ] Developers
[License             ] OSI Approved :: GNU General Public License (GPL),
Other/Proprietary License with Free Trial
[Programming Language] Java
[Topic               ] Communications, Database, Software Development,
Software Development :: Libraries, Software Development :: Libraries ::
Java Libraries, Software Development :: Object Brokering, System ::
Archiving, System :: Recovery Tools, Text Processing :: Markup :: XML

If you would like to cancel subscription to releases of this project,
login to freshmeat.net and choose 'home' from the personal menubar at the
top of the page. You'll be presented with a list of projects and
categories you're subscribed to in the right column, which you may cancel
by highlighting the project or category in question and clicking the
'delete' button.

Sincerely,
freshmeat.net

Hi all,

JSX is now available.

This mailing list is also opened up, so if you are subscribed to it
you can now post to it.


Cheers,
Brendan Macmillan

Hi all,

I have closed down the list for now.

You can still search the arhives, and I will be able to post any relevant news
to you; but no one
will be able ot post.

Meanwhile, for existing customers, support options are indicated on the
homepage.

Thanks for your support over the years.


Cheers,
Brendan Macmillan

> Any comment on why the product was taken off the market or whether
> there are any plans to release the source-code?

It's now time to write up my PhD on JSX, and running a business at the same time
is a bit too much.
Processing sales takes a surprising amount of work, even though it is entirely
automated
(theoretically).

Part of the PhD is structural mappings for XML, using a new approach for XML
transformations. In due
course, this will be released as a product (and combined with JSX). Another
factor is that JSX has
been mature for years now, and other projects are catching up - I have more to
offer the world by
continuing to pioneer new products, rather focussing on slight variations
between different
products.

There are no plans to release source.


>
> Gili
>
>
>
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>
>