You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Rahul Akolkar <ra...@gmail.com> on 2008/11/22 02:51:50 UTC
[all] Commons SCXML 0.9 RC1 available
Distributions, key, release notes:
http://people.apache.org/builds/commons/scxml/0.9/RC1/
Site including clirr and rat reports (many links -- such as release
docs, some Javadoc links and images will remain broken on staging
site):
http://people.apache.org/builds/commons/scxml/0.9/RC1/site/
m2 staging repo:
http://people.apache.org/builds/commons/scxml/0.9/RC1/staged/
Thanks in advance for all feedback. If no blockers surface, I intend
to put these bits up for vote in a week.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Phil Steitz <ph...@gmail.com>.
Rahul Akolkar wrote:
> Thanks Phil, comments below.
>
> On Sat, Nov 22, 2008 at 4:17 PM, Phil Steitz <ph...@gmail.com> wrote:
> <snip/>
>
>> Looks good. Checked only m2 build, using jdk 1.5.0_16. Jar contents, etc
>> look fine. If you do end up cutting another RC, it would be nice to include
>> miniumum required JDK level somewhere (could not find that on the site).
>> Looks like the jar was built with 1.4.
>>
> <snap/>
>
> Yup, thats also the minimum since the first release. You're right
> theres nothing on the site, but the (binary) jar manifest does have
> these properties:
>
> X-Compile-Source-JDK: 1.4
> X-Compile-Target-JDK: 1.4
>
>
>
>> FWIW, I don't like us publishing RCs with "final" names, even just on
>> people.a.o. I am willing to retest "final" bits when the release vote is
>> called. Apologies if I missed the discussion on this.
>>
>>
> <snip/>
>
> Nothing beyond our last thread on this topic:
>
> http://markmail.org/message/3emjaadwpf7cr5q3
>
> Your comments about not having final names in RCs when asking for
> functional testing and feedback from the community make good sense to
> me. TBH, I wasn't really anticipating that kind of feedback and
> testing. In fact, I see very little beyond packaging and static
> analysis checks for many of the RCs these days (what we do about it is
> best a separate thread -- and for some "broad shallow API" components
> those checks may actually be sufficient).
>
> Since we want to vote on the actual artifacts, these must be on p.a.o
> atleast for the duration of the vote. This thread is merely a
> precursor to the vote in my mind (barring blocking packaging mistakes
> and the like).
>
Got it. Not a problem in this case, but probably best to use the RC
naming unless we are pretty confident we are going to release the RC bits.
Phil
> -Rahul
>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
Thanks Phil, comments below.
On Sat, Nov 22, 2008 at 4:17 PM, Phil Steitz <ph...@gmail.com> wrote:
<snip/>
>
> Looks good. Checked only m2 build, using jdk 1.5.0_16. Jar contents, etc
> look fine. If you do end up cutting another RC, it would be nice to include
> miniumum required JDK level somewhere (could not find that on the site).
> Looks like the jar was built with 1.4.
<snap/>
Yup, thats also the minimum since the first release. You're right
theres nothing on the site, but the (binary) jar manifest does have
these properties:
X-Compile-Source-JDK: 1.4
X-Compile-Target-JDK: 1.4
> FWIW, I don't like us publishing RCs with "final" names, even just on
> people.a.o. I am willing to retest "final" bits when the release vote is
> called. Apologies if I missed the discussion on this.
>
<snip/>
Nothing beyond our last thread on this topic:
http://markmail.org/message/3emjaadwpf7cr5q3
Your comments about not having final names in RCs when asking for
functional testing and feedback from the community make good sense to
me. TBH, I wasn't really anticipating that kind of feedback and
testing. In fact, I see very little beyond packaging and static
analysis checks for many of the RCs these days (what we do about it is
best a separate thread -- and for some "broad shallow API" components
those checks may actually be sufficient).
Since we want to vote on the actual artifacts, these must be on p.a.o
atleast for the duration of the vote. This thread is merely a
precursor to the vote in my mind (barring blocking packaging mistakes
and the like).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Phil Steitz <ph...@gmail.com>.
Rahul Akolkar wrote:
> Distributions, key, release notes:
>
> http://people.apache.org/builds/commons/scxml/0.9/RC1/
>
> Site including clirr and rat reports (many links -- such as release
> docs, some Javadoc links and images will remain broken on staging
> site):
>
> http://people.apache.org/builds/commons/scxml/0.9/RC1/site/
>
> m2 staging repo:
>
> http://people.apache.org/builds/commons/scxml/0.9/RC1/staged/
>
> Thanks in advance for all feedback. If no blockers surface, I intend
> to put these bits up for vote in a weekx
>
> -Rahul
>
Looks good. Checked only m2 build, using jdk 1.5.0_16. Jar contents,
etc look fine. If you do end up cutting another RC, it would be nice to
include miniumum required JDK level somewhere (could not find that on
the site). Looks like the jar was built with 1.4.
FWIW, I don't like us publishing RCs with "final" names, even just on
people.a.o. I am willing to retest "final" bits when the release vote
is called. Apologies if I missed the discussion on this.
Phil
> ---------------------------------------------------------------------
> 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Nov 25, 2008 at 5:25 AM, sebb <se...@gmail.com> wrote:
<snip/>
>
> I've just discovered the cause of the NPE - there is an IO error that
> is being ignored:
>
> "(The requested operation cannot be performed on a file with a
> user-mapped section open)"
>
> It looks as though it might perhaps be an interaction with my Antivirus.
> It's not necessary to generate all these temporary .ser files; I'll
> file a JIRA about that.
>
> I've already created a JIRA issue about the ignored errors.
>
<snap/>
Thanks for taking time to hunt this down at your end and for filing
the JIRA issues. Its always useful to have more people stare at the
code.
A quick glance seems to suggest that we should fix a third of an issue
(one of the JIRA issues you've created has three separable parts) and
the rest of the two and two-thirds seem like wontfixes to me (I'll
elaborate in JIRA comments).
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 25/11/2008, sebb <se...@gmail.com> wrote:
> On 24/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> > On Mon, Nov 24, 2008 at 4:40 PM, sebb <se...@gmail.com> wrote:
> > <snip/>
> >
> > >
> > > I've just seen the error again.
> > > I updated the fail() message to fail(e+e.getMessage()) so I got a bit
> > > more information:
> > >
> > > -------------------------------------------------------------------------------
> > > Test set: org.apache.commons.scxml.model.ModelTestSuite
> > > -------------------------------------------------------------------------------
> > > Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.876
> > > sec <<< FAILURE!
> > > testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
> > > Time elapsed: 0.125 sec <<< FAILURE!
> > > junit.framework.AssertionFailedError: java.lang.NullPointerExceptionnull
> > > at junit.framework.Assert.fail(Assert.java:47)
> > > at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:195)
> > > at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:171)
> > > at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:114)
> > >
> > > I think the fail(e.getMessage()) calls need to be updated to something
> > > more useful, as the current code swallows all the useful information.
> > > In test cases it's best to let the code throw an Exception - only
> > > expected throwables should be caught by test cases.
> > >
> >
> > <snap/>
> >
> > Yup, that pattern needs to be changed throughout the test cases.
> >
> >
> >
> > > I did this, and ran the test a few more times, and now I get:
> > >
> > > -------------------------------------------------------------------------------
> > > Test set: org.apache.commons.scxml.model.ModelTestSuite
> > > -------------------------------------------------------------------------------
> > > Tests run: 78, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.906
> > > sec <<< FAILURE!
> > > testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
> > > Time elapsed: 0.125 sec <<< ERROR!
> > > java.lang.NullPointerException
> > > at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:194)
> > > at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:181)
> > > at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:115)
> > >
> > > It looks like the testExecutorSerializability() method is returning
> > > null, though I'm not sure why as it appears the file is generated and
> > > read OK. I replaced the File I/O with ByteArray I/O and I did not get
> > > the error, though I did not test very many times
> > >
> > > When I run the test on 1.4.2, I get a lot of messages:
> > > SERIALIZATION ERROR: The DOM implementation in use is not serializable
> > >
> > > This is possibly because the DOM implementation is being provided by
> > > the JDK, as I don't get it with JDK 1.5.0 or 1.6.0.
> > >
> > > Does JDK 1.4.2 require additional dependencies?
> > >
> >
> > <snip/>
> >
> > No, its actually the other way around (for example, we require Xalan
> > for XPath support if its greater than 1.4).
> >
> > What you are seeing is probably more a statement about what xml-apis
> > Maven is using when running the tests (at some point they started
> > pegging the xml-api versions IIRC).
> >
>
>
> Surely Maven will use either whatever the JDK provides or whatever the
> POM specifies?
>
> I did some more tests, and if I add xercesImpl and xml-apis to the
> dependencies, then Java 1.4.2 no longer reports any serialisation
> errors. This suggests that (some) Java 1.4.2 xml classes are not
> serialisable whereas Java 1.5.0+ are serialisable. Further, this
> suggests that SCXML will not be serialisable on Java 1.4 unless
> additional dependencies are provided.
>
> Have you not seen the serialisation errors when testing on Java 1.4.2?
>
> What is a bit odd is that the test error also seems to disappear when
> I add xerces and xml-apis. The method that fails already checks for
> serialisation problems.
I've just discovered the cause of the NPE - there is an IO error that
is being ignored:
"(The requested operation cannot be performed on a file with a
user-mapped section open)"
It looks as though it might perhaps be an interaction with my Antivirus.
It's not necessary to generate all these temporary .ser files; I'll
file a JIRA about that.
I've already created a JIRA issue about the ignored errors.
> >
> > > I think the test suite should be improved to give more details if/when
> > > errors occur. At present errors are quite difficult to track down.
> > >
> >
> > <snap/>
> >
> > Agreed, as proven by this thread. We should track this via a JIRA
> > ticket (I suggest fix version v0.10) and subsequent improvements to
> > the tests, Javadoc and FAQ as necessary.
> >
>
>
> OK.
>
>
> > -Rahul
> >
> > ---------------------------------------------------------------------
> > 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Nov 28, 2008 at 10:05 AM, sebb <se...@gmail.com> wrote:
<snip/>
>
> I'm not saying that the tests need to be fixed for 0.9, however I
> think they need to be fixed for any subsequent release. I'm happy to
> provide patches and/or update trunk to achieve this.
>
<snap/>
Always great to have help :-) Oh, and trunk as well as J6 branch please.
Now, lets discuss the proposed fix.
> IMO, it's important that tests can be run using some form of CI (e.g.
> Continum or Gump) and for the tests to report a failure if there are
> any problems. Therefore it is important that any testing errors are
> reflected in the final testing status, not just in the debug output.
>
<snap/>
Yes, but the DOM serialization is optionally required (so if someone
wants to use JavaScript as the expression language in SCXML documents
-- or JEXL, or EL, or many of the others available via the
javax.script APIs in JDK 1.6 and procedurally inject the root
datamodel, then it doesn't matter if the DOM implementation is
serializable -- so they should be able to build).
> Further, if the test is run on a supported version of Java (e.g. Sun
> Java 1.4) and some of the tests for that version of Java cannot be
> run, this should be regarded as a test failure.
>
<snip/>
Or a big honking warning, saying additional JDK configuration will be
needed if a particular optional feature and additionally its
serialization are needed as well.
To clarify again -- the tests can be run, functionality can be tested.
Serialization isn't done for some tests (and for completion, other
tests that don't use <datamodel> are run and also tested for
serialization).
My preference would be to talk code going forward, happy to discuss
suggested patches in JIRA.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 27/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
>
>
> On Nov 27, 2008, at 8:25 AM, sebb <se...@gmail.com> wrote:
>
>
> > On 26/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> >
> > > On Wed, Nov 26, 2008 at 6:20 AM, sebb <se...@gmail.com> wrote:
> > >
> > > > On 25/11/2008, Rahul Akolkar <ra...@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.
>
I'm not saying that the tests need to be fixed for 0.9, however I
think they need to be fixed for any subsequent release. I'm happy to
provide patches and/or update trunk to achieve this.
IMO, it's important that tests can be run using some form of CI (e.g.
Continum or Gump) and for the tests to report a failure if there are
any problems. Therefore it is important that any testing errors are
reflected in the final testing status, not just in the debug output.
Further, if the test is run on a supported version of Java (e.g. Sun
Java 1.4) and some of the tests for that version of Java cannot be
run, this should be regarded as a test failure.
> -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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Nov 27, 2008, at 8:25 AM, sebb <se...@gmail.com> wrote:
> On 26/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
>> On Wed, Nov 26, 2008 at 6:20 AM, sebb <se...@gmail.com> wrote:
>>> On 25/11/2008, Rahul Akolkar <ra...@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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 26/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> On Wed, Nov 26, 2008 at 6:20 AM, sebb <se...@gmail.com> wrote:
> > On 25/11/2008, Rahul Akolkar <ra...@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.
That's why I think the test suite should generate at least one failure
if serialisation is not possible.
> 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Wed, Nov 26, 2008 at 6:20 AM, sebb <se...@gmail.com> wrote:
> On 25/11/2008, Rahul Akolkar <ra...@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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 25/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> On Tue, Nov 25, 2008 at 4:35 AM, sebb <se...@gmail.com> wrote:
> <snip/>
> >
>
> > Surely Maven will use either whatever the JDK provides or whatever the
> > POM specifies?
> >
>
> <snap/>
>
> Yes.
>
>
> > I did some more tests, and if I add xercesImpl and xml-apis to the
> > dependencies, then Java 1.4.2 no longer reports any serialisation
> > errors. This suggests that (some) Java 1.4.2 xml classes are not
> > serialisable whereas Java 1.5.0+ are serialisable. Further, this
> > suggests that SCXML will not be serialisable on Java 1.4 unless
> > additional dependencies are provided.
> >
> > Have you not seen the serialisation errors when testing on Java 1.4.2?
> >
>
> <snip/>
>
> I mostly use the IBM JDKs for development, testing and deployments.
>
> I just reminded myself by trying various JDKs, here is the run down:
> 1) IBM JDKs use Xerces (which has a serializable impl)
> 2) Sun 1.5+ use an internally packaged Xerces
AIUI, the version in the JDK has not kept up with all the fixes.
> 3) Sun 1.4 uses the now largely defunct Crimson
>
> 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)
> 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.
The failure message should make it clear that the problem lies in the
environment.
>
> -Rahul
>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Tue, Nov 25, 2008 at 4:35 AM, sebb <se...@gmail.com> wrote:
<snip/>
>
> Surely Maven will use either whatever the JDK provides or whatever the
> POM specifies?
>
<snap/>
Yes.
> I did some more tests, and if I add xercesImpl and xml-apis to the
> dependencies, then Java 1.4.2 no longer reports any serialisation
> errors. This suggests that (some) Java 1.4.2 xml classes are not
> serialisable whereas Java 1.5.0+ are serialisable. Further, this
> suggests that SCXML will not be serialisable on Java 1.4 unless
> additional dependencies are provided.
>
> Have you not seen the serialisation errors when testing on Java 1.4.2?
>
<snip/>
I mostly use the IBM JDKs for development, testing and deployments.
I just reminded myself by trying various JDKs, here is the run down:
1) IBM JDKs use Xerces (which has a serializable impl)
2) Sun 1.5+ use an internally packaged Xerces
3) Sun 1.4 uses the now largely defunct Crimson
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)
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.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 24/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> On Mon, Nov 24, 2008 at 4:40 PM, sebb <se...@gmail.com> wrote:
> <snip/>
>
> >
> > I've just seen the error again.
> > I updated the fail() message to fail(e+e.getMessage()) so I got a bit
> > more information:
> >
> > -------------------------------------------------------------------------------
> > Test set: org.apache.commons.scxml.model.ModelTestSuite
> > -------------------------------------------------------------------------------
> > Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.876
> > sec <<< FAILURE!
> > testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
> > Time elapsed: 0.125 sec <<< FAILURE!
> > junit.framework.AssertionFailedError: java.lang.NullPointerExceptionnull
> > at junit.framework.Assert.fail(Assert.java:47)
> > at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:195)
> > at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:171)
> > at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:114)
> >
> > I think the fail(e.getMessage()) calls need to be updated to something
> > more useful, as the current code swallows all the useful information.
> > In test cases it's best to let the code throw an Exception - only
> > expected throwables should be caught by test cases.
> >
>
> <snap/>
>
> Yup, that pattern needs to be changed throughout the test cases.
>
>
>
> > I did this, and ran the test a few more times, and now I get:
> >
> > -------------------------------------------------------------------------------
> > Test set: org.apache.commons.scxml.model.ModelTestSuite
> > -------------------------------------------------------------------------------
> > Tests run: 78, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.906
> > sec <<< FAILURE!
> > testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
> > Time elapsed: 0.125 sec <<< ERROR!
> > java.lang.NullPointerException
> > at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:194)
> > at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:181)
> > at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:115)
> >
> > It looks like the testExecutorSerializability() method is returning
> > null, though I'm not sure why as it appears the file is generated and
> > read OK. I replaced the File I/O with ByteArray I/O and I did not get
> > the error, though I did not test very many times
> >
> > When I run the test on 1.4.2, I get a lot of messages:
> > SERIALIZATION ERROR: The DOM implementation in use is not serializable
> >
> > This is possibly because the DOM implementation is being provided by
> > the JDK, as I don't get it with JDK 1.5.0 or 1.6.0.
> >
> > Does JDK 1.4.2 require additional dependencies?
> >
>
> <snip/>
>
> No, its actually the other way around (for example, we require Xalan
> for XPath support if its greater than 1.4).
>
> What you are seeing is probably more a statement about what xml-apis
> Maven is using when running the tests (at some point they started
> pegging the xml-api versions IIRC).
>
Surely Maven will use either whatever the JDK provides or whatever the
POM specifies?
I did some more tests, and if I add xercesImpl and xml-apis to the
dependencies, then Java 1.4.2 no longer reports any serialisation
errors. This suggests that (some) Java 1.4.2 xml classes are not
serialisable whereas Java 1.5.0+ are serialisable. Further, this
suggests that SCXML will not be serialisable on Java 1.4 unless
additional dependencies are provided.
Have you not seen the serialisation errors when testing on Java 1.4.2?
What is a bit odd is that the test error also seems to disappear when
I add xerces and xml-apis. The method that fails already checks for
serialisation problems.
>
> > I think the test suite should be improved to give more details if/when
> > errors occur. At present errors are quite difficult to track down.
> >
>
> <snap/>
>
> Agreed, as proven by this thread. We should track this via a JIRA
> ticket (I suggest fix version v0.10) and subsequent improvements to
> the tests, Javadoc and FAQ as necessary.
>
OK.
> -Rahul
>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Mon, Nov 24, 2008 at 4:40 PM, sebb <se...@gmail.com> wrote:
<snip/>
>
> I've just seen the error again.
> I updated the fail() message to fail(e+e.getMessage()) so I got a bit
> more information:
>
> -------------------------------------------------------------------------------
> Test set: org.apache.commons.scxml.model.ModelTestSuite
> -------------------------------------------------------------------------------
> Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.876
> sec <<< FAILURE!
> testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
> Time elapsed: 0.125 sec <<< FAILURE!
> junit.framework.AssertionFailedError: java.lang.NullPointerExceptionnull
> at junit.framework.Assert.fail(Assert.java:47)
> at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:195)
> at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:171)
> at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:114)
>
> I think the fail(e.getMessage()) calls need to be updated to something
> more useful, as the current code swallows all the useful information.
> In test cases it's best to let the code throw an Exception - only
> expected throwables should be caught by test cases.
>
<snap/>
Yup, that pattern needs to be changed throughout the test cases.
> I did this, and ran the test a few more times, and now I get:
>
> -------------------------------------------------------------------------------
> Test set: org.apache.commons.scxml.model.ModelTestSuite
> -------------------------------------------------------------------------------
> Tests run: 78, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.906
> sec <<< FAILURE!
> testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
> Time elapsed: 0.125 sec <<< ERROR!
> java.lang.NullPointerException
> at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:194)
> at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:181)
> at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:115)
>
> It looks like the testExecutorSerializability() method is returning
> null, though I'm not sure why as it appears the file is generated and
> read OK. I replaced the File I/O with ByteArray I/O and I did not get
> the error, though I did not test very many times
>
> When I run the test on 1.4.2, I get a lot of messages:
> SERIALIZATION ERROR: The DOM implementation in use is not serializable
>
> This is possibly because the DOM implementation is being provided by
> the JDK, as I don't get it with JDK 1.5.0 or 1.6.0.
>
> Does JDK 1.4.2 require additional dependencies?
>
<snip/>
No, its actually the other way around (for example, we require Xalan
for XPath support if its greater than 1.4).
What you are seeing is probably more a statement about what xml-apis
Maven is using when running the tests (at some point they started
pegging the xml-api versions IIRC).
> I think the test suite should be improved to give more details if/when
> errors occur. At present errors are quite difficult to track down.
>
<snap/>
Agreed, as proven by this thread. We should track this via a JIRA
ticket (I suggest fix version v0.10) and subsequent improvements to
the tests, Javadoc and FAQ as necessary.
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> On Sat, Nov 22, 2008 at 8:46 AM, sebb <se...@gmail.com> wrote:
> > On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
>
> <snip/>
>
> >>
> >> I've been nudged before, but I'm OK with it being there.
> >>
> >
> > OK by me too, so long as they are up to date, so I just ran a "maven
> > test" and it completed successfully, and the same number of tests
> > (228) was run, so I guess that's OK
> >
>
> <snap/>
>
> Its upto date.
>
>
>
> > However, I also just ran "mvn test" again, and it failed with:
> >
> > -------------------------------------------------------------------------------
> > Test set: org.apache.commons.scxml.model.ModelTestSuite
> > -------------------------------------------------------------------------------
> > Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.641
> > sec <<< FAILURE!
> > testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
> > Time elapsed: 0.188 sec <<< FAILURE!
> > junit.framework.AssertionFailedError
> > at junit.framework.Assert.fail(Assert.java:47)
> > at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:195)
> > at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:150)
> > at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:114)
> >
> > The next 2 runs succeeded.
> > There may be a timing error in that test - and it would help if the
> > fail message gave a bit more information.
> >
>
> <snip/>
>
> Haven't seen that before. While it shouldn't matter, I usually clean
> the previous build before switching (so, 'maven test' -> 'maven clean'
> -> 'mvn test').
>
Actually, I was using a separate installation for the M1 build.
But it should not matter.
I've just seen the error again.
I updated the fail() message to fail(e+e.getMessage()) so I got a bit
more information:
-------------------------------------------------------------------------------
Test set: org.apache.commons.scxml.model.ModelTestSuite
-------------------------------------------------------------------------------
Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.876
sec <<< FAILURE!
testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
Time elapsed: 0.125 sec <<< FAILURE!
junit.framework.AssertionFailedError: java.lang.NullPointerExceptionnull
at junit.framework.Assert.fail(Assert.java:47)
at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:195)
at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:171)
at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:114)
I think the fail(e.getMessage()) calls need to be updated to something
more useful, as the current code swallows all the useful information.
In test cases it's best to let the code throw an Exception - only
expected throwables should be caught by test cases.
I did this, and ran the test a few more times, and now I get:
-------------------------------------------------------------------------------
Test set: org.apache.commons.scxml.model.ModelTestSuite
-------------------------------------------------------------------------------
Tests run: 78, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 3.906
sec <<< FAILURE!
testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
Time elapsed: 0.125 sec <<< ERROR!
java.lang.NullPointerException
at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:194)
at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:181)
at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:115)
It looks like the testExecutorSerializability() method is returning
null, though I'm not sure why as it appears the file is generated and
read OK. I replaced the File I/O with ByteArray I/O and I did not get
the error, though I did not test very many times
When I run the test on 1.4.2, I get a lot of messages:
SERIALIZATION ERROR: The DOM implementation in use is not serializable
This is possibly because the DOM implementation is being provided by
the JDK, as I don't get it with JDK 1.5.0 or 1.6.0.
Does JDK 1.4.2 require additional dependencies?
I think the test suite should be improved to give more details if/when
errors occur. At present errors are quite difficult to track down.
>
> -Rahul
>
>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sat, Nov 22, 2008 at 8:46 AM, sebb <se...@gmail.com> wrote:
> On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
<snip/>
>>
>> I've been nudged before, but I'm OK with it being there.
>>
>
> OK by me too, so long as they are up to date, so I just ran a "maven
> test" and it completed successfully, and the same number of tests
> (228) was run, so I guess that's OK
>
<snap/>
Its upto date.
> However, I also just ran "mvn test" again, and it failed with:
>
> -------------------------------------------------------------------------------
> Test set: org.apache.commons.scxml.model.ModelTestSuite
> -------------------------------------------------------------------------------
> Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.641
> sec <<< FAILURE!
> testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
> Time elapsed: 0.188 sec <<< FAILURE!
> junit.framework.AssertionFailedError
> at junit.framework.Assert.fail(Assert.java:47)
> at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:195)
> at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:150)
> at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:114)
>
> The next 2 runs succeeded.
> There may be a timing error in that test - and it would help if the
> fail message gave a bit more information.
>
<snip/>
Haven't seen that before. While it shouldn't matter, I usually clean
the previous build before switching (so, 'maven test' -> 'maven clean'
-> 'mvn test').
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sat, Nov 22, 2008 at 12:13 PM, sebb <se...@gmail.com> wrote:
> On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
<snip/>
>>
>> Thanks for going over the Findbugs list. While this is a bit of a déjà
>> vu for me ...
>>
>> http://markmail.org/message/si5kphud52ntxbqi
>>
>> ... I don't expect others to remember the discussion :-) and should
>> have commented on it earlier in this thread.
>>
>
> I've just had a look, and it raises some issues:
>
> Are all common Log implementations serialisable?
> Does it make sense for Log implementations to have to implement serialisable?
> If not, then it's an easy fix to use private static final instead of private.
<snap/>
Static probably not, container use expected:
http://wiki.apache.org/jakarta-commons/Logging/StaticLog
> Alternatively, one could document that the code assumes the logging
> implementation is serialisable.
>
<snip/>
With the exception of AvalonLog perhaps, most provided impls are Serializable:
http://markmail.org/message/kqee6ozfrb5ktehh
We could document this better in the FAQ (see last Q, in my mind,
custom log impls come close to user-defined content :-):
http://commons.apache.org/scxml/faq.html
> The discussion on threading mentions setting variables once, and
> referring to them later, both without synchronisation. This is not
> guaranteed to work, unless the thread that sets the data then uses a
> lock that is also used by the reading thread(s) at least once after
> the variable was set. [With a shared lock, changes to shared variables
> by thread A "happen before" the lock is released, and lock release
> "happens before" the lock is acquired by thread B.]
>
> Constructors don't guarantee safe publishing either. Non-final
> instance fields that are set in a constructor and never updated are
> not necessarily accessible to other threads - that is why the
> java.lang.String instance fields had to be made final in Java 1.5. It
> is a good idea to do the same so as far as possible in other code.
>
> It's unlikely that testing - or even much production use - will ever
> find such problems, but that does not mean they cannot happen.
>
> It would be nice if the thread-safety guarantees (or otherwise) were
> documented in the Javadoc. Maybe that is something to work towards for
> the next release.
>
<snap/>
We do FAQ this a bit (see second last Q), but again, it could be more
elaborate and highlighted in various Javadoc bits.
>> >
>> > Class org.apache.commons.scxml.model.Data defines non-transient
>> > non-serializable instance field node
>> >
>
> I've had a look at a few of the classes that implement Node, and not
> yet found one that implements serialisable, so I don't know how that's
> going to work.
>
<snip/>
This one has broad usage in the target JDK for this release (and elsewhere):
http://xerces.apache.org/xerces-j/apiDocs/org/apache/xerces/dom/NodeImpl.html
The state machine's XML datamodel is user-defined content, but the
implication that the DOM impl needs to be Serializable could be better
stressed in the FAQ.
>> > ==
>> >
>> > org.apache.commons.scxml.env.jexl.JexlEvaluator.evalCond(Context,
>> > String) has Boolean return type and returns explicit null
>> >
>> > org.apache.commons.scxml.env.jsp.ELEvaluator.evalCond(Context, String)
>> > has Boolean return type and returns explicit null
>> >
>> > These will cause problems if used later with autoboxing.
>
> Are these not problems when using Java 1.5+?
>
<snap/>
I will have to look (won't be today), but we do have a J6-minimum
branch already:
http://svn.apache.org/repos/asf/commons/proper/scxml/branches/J6/
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> On Sat, Nov 22, 2008 at 9:19 AM, sebb <se...@gmail.com> wrote:
> > Just thought to run Findbugs on the code.
> >
>
> <snip/>
>
> Thanks for going over the Findbugs list. While this is a bit of a déjà
> vu for me ...
>
> http://markmail.org/message/si5kphud52ntxbqi
>
> ... I don't expect others to remember the discussion :-) and should
> have commented on it earlier in this thread.
>
I've just had a look, and it raises some issues:
Are all common Log implementations serialisable?
Does it make sense for Log implementations to have to implement serialisable?
If not, then it's an easy fix to use private static final instead of private.
Alternatively, one could document that the code assumes the logging
implementation is serialisable.
The discussion on threading mentions setting variables once, and
referring to them later, both without synchronisation. This is not
guaranteed to work, unless the thread that sets the data then uses a
lock that is also used by the reading thread(s) at least once after
the variable was set. [With a shared lock, changes to shared variables
by thread A "happen before" the lock is released, and lock release
"happens before" the lock is acquired by thread B.]
Constructors don't guarantee safe publishing either. Non-final
instance fields that are set in a constructor and never updated are
not necessarily accessible to other threads - that is why the
java.lang.String instance fields had to be made final in Java 1.5. It
is a good idea to do the same so as far as possible in other code.
It's unlikely that testing - or even much production use - will ever
find such problems, but that does not mean they cannot happen.
It would be nice if the thread-safety guarantees (or otherwise) were
documented in the Javadoc. Maybe that is something to work towards for
the next release.
> There is one new finding, I'll comment on it below.
>
>
>
> > There are a lot of cases of the statement:
> >
> > private Log appLog = LogFactory.getLog(...)
> >
> > which appear in serializable classes.
> >
> > However Log does not appear to be Serializable, so this will cause a
> > problem if the classes are serialised. So long as the Log fields are
> > private, they could just be made static and final.
> >
> > ==
> >
> > org.apache.commons.scxml.io.SCXMLDigester.digest() has:
> > if (scxml != null) {
> > ModelUpdater.updateSCXML(scxml);
> > }
> > scxml.setLegacy(true); // could be null - should be in
> > previous if statement
> >
> > ==
>
> <snap/>
>
> Indeed :-) I'll fix that in a minute, but I won't be cutting a new RC
> just for this:
> 1) We could do better than a NPE, but its a fatal parsing error at that point
> 2) Its a long deprecated class (deprecated in 0.7)
OK, no problem with that.
> -Rahul
>
>
>
>
> >
> > Class org.apache.commons.scxml.model.Data defines non-transient
> > non-serializable instance field node
> >
I've had a look at a few of the classes that implement Node, and not
yet found one that implements serialisable, so I don't know how that's
going to work.
> > ==
> >
> > org.apache.commons.scxml.env.jexl.JexlEvaluator.evalCond(Context,
> > String) has Boolean return type and returns explicit null
> >
> > org.apache.commons.scxml.env.jsp.ELEvaluator.evalCond(Context, String)
> > has Boolean return type and returns explicit null
> >
> > These will cause problems if used later with autoboxing.
Are these not problems when using Java 1.5+?
> > ==
> >
> > Inconsistent synchronization of
> > org.apache.commons.scxml.SCXMLExecutor.errorReporter; locked 76% of
> > time
> >
> > Similarly for eventDispatcher, stateMachine, superStep in the same class
> >
> > It appears that the class will be used in multiple threads, so if
> > those variables can be accessed from multiple threads, then all access
> > to them will need to be synchronized.
> >
> > ==
> >
> > There are a few other Findbugs warnings - mainly in the test code. Let
> > me know if you want the full list (though if you use Eclipse, it's
> > probably easier to add the Findbugs plugin).
> >
> > ==
> >
> > I also just noticed that there are a few instance fields that could be
> > made final - e.g. most of the items set up in the
> > org.apache.commons.scxml.SCInstance.SCInstance constructor.
> > This would improve thread-safety.
> >
>
>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Sat, Nov 22, 2008 at 9:19 AM, sebb <se...@gmail.com> wrote:
> Just thought to run Findbugs on the code.
>
<snip/>
Thanks for going over the Findbugs list. While this is a bit of a déjà
vu for me ...
http://markmail.org/message/si5kphud52ntxbqi
... I don't expect others to remember the discussion :-) and should
have commented on it earlier in this thread.
There is one new finding, I'll comment on it below.
> There are a lot of cases of the statement:
>
> private Log appLog = LogFactory.getLog(...)
>
> which appear in serializable classes.
>
> However Log does not appear to be Serializable, so this will cause a
> problem if the classes are serialised. So long as the Log fields are
> private, they could just be made static and final.
>
> ==
>
> org.apache.commons.scxml.io.SCXMLDigester.digest() has:
> if (scxml != null) {
> ModelUpdater.updateSCXML(scxml);
> }
> scxml.setLegacy(true); // could be null - should be in
> previous if statement
>
> ==
<snap/>
Indeed :-) I'll fix that in a minute, but I won't be cutting a new RC
just for this:
1) We could do better than a NPE, but its a fatal parsing error at that point
2) Its a long deprecated class (deprecated in 0.7)
-Rahul
>
> Class org.apache.commons.scxml.model.Data defines non-transient
> non-serializable instance field node
>
> ==
>
> org.apache.commons.scxml.env.jexl.JexlEvaluator.evalCond(Context,
> String) has Boolean return type and returns explicit null
>
> org.apache.commons.scxml.env.jsp.ELEvaluator.evalCond(Context, String)
> has Boolean return type and returns explicit null
>
> These will cause problems if used later with autoboxing.
>
> ==
>
> Inconsistent synchronization of
> org.apache.commons.scxml.SCXMLExecutor.errorReporter; locked 76% of
> time
>
> Similarly for eventDispatcher, stateMachine, superStep in the same class
>
> It appears that the class will be used in multiple threads, so if
> those variables can be accessed from multiple threads, then all access
> to them will need to be synchronized.
>
> ==
>
> There are a few other Findbugs warnings - mainly in the test code. Let
> me know if you want the full list (though if you use Eclipse, it's
> probably easier to add the Findbugs plugin).
>
> ==
>
> I also just noticed that there are a few instance fields that could be
> made final - e.g. most of the items set up in the
> org.apache.commons.scxml.SCInstance.SCInstance constructor.
> This would improve thread-safety.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
Just thought to run Findbugs on the code.
There are a lot of cases of the statement:
private Log appLog = LogFactory.getLog(...)
which appear in serializable classes.
However Log does not appear to be Serializable, so this will cause a
problem if the classes are serialised. So long as the Log fields are
private, they could just be made static and final.
==
org.apache.commons.scxml.io.SCXMLDigester.digest() has:
if (scxml != null) {
ModelUpdater.updateSCXML(scxml);
}
scxml.setLegacy(true); // could be null - should be in
previous if statement
==
Class org.apache.commons.scxml.model.Data defines non-transient
non-serializable instance field node
==
org.apache.commons.scxml.env.jexl.JexlEvaluator.evalCond(Context,
String) has Boolean return type and returns explicit null
org.apache.commons.scxml.env.jsp.ELEvaluator.evalCond(Context, String)
has Boolean return type and returns explicit null
These will cause problems if used later with autoboxing.
==
Inconsistent synchronization of
org.apache.commons.scxml.SCXMLExecutor.errorReporter; locked 76% of
time
Similarly for eventDispatcher, stateMachine, superStep in the same class
It appears that the class will be used in multiple threads, so if
those variables can be accessed from multiple threads, then all access
to them will need to be synchronized.
==
There are a few other Findbugs warnings - mainly in the test code. Let
me know if you want the full list (though if you use Eclipse, it's
probably easier to add the Findbugs plugin).
==
I also just noticed that there are a few instance fields that could be
made final - e.g. most of the items set up in the
org.apache.commons.scxml.SCInstance.SCInstance constructor.
This would improve thread-safety.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> Thanks for your time (some comments below).
>
> On Fri, Nov 21, 2008 at 9:51 PM, sebb <se...@gmail.com> wrote:
> <snip/>
>
> >
> > All looks OK:
> > + hashes, sigs OK
> > + tar and zip archives have same contents
> > + source agrees with SVN tag
> > + mvn test works OK on 1.4.2 and 1.6.0
> > + Ant jar works on 1.6.0 and 1.4.2; test works on 1.4.2.
> >
> > Just a few minor tweaks to consider:
> > + Since the build now uses M2, it would be good to remove the M1 files
>
> <snap/>
>
> I've been nudged before, but I'm OK with it being there.
>
OK by me too, so long as they are up to date, so I just ran a "maven
test" and it completed successfully, and the same number of tests
(228) was run, so I guess that's OK
However, I also just ran "mvn test" again, and it failed with:
-------------------------------------------------------------------------------
Test set: org.apache.commons.scxml.model.ModelTestSuite
-------------------------------------------------------------------------------
Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 4.641
sec <<< FAILURE!
testDatamodelNamespacePrefixedXPaths(org.apache.commons.scxml.model.DatamodelTest)
Time elapsed: 0.188 sec <<< FAILURE!
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at org.apache.commons.scxml.model.DatamodelTest.fireEvent(DatamodelTest.java:195)
at org.apache.commons.scxml.model.DatamodelTest.runtest(DatamodelTest.java:150)
at org.apache.commons.scxml.model.DatamodelTest.testDatamodelNamespacePrefixedXPaths(DatamodelTest.java:114)
The next 2 runs succeeded.
There may be a timing error in that test - and it would help if the
fail message gave a bit more information.
>
> > + The Ant build downloads junit.jar but fails to add it to the
> > classpath, which is a bit silly. Either skip the download and use the
> > Ant version, or download and use the jar.
>
> <snip/>
>
> Makes sense, though its a m1 generated file so I probably won't touch it.
>
>
>
> > + Source and Javadoc jars have minimal manifests; it would be useful
> > to include some or all of the following:
> > Implementation-Title: Commons SCXML
> > Implementation-Vendor: The Apache Software Foundation
> > Implementation-Vendor-Id: org.apache
> > Implementation-Version: 0.9
> > Specification-Title: Commons SCXML
> > Specification-Vendor: The Apache Software Foundation
> > Specification-Version: 0.9
> >
>
> <snap/>
>
> Yeah, those would be m2 improvements.
>
>
>
> > Just noticed that the ApacheCon advert is out of date.
> >
>
> <snip/>
>
> Fixed (though I didn't deploy the change yet).
>
> -Rahul
>
>
> > No blockers, so
> >
> > +1
>
> >
>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
Thanks for your time (some comments below).
On Fri, Nov 21, 2008 at 9:51 PM, sebb <se...@gmail.com> wrote:
<snip/>
>
> All looks OK:
> + hashes, sigs OK
> + tar and zip archives have same contents
> + source agrees with SVN tag
> + mvn test works OK on 1.4.2 and 1.6.0
> + Ant jar works on 1.6.0 and 1.4.2; test works on 1.4.2.
>
> Just a few minor tweaks to consider:
> + Since the build now uses M2, it would be good to remove the M1 files
<snap/>
I've been nudged before, but I'm OK with it being there.
> + The Ant build downloads junit.jar but fails to add it to the
> classpath, which is a bit silly. Either skip the download and use the
> Ant version, or download and use the jar.
<snip/>
Makes sense, though its a m1 generated file so I probably won't touch it.
> + Source and Javadoc jars have minimal manifests; it would be useful
> to include some or all of the following:
> Implementation-Title: Commons SCXML
> Implementation-Vendor: The Apache Software Foundation
> Implementation-Vendor-Id: org.apache
> Implementation-Version: 0.9
> Specification-Title: Commons SCXML
> Specification-Vendor: The Apache Software Foundation
> Specification-Version: 0.9
>
<snap/>
Yeah, those would be m2 improvements.
> Just noticed that the ApacheCon advert is out of date.
>
<snip/>
Fixed (though I didn't deploy the change yet).
-Rahul
> No blockers, so
>
> +1
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> On Fri, Nov 21, 2008 at 9:14 PM, sebb <se...@gmail.com> wrote:
> > On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> >> Distributions, key, release notes:
> >>
> >> http://people.apache.org/builds/commons/scxml/0.9/RC1/
> >>
> >> Site including clirr and rat reports (many links -- such as release
> >> docs, some Javadoc links and images will remain broken on staging
> >> site):
> >>
> >> http://people.apache.org/builds/commons/scxml/0.9/RC1/site/
> >>
> >> m2 staging repo:
> >>
> >> http://people.apache.org/builds/commons/scxml/0.9/RC1/staged/
> >>
> >> Thanks in advance for all feedback. If no blockers surface, I intend
> >> to put these bits up for vote in a week.
> >
> > Is there an SVN tag?
> >
>
> <snip/>
>
> Indeed:
>
> http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_9_RC1/
>
All looks OK:
+ hashes, sigs OK
+ tar and zip archives have same contents
+ source agrees with SVN tag
+ mvn test works OK on 1.4.2 and 1.6.0
+ Ant jar works on 1.6.0 and 1.4.2; test works on 1.4.2.
Just a few minor tweaks to consider:
+ Since the build now uses M2, it would be good to remove the M1 files
+ The Ant build downloads junit.jar but fails to add it to the
classpath, which is a bit silly. Either skip the download and use the
Ant version, or download and use the jar.
+ Source and Javadoc jars have minimal manifests; it would be useful
to include some or all of the following:
Implementation-Title: Commons SCXML
Implementation-Vendor: The Apache Software Foundation
Implementation-Vendor-Id: org.apache
Implementation-Version: 0.9
Specification-Title: Commons SCXML
Specification-Vendor: The Apache Software Foundation
Specification-Version: 0.9
Just noticed that the ApacheCon advert is out of date.
No blockers, so
+1
> -Rahul
>
> ---------------------------------------------------------------------
> 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
Re: [all] Commons SCXML 0.9 RC1 available
Posted by Rahul Akolkar <ra...@gmail.com>.
On Fri, Nov 21, 2008 at 9:14 PM, sebb <se...@gmail.com> wrote:
> On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
>> Distributions, key, release notes:
>>
>> http://people.apache.org/builds/commons/scxml/0.9/RC1/
>>
>> Site including clirr and rat reports (many links -- such as release
>> docs, some Javadoc links and images will remain broken on staging
>> site):
>>
>> http://people.apache.org/builds/commons/scxml/0.9/RC1/site/
>>
>> m2 staging repo:
>>
>> http://people.apache.org/builds/commons/scxml/0.9/RC1/staged/
>>
>> Thanks in advance for all feedback. If no blockers surface, I intend
>> to put these bits up for vote in a week.
>
> Is there an SVN tag?
>
<snip/>
Indeed:
http://svn.apache.org/repos/asf/commons/proper/scxml/tags/SCXML_0_9_RC1/
-Rahul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [all] Commons SCXML 0.9 RC1 available
Posted by sebb <se...@gmail.com>.
On 22/11/2008, Rahul Akolkar <ra...@gmail.com> wrote:
> Distributions, key, release notes:
>
> http://people.apache.org/builds/commons/scxml/0.9/RC1/
>
> Site including clirr and rat reports (many links -- such as release
> docs, some Javadoc links and images will remain broken on staging
> site):
>
> http://people.apache.org/builds/commons/scxml/0.9/RC1/site/
>
> m2 staging repo:
>
> http://people.apache.org/builds/commons/scxml/0.9/RC1/staged/
>
> Thanks in advance for all feedback. If no blockers surface, I intend
> to put these bits up for vote in a week.
Is there an SVN tag?
> -Rahul
>
> ---------------------------------------------------------------------
> 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