Directory copy
by Emmanuel Bernard
Hi,
Does Someone know a library to copy one directory to another? Possibly
smart (ie copy only changed files)?
Emmanuel
19 years, 3 months
RE: Jdk1.4 vs jdk5
by Dimitris Andreadis
I tried jbossxb 1.0.0.CR8 in jboss 4.2, that was compiled with jdk5, due
to jboss-test (imported by jbossxb) being compiled with jdk5.
So all 1.4 based testsuite builds of jbossas 4.2 break immediately due
to the jbossxb jdk5 compiled classes.
Do we need to just drop those builds?
Also, how to deal with the compatibility tests? The way we use client
libs from one jboss version against a running server of another version
(e.g. 4.2 client libs against 4.0 server) will not work, unless we run
the client with jdk5.
Is this what we are supposed to do? i.e. require all jboss 4.2 compiled
code to need a jdk5 runtime?
Do you see any other issue interoperating with older servers running on
jdk1.4 ?
> -----Original Message-----
> From: Scott M Stark
> Sent: Thursday, January 11, 2007 9:03 PM
> To: Dimitris Andreadis
> Cc: JBoss.org development list; Scott M Stark;
> jboss-as(a)redhat.com; Ryan Campbell
> Subject: Re: Jdk1.4 vs jdk5
>
> libraries needing to be used under jdk14 must have a version for that.
> Why does jboss-test trigger a jdk14 issue as its not used by
> jboss-4.0.x?
>
> Dimitris Andreadis wrote:
> > With the switch to jdk5 for JBossAS 4.2 we are seeing more
> cases where
> > jdk5 dependencies propagate, e.g.
> >
> > jboss-test-1.0.0.GA build using 1.5 target -> jbossxb 1.0.0.CR8 ->
> > jbossws 1.2.0.CR2 -> jbossAS.
> >
> > So jbossAS with jdk1.4 testsuite runs are bound to fail, plus I
> > presume we'll be start having problems with the
> compatibility runs, e.g.
> >
> > Jboss 4.0.x (jdk14) against JBoss 4.2.x (jdk15)
> >
> > Jdk15 targeted jars won't be accepted on the 1.4 side.
> >
> > How we want to deal with this?
>
>
19 years, 3 months
JTA question for the transaction gurus
by Tim Fox
If I have at least 2 participants enlisted in a JTA tx and call commit,
then the commit fails, e.g. due to network problems say due to the
XAResource being enable to contact it's server.
In this case is it possible the commit fails and the TRansaction is left
in state Status.STATUS_PREPARING?
Basically I have this situation:
I am have a JTA transaction where 2 JMS XAResources are enlisted
corresponding to two different servers.
I am acking some messages on one server and sending some messages on the
other (basically this is a message bridge).
If the network fails, the bridge should be able to catch exceptions and
retry until the network comes back up.
If the failure occurs during the Transaction.commit() call, then I only
want to retry the commit if the transaction didn't get prepared, since
if it got to the prepare stage then the transaction recovery (hopefully)
will commit it eventually.
So I am checking Transaction.getStatus() after the failure to work out
whether to retry commit or not. Basically my assumption is I should
retry after failure if the tx is not prepared.
Is this a correct approach?
--
Tim Fox
JBoss Messaging Technical Lead
JBoss - a division of Red Hat
T: +44 2088006768
M: +44 7957983205
E: tim.fox(a)jboss.com tim.fox(a)redhat.com
19 years, 3 months
RE: Jdk1.4 vs jdk5
by Ryan Campbell
I know you are asking Scott, but here's my opinion anyway.
> Also, how to deal with the compatibility tests? The way we use client
libs
> from one jboss version against a running server of another version
(e.g.
> 4.2 client libs against 4.0 server) will not work, unless we run the
> client with jdk5.
>
> Is this what we are supposed to do? i.e. require all jboss 4.2
compiled
> code to need a jdk5 runtime?
As I understand it, yes. We should kill the 1.4 JDK test suites and
move the compatibility tests to 1.5.
>
> Do you see any other issue interoperating with older servers running
on
> jdk1.4 ?
This should only be a problem if the JDK broke serialization uid's
between 1.4 & 1.5, correct?
19 years, 3 months
