Re: Synchronizing James and Cornerstone

[Stephen McConnell]

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:[EMAIL PROTECTED]
http://www.osm.net




--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>