I have committed a fix for this in r608514. The original code was
dependent on the order in which databindings were loaded, and for
some reason this varied depending on the environment in which the
test was run (top-level build, standalone test, different
combinations of preceding tests). With this fix, the order of
loading databindings is not significant and I have been able to
run all the itests without problems.
Simon
Simon Nash wrote:
I did some further investigation as to why this fails from a top-level
build but works when running the exceptions-cross-binding itest
standalone. If the databindings itest is run (in the same JVM) before
the exceptions-cross-binding itest, then exceptions-cross-binding
fails, otherwise it works.
Drilling down one level further, if any one (or more) of the
following submodules of itest/databindings:
sdogen
jaxbgen
interop
are run before itest/exceptions-cross-binding, then
exceptions-cross-binding fails, otherwise it works.
It appears that something is happening as a side-effect of the
earlier tests that is causing the later test to fail.
Reversing the order (i.e., running exceptions-cross-binding first)
doesn't result in any failures from the databindings itest.
Simon
Simon Laws wrote:
On Jan 2, 2008 10:41 PM, Simon Nash <[EMAIL PROTECTED]> wrote:
I ran the test again (standalone, not from the itest directory)
and it works OK now. I can't understand what changed since the
earlier failure. See below for the error message and stack trace
that I got earlier. Any insights into this?
Simon
-------- Original Message --------
Subject: Commit r608213 breaks exceptions-cross-binding itest
Date: Wed, 02 Jan 2008 22:16:44 +0000
From: Simon Nash <[EMAIL PROTECTED]>
Organization: IBM
To: [email protected]
It looks like my commit r608213 has broken the exceptions-cross-binding
itest. My apologies for this. I am looking into this now. My first
impression is that I need to refine the code for matching exception
types
to data bindings in DefaultDataBindingExtensionPoint.introspectType() so
that the new java:exception data binding is not selected for exceptions
generated by JAXB. I will send another update as soon as I have more
news.
Simon
- - - - - - - - errors from first run are below - - - - - - - -
(cut)
Simon
I see the same problem on a clean build. I'm afraid that I don't have any
particular insight but stopping it at the point where the problem occurs
shows that for the source operation "stockQuoteOffer" the 3 source fault
types are given as
java.rmi.RemoteException
org.apache.tuscany.sca.test.exceptions.sdohandgen.InvalidSymbolSDOException
org.apache.tuscany.sca.test.exceptions.sdohandgen.MarketClosedSDOException
The target operation is "stockQuoteOffer" and the 3 fault types here are
org.apache.tuscany.sca.test.exceptions.impl.jaxb.InvalidSymbolFault_Exception
org.apache.tuscany.sca.test.exceptions.impl.jaxb.MarketClosedFault
org.apache.tuscany.sca.test.exceptions.impl.jaxb.TestNotDeclaredAtSourceFault
It's trying to throw InvalidSymbolFault_Exception and reports that it
can't
find a match between source and target faults. There is some matching
logic
that would require further investigation. Any of this make sense?
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
