You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@apache.org> on 2003/01/11 06:06:27 UTC
Synchronizing James and Cornerstone
Noel J. Bergman wrote:
>>the transition from Composable to Serviceable is not too difficult
>>is just a matter of some specific replacements and a some
>>validatition - the more relavant question is when?
>>
>>
>
>Well, that's why I asked. What exactly do we need to do? We may not do it
>for James v2, but I'd like James v3 (HEAD) to be able to float against
>Avalon.
>
On timming I would very much like to see synchronization as early as
possible. I'm currently running into lot of problems with James that
are related to the Cornerstone version in james/lib. The problem
appears to be that the James version is still linked to BlockContext
whereas the Avalon version is not (following recent Cornerstone changes).
Some of the problems I'm encountering when attempting to build James
against Avalon Cornerstone include:
- 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.
Problems related to working with the current James version of
Cornerstone include:
- ClassCastExceptions when dealing with context (which is surely
related to Pheonix BlockContext but I don't know where the code is
backing the the James version of Cornerstone so I'm working in
the dark.
Things would be *so* much easier if we got James and Cornerstone in sync.
In addition to synchronization I think there is some repackaging
required on the Avalon side. Currently the Cornerstone.jar contains a
bunch of components that are not used by James (RMISubscriber,
SocketStreamPublisher, RMIPublisher, DefaultAuthenticator, and Glue).
It would make a lot more sense for individual components in Cornerstone
to be packaged in individual jars and treated as specific products (with
respective releases, status, versions, etc.).
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Sam,
>
>
>
>>FYI: you can always pick up an internally self-consistent set of jars,
>>appropriately datestamped, at http://gump.covalent.net/jars/.
>>
>>
>
>Thanks. But Stephen had said "In addition to synchronization I think there
>is some repackaging required on the Avalon side" so I'm assuming that the
>current jars aren't what he'd like for us to be using, either. Sounds like
>he is proposing some changes in Avalon's own packaging first.
>
Correct.
Currently the cornerstone.jar contains 13 different components with
quite different purposes, depedencies, relase status, and supporting
community. This makes it very difficult to "take responsibility" for
Cornerstone - its much easier if we break up Cornerstone into respective
components - and put the effort where it is needed - and for me - the
immediate priority is to get the Avalon/Cornerstone/James peices sorted
out ASAP. This means some immediate addention on the following
Cornerstone components:
* threads
* store
* sockets
* connection
* scheduler
* datasource
Cheers, Steve.
>
> --- Noel
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sam,
> FYI: you can always pick up an internally self-consistent set of jars,
> appropriately datestamped, at http://gump.covalent.net/jars/.
Thanks. But Stephen had said "In addition to synchronization I think there
is some repackaging required on the Avalon side" so I'm assuming that the
current jars aren't what he'd like for us to be using, either. Sounds like
he is proposing some changes in Avalon's own packaging first.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
Sam,
> FYI: you can always pick up an internally self-consistent set of jars,
> appropriately datestamped, at http://gump.covalent.net/jars/.
Thanks. But Stephen had said "In addition to synchronization I think there
is some repackaging required on the Avalon side" so I'm assuming that the
current jars aren't what he'd like for us to be using, either. Sounds like
he is proposing some changes in Avalon's own packaging first.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>
> 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.
FYI: you can always pick up an internally self-consistent set of jars,
appropriately datestamped, at
http://gump.covalent.net/jars/
- Sam Ruby
P.S. Excellent rant! ;-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>
> 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.
FYI: you can always pick up an internally self-consistent set of jars,
appropriately datestamped, at
http://gump.covalent.net/jars/
- Sam Ruby
P.S. Excellent rant! ;-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Stephen McConnell <mc...@apache.org>.
Sam Ruby wrote:
> Noel J. Bergman wrote:
>
>>> Gump should have warned us before, but it has not been working
>>> for too much time. We have to fix it. Sam is helping everybody
>>> to get back to making Gump build everything
>>
>>
>> Sam is working hard, but one problem is that if GUMP can't successfully
>> build a dependency, then it can hardly report when that dependency
>> changes
>> in such manner that when it finally builds it will break dependents.
>
>
> Getting the system to cleanly build is hard, and a number of us are
> working on it (I won't take full credit).
>
> Keeping the system cleanly building takes cooperation. What it means
> is that people don't keep components failing for weeks on end. You've
> known about incompatibilities, but you have not chosen to address
> them. This is not a big deal as other projects aren't depending on
> you, but is a big deal in other cases.
>
> Leo Simons hit the nail on the head when he said "Let's try and stop
> being the gump problem child, shall we?".
>
> It is my opinion that the Avalon team is now sufficiently motivated to
> try to keep their components building under Gump.
Yep .. count on it.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>>Gump should have warned us before, but it has not been working
>>for too much time. We have to fix it. Sam is helping everybody
>>to get back to making Gump build everything
>
> Sam is working hard, but one problem is that if GUMP can't successfully
> build a dependency, then it can hardly report when that dependency changes
> in such manner that when it finally builds it will break dependents.
Getting the system to cleanly build is hard, and a number of us are
working on it (I won't take full credit).
Keeping the system cleanly building takes cooperation. What it means is
that people don't keep components failing for weeks on end. You've
known about incompatibilities, but you have not chosen to address them.
This is not a big deal as other projects aren't depending on you, but
is a big deal in other cases.
Leo Simons hit the nail on the head when he said "Let's try and stop
being the gump problem child, shall we?".
It is my opinion that the Avalon team is now sufficiently motivated to
try to keep their components building under Gump.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Sam Ruby <ru...@apache.org>.
Noel J. Bergman wrote:
>>Gump should have warned us before, but it has not been working
>>for too much time. We have to fix it. Sam is helping everybody
>>to get back to making Gump build everything
>
> Sam is working hard, but one problem is that if GUMP can't successfully
> build a dependency, then it can hardly report when that dependency changes
> in such manner that when it finally builds it will break dependents.
Getting the system to cleanly build is hard, and a number of us are
working on it (I won't take full credit).
Keeping the system cleanly building takes cooperation. What it means is
that people don't keep components failing for weeks on end. You've
known about incompatibilities, but you have not chosen to address them.
This is not a big deal as other projects aren't depending on you, but
is a big deal in other cases.
Leo Simons hit the nail on the head when he said "Let's try and stop
being the gump problem child, shall we?".
It is my opinion that the Avalon team is now sufficiently motivated to
try to keep their components building under Gump.
- Sam Ruby
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>Gump should have warned us before, but it has not been working
>>for too much time. We have to fix it. Sam is helping everybody
>>to get back to making Gump build everything
[...]
> One should support contracts for as long as possible, even if just for
> binary compatibility.
[...]
>In other
> words, if one is going to change a contract don't do so linearly. I also
> suggest that such changes only occur on major release boundaries.
Correct. Gump is not the solution, but an early warning system.
>>I have a better idea. We are floating the possibility of opening our
>>Component repository to the projects that are using Avalon, and that
>>would include James. Would that be a deal?
>
>
> I just starting looking at your proposal. It sounds as if it basically
> would make Committers from Avalon-using projects Committers on the
> components part of the Avalon landscape, and allow us to commit fixes to
> Avalon components, e.g., Excalibur and Cornerstone. Of course, you could do
> that simply make us committers on those modules.
Yes. The unification is another aspect of the proposal, more targetted
to the needs of Avalon as a project to reunite in a more coherent vision.
> But we still need to change James because of interface changes, so unless
> Avalon is proposing rolling back those changes (which might be even more
> work at this point), I'm not sure how it is a better idea than updating
> James with Stephen's help.
This proposal is made with in mind a better relationship between James
and Avalon for the future.
I put myself in your situation, and thought that I would never use
Avalon Components again unless I was able to have access to their CVS. I
would also want to veto and revert changes if Gump fails badly, and
partecipate in their life.
Hence the proposal.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
>>Gump should have warned us before, but it has not been working
>>for too much time. We have to fix it. Sam is helping everybody
>>to get back to making Gump build everything
[...]
> One should support contracts for as long as possible, even if just for
> binary compatibility.
[...]
>In other
> words, if one is going to change a contract don't do so linearly. I also
> suggest that such changes only occur on major release boundaries.
Correct. Gump is not the solution, but an early warning system.
>>I have a better idea. We are floating the possibility of opening our
>>Component repository to the projects that are using Avalon, and that
>>would include James. Would that be a deal?
>
>
> I just starting looking at your proposal. It sounds as if it basically
> would make Committers from Avalon-using projects Committers on the
> components part of the Avalon landscape, and allow us to commit fixes to
> Avalon components, e.g., Excalibur and Cornerstone. Of course, you could do
> that simply make us committers on those modules.
Yes. The unification is another aspect of the proposal, more targetted
to the needs of Avalon as a project to reunite in a more coherent vision.
> But we still need to change James because of interface changes, so unless
> Avalon is proposing rolling back those changes (which might be even more
> work at this point), I'm not sure how it is a better idea than updating
> James with Stephen's help.
This proposal is made with in mind a better relationship between James
and Avalon for the future.
I put myself in your situation, and thought that I would never use
Avalon Components again unless I was able to have access to their CVS. I
would also want to veto and revert changes if Gump fails badly, and
partecipate in their life.
Hence the proposal.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Gump should have warned us before, but it has not been working
> for too much time. We have to fix it. Sam is helping everybody
> to get back to making Gump build everything
Sam is working hard, but one problem is that if GUMP can't successfully
build a dependency, then it can hardly report when that dependency changes
in such manner that when it finally builds it will break dependents.
One should support contracts for as long as possible, even if just for
binary compatibility. Consider this example from the Servlet API: "In this
version, this method always returns null and remains only to preserve binary
compatibility. This method will be permanently removed in a future version
of the Java Servlet API.". Does this mean that one can never remove them?
No, but there are ways to do it that are more graceful.
If I understand correctly, GUMP supports branchs and tags. Before making
incompatible interface changes, the relevant Avalon CVS modules could have
been branched so that (a) GUMP could be told to build clients against a
particular branch, and (b) the module could patched if/when necessary to fix
a defect without requiring clients to adopt the new interfaces. In other
words, if one is going to change a contract don't do so linearly. I also
suggest that such changes only occur on major release boundaries.
> I have a better idea. We are floating the possibility of opening our
> Component repository to the projects that are using Avalon, and that
> would include James. Would that be a deal?
I just starting looking at your proposal. It sounds as if it basically
would make Committers from Avalon-using projects Committers on the
components part of the Avalon landscape, and allow us to commit fixes to
Avalon components, e.g., Excalibur and Cornerstone. Of course, you could do
that simply make us committers on those modules.
But we still need to change James because of interface changes, so unless
Avalon is proposing rolling back those changes (which might be even more
work at this point), I'm not sure how it is a better idea than updating
James with Stephen's help.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Gump should have warned us before, but it has not been working
> for too much time. We have to fix it. Sam is helping everybody
> to get back to making Gump build everything
Sam is working hard, but one problem is that if GUMP can't successfully
build a dependency, then it can hardly report when that dependency changes
in such manner that when it finally builds it will break dependents.
One should support contracts for as long as possible, even if just for
binary compatibility. Consider this example from the Servlet API: "In this
version, this method always returns null and remains only to preserve binary
compatibility. This method will be permanently removed in a future version
of the Java Servlet API.". Does this mean that one can never remove them?
No, but there are ways to do it that are more graceful.
If I understand correctly, GUMP supports branchs and tags. Before making
incompatible interface changes, the relevant Avalon CVS modules could have
been branched so that (a) GUMP could be told to build clients against a
particular branch, and (b) the module could patched if/when necessary to fix
a defect without requiring clients to adopt the new interfaces. In other
words, if one is going to change a contract don't do so linearly. I also
suggest that such changes only occur on major release boundaries.
> I have a better idea. We are floating the possibility of opening our
> Component repository to the projects that are using Avalon, and that
> would include James. Would that be a deal?
I just starting looking at your proposal. It sounds as if it basically
would make Committers from Avalon-using projects Committers on the
components part of the Avalon landscape, and allow us to commit fixes to
Avalon components, e.g., Excalibur and Cornerstone. Of course, you could do
that simply make us committers on those modules.
But we still need to change James because of interface changes, so unless
Avalon is proposing rolling back those changes (which might be even more
work at this point), I'm not sure how it is a better idea than updating
James with Stephen's help.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Noel J. Bergman wrote:
> Stephen,
>
> [Responding to all of your various notes here]
[...]
> 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.
Noel, I knew this from the beginning and support James 100% in this
move. There is IMNSHO no other sensible thing that James could have done
ATM.
My apologies for the problems Avalon has given James. Gump should have
warned us before, but it has not been working for too much time. We have
to fix it. Sam is helping everybody to get back to making Gump build
everything, and I've done it for POI using Centipede, for Centipede
itself (geez, it really helped when Ant moved stuff to the main branch
:-) and now giving a small hand for Cocoon.
> 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.
I have a better idea. We are floating the possibility of opening our
Component repository to the projects that are using Avalon, and that
would include James. Would that be a deal?
> And we can let GUMP warn us if someone changes interfaces again.
+100
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Stephen McConnell <mc...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> 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.
Actually, Noel's last email raises a bigger question for me... what Avalon
**release** are we proposing upgrading to? I would be *much* more
relunctant if the proposal is just to upgrade to Avalon's HEAD. What we're
running with now was HEAD at one point, and then things start changing and
we're told we have an unsupported version.
If Avalon has a release we want to upgrade to, that sounds great. But just
upgrading to their HEAD sounds like trouble in river city to me.
Serge Knystautas
Loki Technologes
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Steve,
>
>
>
>>>Actually, Noel's last email raises a bigger question for me...
>>>what Avalon **release** are we proposing upgrading to? I would
>>>be *much* more relunctant if the proposal is just to upgrade to
>>>Avalon's HEAD. What we're running with now was HEAD at one
>>>point, and then things start changing and we're told we have an
>>>unsupported version.
>>>
>>>If Avalon has a release we want to upgrade to, that sounds great.
>>>But just upgrading to their HEAD sounds like trouble in river
>>>city to me.
>>>
>>>
>>A combination of both.
>> 1. build against specific version of jars with crear version
>> dependencies and release status
>> 2. gump validation against the CVS HEAD
>>
>>
>Serge's point is really valid though. THIS time we have to get release
>jars, with all of what that entails (including tagging the CVS). As you've
>noticed, you can't even backup to what we have without guessing about some
>old beta version of cornerstone.
>
>Yes, GUMP will build us against the Avalon CVS HEAD, but that's just an
>Early Warning System to get us running over to avalon-dev@ to see WTF is
>going on.
>
>Is the Avalon PMC able to define a coordinated Release of all the A4 modules
>such that we know that they all work together?
>
>
Well you have one PMC member who is very keen to see (a) a checklist
fulfilment that precoditions any release, and (b) a product sheet
detailing the products in Avalon and asociated status. However - one
isn't sufficient - lets raise this on the avalon list and see if we can
get that checklist into place. I've already started the process of
digging into the thread, poll, threadcontext and conerstone thread
packages which will al least facilitate a kick-off a product list.
I'm CC'ing to Avalon Dev and Avalon PMC so we can get more feedback on
this suggestion.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>Steve,
>
>
>
>>>Actually, Noel's last email raises a bigger question for me...
>>>what Avalon **release** are we proposing upgrading to? I would
>>>be *much* more relunctant if the proposal is just to upgrade to
>>>Avalon's HEAD. What we're running with now was HEAD at one
>>>point, and then things start changing and we're told we have an
>>>unsupported version.
>>>
>>>If Avalon has a release we want to upgrade to, that sounds great.
>>>But just upgrading to their HEAD sounds like trouble in river
>>>city to me.
>>>
>>>
>>A combination of both.
>> 1. build against specific version of jars with crear version
>> dependencies and release status
>> 2. gump validation against the CVS HEAD
>>
>>
>Serge's point is really valid though. THIS time we have to get release
>jars, with all of what that entails (including tagging the CVS). As you've
>noticed, you can't even backup to what we have without guessing about some
>old beta version of cornerstone.
>
>Yes, GUMP will build us against the Avalon CVS HEAD, but that's just an
>Early Warning System to get us running over to avalon-dev@ to see WTF is
>going on.
>
>Is the Avalon PMC able to define a coordinated Release of all the A4 modules
>such that we know that they all work together?
>
>
Well you have one PMC member who is very keen to see (a) a checklist
fulfilment that precoditions any release, and (b) a product sheet
detailing the products in Avalon and asociated status. However - one
isn't sufficient - lets raise this on the avalon list and see if we can
get that checklist into place. I've already started the process of
digging into the thread, poll, threadcontext and conerstone thread
packages which will al least facilitate a kick-off a product list.
I'm CC'ing to Avalon Dev and Avalon PMC so we can get more feedback on
this suggestion.
Cheers, Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
Steve,
> > Actually, Noel's last email raises a bigger question for me... what
Avalon
> > **release** are we proposing upgrading to? I would be *much* more
> > relunctant if the proposal is just to upgrade to Avalon's HEAD. What
we're
> > running with now was HEAD at one point, and then things start changing
and
> > we're told we have an unsupported version.
>
> > If Avalon has a release we want to upgrade to, that sounds great. But
just
> > upgrading to their HEAD sounds like trouble in river city to me.
> A combination of both.
> 1. build against specific version of jars with crear version
> dependencies and release status
> 2. gump validation against the CVS HEAD
Serge's point is really valid though. THIS time we have to get release
jars, with all of what that entails (including tagging the CVS). As you've
noticed, you can't even backup to what we have without guessing about some
old beta version of cornerstone.
Yes, GUMP will build us against the Avalon CVS HEAD, but that's just an
Early Warning System to get us running over to avalon-dev@ to see WTF is
going on.
Is the Avalon PMC able to define a coordinated Release of all the A4 modules
such that we know that they all work together?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Stephen McConnell <mc...@apache.org>.
Serge Knystautas wrote:
>----- Original Message -----
>From: "Noel J. Bergman" <no...@devtech.com>
>
>
>
>
>>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.
>>
>>
>
>Actually, Noel's last email raises a bigger question for me... what Avalon
>**release** are we proposing upgrading to? I would be *much* more
>relunctant if the proposal is just to upgrade to Avalon's HEAD. What we're
>running with now was HEAD at one point, and then things start changing and
>we're told we have an unsupported version.
>
>If Avalon has a release we want to upgrade to, that sounds great. But just
>upgrading to their HEAD sounds like trouble in river city to me.
>
A combination of both.
1. build against specific version of jars with crear version
dependencies and release status
2. gump validation against the CVS HEAD
Cheers, Steve.
>
>Serge Knystautas
>Loki Technologes
>http://www.lokitech.com/
>
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
>
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
> 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.
Actually, Noel's last email raises a bigger question for me... what Avalon
**release** are we proposing upgrading to? I would be *much* more
relunctant if the proposal is just to upgrade to Avalon's HEAD. What we're
running with now was HEAD at one point, and then things start changing and
we're told we have an unsupported version.
If Avalon has a release we want to upgrade to, that sounds great. But just
upgrading to their HEAD sounds like trouble in river city to me.
Serge Knystautas
Loki Technologes
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Stephen McConnell <mc...@apache.org>.
Peter Donald wrote:
>Noel,
>
>I know of only one backward incompatible change made that effects James. It
>was made to AbstractHandlerFactory to make it Serviceable rather than
>Composable. You need all of three line change to fix it up.
>
>
And the rest!
Retraction of Block instead of replacing Block with Component ?
Does that have a impact on interface compatibility ?
If you look at a component contract in terms of the services it provides
- then yes - Cornerstone is relatively stable - problems occur when
container side code uses this stuff. You cannot assume that there is
one and one container that hides the problems (such as Block proxy
generation, etc.) because anyone coding against the implementations in
Cornerstone are dealing with objects implementing Composable and the
underlying type changes to Serviceable, or a ComponentManager instance
gets passed as a parent to a new ComponentManager - all of these
situations break as result of the changes that were applied.
This is more then a three-line exercise!
Steve.
--
Stephen J. McConnell
mailto:mcconnell@apache.org
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by Paul Hammant <pa...@yahoo.com>.
Noel buddy,
> > This has been revisited numerous times now. What will happen is Uber.
> > Merlin does not have to emulate phoenix. That it was possible is for
> > history only.
>
> Paul, I am not trying to raise old issues. Stephen is trying, RIGHT NOW, to
> have James running with containers other than Phoenix. The James project
> currently considers it desirable that we be able to support such efforts.
> Now it may be the case that this isn't reasonable until A5 is ready, but if
> Stephen wants to make changes in Fortress/Merlin, why would I find that an
> issue? All I asked is what Stephen would have to do. You seem to be saying
> that *if* Stephen wants to support James, then he has to emulate Phoenix. I
> presume that you refer to specific areas, not the entirety. :-)
No I am saying that he could have emulated Phoenix. It would have been a doddle.
could <> has to
- Paul
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > So any application that uses Cornerstone is, by that definition, not
> > intended to be portable? If Stephen wants Cornerstone users to work
with
> > Fortress/Merlin, then he needs to do what, in your view, to obtain such
> > portability?
> This has been revisited numerous times now. What will happen is Uber.
> Merlin does not have to emulate phoenix. That it was possible is for
> history only.
Paul, I am not trying to raise old issues. Stephen is trying, RIGHT NOW, to
have James running with containers other than Phoenix. The James project
currently considers it desirable that we be able to support such efforts.
Now it may be the case that this isn't reasonable until A5 is ready, but if
Stephen wants to make changes in Fortress/Merlin, why would I find that an
issue? All I asked is what Stephen would have to do. You seem to be saying
that *if* Stephen wants to support James, then he has to emulate Phoenix. I
presume that you refer to specific areas, not the entirety. :-)
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by Paul Hammant <pa...@yahoo.com>.
> > Cornerstone is defined as "Set of default services for Avalon/Phoenix"
> > Every container has perculiarities but phoenix specific ones are meant to
> > go into cornerstone.
>
> So any application that uses Cornerstone is, by that definition, not
> intended to be portable? If Stephen wants Cornerstone users to work with
> Fortress/Merlin, then he needs to do what, in your view, to obtain such
> portability?
This has been revisited numerous times now. What will happen is Uber. Merlin does not have to
emulate phoenix. That it was possible is for history only.
-ph
__________________________________________________
Do You Yahoo!?
Everything you'll ever need on one web page
from News and Sport to Email and Music Charts
http://uk.my.yahoo.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
> > And we did move the file repository code into our project. But we do
still
> > have references to org.apache.avalon.cornerstone.services.store.Store.
Did
> > you want us to take the entire store service out of Cornerstone?
> that would be great as the code sucks.
Is there anything else we should take over, in your view?
> > Well, isn't Phoenix was an implementation of Avalon,
> > not the definition of it?
> Cornerstone is defined as "Set of default services for Avalon/Phoenix"
> Every container has perculiarities but phoenix specific ones are meant to
go
> into cornerstone.
So any application that uses Cornerstone is, by that definition, not
intended to be portable? If Stephen wants Cornerstone users to work with
Fortress/Merlin, then he needs to do what, in your view, to obtain such
portability?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 12 Jan 2003 14:03, Noel J. Bergman wrote:
> And we did move the file repository code into our project. But we do still
> have references to org.apache.avalon.cornerstone.services.store.Store. Did
> you want us to take the entire store service out of Cornerstone?
that would be great as the code sucks.
> Well, isn't Phoenix was an implementation of Avalon, not the definition of
> it?
Cornerstone is defined as "Set of default services for Avalon/Phoenix"
Every container has perculiarities but phoenix specific ones are meant to go
into cornerstone.
--
Cheers,
Peter Donald
*------------------------------------------------------*
| "The whole problem with the world is that fools and |
| fanatics are always so certain of themselves, but |
| wiser people so full of doubts." - Bertrand Russell |
*------------------------------------------------------*
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
> The AbstractHandlerFactory is cause of one of those problems. The
> others are related to Store going to be Serviceable.
IOW, it isn't one thing, which is all I said.
> As I said before you have to be mad to use any of that because it is a
flawed
> design. I could have sworn I have told james committers time and time
again
> to move it to their own repo to fix this.
And we did move the file repository code into our project. But we do still
have references to org.apache.avalon.cornerstone.services.store.Store. Did
you want us to take the entire store service out of Cornerstone?
> > Plus, Stephen has reported other problems, although
> > perhaps those are because he's using a container
> > other than Phoenix.
> precisely.
Well, isn't Phoenix was an implementation of Avalon, not the definition of
it?
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Peter Donald <pe...@realityforge.org>.
On Sun, 12 Jan 2003 11:28, Noel J. Bergman wrote:
> http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apach
>e .org&msgNo=6625. Those compile errors are all unrelated to
> AbstractHandlerFactory.
look closer. The AbstractHandlerFactory is cause of one of those problems. The
others are related to Store going to be Serviceable. The other changes were
made for Steve Short for James and while he was not officially a James
committer he gave a heads up and resolution to James days after the change
occured.
As I said before you have to be mad to use any of that because it is a flawed
design. I could have sworn I have told james committers time and time again
to move it to their own repo to fix this.
> Plus, Stephen has reported other problems,
> although perhaps those are because he's using a container other than
> Phoenix.
precisely.
--
Cheers,
Peter Donald
--------------------------------------------
Beer is proof that God loves us and wants
us to be happy. -- Benjamin Franklin
--------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I know of only one backward incompatible change made that effects James.
It
> was made to AbstractHandlerFactory to make it Serviceable rather than
> Composable. You need all of three line change to fix it up.
See:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache
.org&msgNo=6625. Those compile errors are all unrelated to
AbstractHandlerFactory. Plus, Stephen has reported other problems, although
perhaps those are because he's using a container other than Phoenix.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I know of only one backward incompatible change made that effects James.
It
> was made to AbstractHandlerFactory to make it Serviceable rather than
> Composable. You need all of three line change to fix it up.
See:
http://nagoya.apache.org/eyebrowse/ReadMsg?listName=james-dev@jakarta.apache
.org&msgNo=6625. Those compile errors are all unrelated to
AbstractHandlerFactory. Plus, Stephen has reported other problems, although
perhaps those are because he's using a container other than Phoenix.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Peter Donald <pe...@realityforge.org>.
Noel,
I know of only one backward incompatible change made that effects James. It
was made to AbstractHandlerFactory to make it Serviceable rather than
Composable. You need all of three line change to fix it up.
--
Cheers,
Peter Donald
--------------------------------------------------
The fact that nobody understands you doesn't
mean you're an artist.
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Stephen McConnell <mc...@apache.org>.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Synchronizing James and Cornerstone
Posted by Peter Donald <pe...@realityforge.org>.
Noel,
I know of only one backward incompatible change made that effects James. It
was made to AbstractHandlerFactory to make it Serviceable rather than
Composable. You need all of three line change to fix it up.
--
Cheers,
Peter Donald
--------------------------------------------------
The fact that nobody understands you doesn't
mean you're an artist.
--------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
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.
> 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.
> 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'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?
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.
> - 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?
> 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.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Synchronizing James and Cornerstone
Posted by "Noel J. Bergman" <no...@devtech.com>.
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.
> 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.
> 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'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?
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.
> - 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?
> 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.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>