[Biojava-dev] maven progress

[Andy Law (RI)]

On 1 Sep 2009, at 15:37, Andreas Prlic wrote:

> Hi Andy,
>
> this repository location is ssh protected.  Anonymous checkouts are
> possible via
>
> svn://code.open-bio.org/biojava/biojava-live/biojava


OK. I've got a checkout from there thanks.

I trip up over a dependency on bytecode version 3.0. That will need to  
either be incorporated into the tree or published to maven central  
before the system works as it should (version 1.5 is on the maven  
central repo but I couldn't find a later version)



>>>
>>> At the moment I am chasing an "interesting" problem. When I run the
>>> junit tests on the new core module in eclipse, they run fine.    
>>> When I
>>> do the same via a mvn test I get several issues like the one below.
>>> Anybody got an idea?
>>>
>>>
>>> -------------------------------------------------------------------------------
>>> Test set: org.biojava.bio.seq.project.ProjectedFeatureHolderTest
>>>
>>> -------------------------------------------------------------------------------
>>> Tests run: 6, Failures: 0, Errors: 1, Skipped: 0, Time elapsed:  
>>> 0.036
>>> sec <<< FAILURE!
>>>
>>> testFeatureChangeEvent 
>>> (org.biojava.bio.seq.project.ProjectedFeatureHolderTest)
>>> Time elapsed: 0.011 sec  <<< ERROR!
>>> java.lang.AssertionError: firePreChangeEvent must be called in a
>>> synchronized block locking the ChangeSupport
>>>        at
>>> org 
>>> .biojava.utils.ChangeSupport.firePreChangeEvent(ChangeSupport.java: 
>>> 281)
>>>        at
>>> org.biojava.bio.seq.projection.ReparentContext 
>>> $PFChangeForwarder.preChange(ReparentContext.java:299)
>>>        at
>>> org 
>>> .biojava.utils.ChangeSupport.firePreChangeEvent(ChangeSupport.java: 
>>> 297)
>>>        at
>>> org 
>>> .biojava.bio.seq.impl.SimpleFeature.setLocation(SimpleFeature.java: 
>>> 173)
>>>        at
>>> org 
>>> .biojava 
>>> .bio 
>>> .seq 
>>> .project 
>>> .ProjectedFeatureHolderTest 
>>> .testFeatureChangeEvent(ProjectedFeatureHolderTest.java:297)
>>>
>>
>>
>> That's certainly not one that I've ever seen, but then I probably  
>> don't
>> write code that is as complicated as BioJava :o}
>>
>> If I could get a checkout (see above) then I would try it out in  
>> NetBeans to
>> see if it is something that Eclipse is doing to "protect" against the
>> synchronisation problem. But I can't get the code so I can't test  
>> it :o{
>>



Thos error messages *do* appear when running the tests from inside  
Netbeans, so clearly something that Eclipse is doing must be hiding  
the errors from you :o}

 From what I can tell, there are instances in the code that fire off  
preChange()/postChange() in ChangeListeners without first locking down  
the ChangeSupport object (whatever that is - this is the first real  
delve that I've had in the BioJava guts).

For example, SimpleSequence.java contains a private class called  
FeatureForwarder that implements ChangeListener (lines 322:332)
This currently reads:

     private class FeatureForwarder implements ChangeListener {
       public void preChange(ChangeEvent cev)
       throws ChangeVetoException
       {
         getChangeSupport(cev.getType()).firePreChangeEvent(cev);
           }

       public void postChange(ChangeEvent cev) {
         getChangeSupport(cev.getType()).firePostChangeEvent(cev);
           }
     }



I think that it *should* read something like

     private class FeatureForwarder implements ChangeListener {
       public void preChange(ChangeEvent cev)
       throws ChangeVetoException
       {
           ChangeSupport cs = getChangeSupport(cev.getType());
           synchronized(cs) {
         cs.firePreChangeEvent(cev);
           }
       }

       public void postChange(ChangeEvent cev) {
         ChangeSupport cs = getChangeSupport(cev.getType());
           synchronized(cs) {
         cs.firePostChangeEvent(cev);
           }
       }
     }

and when I change my local copy to this, the problems go away (for at  
least one section of the tests). I still get the same error cropping  
up in other parts (where the code funnels through different  
ChangeListener implementations which all have the same style as the  
first version above but that, I guess, is to be expected.

There are test problems relating to file paths too - but I presume  
that you knew that stuff already.

Later,

Andy
--------
Yada, yada, yada...
The University of Edinburgh is a charitable body, registered in  
Scotland, with registration number SC005336
Disclaimer: This e-mail and any attachments are confidential and  
intended solely for the use of the recipient(s) to whom they are  
addressed. If you have received it in error, please destroy all copies  
and inform the sender.