avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Synchronizing James and Cornerstone
Date Sat, 11 Jan 2003 20:54:24 GMT


Noel J. Bergman wrote:

>Stephen,
>
>[Responding to all of your various notes here]
>
>I don't know if Paul tagged the CVS when he took the code currently embedded
>in James from the Avalon CVS.  Yes, it is certainly an older version of the
>code prior to Avalon violating (er, unilaterally changing) interface
>contracts.
>

I just checked the CVS "with-Avalon-4_0b2" - if could be this (at least 
the code I'm looking at on the WebCVS is consitent with the error I was 
getting originally).

>>What I don't understand is how James could be running inside Phoneix
>>without problem unless nobody from James has executed a clean checkout of
>>Excalibur in the last 3 months.
>>    
>>
>
>Of course we haven't:
>
>   http://cvs.apache.org/viewcvs.cgi/jakarta-james/phoenix-bin/lib/
>   http://cvs.apache.org/viewcvs.cgi/jakarta-james/lib/
>
>As should be well understood by now, James uses the older version because
>the interfaces were changed, and broke our code.  At some point, we had to
>focus on our own release, and not play three-card monty with Avalon's
>interfaces.
>  
>

Yep.

>  
>
>>   James is runing againt excalibur-thread-1.0.jar (size 22k)
>>   Excalibur current build of excalibur-thread-1.0.jar (size 32k)
>>   appears to be incompatible
>>    
>>
>
>Gee, what a shock.  And with the same version label, no less.
>
>If I sound a bit testy today, I'm sorry (and probably a bit testy, anyway
>:-)).  Reading your messages has me thinking about how much work and testing
>we may have to do to get James running with the current Avalon.  Plus the
>fact that this is still open despite being reported multiple times, put in
>bugzilla, *and* having had the fix posted with it:
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15296.
>
>FWIW, we did take the file repository classes from Avalon and moved them
>into our codebase because we were told that the code was in Avalon only for
>us, and would not ever be fixed.
>
>  
>
>>Things would be *so* much easier if we got James and Cornerstone in sync.
>>    
>>
>
>Yes, getting back to the problem at hand ... how far have you gotten on all
>of the problems you enumerated?
>

I have James running - but failing due to what I think is an 
incompatability in excalibur-thread-1.0.jar - which I think may be 
linked to the collections jar.  Aside from that - there were some issues 
I encountered on the container side relating to non-components being 
passed out of a component manager but that has been solved with a proxy. 
 That, combined with a simulated Phoenix BlockContext seems to have 
resolved the build and deployment stages.

>
>I'm willing to work with you on updating the HEAD to work with the curent
>Avalon code.  I suspect that the best thing, so as not to foul up others
>would be to create a short-lived branch of James, put the new Avalon jars in
>that branch, and work on the James code until we can once again build and
>run.  Then we can merge the Avalon jars and the changed code into HEAD.
>
>And we can let GUMP warn us if someone changes interfaces again.
>
>That the way you'd do it?
>  
>

Sound good.

>I don't see any value to changing the v2 branch to use the updated Avalon
>interfaces.  Frankly, there is a trust factor, and I don't want to risk
>breaking our stable branch.
>  
>

I agree - there is some rebuilding to be done (I'm I not referring to code).

>>- Classes in James that extend Cornerstone and call super
>>  on ComponentManager (which is broken because the Cornerstone
>>  classes no longer implement ComponentManager.
>>    
>>
>
>  
>
>> - Numerouse casting errors related to James casting of objects
>>   to Component which do not exist in the current Cornerstone
>>   package.
>>    
>>
>
>  
>
>> - Some more tricky errors related to the passing of component
>>   managers and component across different instances which don't
>>   show up until runtime.
>>    
>>
>
>What about the other errors reported by GUMP, e.g.,
>
>  org.apache.james.core.AvalonMailStore should be declared abstract;
>  it does not define isSelectable(java.lang.Object)
>
>  select(java.lang.Object) in org.apache.james.core.AvalonMailStore
>  cannot implement select(java.lang.Object); attempting to use
>  incompatible return type
>     found   : org.apache.avalon.framework.component.Component
>     required: java.lang.Object
>
>Etc.  Are you including those errors, or have you fixed them already?
>  
>

These errors are directly related to the ComponentManager/ServiceManager 
changes in Cornerstone.  Basically some of the classes in James  extend 
classes in Cornerstone and there are places where a James compoent is 
invoking super.compose( manager ) and the supertype does not implement 
the the compose operation.  Other errors are simply cast errors related 
to the Component interface.  There a few tricky ones where the compoennt 
manager is held as a state member and subsequently passed as an argument 
which is a little harder to track down given all of the inconsitencies. 
 Bottom line - 95% of the issue will dissapear with the CM -> SM 
rollover in the James code.

>>In addition to synchronization I think there is some repackaging
>>required on the Avalon side.
>>    
>>
>
>If we do it as suggested above, just package up the new Avalon jars to
>replace what we have, get them to me, and I'll commit them.
>

Ok - here is a outline of a plan:

   1. you create a special James tag for the rationalization process
   2. I'll propose to Avalon that we get at least the components used by 
James
      packaged as individual jars (building against the current Excalibur
      sources)
   3. we to transition of CM -> SM
   4. validate, fix, validate, test

Cheers, Steve.

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net




--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message