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: [all] Commons SCXML 0.9 RC1 available
Date Wed, 26 Nov 2008 19:46:04 GMT
On Wed, Nov 26, 2008 at 6:20 AM, sebb <sebbaz@gmail.com> wrote:
> On 25/11/2008, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
<snip/>
>>
>>  So, if and only if:
>>  a) the usage needs serializability (not all library uses do), and
>>  b) a DOM impl that isn't serializable is in use (such as Crimson)
<snap/>

It turns out I left another clause out of the compound predicate
above, which is:

c) and if the SCXML documents define the XML data model via the
<datamodel> element.

(<datamodel> is optional ofcourse, hence the 'if')


>>  then it'd be necessary to switch to a more helpful parser.
>>
>>  In any case, the tests are meant to spew copious warnings to remind
>>  folks when the above is true, but they are not designed to fail since
>>  there is nothing in the library source that needs changing.
>
> Agreed that the source is not at fault - it is the test environment
> that is at fault.
>
> However, it means that the test does not exercise all the library code
> - it might fail to pick up genuine faults - so I think that should be
> regarded as a test failure.
>
<snip/>

But we do test that all library code gets exercised :-)

Lets play out the scenario when the DOM impl isn't serializable (if it
is, thats no longer a scenario of interest for this discussion since
all is well):

(1) We run all tests that have nothing to do with serialization
(2) For tests that have something to do with serialization
   (2a) We run those that do not use the XML <datamodel> element
         (examples [1, 2])
   (2b) We run those that use the <datamodel> element, but skip the
          serialization because the DOM impl is not serializable

In (2a), we have already tested that serialization works for the rest
of the library. So if the DOM impl is replaced by a serializable one,
we can be reasonably certain that serialization will work in (2b). We
have already tested (2b) from a functional PoV in all aspects other
than serialization.


> The failure message should make it clear that the problem lies in the
> environment.
>
<snap/>

But its not a concern for those who may choose to not use the
<datamodel> i.e. there are viable scenarios where it is acceptable to
not require a serializable DOM impl. Therefore, it should not be a
build failure (the message can be improved, as is very often true with
messages).

Thanks for bringing this up in detail -- I'm increasingly of the
opinion that we are doing the right thing.

-Rahul

[1] http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/history-shallow-01.xml
[2] http://svn.apache.org/repos/asf/commons/proper/scxml/trunk/src/test/java/org/apache/commons/scxml/history-deep-01.xml

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


Mime
View raw message