commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rahul Akolkar" <rahul.akol...@gmail.com>
Subject Re: [SCXML] test should fail if serialisation work dir cannot be created
Date Tue, 06 Jan 2009 20:43:53 GMT
On Mon, Jan 5, 2009 at 5:40 PM, sebb <sebbaz@gmail.com> wrote:
> On 05/01/2009, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>> On Mon, Jan 5, 2009 at 3:52 PM, sebb <sebbaz@gmail.com> wrote:
<snip/>
>>  >
>>  > Not sure I know how to do that in Maven. Why not do a single test for
>>  > NSE and skip any further serialisation tests if the the initial test
>>  > fails?
>>  >
>>
>> <snap/>
>>
>>  You mean single JUnit test? That'll cause the build to fail on JDKs
>>  like Sun 1.4 (unless the tests are skipped), which seems suboptimal
>>  given its an optional feature users may not need and an environment
>>  configuration, rather than code, issue.
>
> Yes, the idea would be to use a separate JUnit test to probe for the
> specific NSE error and skip the other tests that would fail.
>
> The NSE exceptions would then no longer need to be caught.
>
> This would make it much easier to detect other serialisation errors,
> e.g. if any of the classes are updated in future. There would be no
> need to check what class was involved - i.e. the present "fragile"
> check would not be needed.
>
<snap/>

Apart from the details of conditionally turning off certain tests once
the surefire plugin sets off (which I'm not aware of) ...

Ideally, we don't want to skip those tests entirely, we just want to
skip the serialization round trips in those tests once we detect the
specific NSE due to the DOM impl.

Each of those tests takes the form of functional testing interspersed
with serialization testing, this best emulates real world scenarios,
IOW:

1. test something
2. do a serialization round trip
3. test something else assuming state at end of 1
4. do another serialization round trip
...

So we'd want to skip 2 and 4, but keep testing 1 and 3. Which is what
we do now. Ofcourse, at any point, if the JDK DOM impl isn't
serializable, then the endorsed standards override mechanism can be
used to change that and fully run all the tests with serialization.
Your point of making it easier to detect other serialization errors on
such a JDK is well taken.


>>  When I weight the pros and
>>  cons of a build failure vs. current outcome (warnings to console) in
>>  this context, the latter seems better to me.
>>
>
> Now that the test output is shorter, the serialisation warning
> messages stand out better,
<snip/>

Yup, thats a good thing, thanks :-)


> but I think NSEs which are not caused by
> the faulty Sun 1.4 DOM should cause failures.
>
<snap/>

OK, so what you added to trunk does that. I guess we can retain the
crimson check as-is and keep refining it as and when it breaks with
other obscure JDKs and configurations you and I haven't tested on.

-Rahul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message