Hi,
>How many people think that better documentation of Config would help a lot?
Impossible to say until we have seen the improved docuumentation!
Regards
Mike
>From: "Brendan Macmillan" <bren@...>
>Reply-To: JSX-ideas@yahoogroups.com
>To: <JSX-ideas@yahoogroups.com>
>Subject: [JSX] Documentation on use of Config?
>Date: Fri, 3 May 2002 09:46:14 +1000
>
>I'm getting the impression that Config takes some time to learn how to use,
>and it is more complex and confusing than it needs to be.
>
>
>
>Another syntax is:
> Config cfg = new Config().superVersion();
>
>Also, if you are specifying an output stream, the ObjOut constructor is:
> ObjOut out = new ObjOut(yourStream, cfg);
>
>
>I hope this helps!
>Brendan
> Config cfg = new Config();
> cfg.superversion = true;
> ObjOut out = new ObjOut(cfg);
Regards
Mike
~~~~~~~~~~~~~~
Mike Goldwater
Auric Hydrates Ltd
26, Sandal Road
New Malden
Surrey KT3 5AP
UK
Tel and Fax: +44 (020) 8949 0353
Mobile: +44 07956 359001
_________________________________________________________________
MSN Photos is the easiest way to share and print your photos:
http://photos.msn.com/support/worldwide.aspx
Greetings,
It seems that minor class changes that Java serialization could live
with are causing JSX to lose its mind. That's not the problem, however -
the deserialization code is in a try/catch, but it hangs the JVM and
never returns for the catch -- not even an interrupt in the OS window
from which java was launched will wake it up, it has to be killed
(Win/NT & Linux). I'd like to make this a bit more user friendly -- any
suggestions?
-dd
Stack trace from offending exception:
java.lang.NullPointerException
at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1973)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1026)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at
JSX.XMLDeserialize.addVectorElements(XMLDeserialize.java:2114)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:827)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.createArray(XMLDeserialize.java:1755)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:673)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at
JSX.XMLDeserialize.addVectorElements(XMLDeserialize.java:2114)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:827)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
at
JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:330)
at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
at
java.io.ObjectInputStream.readObject(ObjectInputStream.java:232)
Hi David,
This sounds pretty serious!! What version JVM are you using? It sounds
like JSX is
provoking a bug in it.
Cheers,
Brendan
> -----Original Message-----
> From: David S. Dixon [mailto:ddixon@...]
> Sent: Wednesday, 8 May 2002 11:44 PM
> To: JSX-ideas@yahoogroups.com
> Subject: [JSX] JVM hang
>
>
> Greetings,
>
> It seems that minor class changes that Java serialization could live
> with are causing JSX to lose its mind. That's not the problem, however -
>
> the deserialization code is in a try/catch, but it hangs the JVM and
> never returns for the catch -- not even an interrupt in the OS window
> from which java was launched will wake it up, it has to be killed
> (Win/NT & Linux). I'd like to make this a bit more user friendly -- any
>
> suggestions?
>
> -dd
>
> Stack trace from offending exception:
>
> java.lang.NullPointerException
> at JSX.XMLDeserialize.addAttr(XMLDeserialize.java:1973)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1026)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at
> JSX.XMLDeserialize.addVectorElements(XMLDeserialize.java:2114)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:827)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.createArray(XMLDeserialize.java:1755)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:673)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at
> JSX.XMLDeserialize.addVectorElements(XMLDeserialize.java:2114)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:827)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.addTags(XMLDeserialize.java:2065)
> at
> JSX.XMLDeserialize.defaultReadObject(XMLDeserialize.java:1437)
> at JSX.XMLDeserialize.createObject(XMLDeserialize.java:1247)
> at JSX.XMLDeserialize.deserialize(XMLDeserialize.java:330)
> at JSX.ObjIn.readObjectOverride(ObjIn.java:138)
> at
> java.io.ObjectInputStream.readObject(ObjectInputStream.java:232)
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> JSX-ideas-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
When I generated a DTD, how should to me make to generate a file XML
with the DTD?
I do not want any structure of the data in the file XML, only the
data. The structure of the data is in the DTD.
Please tell me how to generate a file XML without description of
structure but with a DTD.
Hi aldocaponefr (?),
I'm not sure what you mean...
Do you want the XML to reference the DTD, so that a validating parser
(like SAX) will automatically associate the XML with that DTD? JSX
doesn't do this at the moment, but it's not hard to modify the source
code of JSX, to automatically add in the line to do that.
Is that what you meant?
Cheers,
Brendan
> -----Original Message-----
> From: aldocaponefr [mailto:capone.aldo@...]
> Sent: Monday, 13 May 2002 4:27 PM
> To: JSX-ideas@yahoogroups.com
> Subject: [JSX] DTD
>
>
> When I generated a DTD, how should to me make to generate a file XML
> with the DTD?
> I do not want any structure of the data in the file XML, only the
> data. The structure of the data is in the DTD.
> Please tell me how to generate a file XML without description of
> structure but with a DTD.
>
>
>
> To unsubscribe from this group, send an email to:
> JSX-ideas-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Hi,
I'm the project leader for Metacosm ( http://metacosm.org ).
I saw yesterday your poll "If JSX was available under a non-GPL open source
license, that prevented any commercial use, how would it affect you?" (now
commented in the HTML source code).
Metacosm is under GPL, and used, until recently, JSX (GPL), Xerces (Apache
1.1) and Log4j(Apache 1.1). Due to incompatibilities between GPL and Apache
1.1 (Apache Software Group and FSF disagree on this incompatibility), we
removed Apache 1.1 modules and replaced them be Piccolo (LGPL) and
Lumberjack (LGPL).
We like the GPL, so we would prefer JSX to be available under GPL. If JSX
changed for an GPL incompatible license, we would drop JSX. If JSX changed
for a GPL compatible license, we would probably look for GPL equivalent and
decide what to do depending of this search results. If JSX was tri-licensed
(commercial, GPL and an other non-GPL open source license), we would use
the GPL version.
Summary: we would prefer JSX stays available under GPL.
--
Benoît Sibaud
http://oumph.free.fr
Hi Benoît,
> I saw yesterday your poll "If JSX was available under a non-GPL
> open source
> license, that prevented any commercial use, how would it affect you?" (now
> commented in the HTML source code).
Looks like you have foiled my cunning plan of hiding this information! ;-)
> Metacosm is under GPL, and used, until recently, JSX (GPL), Xerces (Apache
> 1.1) and Log4j(Apache 1.1). Due to incompatibilities between GPL
> and Apache 1.1 (Apache Software Group and FSF disagree on this
incompatibility),
> we removed Apache 1.1 modules and replaced them be Piccolo (LGPL) and
> Lumberjack (LGPL).
If you like GPL, it is good to promote it. For example, I was not aware of
that Piccolo was LGPL (tho heard it is muc faster than Xerces); and I hadn't
heard of the LGPL alternative to Log4j. If you mentioned these technologies
on
your web-site, it would do a lot for the FSF cause - a lot more than using
them silently! ;-) [ But I haven't checked if you mention them in comments
in
the HTML source code... ;-) ]
> We like the GPL, so we would prefer JSX to be available under GPL. If JSX
> changed for an GPL incompatible license, we would drop JSX. If JSX changed
> for a GPL compatible license, we would probably look for GPL
> equivalent and decide what to do depending of this search results. If JSX
was
> tri-licensed (commercial, GPL and an other non-GPL open source license),
we
> would use the GPL version.
>
> Summary: we would prefer JSX stays available under GPL.
Thanks for this clear articulation of policy.
The decision made (and which still stands) is for JSX to remain available
under
the GPL (and also commercial license).
However, I should mention that JSX has inspired another project, which is a
complete rewrite and generalization of JSX as an open platform - tho part of
this platform will be closed-source. Since the existing JSX will continue,
the existance of this second project should not cause any problems.
Cheers,
Brendan
PS: I'm glad that you are OK with the dual GPL/commercial licensing of JSX.
I think
this is a much better solution all round than the Apache-style one (which I
think makes money for consultants who use the technology - there's a
motivation
there for not making it as good as possible).
Hi all,
I'm on holidays til Mon 27 May (that's next Monday).
However, it may still be worth asking any question you have, since other
people on the list may enjoy answering it. And of course, you might as well
post it while it's fresh in your mind, and I'll see it when I get back. ;-)
Meanwhile, have a great week everyone!
Cheers,
Brendan
Hi,
> Looks like you have foiled my cunning plan of hiding this information!
> ;-)
That's my hobby to read only HTML comments on the web :)
> If you like GPL, it is good to promote it. For example, I was not aware
> of that Piccolo was LGPL (tho heard it is muc faster than Xerces); and I
> hadn't heard of the LGPL alternative to Log4j. If you mentioned these
> technologies on your web-site, it would do a lot for the FSF cause - a
> lot more than using them silently! ;-) [ But I haven't checked if you
> mention them in comments in the HTML source code... ;-) ]
I just updated http://metacosm.org (we have a hard week-end to find new
libs, replace the old ones, test and debug, and I had not time to update
the site sooner).
> The decision made (and which still stands) is for JSX to remain available
> under the GPL (and also commercial license).
Good news.
> However, I should mention that JSX has inspired another project, which is
> a complete rewrite and generalization of JSX as an open platform - tho
> part of this platform will be closed-source. Since the existing JSX will
> continue, the existance of this second project should not cause any
> problems.
We had begun to implement our own "serialization binary to XML" code before
founding JSX. It works poorly and JSX is really much more advanced and
reliable :)
> PS: I'm glad that you are OK with the dual GPL/commercial licensing of
> JSX. I think this is a much better solution all round than the
> Apache-style one (which I think makes money for consultants who use the
> technology - there's a motivation there for not making it as good as
> possible).
I could be considered my free software zealot, but as long as a software is
a free software and ideally GPL-compliant, I'm fully OK. People who doesn't
want GPL can still use JSX with the commercial license, and people who like
free software can use a free license. Sounds good. That's also the Cygnus
business model (www.cygwin.com).
We are currently trying/testing free JVM (ORP, kissme) and gcj. First tests show
free JVM lack to many features for our project. gcj 3.0 has some problems
too (ICE, no Swing, compilation problems with java.io). Just finished to
compile gcj 3.1 (and I should also test astyle for Java indentation.)
--
Benoît Sibaud
http://oumph.free.fr
Hi Benoît,
> I just updated http://metacosm.org (we have a hard week-end to find new
> libs, replace the old ones, test and debug, and I had not time to update
> the site sooner).
Actually, I was also kind of hoping that you'd let other people know about
all the GPL software you use... like JSX ;-)
> We had begun to implement our own "serialization binary to XML"
> code before founding JSX. It works poorly and JSX is really much more
> advanced and reliable :)
Cool! ;-)
> > PS: I'm glad that you are OK with the dual GPL/commercial licensing of
> > JSX. I think this is a much better solution all round than the
> > Apache-style one (which I think makes money for consultants who use the
> > technology - there's a motivation there for not making it as good as
> > possible).
>
> I could be considered my free software zealot, but as long as a
> software is a free software and ideally GPL-compliant, I'm fully OK.
> People who doesn't want GPL can still use JSX with the commercial license,
> and people who like free software can use a free license. Sounds good.
Yes - this is what the sleepy cat software people say - it sounds a bit
like the "tit for tat" strategy for iterated prisoner's dilemma (which
James Gosling references from his site).
If you are open source, then we are too. If you are closed source, then
so are we.
> That's also the Cygnus business model (www.cygwin.com).
I checked them out, but they don't seem to be doing this any more...
> We are currently trying/testing free JVM (ORP, kissme) and gcj.
> First tests show free JVM lack to many features for our project. gcj 3.0
> has some problems too (ICE, no Swing, compilation problems with java.io).
> Just finished to compile gcj 3.1 (and I should also test astyle for Java
> indentation.)
I fear that JSX may not work with these alternative implementations...
but it sounds like you aren't intending to switch for a while, anyway.
Cheers,
Brendan
Hi,
> > I just updated http://metacosm.org (we have a hard week-end to find new
> > libs, replace the old ones, test and debug, and I had not time to
> > update the site sooner).
>
> Actually, I was also kind of hoping that you'd let other people know
> about all the GPL software you use... like JSX ;-)
According to http://cgi.cs.wisc.edu/scripts/ballard/bofhserver.pl
The cause of the problem is:
"Well fix that in the next (upgrade, update, patch release, service pack)."
Done. Have a look at http://www.metacosm.org/legal.php3
> > That's also the Cygnus business model (www.cygwin.com).
> I checked them out, but they don't seem to be doing this any more...
http://cygwin.com/faq/faq_8.html#SEC133
"Cygwin is currently available for proprietary use only through a
proprietary-use license. Please contact sales@... for more
information."
> > We are currently trying/testing free JVM (ORP, kissme) and gcj.
> > First tests show free JVM lack to many features for our project. gcj
> > 3.0 has some problems too (ICE, no Swing, compilation problems with
> > java.io). Just finished to compile gcj 3.1 (and I should also test
> > astyle for Java indentation.)
>
> I fear that JSX may not work with these alternative implementations...
> but it sounds like you aren't intending to switch for a while, anyway.
In fact, something working with these alternative implementations is needed
to open a project on FSF Savannah (http://savannah.gnu.org/ ), and we are
trying to move from SourceForge to Savannah. JSX is not yet an essential
part of Metacosm, so it isn't vital it works with free JVM (for Savannah,
and for now). Anyway I'll report our test results for JSX.
Ps: did you know Mauve (http://sources.redhat.com/mauve/ )?
--
Benoît Sibaud
http://oumph.free.fr
Hi Benoît,
> According to http://cgi.cs.wisc.edu/scripts/ballard/bofhserver.pl
> The cause of the problem is:
> "Well fix that in the next (upgrade, update, patch release,
> service pack)."
heheh ironically, this is exactly the "release early, release often"
philosophy
of XP and OSS, and it seems to work really well. Iterative prototyping is
the
only way to go when you are exploring a genuinely new space.
> Done. Have a look at http://www.metacosm.org/legal.php3
Hey, that's really cool! The images are very effective (especially the
piccolo one).
Seeing it, I think it also adds credibility to your own project.
> http://cygwin.com/faq/faq_8.html#SEC133
> "Cygwin is currently available for proprietary use only through a
> proprietary-use license. Please contact sales@... for more
> information."
Cool, thanks for that.
> > I fear that JSX may not work with these alternative implementations...
> > but it sounds like you aren't intending to switch for a while, anyway.
>
> In fact, something working with these alternative implementations
> is needed to open a project on FSF Savannah (http://savannah.gnu.org/ ),
and we are
> trying to move from SourceForge to Savannah. JSX is not yet an essential
> part of Metacosm, so it isn't vital it works with free JVM (for Savannah,
> and for now). Anyway I'll report our test results for JSX.
If Java's own Serialization is working on these alt impl, then it's
certainly
possible for JSX to work on them. However, it can't be a priority just at
the
moment (but it would be interesting).
BTW: I love the cartoon at http://savannah.gnu.org/
> Ps: did you know Mauve (http://sources.redhat.com/mauve/ )?
No, I hadn't heard of this (nor of Savannah), but I'm not sure I agree with
it -
the point of the test suite is to ensure compatibility. So, if the
test-suites are
forked, then that's bad... of course, if the main point is not to replace
the
real test or provide an alternative gold standard, but merely to be a
resource to help
move people towards passing the real test (like a practice exam), then that
is great.
But even if that was the point, I think people could start to use it as a
"silver
standard", and then, very soon, we have a fork in the java road. Sure, Sun
doesn't
control it any more, but splits the developers. OTOH, the Unix market used
to be like this
before Linux came along and unified it in effect - so maybe all these free
alternatives are a good idea? Certainly, it will keep the Sun people
honest! ;-)
BTW: From Sun's historical business approach, I think they are right to
worry
about fragmentation of standards, even if it means it's not entirely fair to
everyone (eg JBoss). It's the lesser evil, because fragmentation of
standards
is bad for everyone. I believe that Sun isn't making real money from Java
and
J2EE (although it is so good, that I would be happy if they did), and they
are going
on about standards mainly because they know it makes a good environment for
both
them and everyone else to create valuable products, and so make money. It's
a
business strategy that maximizes the global benefit (which means that it
might not
be optimal for everyone, locally).
For example, Sun (successfully) sued Microsoft for distributing a
non-compatible version of Java - they are very serious about enforing
standards!
Anyway, just my opinion, don't want to start a flame war! ;-)
Thanks a lot for all the links, and for adding JSX (and others) to your
project site!
Cheers,
Brendan
JSX FAQ - 14 November 2001
=======
JSX instantly XML-enables applications, by re-implementing the Serialization
API for XML.
FAQ Contents:
(1). Background
(2). Using the Serialization API
(3). Using JSX
If your question is not answered here, please try the homepage:
http://www.csse.monash.edu.au/~bren/JSX/
or mailing list:
http://groups.yahoo.com/group/JSX-ideas/messages
------------------------------------------------------------------------------
(1). Background
===============
(1.1) JSX stands for...?
Java Serialization to XML
(1.2) What does JOS stand for?
Java Object Serialization (sometimes referred to as "Java's own Serialization")
(1.3) What are the uses of JSX?
- Long-term persistence - XML can be modified directly.
- A transparent protocol for communicating between different components,
that is easy to debug, and able to cope with different objects.
- Configuration files.
- A debugging tool - dumping object state.
(1.4) What are the benefits of JSX?
- A human-readable form of normally invisible objects
- A human-edtiable form, for entering and editing objects
- A human-comprehendible wire/file protocol for object and data exchange
between other applications and languages
(1.5) What are the goals of JSX?
To be able to instantly XML-enable applications, without needing to change
them at all.
- to produce a "human comprehendible" XML representation of object graphs,
that is readable and robust under human edits.
- in the long-term, to help users handle the inevitable evolution of objects
- a direct JOS replacement.
- replaceable *by* JOS. Thus, JSX should not pollute the Serialization API -
and so JSX can only add functionality through its constructors, using the
Config object.
(2). Using the Serialization API
================================
(2.1). Where's a good tutorial?
"Advanced Object Serialization", by John Zukowski (August 2001)
http://developer.java.sun.com/developer/technicalArticles/ALT/serialization/
(2.2). How do I write my own readObject() and writeObject() methods?
Here's the signatures:
private void readObject(ObjectInputStream ois)
throws ClassNotFoundException, IOException {
//your code here
}
private writeObject(ObjectOutputStream oos)
throws IOException {
//your code here
}
(2.3). How do I use GetField?
It can only be used within a readObject() method that you have coded for your
class, and is called by the serialization system.
See example in:
http://developer.java.sun.com/developer/technicalArticles/ALT/serialization/
It's almost halfway through, under the heading: "Using ObjectStreamField"
(3). Using JSX
==============
(3.1). How do I use Config?
Config is used to configure JSX for both input and output. You create the
Config object, set it, and then pass it into the constructor of either an
ObjIn or ObjOut. For example:
Config cfg = new Config().setNoSuchFieldHandler(handler).setFormatting(false);
ObjectInputStream in = new ObjIn(cfg); //pass it in
Note that the option setting can be chained. Check the source code
(Config.java) for more options.
For the above example, "handler" is used like an event handler. A common
approach is to subclass the default implementation with your own anonymous
class:
NoSuchFieldHandler handler = new NoSuchFieldHandler() {
public String noSuchField(Class c, String fieldName) {
if (c==TheClassName.class && fieldName.equals("theOldFieldName") )
return "theNewFieldName";
else
throw new NoSuchFieldException("No mapping for "+theOldFieldName+" in
"+c);
}
};
//NOTE: instead of "if" above, use a Hashtable or HashMap for more complex cases
//Eg. could use two: first tier maps classes to HashMaps, which in turn maps
//old fieldnames to new fieldnames.
Hi all,
Just a pre-warning about the coming price rise on 30 June 2002. Any
commercial
licenses signed before then will come under the present pricing. (Of
course,
this does not affect GPL users).
The planned price rise is quite dramatic, as those who saw the last price
rise
can imagine.
BTW: the complete rewrite is well beyond the functioning prototype stage,
and
is in the last few rounds of testing before release.
The architecture enables third-party add-ons to easily take advantage of
both the very simple front-end of Serialization (ie a single call to read
and
write); and also the XML back-end is now easily customizable for different
XML formats. In fact, it is also possible to plug-in a non-XML back-end
(such
as one that makes SQL calls, for example, or generates a GUI, or formats a
report.)
This architecture will be made as open as possible, to facilitate the
success of such third-party tools. Please be in contact if this sounds
interesting to you or your company.
Have a great day, everyone!
Cheers,
Brendan Macmillan
when you try to use JSX in a J2EE environment, then the
ObjIn.resolveClass throws a ClassNotFoundException because the JSX uses
the wrong ClassLoader !
the method shouldn't use Class.forName it should use
Thread.currentThread().getContextClassLoader().loadClass(v.getName());
instead of this !
please change in the next release
thanks
change the Method with the following lines will fix the bug !
protected Class resolveClass(ObjectStreamClass v) throws IOException,
ClassNotFoundException {
//return Class.forName(v.getName(), true,
this.getClass().getClassLoader()); //Wolf test: same as forName(name)
//return Class.forName(v.getName(), false, cl);
Class clazz = null;
try {
//clazz = Class.forName(v.getName()); //this *would*
solve Wolf's problem
clazz=Thread.currentThread().getContextClassLoader().loadClass(v.getName());
//changed by T.Margreiter 2002-06-13
} catch (ClassNotFoundException e) {
throw new
ClassNotFoundException("forName(\""+v.getName()+"\") didn't find the
class. Please report this problem. Wrapped: "+e.getMessage());
//Will it work, in general? We'll see...
//clazz = super.resolveClass(v); //best: but
latestUserDefinedLoader...
}
return clazz;
}
Hi Ing. Thomas Margreiter,
> when you try to use JSX in a J2EE environment, then the
> ObjIn.resolveClass throws a ClassNotFoundException because the JSX uses
> the wrong ClassLoader !
> the method shouldn't use Class.forName it should use
> Thread.currentThread().getContextClassLoader().loadClass(v.getName());
> instead of this !
Thanks very much for this - I wasn't aware of this solution!
I've known of the potential problem for a long time, but thought the
only way to do it was the way JOS does it: JOS gets the Classloader of
the code which calls serialization. But because of the way JSX
subclasses the JOS ObjectInputStream, and is called through it's
superclass, there is one extra layer on the stack. Thus, JSX can't use
this techique.
> please change in the next release
Will do!
Looks like open source has proven its worth yet again!
Cheers,
Brendan Macmillan, JSX maintainer
> change the Method with the following lines will fix the bug !
>
> protected Class resolveClass(ObjectStreamClass v) throws IOException,
> ClassNotFoundException {
> //return Class.forName(v.getName(), true,
> this.getClass().getClassLoader()); //Wolf test: same as forName(name)
> //return Class.forName(v.getName(), false, cl);
> Class clazz = null;
> try {
> //clazz = Class.forName(v.getName()); //this *would*
> solve Wolf's problem
>
> clazz=Thread.currentThread().getContextClassLoader().loadClass(v.g
> etName());
> //changed by T.Margreiter 2002-06-13
> } catch (ClassNotFoundException e) {
> throw new
> ClassNotFoundException("forName(\""+v.getName()+"\") didn't find the
> class. Please report this problem. Wrapped: "+e.getMessage());
>
> //Will it work, in general? We'll see...
> //clazz = super.resolveClass(v); //best: but
> latestUserDefinedLoader...
> }
> return clazz;
> }
This email is to inform you of release '1.0.1.2' of 'Java Serialization for
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 class loader issue was fixed, so JSX now works in a J2EE
environment.
Project description:
Java Serialization for XML (JSX) enables, with two lines of code, all
program data to be inspected and processed as XML. This allows
objects from an old version of your program to be migrated to the
current version, despite class evolution. With unique data binding,
JSX works for all objects, since it implements the standard Java
Object Serialization specification.
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 you're
subscribed to in the right column, which you may cancel by highlighting
the project in question and clicking the 'delete' button.
Sincerely,
freshmeat.net
Hi Marti,
I'm developing an interesting idea for back-compatibility, which
seems to be very powerful, and may suit your needs:
> we have more faith in developers to update the read/write
> object method in Java while they are editing the object
> than in their ability to go and update the external scripts
> in XSLT, which they do not know. Either way, BW compatibility
> is hard to maintain, as you probably know.
The idea is to serialize a "Memento" object that represents the
Originating object. This gives you a level of indirection, so that
the mapping code between the two representations can change to cope
with updates. It gives many of the benefits of
serialPersistentFields, but is higher-level and simpler.
I intend to write an article for JavaWorld, and would love to be able
to use as an example some of your code (or if JPL objects, if you
could come up with a similiar "real life" example - you'd be
credited, of course).
Cheers,
Brendan
PS: If anyone else is interested, or has comments or ideas on this,
please reply. I'll be posting a draft of the article very soon.
> >Thanks for your well-detailed bug report - it made it easy to track
> >down the bug, and fix it. The fix is now available, as
> >JSX0.9.8.3.jar.
> >
> >Your inference that it was to do with primitive fields was correct.
> > > If I change the "y" member of Evolve to wrapper type Integer
> > > rather than primitive int, it works. Am I doing something wrong?
> >
> >However: it may be easier to use XSLT to map to different names
> >between the Java objects and XML (this requires two XSLT scripts,
> >for writing and reading).
> >
> >If it is not mapping that you need this
> >for, but coping with evolution of classes, you only to write one
> >XSLT script, to map from the old version of the XML to the new
> >version. This has the advantage of updating the XML in
> >accordance with the fieldnames used in the Java code (which is less
> >confusing).
> >
> >But I'm guessing on what you need it for here! What do you need it
> >for? ;-)
> >
> >
> >Cheers,
> >Brendan
> >
> >
> >To unsubscribe from this group, send an email to:
> >JSX-ideas-unsubscribe@e...
> >
> >
> >
> >Your use of Yahoo! Groups is subject to
http://docs.yahoo.com/info/terms/
This email is to inform you of release '1.0.1.3' of 'Java Serialization for
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 fix for a subtle bug with writeReplace and readResolve, which allows
the memento pattern as an inner class to work.
Project description:
Java Serialization for XML (JSX) enables, with two lines of code, all
program data to be inspected and processed as XML. This allows
objects from an old version of your program to be migrated to the
current version, despite class evolution. Unique in data binding, JSX
works for all objects, since it implements the standard Java Object
Serialization specification.
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 you're
subscribed to in the right column, which you may cancel by highlighting
the project in question and clicking the 'delete' button.
Sincerely,
freshmeat.net
Hi,
I've been working with JSX a little within an embedded environment
and it's proving really useful - thanks !
I had a couple of minor issues when running with OTI/IBM's
J9 JVM though:
- the import of java.lang.awt in XMLDeserialize.java
- the use of XLSTimport in ObjIn.java requiring javax.xml etc.
- OTI's use of the 'className' field instead of the 'name' field
as implemented in XMLDeserialize::getOsc()
Would it be helpful/possible to contribute mods. for the above
to get JSX running on a minimal J9 VM out of the box ?
Best,
-Alex
Hi Alex,
What OTI/IBM's J9 JVM? If it's a tiny java for cell phones etc that
JSX works for, that would be *really* cool to support!!
> I've been working with JSX a little within an embedded environment
> and it's proving really useful - thanks !
That's great to hear! An "embedded environment" - does that mean
a PDA, or something more like J2EE?
> I had a couple of minor issues when running with OTI/IBM's
> J9 JVM though:
>
> - the import of java.lang.awt in XMLDeserialize.java
OK, that's weird. Must be some legacy testing code or something.
> - the use of XLSTimport in ObjIn.java requiring javax.xml etc.
Yeah, this is a bit tricky: it's a nice feature to have the XLSTimport,
but not necessary for most people. I'm not sure what to do about
this - any ideas?
It could be a separately downloaded extension to JSX; or I could
change the code to use the javax.xml stuff by reflection; or put
all the XSLT stuff in a separate class (in a separate package and
directory) and load that at runtime. That way, there is only an
error if you (a). try to execute the feature that uses XSLT; or
(b). try to compile the separate directory.
> - OTI's use of the 'className' field instead of the 'name' field
> as implemented in XMLDeserialize::getOsc()
I'm not sure what you mean by the "className" field?
> Would it be helpful/possible to contribute mods. for the above
> to get JSX running on a minimal J9 VM out of the box ?
Yes, very helpful. Of course, we need to ensure that they work
with a standard envirnoment too ;-)
Cheers,
Brendan
Hi Brendan,
> What OTI/IBM's J9 JVM? If it's a tiny java for cell phones etc that
> JSX works for, that would be *really* cool to support!!
The OTI JVM is pretty scalable - it supports MIDP, CDC, CLDC
(so yes - it does 'phones !) There are also a more heavyweight set
of configurations with an implementation of AWT, RMI etc.
There are more details at www.embedded.oti.com
> That's great to hear! An "embedded environment" - does that mean
> a PDA, or something more like J2EE?
The company I work for develops embedded hardware and software
for industrial use mainly (oil&gas, medical, gaming, power etc. etc).
I'm interested in this stuff myself because I'm working with a Linux based
embedded platform running the J9 JVM. It's a PC/104 based board -
there are some specs here:
http://www.arcomcontrols.com/products/icp/pc104/processors/PEGASUS.htm
It's a neat platform to work with - although I suppose I would say that ;)
> > - the use of XLSTimport in ObjIn.java requiring javax.xml etc.
> Yeah, this is a bit tricky: it's a nice feature to have the XLSTimport,
> but not necessary for most people. I'm not sure what to do about
> this - any ideas?
Not as such - I just commented out for the time being (tut!) but I guess
it's got to come down to the granularity of the JSX feature set and how
that's best achieved (?)
> It could be a separately downloaded extension to JSX; or I could
> change the code to use the javax.xml stuff by reflection; or put
> all the XSLT stuff in a separate class (in a separate package and
> directory) and load that at runtime. That way, there is only an
> error if you (a). try to execute the feature that uses XSLT; or
> (b). try to compile the separate directory.
In general I'm finding Java a very productive and stable environment
to work. One real concern I have though is due to the dynamic binding
nature of class loading. i.e. I can run my embedded code for an extended
period until it takes a code-path requiring ObjectX. All of a sudden
I find I didn't put ClassX on the target and the system fails. I'd much
prefer
to see that problem at compile time....
This worries me - and loading by reflection (If I understand your comment)
hides the issue until runtime when it's too late to fix easily. I'm not sure
of the
rights and wrongs of this yet...
> > - OTI's use of the 'className' field instead of the 'name' field
> > as implemented in XMLDeserialize::getOsc()
> I'm not sure what you mean by the "className" field?
It's these lines in XMLDeserialize that cause me a problem:
static private ObjectStreamClass getOsc(String escapedName) throws
ClassNotFoundException, IOException {
ObjectStreamClass osc = null;
try {
osc = (ObjectStreamClass) MagicClass.newInstance(ObjectStreamClass.class);
Field oscNameField = ObjectStreamClass.class.getDeclaredField("name");
oscNameField.setAccessible(true); //"name" is private
//System.err.println("osc: "+osc);
setFinal(oscNameField, osc, escapedName);
//System.err.println("osc: "+osc);
} catch (InvocationTargetException e) {
When I run under J9 I get a NoSuchFieldException:
java.lang.NoSuchFieldException
Stack trace:
java/lang/Throwable.<init>()V
java/lang/Throwable.<init>(Ljava/lang/String;)V
java/lang/NoSuchFieldException.<init>(Ljava/lang/String;)V
java/lang/Class.getDeclaredFieldImpl(Ljava/lang/String;)Ljava/lang/reflect/F
ield;
java/lang/Class.getDeclaredField(Ljava/lang/String;)Ljava/lang/reflect/Field
;
JSX/XMLDeserialize.getOsc(Ljava/lang/String;)Ljava/io/ObjectStreamClass;
JSX/XMLDeserialize.createArray([LJSX/ParserXML$Attr;Ljava/lang/String;Ljava/
lang/Object;)LJSX/XMLDeserialize$NamedObject;
JSX/XMLDeserialize.createObject(LJSX/ParserXML$Tag;[LJSX/ParserXML$Attr;Ljav
a/lang/Object;)Ljava/lang/Object;
JSX/XMLDeserialize.createObject(LJSX/ParserXML$Tag;Ljava/lang/Object;)Ljava/
lang/Object;
JSX/XMLDeserialize.deserialize()Ljava/lang/Object;
JSX/ObjIn.readObjectOverride()Ljava/lang/Object;
java/io/ObjectInputStream.readObject()Ljava/lang/Object;
com/arcom/gizmo/framework/ServiceManager.init()V
com/arcom/gizmo/framework/ServiceManager.getServiceManager()Lcom/arcom/gizmo
/framework/ServiceManager;
com/arcom/gizmo/Startup.main([Ljava/lang/String;)V
This is because OTI use a "className" field instead of a "class" field (I
think!)
The following mod. fixes the problem and retains compatibility:
Field oscNameField;
try {
oscNameField = ObjectStreamClass.class.getDeclaredField("name");
} catch(NoSuchFieldException) {
oscNameField = ObjectStreamClass.class.getDeclaredField("className");
}
Cheers,
-Alex
----- Original Message -----
From: "Brendan Macmillan" <bren@...>
To: <JSX-ideas@yahoogroups.com>
Sent: Tuesday, June 18, 2002 4:28 AM
Subject: RE: [JSX] JSX with OTI J9 JVM
> Hi Alex,
>
> What OTI/IBM's J9 JVM? If it's a tiny java for cell phones etc that
> JSX works for, that would be *really* cool to support!!
>
>
> > I've been working with JSX a little within an embedded environment
> > and it's proving really useful - thanks !
> That's great to hear! An "embedded environment" - does that mean
> a PDA, or something more like J2EE?>
> > I had a couple of minor issues when running with OTI/IBM's
> > J9 JVM though:
> >
> > - the import of java.lang.awt in XMLDeserialize.java
> OK, that's weird. Must be some legacy testing code or something.
>
> > - the use of XLSTimport in ObjIn.java requiring javax.xml etc.
> Yeah, this is a bit tricky: it's a nice feature to have the XLSTimport,
> but not necessary for most people. I'm not sure what to do about
> this - any ideas?
>
> It could be a separately downloaded extension to JSX; or I could
> change the code to use the javax.xml stuff by reflection; or put
> all the XSLT stuff in a separate class (in a separate package and
> directory) and load that at runtime. That way, there is only an
> error if you (a). try to execute the feature that uses XSLT; or
> (b). try to compile the separate directory.
>
> > - OTI's use of the 'className' field instead of the 'name' field
> > as implemented in XMLDeserialize::getOsc()
> I'm not sure what you mean by the "className" field?
>
>
> > Would it be helpful/possible to contribute mods. for the above
> > to get JSX running on a minimal J9 VM out of the box ?
> Yes, very helpful. Of course, we need to ensure that they work
> with a standard envirnoment too ;-)
>
>
> Cheers,
> Brendan
>
>
> To unsubscribe from this group, send an email to:
> JSX-ideas-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> _____________________________________________________________________
> This message has been checked for all viruses by MessageLabs Virus Control
Centre.
>
Hi Brendan,
> What OTI/IBM's J9 JVM? If it's a tiny java for cell phones etc that
> JSX works for, that would be *really* cool to support!!
The OTI JVM is pretty scalable - it supports MIDP, CDC, CLDC
(so yes - it does 'phones !) There are also a more heavyweight set
of configurations with an implementation of AWT, RMI etc.
There are more details at www.embedded.oti.com
> That's great to hear! An "embedded environment" - does that mean
> a PDA, or something more like J2EE?
The company I work for develops embedded hardware and software
for industrial use mainly (oil&gas, medical, gaming, power etc. etc).
I'm interested in this stuff myself because I'm working with a Linux based
embedded platform running the J9 JVM. It's a PC/104 based board -
there are some specs here:
http://www.arcomcontrols.com/products/icp/pc104/processors/PEGASUS.htm
It's a neat platform to work with - although I suppose I would say that ;)
> > - the use of XLSTimport in ObjIn.java requiring javax.xml etc.
> Yeah, this is a bit tricky: it's a nice feature to have the XLSTimport,
> but not necessary for most people. I'm not sure what to do about
> this - any ideas?
Not as such - I just commented out for the time being (tut!) but I guess
it's got to come down to the granularity of the JSX feature set and how
that's best achieved (?)
> It could be a separately downloaded extension to JSX; or I could
> change the code to use the javax.xml stuff by reflection; or put
> all the XSLT stuff in a separate class (in a separate package and
> directory) and load that at runtime. That way, there is only an
> error if you (a). try to execute the feature that uses XSLT; or
> (b). try to compile the separate directory.
In general I'm finding Java a very productive and stable environment
to work. One real concern I have though is due to the dynamic binding
nature of class loading. i.e. I can run my embedded code for an extended
period until it takes a code-path requiring ObjectX. All of a sudden
I find I didn't put ClassX on the target and the system fails. I'd much
prefer
to see that problem at compile time....
This worries me - and loading by reflection (If I understand your comment)
hides the issue until runtime when it's too late to fix easily. I'm not sure
of the
rights and wrongs of this yet...
> > - OTI's use of the 'className' field instead of the 'name' field
> > as implemented in XMLDeserialize::getOsc()
> I'm not sure what you mean by the "className" field?
It's these lines in XMLDeserialize that cause me a problem:
static private ObjectStreamClass getOsc(String escapedName) throws
ClassNotFoundException, IOException {
ObjectStreamClass osc = null;
try {
osc = (ObjectStreamClass) MagicClass.newInstance(ObjectStreamClass.class);
Field oscNameField = ObjectStreamClass.class.getDeclaredField("name");
oscNameField.setAccessible(true); //"name" is private
//System.err.println("osc: "+osc);
setFinal(oscNameField, osc, escapedName);
//System.err.println("osc: "+osc);
} catch (InvocationTargetException e) {
When I run under J9 I get a NoSuchFieldException:
java.lang.NoSuchFieldException
Stack trace:
java/lang/Throwable.<init>()V
java/lang/Throwable.<init>(Ljava/lang/String;)V
java/lang/NoSuchFieldException.<init>(Ljava/lang/String;)V
java/lang/Class.getDeclaredFieldImpl(Ljava/lang/String;)Ljava/lang/reflect/F
ield;
java/lang/Class.getDeclaredField(Ljava/lang/String;)Ljava/lang/reflect/Field
;
JSX/XMLDeserialize.getOsc(Ljava/lang/String;)Ljava/io/ObjectStreamClass;
JSX/XMLDeserialize.createArray([LJSX/ParserXML$Attr;Ljava/lang/String;Ljava/
lang/Object;)LJSX/XMLDeserialize$NamedObject;
JSX/XMLDeserialize.createObject(LJSX/ParserXML$Tag;[LJSX/ParserXML$Attr;Ljav
a/lang/Object;)Ljava/lang/Object;
JSX/XMLDeserialize.createObject(LJSX/ParserXML$Tag;Ljava/lang/Object;)Ljava/
lang/Object;
JSX/XMLDeserialize.deserialize()Ljava/lang/Object;
JSX/ObjIn.readObjectOverride()Ljava/lang/Object;
java/io/ObjectInputStream.readObject()Ljava/lang/Object;
com/arcom/gizmo/framework/ServiceManager.init()V
com/arcom/gizmo/framework/ServiceManager.getServiceManager()Lcom/arcom/gizmo
/framework/ServiceManager;
com/arcom/gizmo/Startup.main([Ljava/lang/String;)V
This is because OTI use a "className" field instead of a "class" field (I
think!)
The following mod. fixes the problem and retains compatibility:
Field oscNameField;
try {
oscNameField = ObjectStreamClass.class.getDeclaredField("name");
} catch(NoSuchFieldException) {
oscNameField = ObjectStreamClass.class.getDeclaredField("className");
}
Cheers,
-Alex
----- Original Message -----
From: "Brendan Macmillan" <bren@...>
To: <JSX-ideas@yahoogroups.com>
Sent: Tuesday, June 18, 2002 4:28 AM
Subject: RE: [JSX] JSX with OTI J9 JVM
> Hi Alex,
>
> What OTI/IBM's J9 JVM? If it's a tiny java for cell phones etc that
> JSX works for, that would be *really* cool to support!!
>
>
> > I've been working with JSX a little within an embedded environment
> > and it's proving really useful - thanks !
> That's great to hear! An "embedded environment" - does that mean
> a PDA, or something more like J2EE?>
> > I had a couple of minor issues when running with OTI/IBM's
> > J9 JVM though:
> >
> > - the import of java.lang.awt in XMLDeserialize.java
> OK, that's weird. Must be some legacy testing code or something.
>
> > - the use of XLSTimport in ObjIn.java requiring javax.xml etc.
> Yeah, this is a bit tricky: it's a nice feature to have the XLSTimport,
> but not necessary for most people. I'm not sure what to do about
> this - any ideas?
>
> It could be a separately downloaded extension to JSX; or I could
> change the code to use the javax.xml stuff by reflection; or put
> all the XSLT stuff in a separate class (in a separate package and
> directory) and load that at runtime. That way, there is only an
> error if you (a). try to execute the feature that uses XSLT; or
> (b). try to compile the separate directory.
>
> > - OTI's use of the 'className' field instead of the 'name' field
> > as implemented in XMLDeserialize::getOsc()
> I'm not sure what you mean by the "className" field?
>
>
> > Would it be helpful/possible to contribute mods. for the above
> > to get JSX running on a minimal J9 VM out of the box ?
> Yes, very helpful. Of course, we need to ensure that they work
> with a standard envirnoment too ;-)
>
>
> Cheers,
> Brendan
>
>
> To unsubscribe from this group, send an email to:
> JSX-ideas-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
> _____________________________________________________________________
> This message has been checked for all viruses by MessageLabs Virus Control
Centre.
>
Hello,
I just started researching JSX (JSX 1.0.1.3) and here are what's
popped-up just during the first try:
1) What is the output XML file encoding ? It is not set in header -
<?jsx version='1'?>. What encoding uses JSX ?
2) Why this code is not working ? Is it a bug or just invalid usage ?
java.io.FileOutputStream fos = new java.io.FileOutputStream(new
File("/var/tmp/test.xml"));
ObjOut ts = new ObjOut(fos);
ts.writeUTF("Tatoo, song sample.");
fos.close();€
causes:
Exception in thread "main" java.lang.NullPointerException
at JSX.XMLSerialize.writePrim(XMLSerialize.java:415)
at JSX.ObjOut.writeUTF(ObjOut.java:212)
at org.livotov.jaitools.ImageViewer.main(ImageViewer.java:127)à
From other hand, if I change ts.writeUTF("Tatoo, song sample."); to :
String sample = new String("Tatoo, song sample.");
ts.writeUTF(sample);
everything works fine.
Thanks,
Dmitri
Hi Alex,
> There are more details at www.embedded.oti.com
Cool... tho I couldn't see any information there, it redirects to
a page on WebSphere developer...
> The company I work for develops embedded hardware and software
> for industrial use mainly (oil&gas, medical, gaming, power etc. etc).
Cool stuff. I guess you realize that if your company distributes JSX
in a non-GPL way (eg closed source), then your company would need to
purchase a commercial license? There's also a price rise coming at
the end of this month, so it might be wise to purchase it sooner,
if they will definitely need it. [anyway, enough sales stuff!]
> http://www.arcomcontrols.com/products/icp/pc104/processors/PEGASUS.htm
>
> It's a neat platform to work with - although I suppose I would say that ;)
It's amazing to have embedded components that are as powerful as a
top desktop PC of only 10 years ago! Moore's law constantly surprises...
> > > - the use of XLSTimport in ObjIn.java requiring javax.xml etc.
> > Yeah, this is a bit tricky: it's a nice feature to have the XLSTimport,
> > but not necessary for most people. I'm not sure what to do about
> > this - any ideas?
>
> Not as such - I just commented out for the time being (tut!) but I guess
> it's got to come down to the granularity of the JSX feature set and how
> that's best achieved (?)
>
> > It could be a separately downloaded extension to JSX; or I could
> > change the code to use the javax.xml stuff by reflection; or put
> > all the XSLT stuff in a separate class (in a separate package and
> > directory) and load that at runtime. That way, there is only an
> > error if you (a). try to execute the feature that uses XSLT; or
> > (b). try to compile the separate directory.
>
> In general I'm finding Java a very productive and stable environment
> to work. One real concern I have though is due to the dynamic binding
> nature of class loading. i.e. I can run my embedded code for an extended
> period until it takes a code-path requiring ObjectX. All of a sudden
> I find I didn't put ClassX on the target and the system fails. I'd much
> prefer to see that problem at compile time....
>
> This worries me - and loading by reflection (If I understand your comment)
> hides the issue until runtime when it's too late to fix easily.
Yes, that's it.
> I'm not sure of the rights and wrongs of this yet...
OK - I think a nice solution is for some kind of a specific *Exception*
to be thrown, if it can't load the classX... this forces the issue at
compile time, because you then have to code to catch that exception.
I think there probably is a nice Exception available for precisely
this purpose, but I can't think of what it is right now... perhaps,
"ClassNotFoundException"? ;-)
However, I think it may be simpler for me to just remove the XSLT
stuff, since I think that no one is using it ;-)
> > > - OTI's use of the 'className' field instead of the 'name' field
> > > as implemented in XMLDeserialize::getOsc()
> > I'm not sure what you mean by the "className" field?
>
> It's these lines in XMLDeserialize that cause me a problem:
OK, thanks a lot for the explanation! It's because JSX is
relying on the implementation of ObjectStreamClass, and IBM has
evolved this class in the meantime.
I don't recall positively, but I *think* the entire purpose of this
section of code was to deal with classloading, which the 1.0.1.2
released fixed (thanks to Ing. Thomas Margreiter). So this code
may be unnecessary now... need to check this carefully.
> This is because OTI use a "className" field instead of a "class" field (I
> think!)
>
> The following mod. fixes the problem and retains compatibility:
>
> Field oscNameField;
> try {
> oscNameField = ObjectStreamClass.class.getDeclaredField("name");
> } catch(NoSuchFieldException) {
> oscNameField = ObjectStreamClass.class.getDeclaredField("className");
> }
Thanks for the bug-fix, it will go in shortly; tho I'll remove the whole
section instead, if it is not necessary... ;-)
Cheers,
Brendan
Hi Dmitri,
Thanks a lot for reporting this, rather than giving up on JSX right
away!
> I just started researching JSX (JSX 1.0.1.3) and here are what's
> popped-up just during the first try:
>
> 1) What is the output XML file encoding ? It is not set in header -
> <?jsx version='1'?>. What encoding uses JSX ?
This is just for JSX to distinguish between different versions.
By "output XML file encoding", do you mean what DTD (or XML Schema)?
If so, the answer is that the JSX grammar is based on the classes you use.
You can generate a DTD that fits it using example code on the website
(however, this DTD generation is still experimental).
But I sense I haven't fully grasped your question...
> 2) Why this code is not working ? Is it a bug or just invalid usage ?
>
> java.io.FileOutputStream fos = new java.io.FileOutputStream(new
> File("/var/tmp/test.xml"));
> ObjOut ts = new ObjOut(fos);
> ts.writeUTF("Tatoo, song sample.");
> fos.close();-
>
> causes:
>
> Exception in thread "main" java.lang.NullPointerException
> at JSX.XMLSerialize.writePrim(XMLSerialize.java:415)
> at JSX.ObjOut.writeUTF(ObjOut.java:212)
> at org.livotov.jaitools.ImageViewer.main(ImageViewer.java:127)à
>
>
> From other hand, if I change ts.writeUTF("Tatoo, song sample."); to :
>
> String sample = new String("Tatoo, song sample.");
> ts.writeUTF(sample);
>
> everything works fine.
Specific answer: I cannot imagine why this would make a difference, since a
String would
be passed to writeUTF, in both cases... are you sure that the full source
code is the same? But it doesn't really matter, because:
General answer: You usage is OK for JOS (Java's Serialization), but isn't
for
JSX. JSX takes the view that object serialization is for objects only - and
so
the internal methods (like writeUTF, writeInt, writeDouble etc) are only
intended to work from within an object (they are used to customize the
serialization.
To get JSX to work, use:
ts.writeObject("Tatoo, song sample.");
Is behaviour of JSX a bug? As far as mimicking JOS goes, yes, I guess it is
a bug.
The problem is deeper, however: if you were to writeInt() directly to the
JSX output
stream, JSX could not represent it, because JSX represents primitives as
attributes...
and you can't have an XML attribute without an element to enclose it.
Can you (or anyone else) think of a reason for wanting to do this, in
practice? I'd
prefer to leave it (unless I'm missing something).
Cheers,
Brendan
Brendan Macmillan wrote:
>
> Hi Dmitri,
>
> Thanks a lot for reporting this, rather than giving up on JSX right
> away!
>
> > I just started researching JSX (JSX 1.0.1.3) and here are what's
> > popped-up just during the first try:
> >
> > 1) What is the output XML file encoding ? It is not set in header -
> > <?jsx version='1'?>. What encoding uses JSX ?
> This is just for JSX to distinguish between different versions.
>
> By "output XML file encoding", do you mean what DTD (or XML Schema)?
> If so, the answer is that the JSX grammar is based on the classes you use.
> You can generate a DTD that fits it using example code on the website
> (however, this DTD generation is still experimental).
>
> But I sense I haven't fully grasped your question...
He's talking about which encoding, as in Latin1, ASCII, UTF-8, etc.
Usually the <?xml ... ?> part contains the version of xml and the
encoding.
Mark
> > > 1) What is the output XML file encoding ? It is not set in
header -
> > > <?jsx version='1'?>. What encoding uses JSX ?
...
> > But I sense I haven't fully grasped your question...
>
> He's talking about which encoding, as in Latin1, ASCII, UTF-8, etc.
> Usually the <?xml ... ?> part contains the version of xml and the
> encoding.
Oh, of course. ;-) JSX just uses the default, which is UTF-8.
Cheers,
Brendan
Hi Brendan,
Hi All,
My last subscription to the group is rather old (Dec. 2001).
We had a major problem with our project, which has now been solved by
IBM : they have released a patch (OS level, pthreads).
To remind the context :
- IBM AIX 4.3.3
- IBM jre1.3.0
- Tomcat 3.2.x, Log4j, xalan, xerces...
- persistence (JOS)
The application transfers files between machines. Distribution is
based on subscriptions.
We were interested by JSX, but we decided to wait and use JOS.
We have deployed our application on some servers, and it's running
fine for 2 months.
I had a try this morning with JSX, and got a javacore after 3 hours
(I've post the file : javacore32984.1025267585.zip).
There were some suspicions on JSX's thread-safety at a time, which
were resolved.
Any idea ?
Hi Jean-Christian (is that right?),
Thanks for trying this out - unfortunately nothing I'm aware of has come
to light that might help with this. The fact that it seems random
makes it difficult to diagnose - especially since we ruled out thread
problems.
Your javacore makes me think that there were several problems, and the
IBM has fixed one of them, revealing another... it looks like there is
a particular class, with a particular field that JSX is not handling
properly. Can you send the last XML that was written? And also, the
source code of the class that JSX had trouble with?
For example, it is possible that IBM have implemented some aspects of
inner classes differently from Sun, and this could cause a problem.
"Thread-9" (TID:0x30098010, sys_thread_t:0x3547aa68, state:R, native
ID:0x1112) prio=5: pending=java.lang.NoSuchFieldException
at java.lang.Class.getField0(Native Method)
at java.lang.Class.getDeclaredField(Class.java(Compiled Code))
at JSX.XMLSerialize.isShadowed(XMLSerialize.java(Compiled Code))
at JSX.XMLSerialize.shadowEncode(XMLSerialize.java(Compiled Code))
at JSX.XMLSerialize.serializeFields(XMLSerialize.java(Compiled Code))
at JSX.XMLSerialize.serializeObject(XMLSerialize.java(Compiled Code))
at JSX.XMLSerialize.serializeObject(XMLSerialize.java(Compiled Code))
at JSX.XMLSerialize.commonSer(XMLSerialize.java(Compiled Code))
at JSX.XMLSerialize.serialize(XMLSerialize.java(Compiled Code))
at JSX.ObjOut.writeObjectOverride(ObjOut.java(Compiled Code))
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java(Compiled
Code))
at LDS.Persistence.LDSPersistJSX.doSave(LDSPersistJSX.java(Compiled Code))
Another possible cause is how JSX deals with "final" fields. And I have a
feeling it might involve checking over some of IBM's source code (if it
is available?). OTOH, it might be possible to work out a fix that will
work specifically for your code - I would need access to your code, for
this.
I think diagnosing and fixing this would probably be a lot more work than
I can justify doing for free, unforuntately.
Cheers,
Brendan
> -----Original Message-----
> From: jcsalome [mailto:jean-christophe.salome@...]
> Sent: Saturday, 29 June 2002 12:53 AM
> To: JSX-ideas@yahoogroups.com
> Subject: [JSX] Javacore
>
>
> Hi Brendan,
> Hi All,
>
> My last subscription to the group is rather old (Dec. 2001).
> We had a major problem with our project, which has now been solved by
> IBM : they have released a patch (OS level, pthreads).
>
> To remind the context :
> - IBM AIX 4.3.3
> - IBM jre1.3.0
> - Tomcat 3.2.x, Log4j, xalan, xerces...
> - persistence (JOS)
> The application transfers files between machines. Distribution is
> based on subscriptions.
>
> We were interested by JSX, but we decided to wait and use JOS.
> We have deployed our application on some servers, and it's running
> fine for 2 months.
> I had a try this morning with JSX, and got a javacore after 3 hours
> (I've post the file : javacore32984.1025267585.zip).
>
> There were some suspicions on JSX's thread-safety at a time, which
> were resolved.
>
> Any idea ?
>
>
>
>
>
>
>
> To unsubscribe from this group, send an email to:
> JSX-ideas-unsubscribe@egroups.com
>
>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Send Email
