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 Thu, 27 Nov 2008 15:22:05 GMT


On Nov 27, 2008, at 8:25 AM, sebb <sebbaz@gmail.com> wrote:

> On 26/11/2008, Rahul Akolkar <rahul.akolkar@gmail.com> wrote:
>> 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
>
> But one cannot be sure that the serialisation works correctly unless
> it is actually performed. A class may serialise without an error, but
> the serialsed form may not behave correctly.

I'll be brief, since I dislike typing on the phone :-)

We have numerous tests and data points for actual serialization that  
are known to work.



>
> That's why I think the test suite should generate at least one failure
> if serialisation is not possible.
>

We disagree given the specifics I've mentioned earlier in this thread.

-Rahul






>> 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
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

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


Mime
View raw message