You are viewing a plain text version of this content. The canonical link for it is here.
Posted to server-dev@james.apache.org by Stephen McConnell <mc...@apache.org> on 2003/01/22 12:17:08 UTC
Excalibur/Cornerstone/James woes
Guys:
It looks like my earlier note concerning success with James was
premature. I'm back experiencing an loop inside James mail processing
and have not been able to isolate the problem.
Relevant points:
1. build of James, Cornerstone and Excalibur related resources
are all from current CVS
2. James sources have been updated locally to support the service
package (to sync with Cornerstone changes)
Some important notes:
1. james extends several Cornerstone classes based on Cornerstone
implementations from back in June and I suspect that there may
be a runtime disconnect here somewhere
2. problem occurs when running under Phoenix or Merlin so I think
we can rule out containers as the issue
I've put up a log with full debug level on at the following URL:
http://www.osm.net/technical/james/james-log.txt
Comments added to the log file are prefixed by ##.
In order to resolve this problem I would like to import the modified
James sources into avalon-sandbox to enable James and Avalon people to
dig into this.
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: Excalibur/Cornerstone/James woes
Posted by Peter Donald <pe...@realityforge.org>.
On Wed, 22 Jan 2003 22:17, Stephen McConnell wrote:
> In order to resolve this problem I would like to import the modified
> James sources into avalon-sandbox to enable James and Avalon people to
> dig into this.
Please dont.
--
Cheers,
Peter Donald
-----------------------------------------------
"You can't depend on your eyes when your
imagination is out of focus." -Mark Twain
-----------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Stephen is proposing a CVS repository of James and Avalon in Avalon Sandbox.
This would be based on current CVS code and would be temporary.
- If it is based on current CVS, shouldn't it be ongoing rather than
temporary ? I would expect a temporary integration codebase for well defined
releases not current CVS.
- It would be better to to only sync up on well defined releases rather than
current CVS. Stephen do you have a release candidate of
Excalibur/Cornerstone that you want to synch up with James. Or is the desire
to be always in Synch within development trees. James is a user of Phonix
and as long as there is a stable version of Phoenix for James all is good.
Not sure why James needs to tie in into current CVS of
Excalibur/Cornerstone.
It seems heavy to sync up on development trees via a temporary CVS
repository but if Stephen wants to do it, no harm there.
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "Avalon Developers List" <av...@jakarta.apache.org>; "James
Developers List" <ja...@jakarta.apache.org>
Sent: Wednesday, January 22, 2003 10:32 PM
Subject: RE: Excalibur/Cornerstone/James woes
> > Stephen, are you planning to sync with a release version of
> > Excalibur/Cornerstone or with a development snapshot ?
>
> Harmeet, are you having trouble keeping up with james-dev? Stephen,
Serge,
> Nico, and I have discussed this issue in depth and in multiple message
> threads.
>
> Stephen is one of the Avalon developers and PMC members. He is working to
> prepare a formal set of Avalon Release builds.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Serge Knystautas <se...@lokitech.com>.
Serge Knystautas wrote:
> Codebases change all the time, and I have to believe the Avalon
> committers did what they felt was a right by moving to a different
> naming/design pattern. But with software engineering, you need software
> development practices to support it.
By the way, I'm not saying James does this perfect either, and this is
something we should keep very much in mind when we release 3.0.
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James clarification
Posted by Stephen McConnell <mc...@apache.org>.
Serge Knystautas wrote:
> Stephen McConnell wrote:
>
>> There are two scenarios I think you should be considering:
>>
>> 1. a James releasse scenario - this is where you referencing
>> relased jars
>> 2. a James build that is based on the current CVS of Avalon based
>> on Gump
>
>
> I agree with 1, but not with 2.
>
> I don't think it does James any good to treat the Avalon jar
> dependencies any different than we would other libraries. I also
> don't think it does Avalon any good in the long term.
Some clarification:
Scenario (1) is getting James into shape so that it is
built and distributed based on released jar files from
wherever. This is not the case today. James is currently
using an unsupported build of cornerstone. James will
also needs to upgrade at some point to the new thread jar
from excalibur (that includes the fixes concerning pool
sizes). This upgrade impacts Phoenix as well because
James is currently bound to Phoneix at the level of the
code. All of the above is managable stuff that is reflected
in the James repository via addition of released jars in
lib directories, etc. Key actions that both James and
Avalon people need to be concerned about is:
* migration to a release for the cornerstone 1.0 components
* migration to the updated thread 1.1
* migration to a Phoenix release backed with thrread 1.1
Scenario (2) is about collaborating sufficiently so that
release candidates (like the current cornerstone-xxx-1.0 jars
and the excalibur-thread-1.1 jar) can be validated. The best
approach to this is to establish a Gump based build procedure
that is a seperate process that builds James against all of
the current Apache repositories. This has been in place for
ages and has been failing for ages. Things I'm doing are in
part address this disconnect.
Some misconceptions:
Nobody is suggesting that James move from well defined releases
to HEAD depedencies. Gump is an early warning system that will
help to keep the James community aware of changes that may
impact them across the entire Apache community. I am suggesting
that James/Cornerstone dependency get sorted - because the setup
in James today with respect to cornerstone is far from
satisfactory.
Hope that clarifies things.
Something else to keep in mind is that I'm moving close to a point
where I will be introducing James depedencies into code I'm working
on. Having James in Gump (working) provides me with a lot more
assurance about things - if something fails - then I've got info
about the source (where the source could be James or could be a
dependency that James has on some other Apache project).
>
> I know it's not ideal, but for me the big API change that happened in
> the Avalon project (Component -> Service I think it was) is not that
> big of a deal. What made it a big deal is that there was not much of
> a clear release beforehand, I don't think any release (yet) after the
> fact, and I haven't heard of a changelog or HOWTO to help users make
> this change.
>
> Codebases change all the time, and I have to believe the Avalon
> committers did what they felt was a right by moving to a different
> naming/design pattern. But with software engineering, you need
> software development practices to support it.
>
> As an example with another open source project, we use Netsaint for
> monitoring. This was basically disolved, and the authors went and
> refactored the codebase into Nagios. I don't mind that Netsaint isn't
> supported or that my large conf file needs to be completely
> rewritten... because there is explanation of what happened, clear
> releases so I can stay with Netsaint until we have the time to
> migrate, and I've heard rumor there is a conversion tool out there to
> help you migrate your conf file. These practices allow me to handle
> the change, and this is better than having Nagios people who are very
> willing to help because in the end, I know my code/system best and
> need to understand how to apply it.
>
> These software development practices allow the software engineering to
> happen with less restrictions. For the Avalon community, having James
> build against Avalon and have Avalon committers help James with that
> is a misdirection of resources (IMHO). You will get James working on
> it, but at the expense of other activities that can slow adoption of
> the codebase (which ultimately James needs to see happen as well).
I disagree with the "slowing adoption" argument. Getting James in sync
with avalon releases will accellerate adoption.
>
>
> So, I think Avalon should be treated just like other dependencies...
> people can propose updates, the community reviews it, and then if
> approved, the update happens.
>
Sounds good and I agree in principal.
BUT.
1. James needs to dump cornerstone.jar
2. A set of candidate releases of corerstone components have been
prepared that incorporate bug fixes raised here.
3. To move from a unreleased and unmaintained corerstone jar to
the candidate release means tranition from CM to SM (details
on this already supplied).
4. Both Pete and I have done the transition (not a big deal)
5. My testcase is showing problems and I havn't been able to
figure out if this is a James, Cornerstone, Excalibur issue.
6. Apparently there are problems in James HEAD that could be
contributing to this.
7. I would like to validate Cornerstone and Excalibur candidate
released against James BEFORE proposing these packages for
Avalon release.
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: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>My concern is that we end up relying on this compilation check *at the
>>expense of other support*.
>>
>>
>
>Serge, this ties in with something I've been wondering about, which would be
>whether Sam could add JUnit type testing to GUMP.
>
This can be achieved by declaring the ant target in the gump project
that includes a JUnit test. I.e. it's an quation of availablity of
Junity tests withi individual projects. This does assume that test
targets are depedent on the general build target.
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: Excalibur/Cornerstone/James woes
Posted by "Noel J. Bergman" <no...@devtech.com>.
> My concern is that we end up relying on this compilation check *at the
> expense of other support*.
Serge, this ties in with something I've been wondering about, which would be
whether Sam could add JUnit type testing to GUMP.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Serge Knystautas <se...@lokitech.com>.
----- Original Message -----
From: "Stephen McConnell" <mc...@apache.org>
> No. I'm not suggesting *using* unrelease code.
> #2 is getting the Gump descriptor for James sorted - that does not
> effect you day to day work.
Right, I understand your intention. I think I see that you're treating Gump
as a step towards having that better Avalon release process, so that sounds
good.
My concern is that we end up relying on this compilation check *at the
expense of other support*. As an example, the (very frustrating) file
repository change that started numbering instances, which didn't change the
API and would not have been caught with Gump. I'm looking to Avalon to
build a better release process so more changes could be clear to James. I'm
also slightly concerned that Gump would give James or Avalon developers
false confidence to start making changes that could have unintentended
consequences or use code that in the end wasn't going to get released.
> I would really like to sucessfully validate the candidates against James
> before proposing releases.
Ok.
> I've updated corenerstone so that each component that James is depedent
> on has its own build procedure and release version. This means that (a)
> your not carrying around code for components you are not using, (b) your
> migrating to something that is supported, and (c) furture evolution of
> components can be managed properly.
Ok. I really appreciate your changes as it would be great to get on an
Avalon release, and if an early warning system can help you support Avalon
and make it easier to propose upgrades for James, then that's great. I'd
rather not be one of those people getting the early warning messages though
if possible. :)
Anyway, I think we're both heading in the same direction... we want James on
an Avalon release (and cleaner code and more avalon adoption). Seems like
most of our chat was how we would prioritize achieving those differently,
but they're pretty close in the end.
Again, much appreciated.
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Serge Knystautas wrote:
> Stephen McConnell wrote:
>
>> Danny Angus wrote:
>>
>>>>> 1. a James releasse scenario - this is where you referencing
>>>>
>>>> relased jars
>>>>
>>>>> 2. a James build that is based on the current CVS of Avalon
>>>>
>>>> based on Gump
>>>>
>>>> I agree with 1, but not with 2.
>>>>
>>>> I don't think it does James any good to treat the Avalon jar
>>>> dependencies any different than we would other libraries. I also
>>>> don't think it does Avalon any good in the long term.
>>>
>>>
>>> I agree with Serge, despite our close relationship with avalon I
>>> think we *must* work with released software only,
>>
>>
>> But your not - your build against and distributing against an
>> unrelease cornerstone package.
>
>
> Well yes, and I think this is again why we don't want (and would like
> to no longer be) doing #2, i.e., building against what's in CVS...
> because we end up using unreleased code and are otherwise not supported.
No. I'm not suggesting *using* unrelease code.
#2 is getting the Gump descriptor for James sorted - that does not
effect you day to day work.
>
> So now it's a question of getting Avalon to make a published release,
> and then get a proposal from someone to do the upgrade... and as you
> imply, since we're not building against a release, I don't think you'd
> get much disagreement (and I hope we've been supportive of your
> preparatory work to have that happen).
I would really like to sucessfully validate the candidates against James
before proposing releases.
>
>
> If there is cornerstone code we need that isn't getting released, we
> can absorb that code into the James package so that we can determine
> it releasable, and then if Avalon does release it, we can review
> handing over responsibility for that functionality back to them.
I've updated corenerstone so that each component that James is depedent
on has its own build procedure and release version. This means that (a)
your not carrying around code for components you are not using, (b) your
migrating to something that is supported, and (c) furture evolution of
components can be managed properly.
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: Excalibur/Cornerstone/James woes
Posted by Serge Knystautas <se...@lokitech.com>.
Stephen McConnell wrote:
> Danny Angus wrote:
>>>> 1. a James releasse scenario - this is where you referencing
>>> relased jars
>>>> 2. a James build that is based on the current CVS of Avalon
>>> based on Gump
>>>
>>> I agree with 1, but not with 2.
>>>
>>> I don't think it does James any good to treat the Avalon jar
>>> dependencies any different than we would other libraries. I also
>>> don't think it does Avalon any good in the long term.
>>
>> I agree with Serge, despite our close relationship with avalon I think
>> we *must* work with released software only,
>
> But your not - your build against and distributing against an unrelease
> cornerstone package.
Well yes, and I think this is again why we don't want (and would like to
no longer be) doing #2, i.e., building against what's in CVS... because
we end up using unreleased code and are otherwise not supported.
So now it's a question of getting Avalon to make a published release,
and then get a proposal from someone to do the upgrade... and as you
imply, since we're not building against a release, I don't think you'd
get much disagreement (and I hope we've been supportive of your
preparatory work to have that happen).
If there is cornerstone code we need that isn't getting released, we can
absorb that code into the James package so that we can determine it
releasable, and then if Avalon does release it, we can review handing
over responsibility for that functionality back to them.
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur/Cornerstone/James woes
Posted by Danny Angus <da...@apache.org>.
> But your not - your build against and distributing against an unrelease
> cornerstone package.
Ah. Hmm. :-)
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Danny Angus wrote:
>
>
>>> 1. a James releasse scenario - this is where you referencing
>>>
>>>
>>relased jars
>>
>>
>>> 2. a James build that is based on the current CVS of Avalon
>>>
>>>
>>based on Gump
>>
>>I agree with 1, but not with 2.
>>
>>I don't think it does James any good to treat the Avalon jar
>>dependencies any different than we would other libraries. I also don't
>>think it does Avalon any good in the long term.
>>
>>
>
>I agree with Serge, despite our close relationship with avalon I think we *must* work with released software only,
>
But your not - your build against and distributing against an unrelease
cornerstone package.
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: Excalibur/Cornerstone/James woes
Posted by Danny Angus <da...@apache.org>.
> > 1. a James releasse scenario - this is where you referencing
> relased jars
> > 2. a James build that is based on the current CVS of Avalon
> based on Gump
>
> I agree with 1, but not with 2.
>
> I don't think it does James any good to treat the Avalon jar
> dependencies any different than we would other libraries. I also don't
> think it does Avalon any good in the long term.
I agree with Serge, despite our close relationship with avalon I think we *must* work with released software only, working against cvs risks avalon issues blocking James releases. Of course that doesn't mean we can't or won't be aware of avalon progress, for instance I'd quite like to get the class path stuff Peter D. wrote into James, but not if that would mean James couldn't be released until avalon released, and I would very much rather not sanction a release containing un-released avalon code. In the meantime I'm rolling my own classpath configurations.
So my message is release often, I'd rather see a lot of small dependancies advancing in short steps, asynchronously, from stable state to stable state and with corresonding small deltas. That would make the job of upgrading James so much simpler.
> These software development practices allow the software engineering to
> happen with less restrictions. For the Avalon community, having James
> build against Avalon and have Avalon committers help James with that is
> a misdirection of resources (IMHO). You will get James working on it,
> but at the expense of other activities that can slow adoption of the
> codebase (which ultimately James needs to see happen as well).
I agree with this as well, I know it seems odd that Serge and I would rather not see everyone bend over backwards to make James work with avalon's latest, but I honestly believe that if avalon are pursuing stabilisation then that process, and the documentation it generates, will, and should be, be enough to help James catch up.
> So, I think Avalon should be treated just like other dependencies...
> people can propose updates, the community reviews it, and then if
> approved, the update happens.
Again, yes.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Serge Knystautas <se...@lokitech.com>.
Stephen McConnell wrote:
> There are two scenarios I think you should be considering:
>
> 1. a James releasse scenario - this is where you referencing relased jars
> 2. a James build that is based on the current CVS of Avalon based on Gump
I agree with 1, but not with 2.
I don't think it does James any good to treat the Avalon jar
dependencies any different than we would other libraries. I also don't
think it does Avalon any good in the long term.
I know it's not ideal, but for me the big API change that happened in
the Avalon project (Component -> Service I think it was) is not that big
of a deal. What made it a big deal is that there was not much of a
clear release beforehand, I don't think any release (yet) after the
fact, and I haven't heard of a changelog or HOWTO to help users make
this change.
Codebases change all the time, and I have to believe the Avalon
committers did what they felt was a right by moving to a different
naming/design pattern. But with software engineering, you need software
development practices to support it.
As an example with another open source project, we use Netsaint for
monitoring. This was basically disolved, and the authors went and
refactored the codebase into Nagios. I don't mind that Netsaint isn't
supported or that my large conf file needs to be completely rewritten...
because there is explanation of what happened, clear releases so I can
stay with Netsaint until we have the time to migrate, and I've heard
rumor there is a conversion tool out there to help you migrate your conf
file. These practices allow me to handle the change, and this is better
than having Nagios people who are very willing to help because in the
end, I know my code/system best and need to understand how to apply it.
These software development practices allow the software engineering to
happen with less restrictions. For the Avalon community, having James
build against Avalon and have Avalon committers help James with that is
a misdirection of resources (IMHO). You will get James working on it,
but at the expense of other activities that can slow adoption of the
codebase (which ultimately James needs to see happen as well).
So, I think Avalon should be treated just like other dependencies...
people can propose updates, the community reviews it, and then if
approved, the update happens.
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Stephen McConnell wrote:
>
>
> Nicola Ken Barozzi wrote:
>
>>
>> Thanks for the very detailed and insightful summary.
>> I understand your views and agree. Just one comment.
>>
>> Aaron Knauf wrote:
>>
>>> In fact, I believe that we should be very reluctant to change james
>>> to accomodate changes in avalon cvs unless it is clear that a stable
>>> avalon release containing those changes will be available before the
>>> next james release. As others have mentioned, be don't what to
>>> block james releases.
>>
>>
>>
>> Yes, I'm aware of this and it's fundamental. As you can see, Stephen
>> is working very hard to make it done sooner than later.
>>
>> I'd say that intent is quite clear on both sides. Let's resolve
>> things one by one as they come. I personally don't think that we
>> should copy James stuff in avalon-sandbox, and I'm sure that Stephen
>> could be given time-limited karma for changes he has to make.
>>
>> Stephen has modified code that can be patched on James. It seems he
>> really needs a hand in resolving problems, and want you all to try
>> the changes and see if you can help.
>>
>> This can be reasonably done by tagging current James and patching
>> HEAD, or making a branch and tagging that.
>>
>> [talking as an engineer] The best solution is to make a branch, and
>> give temporary karma to Stephen to be able to work on that branch. He
>> is free to change things, James committers can check changes, and
>> current James HEAD is not affected.
>>
>> Stephen, James guys, what do you think?
>>
>
> Works for me.
> In the meantime Pete Goldstein has been helping out with supplying a
> version of James he has transitioned from CM to SM and that's resolved
> the invinite loop problem (the principal difference here is that
> Pete's version is based on HEAD).
Woops - correction!
My version was based on HEAD
Peter version is NOT based on HEAD.
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: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Nicola Ken Barozzi wrote:
>
> Thanks for the very detailed and insightful summary.
> I understand your views and agree. Just one comment.
>
> Aaron Knauf wrote:
>
>> In fact, I believe that we should be very reluctant to change james
>> to accomodate changes in avalon cvs unless it is clear that a stable
>> avalon release containing those changes will be available before the
>> next james release. As others have mentioned, be don't what to block
>> james releases.
>
>
> Yes, I'm aware of this and it's fundamental. As you can see, Stephen
> is working very hard to make it done sooner than later.
>
> I'd say that intent is quite clear on both sides. Let's resolve things
> one by one as they come. I personally don't think that we should copy
> James stuff in avalon-sandbox, and I'm sure that Stephen could be
> given time-limited karma for changes he has to make.
>
> Stephen has modified code that can be patched on James. It seems he
> really needs a hand in resolving problems, and want you all to try the
> changes and see if you can help.
>
> This can be reasonably done by tagging current James and patching
> HEAD, or making a branch and tagging that.
>
> [talking as an engineer] The best solution is to make a branch, and
> give temporary karma to Stephen to be able to work on that branch. He
> is free to change things, James committers can check changes, and
> current James HEAD is not affected.
>
> Stephen, James guys, what do you think?
>
Works for me.
In the meantime Pete Goldstein has been helping out with supplying a
version of James he has transitioned from CM to SM and that's resolved
the invinite loop problem (the principal difference here is that Pete's
version is based on HEAD). So I have something up and running that
against the Cornerstone release candidate jars.
I don't have the test case working successfully yet - but I'm a lot
further ahead than I was a couple of hours ago.
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: [VOTE] Stephen McConnell temporary commit privilege
Posted by Danny Angus <da...@apache.org>.
IMO until he tells us his work is done or v3 whichever is sooner.
Of course his work *will* be done by v3 by definition, so its all a bit moot.
But I agree that we should have some indivisible cut off date.
d.
> -----Original Message-----
> From: Serge Knystautas [mailto:sergek@lokitech.com]
> Sent: 27 January 2003 18:05
> To: James Developers List
> Subject: Re: [VOTE] Stephen McConnell temporary commit privilege
>
>
> Danny Angus wrote:
> > I'd like to propose that we offer Stephen temporary commit
> access to James to let him apply his *very welcome* update to
> James to bring the HEAD up to date with Avalon.
> >
> > d.
>
> +1, although would like to have "temporary" defined... until a specified
> date (couple of weeks?, 3 months?), until a milestone is reached (ACR?,
> James 3.0?), or whatever.
>
> --
> Serge Knystautas
> Lokitech
> Software - Strategy - Design
> http://www.lokitech.com
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: [VOTE] Stephen McConnell temporary commit privilege
Posted by Serge Knystautas <se...@lokitech.com>.
Danny Angus wrote:
> I'd like to propose that we offer Stephen temporary commit access to James to let him apply his *very welcome* update to James to bring the HEAD up to date with Avalon.
>
> d.
+1, although would like to have "temporary" defined... until a specified
date (couple of weeks?, 3 months?), until a milestone is reached (ACR?,
James 3.0?), or whatever.
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: [VOTE] Stephen McConnell temporary commit privilege
Posted by "Noel J. Bergman" <no...@devtech.com>.
+1 to give Stephen commit access to James to help get up to date with
Avalon. I'd suggest that he have such rights at least for this current
update, and preferably until we are integrated with the actual ACR (Avalon
Coordinated Release).
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
[VOTE] Stephen McConnell temporary commit privilege
Posted by Danny Angus <da...@apache.org>.
I'd like to propose that we offer Stephen temporary commit access to James to let him apply his *very welcome* update to James to bring the HEAD up to date with Avalon.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Serge Knystautas <se...@lokitech.com>.
Stephen McConnell wrote:
> I now have two james builds locally on my machine:
>
> 1. James based on Peter's derivative of 2.1, CM/SM
> migration and Cornerstone candidates in place.
> This is working fine. Some problems were occuring
> in the test case but we finally narrowed this down
> to a bug in the test case (the test delete's the user
> before the spool completes its work, resulting in
> email in the spool that contain invalid reciipient
> addresses).
>
> 2. James based on HEAD + CM/SM migration + updates for
> Cornerstone candidates. This version is doing the
> 500 error on "" commands and getting itself into a
> loop. However, it's fully synced with the HEAD and
> can be committed.
>
> I suggest we go ahead and ties build (2) into head and sort of the
> loop/500 problem from there.
Sounds great... this loop bug is one I introduced in HEAD and mean to
sort out soon (was supposed to this weekend, but long story... it will
be fixed soon).
> There is also the question of migration of excalibur-xxx packages to
> commons-xxxx. This has been taken care of for the pool package
> (commons-collection). There may be a coupe of other packages that
> require transition. Also, excalibur-cli (used in Phoenix and a couple
> of Excalibur projects) can/should/could be replaced by commons-cli.
I would support migrating to commons libs as I'm more familiar with them
and I think commons does a good job with release management. Especially
if it means the Avalon community has less to worry about releasing in
the short-term.
Also, for DBCP we'll be bundling commons pool anyway, so one step there.
> i.e. Things are already looking comfortable - and within a few weeks we
> should be able to freeze the release targets and validate things across
> containers, applications and external projects followed by formal
> vote/release/publication.
Great!
> Yep - its in progress. Some of the updated in Excalibur are used
> extensively in Cocoon and some of guys on working on the Avalon/Cocoon
> front in much the same we as I'm trying to get James/Avalon in sync.
Sounds good.
--
Serge Knystautas
Lokitech
Software - Strategy - Design
http://www.lokitech.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>>[talking as an engineer] The best solution is to make a branch, and give
>>temporary karma to Stephen to be able to work on that branch.
>>
>>
>
>+1
>
>Since we are working on James v3, and not impacting the stable v2 branch,
>I'm fine with it. Plus, this is part of what is being done to produce the
>Avalon Coordinated Release build.
>
I now have two james builds locally on my machine:
1. James based on Peter's derivative of 2.1, CM/SM
migration and Cornerstone candidates in place.
This is working fine. Some problems were occuring
in the test case but we finally narrowed this down
to a bug in the test case (the test delete's the user
before the spool completes its work, resulting in
email in the spool that contain invalid reciipient
addresses).
2. James based on HEAD + CM/SM migration + updates for
Cornerstone candidates. This version is doing the
500 error on "" commands and getting itself into a
loop. However, it's fully synced with the HEAD and
can be committed.
I suggest we go ahead and ties build (2) into head and sort of the
loop/500 problem from there.
>
>Any idea how far off the ACR is at this point?
>
Avalon peeps have been busy getting a lot of little things up-to-date on
the Excalibur side - thing like version information, manifest and so on.
Also Gump status across the Excalibur suite is looking much better. The
cornerstone candidates need to be updated to create dist targets with
their doc etc. and respective gump entries. That will help get James
Gump running. The same story applied to Cocoon which is dependent on
some of the same Cornerstone component as James (but currently tied to
the entire Cornerstone project). There have been a couple of updates to
Excalibur that need to propergeted to applications like Phoenix and
Cocoon - in particular excalibur-thread-1.1, excalibur-pool-1.2, and
maybe a excalibur i18n-1.1. There are some recent framework related
wrapper classes that have been introduced but can/could/should be moved
out (more Avalon dev discussion needed). Aside from that - there is
formal release process required for excalibur-configuration,
excalibur-sourceresolver, and possible excalibur-xmlutil.
There is also the question of migration of excalibur-xxx packages to
commons-xxxx. This has been taken care of for the pool package
(commons-collection). There may be a coupe of other packages that
require transition. Also, excalibur-cli (used in Phoenix and a couple
of Excalibur projects) can/should/could be replaced by commons-cli.
i.e. Things are already looking comfortable - and within a few weeks we
should be able to freeze the release targets and validate things across
containers, applications and external projects followed by formal
vote/release/publication.
>I'm sure that you'll need to check with Cocoon, Jesktop, and
>other clients, as well as James.
>
>
Yep - its in progress. Some of the updated in Excalibur are used
extensively in Cocoon and some of guys on working on the Avalon/Cocoon
front in much the same we as I'm trying to get James/Avalon in sync.
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: Excalibur/Cornerstone/James woes
Posted by "Noel J. Bergman" <no...@devtech.com>.
> [talking as an engineer] The best solution is to make a branch, and give
> temporary karma to Stephen to be able to work on that branch.
+1
Since we are working on James v3, and not impacting the stable v2 branch,
I'm fine with it. Plus, this is part of what is being done to produce the
Avalon Coordinated Release build.
Any idea how far off the ACR is at this point? I'm sure that you'll need to
check with Cocoon, Jesktop, and other clients, as well as James.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Danny Angus wrote:
>>I'd say that intent is quite clear on both sides. Let's resolve things
>>one by one as they come. I personally don't think that we should copy
>>James stuff in avalon-sandbox, and I'm sure that Stephen could be given
>>time-limited karma for changes he has to make.
>
> Absolutely, we did the same for Paul H when he helped us with Phoenix.
> I would say that we need to hear on _this_ list, not everyone is actively following discussions on avalon-dev.
+1
>>Stephen has modified code that can be patched on James. It seems he
>>really needs a hand in resolving problems, and want you all to try the
>>changes and see if you can help.
>
>>This can be reasonably done by tagging current James and patching HEAD,
>>or making a branch and tagging that.
>
>
> the former is my prefrence, If the head was changing much, or fast, I'd agree with branching, but as its not I don't think a branch is necessary. Having Stephen break the head will also encourage us to help him fix it(!).
Yes, both are reasonable choices.
Branching would be more correct and "safe".
Patching head is more pragmatic and increases involvement.
Any of the two are fine. Noel, can you please sum up the thread and get
a resolution so that Steven can start?
Thanks :-)
PS: I'm still using James in my company and I *love* it. Is it that it
has matchers and stuff like cocoon that makes it so sexy to my eyes? ;-)
--
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: Excalibur/Cornerstone/James woes
Posted by Danny Angus <da...@apache.org>.
> I'd say that intent is quite clear on both sides. Let's resolve things
> one by one as they come. I personally don't think that we should copy
> James stuff in avalon-sandbox, and I'm sure that Stephen could be given
> time-limited karma for changes he has to make.
Absolutely, we did the same for Paul H when he helped us with Phoenix.
I would say that we need to hear on _this_ list, not everyone is actively following discussions on avalon-dev.
>
> Stephen has modified code that can be patched on James. It seems he
> really needs a hand in resolving problems, and want you all to try the
> changes and see if you can help.
> This can be reasonably done by tagging current James and patching HEAD,
> or making a branch and tagging that.
the former is my prefrence, If the head was changing much, or fast, I'd agree with branching, but as its not I don't think a branch is necessary. Having Stephen break the head will also encourage us to help him fix it(!).
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Thanks for the very detailed and insightful summary.
I understand your views and agree. Just one comment.
Aaron Knauf wrote:
> In fact, I believe that we should be very reluctant to change james to
> accomodate changes in avalon cvs unless it is clear that a stable avalon
> release containing those changes will be available before the next james
> release. As others have mentioned, be don't what to block james releases.
Yes, I'm aware of this and it's fundamental. As you can see, Stephen is
working very hard to make it done sooner than later.
I'd say that intent is quite clear on both sides. Let's resolve things
one by one as they come. I personally don't think that we should copy
James stuff in avalon-sandbox, and I'm sure that Stephen could be given
time-limited karma for changes he has to make.
Stephen has modified code that can be patched on James. It seems he
really needs a hand in resolving problems, and want you all to try the
changes and see if you can help.
This can be reasonably done by tagging current James and patching HEAD,
or making a branch and tagging that.
[talking as an engineer] The best solution is to make a branch, and give
temporary karma to Stephen to be able to work on that branch. He is free
to change things, James committers can check changes, and current James
HEAD is not affected.
Stephen, James guys, what do you think?
--
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: Excalibur/Cornerstone/James woes
Posted by Aaron Knauf <ak...@xtra.co.nz>.
I have read and understood all of the previous posts in this thread.
This whole conversation is only useful if we are agreed that we want to
stay with avalon. If we don't, then someone need to say so before we
waste any more time.
Assuming avalon stays, I can sum up my view by saying that my opinion
remains pretty much unchanged from my previous post.
I have been stuck in various ruts before, where it was "too hard" to
upgrade from a particular item of substandard software to a newer
version. This has invariably been self inflicted (possibly for valid
reasons). The james situation is the same.
We all agree that we do not want to release james with dependencies on
HEAD revisions of anything. I'll go one further and say that we don't
wnat to depend on an unsupported version of anything. (Not unless we are
willing to take over maintenance of it ourselves, which means importing
the source into our own repository.)
HEAD == unreproducible == unmaintainable == unsupportable == unprofessional.
I think we all agree that frequent stable releases of Avalon are
required in order to make this work.
We all agree that gump is a good early warning system for detecting
incompatibilities introduced between projects.
I think that there seems to be a misconception that a failed gump report
requires an immediate fix. This is not the case. A failed gump report
requires a decision to be made over the appropriate action necessary to
resolve the problem. This may result in a discussion with the Avalon
folks about making their change backward compatible, rather than an
update of james. I expect that it would often result in a decision to
make a note in a todo list for when the avalon change actually gets
released.
In fact, I believe that we should be very reluctant to change james to
accomodate changes in avalon cvs unless it is clear that a stable avalon
release containing those changes will be available before the next james
release. As others have mentioned, be don't what to block james releases.
I agree with Serge that the necessary updates to james should be made by
the james community. I also agree with Danny that we don't want to all
become avalon developers just to get james up to date.
In order to get james up to date initially, I still think that a branch
would be useful. Sure, we will need to merge back into head when done.
This can be made easier by merging head into the branch at frequent
intervals. The reason for the branch is simply so that the avalon
upgrade does not hinder current james development. Without the branch,
you can either do it in head, or have just one developer do the whole lot.
Finally, I really don't think forking james over into the avalon
repository is a good idea, because you just end up with an orphan that
will be even harder to merge back in to james head. (Waste of time.)
ADK
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur/Cornerstone/James woes
Posted by "Noel J. Bergman" <no...@devtech.com>.
> I think that JAMES should make a habit of upgrading to every new stable
> avalon release.
The lack of a stable Avalon Release is part of the problem that the Avalon
Community is working to resolve.
GUMP can build against a CVS tag (as well as HEAD to provide early warning
of problematic changes), but apparently the version of Avalon we were given
for James isn't even tagged, much less released. That is part of what we're
trying to avoid for the future.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur/Cornerstone/James woes
Posted by "Noel J. Bergman" <no...@devtech.com>.
Danny,
> But to buy into [continuous integration] for James
> I'd have to have confidence that changes which are
> made to support avalon head changes, and which break
> james for avalon stable packages, will make it into
> stable avalon packages in reasonable time for us to
> release the james head more or less when we want to.
I don't believe that there is any question that the Avalon project has had
some release issues, but they got a major wakeup call in November, and I
think that things are changing. The first major test for them, in some
ways, is going to be the ACR, which will mark a major shift from the
piecemeal mindset to one that understands that there actually is something
called Avalon, not just a loose confederation of code tied by the
Frameworks.
Nicola is proposing that if there are changes made to Avalon that break
James, that we ought to be able to run over to avalon-dev and have a say on
those changes. We do get a GUMP report, when GUMP is able build the
predicates.
I also think that the Avalon project needs to be extremely careful because
of the delayed feedback that errorneous changes will engender. They may
have to push the use of JUnit for their components in the future because
otherwise they don't really have good code coverage, or even good
application feedback until Avalon breaks some client code down the line.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur/Cornerstone/James woes
Posted by Danny Angus <da...@apache.org>.
Nicola,
I totally buy Gump's raison-d'etre, In fact I champion domain engineering and continuous integration at work, and see how continuous integration benefits us.
But to buy into it for James I'd have to have confidence that changes which are made to support avalon head changes, and which break james for avalon stable packages, will make it into stable avalon packages in reasonable time for us to release the james head more or less when we want to.
d.
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> Sent: 24 January 2003 12:52
> To: James Developers List
> Subject: Re: Excalibur/Cornerstone/James woes
>
>
>
>
> Aaron Knauf wrote:
> > Yeah, it doesn't help that the Avalon APIs aren't yet stable.
>
> Which APIs? :-?
>
> The Framework has been stable for a long time.
>
> > This is a
> > sign of the current lack of maturity in the Avalon codebase. When you
> > base your application on such a raw framework, you buy into
> this kind of
> > trouble. It seems to me, however, that the Avalon guys might
> be willing
> > to work on stabilizing their interfaces. They are going to find it
> > tough going trying to stabilize without close support and feedback from
> > their user community, though. (That's us!)
>
> We are consolidating out *implementations*, not our APIs. And yes, we
> would be happy to have close help from you, and that's the reason why we
> are defining concrete ways in which the James community can have real
> life in ours.
>
> > Perhaps a better approach to this might be to kick off an experimental
> > james branch where we can do the required refactoring without worrying
> > too much about breaking things and hindering current james development?
> > Or, if you think that they might have a more stable API in a
> few months,
> > maybe the sync up should wait for james v4?
>
> The best and *easiest* solution for all is to synch now and keep in
> synch via Gump.
>
> Let's say that we make a change to a Component and that breaks James. In
> the possibility that there is an Avalon Component repository, James
> developers active there would have a veto on the commit, and it would
> help keep things clean.
>
> > At the end of the day, what is the point of using Avalon at all if we
> > are going to be stuck with an obsolete version forever?
>
> Let's collaborate, and things will go into place.
>
> --
> 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Aaron Knauf wrote:
> Yeah, it doesn't help that the Avalon APIs aren't yet stable.
Which APIs? :-?
The Framework has been stable for a long time.
> This is a
> sign of the current lack of maturity in the Avalon codebase. When you
> base your application on such a raw framework, you buy into this kind of
> trouble. It seems to me, however, that the Avalon guys might be willing
> to work on stabilizing their interfaces. They are going to find it
> tough going trying to stabilize without close support and feedback from
> their user community, though. (That's us!)
We are consolidating out *implementations*, not our APIs. And yes, we
would be happy to have close help from you, and that's the reason why we
are defining concrete ways in which the James community can have real
life in ours.
> Perhaps a better approach to this might be to kick off an experimental
> james branch where we can do the required refactoring without worrying
> too much about breaking things and hindering current james development?
> Or, if you think that they might have a more stable API in a few months,
> maybe the sync up should wait for james v4?
The best and *easiest* solution for all is to synch now and keep in
synch via Gump.
Let's say that we make a change to a Component and that breaks James. In
the possibility that there is an Avalon Component repository, James
developers active there would have a veto on the commit, and it would
help keep things clean.
> At the end of the day, what is the point of using Avalon at all if we
> are going to be stuck with an obsolete version forever?
Let's collaborate, and things will go into place.
--
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: Excalibur/Cornerstone/James woes
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Danny Angus wrote:
>>Perhaps a better approach to this might be to kick off an experimental
>>james branch where we can do the required refactoring without worrying
>>too much about breaking things and hindering current james development?
>> Or, if you think that they might have a more stable API in a few
>>months, maybe the sync up should wait for james v4?
>
>
> Personally I'm inclined to think that once we find satisfactory avalon bits we may as well stick with them until there are signs of real stability, real bugs, or real improvements, rather than chase our tails just to keep up.
> It has taken until now for us to be able to move to a stable release of phoenix, one didn't exist before, and we cant in good concience release james on alpha and beta versions of major dependancies without issuing caveats to our users. If other avalon things (I hesitate to use specific terms incorrectly) have a long cycle that ends up with a stable version which has a large delta over the previous stable, then we are going to ask ourselves what we gain in return for the cost of refactoring and whether the same situation will occur in the next cycle.
I agree. My proposal is based on the fact that we will not be having a
large delta and we will be consolidating in the short term.
Our roadmap has basically two phases:
1 consolidate and release Avalon4
2 work on Avalon 5
I'm focusing only on phase 1. For phase 2 it would be nute (I agree) to
follow all our changes.
> I'm *not* slagging off avalon or any of the avalon contributors, who are nice, supportive and smart,
:-D
> but I'm not going to pretend we're all always happy with their progress or direction just to perpetuate the idea of a happy apache-java-server domain, I think I'm taking a pragmatic approach, and one that other consumers and potential consumers of avalon will also share.
Yes. As both an Avalon developer and James consumer I agree.
> I think that probably sums up my attitude, I'd really like James to be able to be nothing more than a consumer of avalon, and I'm sure we'd provide plenty of feedback and cross-fertilisation. The problem is that we end up having to be a test-bed, and James commiters have to get their hands dirty in the avalon codebase if we want to keep abreast.
Yes, I understand. :-(
There have been implementation changes that have really been bad for
you, Gump would have caught them before. We really need to release in a
more proper way.
>>At the end of the day, what is the point of using Avalon at all
>
> This is a question we ask ourselves monthly.
>
>>if we
>>are going to be stuck with an obsolete version forever? The benefits of
>>not having to re-invent the wheel begin to pale very rapidly when you
>>can feel every bump in the road through the steel rims! How did people
>>ever get by without steel-belted radials and double wish-bone suspension!
>
>
> Thats, if you mean the effort required to ditch avalon, is sometimes the only reason we don't.
>
> I'm not totally down on avalon, but I would much rather spend my time on making progress than shuffling things round because of dependancies.
Yes.
> As far as the specific case is concerned, there is merit in updating James, and the head is the place to do it, but we should try to gauge the scale of the problem before we cut code.
>
> Finally I think that if avalon people want to look at James they can patch our current code, or fork a copy into their own repositories, I can't see the benefit of creating a branch which will be adapted to avalon's latest, if we then have to migrate all those changes to the ever evolving head.
I agree.
--
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: Excalibur/Cornerstone/James woes
Posted by Danny Angus <da...@apache.org>.
> Perhaps a better approach to this might be to kick off an experimental
> james branch where we can do the required refactoring without worrying
> too much about breaking things and hindering current james development?
> Or, if you think that they might have a more stable API in a few
> months, maybe the sync up should wait for james v4?
Personally I'm inclined to think that once we find satisfactory avalon bits we may as well stick with them until there are signs of real stability, real bugs, or real improvements, rather than chase our tails just to keep up.
It has taken until now for us to be able to move to a stable release of phoenix, one didn't exist before, and we cant in good concience release james on alpha and beta versions of major dependancies without issuing caveats to our users. If other avalon things (I hesitate to use specific terms incorrectly) have a long cycle that ends up with a stable version which has a large delta over the previous stable, then we are going to ask ourselves what we gain in return for the cost of refactoring and whether the same situation will occur in the next cycle.
I'm *not* slagging off avalon or any of the avalon contributors, who are nice, supportive and smart, but I'm not going to pretend we're all always happy with their progress or direction just to perpetuate the idea of a happy apache-java-server domain, I think I'm taking a pragmatic approach, and one that other consumers and potential consumers of avalon will also share.
I think that probably sums up my attitude, I'd really like James to be able to be nothing more than a consumer of avalon, and I'm sure we'd provide plenty of feedback and cross-fertilisation. The problem is that we end up having to be a test-bed, and James commiters have to get their hands dirty in the avalon codebase if we want to keep abreast.
>
> At the end of the day, what is the point of using Avalon at all
This is a question we ask ourselves monthly.
> if we
> are going to be stuck with an obsolete version forever? The benefits of
> not having to re-invent the wheel begin to pale very rapidly when you
> can feel every bump in the road through the steel rims! How did people
> ever get by without steel-belted radials and double wish-bone suspension!
Thats, if you mean the effort required to ditch avalon, is sometimes the only reason we don't.
I'm not totally down on avalon, but I would much rather spend my time on making progress than shuffling things round because of dependancies.
As far as the specific case is concerned, there is merit in updating James, and the head is the place to do it, but we should try to gauge the scale of the problem before we cut code.
Finally I think that if avalon people want to look at James they can patch our current code, or fork a copy into their own repositories, I can't see the benefit of creating a branch which will be adapted to avalon's latest, if we then have to migrate all those changes to the ever evolving head.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Aaron Knauf <ak...@xtra.co.nz>.
Yeah, it doesn't help that the Avalon APIs aren't yet stable. This is a
sign of the current lack of maturity in the Avalon codebase. When you
base your application on such a raw framework, you buy into this kind of
trouble. It seems to me, however, that the Avalon guys might be willing
to work on stabilizing their interfaces. They are going to find it
tough going trying to stabilize without close support and feedback from
their user community, though. (That's us!)
Perhaps a better approach to this might be to kick off an experimental
james branch where we can do the required refactoring without worrying
too much about breaking things and hindering current james development?
Or, if you think that they might have a more stable API in a few
months, maybe the sync up should wait for james v4?
At the end of the day, what is the point of using Avalon at all if we
are going to be stuck with an obsolete version forever? The benefits of
not having to re-invent the wheel begin to pale very rapidly when you
can feel every bump in the road through the steel rims! How did people
ever get by without steel-belted radials and double wish-bone suspension!
:-)
Cheers
ADK
Danny Angus wrote:
>>I think that JAMES should make a habit of upgrading to every new stable
>>avalon release. This requires that Avalon does its releases reasonably
>>frequently. It also assumes that avalon releases are not made every day
>>- we might have to skip a few if that happens.
>>
>>
>
>It also compels us to spend a lot of time refactoring james to take account of revolutionary changes forced on us by Avalon.
>
>d.
>
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur/Cornerstone/James woes
Posted by Danny Angus <da...@apache.org>.
> I think that JAMES should make a habit of upgrading to every new stable
> avalon release. This requires that Avalon does its releases reasonably
> frequently. It also assumes that avalon releases are not made every day
> - we might have to skip a few if that happens.
It also compels us to spend a lot of time refactoring james to take account of revolutionary changes forced on us by Avalon.
d.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Aaron Knauf <ak...@xtra.co.nz>.
IMHO, it is important for james to stay fairly up-to-date with avalon.
Getting stuck in a situation where we just can't have the new
bugfixes/features because it is too hard to upgrade is *painful*. (I've
been there before.) That does not, however, mean that we need to be
running against avalon HEAD.
I think that JAMES should make a habit of upgrading to every new stable
avalon release. This requires that Avalon does its releases reasonably
frequently. It also assumes that avalon releases are not made every day
- we might have to skip a few if that happens.
Cheers
ADK
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Harmeet Bedi wrote:
>Stephen is proposing a CVS repository of James and Avalon in Avalon Sandbox.
>This would be based on current CVS code and would be temporary.
>
>- If it is based on current CVS, shouldn't it be ongoing rather than
>temporary ? I would expect a temporary integration codebase for well defined
>releases not current CVS.
>
>
There are two scenarios I think you should be considering:
1. a James releasse scenario - this is where you referencing relased jars
2. a James build that is based on the current CVS of Avalon based on Gump
Why - because it means that (a) we have to get in sync. and (b) its an
mutual early warning system, and (c) it enables James community to
properly manage migration to released packages in Avalon.
>- It would be better to to only sync up on well defined releases rather than
>current CVS. Stephen do you have a release candidate of
>Excalibur/Cornerstone that you want to synch up with James.
>
Yes.
The cornerstone CVS has been updated to include a cornerstone.xml build
file. This gnerates a set of single component jars which can be manged
under independent release cycles.
>Or is the desire
>to be always in Synch within development trees.
>
Yes - as well - but via Gump.
>James is a user of Phonix
>and as long as there is a stable version of Phoenix for James all is good.
>Not sure why James needs to tie in into current CVS of
>Excalibur/Cornerstone.
>
1. Because your using a cornerstone jar file that I can't replicate.
2. Because there is no feeback loop from James to Avalon - and that's bad.
3. Because there is no feeback loop from Avalon to James - and that's bad.
4. Because I'm integrating James into my patform and I want to see some
real synchronization :-)
>
>It seems heavy to sync up on development trees via a temporary CVS
>repository but if Stephen wants to do it, no harm there.
>
>
I would like to avoid it if I can - its just that I'm kind at a brick
wall and I need help - and that possibly/probably/maybe means getting
what I have here available to you and other James and Avalon people.
Cheers, Steve.
>Harmeet
>
>----- Original Message -----
>From: "Noel J. Bergman" <no...@devtech.com>
>To: "Avalon Developers List" <av...@jakarta.apache.org>; "James
>Developers List" <ja...@jakarta.apache.org>
>Sent: Wednesday, January 22, 2003 10:32 PM
>Subject: RE: Excalibur/Cornerstone/James woes
>
>
>
>
>>>Stephen, are you planning to sync with a release version of
>>>Excalibur/Cornerstone or with a development snapshot ?
>>>
>>>
>>Harmeet, are you having trouble keeping up with james-dev? Stephen,
>>
>>
>Serge,
>
>
>>Nico, and I have discussed this issue in depth and in multiple message
>>threads.
>>
>>Stephen is one of the Avalon developers and PMC members. He is working to
>>prepare a formal set of Avalon Release builds.
>>
>>--- Noel
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
>>
><ma...@jakarta.apache.org>
>
>
>>For additional commands, e-mail:
>>
>>
><ma...@jakarta.apache.org>
>
>
>--
>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: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Harmeet Bedi wrote:
>Stephen is proposing a CVS repository of James and Avalon in Avalon Sandbox.
>This would be based on current CVS code and would be temporary.
>
>- If it is based on current CVS, shouldn't it be ongoing rather than
>temporary ? I would expect a temporary integration codebase for well defined
>releases not current CVS.
>
>
There are two scenarios I think you should be considering:
1. a James releasse scenario - this is where you referencing relased jars
2. a James build that is based on the current CVS of Avalon based on Gump
Why - because it means that (a) we have to get in sync. and (b) its an
mutual early warning system, and (c) it enables James community to
properly manage migration to released packages in Avalon.
>- It would be better to to only sync up on well defined releases rather than
>current CVS. Stephen do you have a release candidate of
>Excalibur/Cornerstone that you want to synch up with James.
>
Yes.
The cornerstone CVS has been updated to include a cornerstone.xml build
file. This gnerates a set of single component jars which can be manged
under independent release cycles.
>Or is the desire
>to be always in Synch within development trees.
>
Yes - as well - but via Gump.
>James is a user of Phonix
>and as long as there is a stable version of Phoenix for James all is good.
>Not sure why James needs to tie in into current CVS of
>Excalibur/Cornerstone.
>
1. Because your using a cornerstone jar file that I can't replicate.
2. Because there is no feeback loop from James to Avalon - and that's bad.
3. Because there is no feeback loop from Avalon to James - and that's bad.
4. Because I'm integrating James into my patform and I want to see some
real synchronization :-)
>
>It seems heavy to sync up on development trees via a temporary CVS
>repository but if Stephen wants to do it, no harm there.
>
>
I would like to avoid it if I can - its just that I'm kind at a brick
wall and I need help - and that possibly/probably/maybe means getting
what I have here available to you and other James and Avalon people.
Cheers, Steve.
>Harmeet
>
>----- Original Message -----
>From: "Noel J. Bergman" <no...@devtech.com>
>To: "Avalon Developers List" <av...@jakarta.apache.org>; "James
>Developers List" <ja...@jakarta.apache.org>
>Sent: Wednesday, January 22, 2003 10:32 PM
>Subject: RE: Excalibur/Cornerstone/James woes
>
>
>
>
>>>Stephen, are you planning to sync with a release version of
>>>Excalibur/Cornerstone or with a development snapshot ?
>>>
>>>
>>Harmeet, are you having trouble keeping up with james-dev? Stephen,
>>
>>
>Serge,
>
>
>>Nico, and I have discussed this issue in depth and in multiple message
>>threads.
>>
>>Stephen is one of the Avalon developers and PMC members. He is working to
>>prepare a formal set of Avalon Release builds.
>>
>>--- Noel
>>
>>
>>--
>>To unsubscribe, e-mail:
>>
>>
><ma...@jakarta.apache.org>
>
>
>>For additional commands, e-mail:
>>
>>
><ma...@jakarta.apache.org>
>
>
>--
>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: Excalibur/Cornerstone/James woes
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Stephen is proposing a CVS repository of James and Avalon in Avalon Sandbox.
This would be based on current CVS code and would be temporary.
- If it is based on current CVS, shouldn't it be ongoing rather than
temporary ? I would expect a temporary integration codebase for well defined
releases not current CVS.
- It would be better to to only sync up on well defined releases rather than
current CVS. Stephen do you have a release candidate of
Excalibur/Cornerstone that you want to synch up with James. Or is the desire
to be always in Synch within development trees. James is a user of Phonix
and as long as there is a stable version of Phoenix for James all is good.
Not sure why James needs to tie in into current CVS of
Excalibur/Cornerstone.
It seems heavy to sync up on development trees via a temporary CVS
repository but if Stephen wants to do it, no harm there.
Harmeet
----- Original Message -----
From: "Noel J. Bergman" <no...@devtech.com>
To: "Avalon Developers List" <av...@jakarta.apache.org>; "James
Developers List" <ja...@jakarta.apache.org>
Sent: Wednesday, January 22, 2003 10:32 PM
Subject: RE: Excalibur/Cornerstone/James woes
> > Stephen, are you planning to sync with a release version of
> > Excalibur/Cornerstone or with a development snapshot ?
>
> Harmeet, are you having trouble keeping up with james-dev? Stephen,
Serge,
> Nico, and I have discussed this issue in depth and in multiple message
> threads.
>
> Stephen is one of the Avalon developers and PMC members. He is working to
> prepare a formal set of Avalon Release builds.
>
> --- Noel
>
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur/Cornerstone/James woes
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Stephen, are you planning to sync with a release version of
> Excalibur/Cornerstone or with a development snapshot ?
Harmeet, are you having trouble keeping up with james-dev? Stephen, Serge,
Nico, and I have discussed this issue in depth and in multiple message
threads.
Stephen is one of the Avalon developers and PMC members. He is working to
prepare a formal set of Avalon Release builds.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur/Cornerstone/James woes
Posted by "Noel J. Bergman" <no...@devtech.com>.
> Stephen, are you planning to sync with a release version of
> Excalibur/Cornerstone or with a development snapshot ?
Harmeet, are you having trouble keeping up with james-dev? Stephen, Serge,
Nico, and I have discussed this issue in depth and in multiple message
threads.
Stephen is one of the Avalon developers and PMC members. He is working to
prepare a formal set of Avalon Release builds.
--- Noel
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Stephen, are you planning to sync with a release version of
Excalibur/Cornerstone or with a development snapshot ?
If it is the latter, it may be better to sync up when there is an official
or candidate release. At the moment James is not broken and changes are usu.
done in the development cycle. James may end up dragging you down and vice
versa. The last time there was an upgrade, there were a few surprises as is
expected from any major upgrade. It would be good to upgrade to stable
versions.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Harmeet Bedi <ha...@kodemuse.com>.
Stephen, are you planning to sync with a release version of
Excalibur/Cornerstone or with a development snapshot ?
If it is the latter, it may be better to sync up when there is an official
or candidate release. At the moment James is not broken and changes are usu.
done in the development cycle. James may end up dragging you down and vice
versa. The last time there was an upgrade, there were a few surprises as is
expected from any major upgrade. It would be good to upgrade to stable
versions.
Harmeet
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> It looks like my earlier note concerning success with James was
>> premature. I'm back experiencing an loop inside James mail
>> processing and have not been able to isolate the problem.
>>
> <snip/>
>
>>
>> In order to resolve this problem I would like to import the modified
>> James sources into avalon-sandbox to enable James and Avalon people
>> to dig into this.
>
>
> If it is temporary only and the james team agrees (I think they are
> indeed interested in seeing this code soon, right?) it's fine by me,
> even if from your e-mail it sounds like it makes more sense to me to
> add a branch to james cvs.
Temporary - Yes.
Is an immediate concern - for me yes, for the James commitee - it as
thorn in the side.
The reason for propsing avalon-sandbox is that (a) I consider this to be
our problem - not a James problem - i.e I'm confident this is a
Cornerstone/Exalibur change issue and we will need assistance from James
people to sort ot out, and (b) its more convinient because I'm not a
comitter over on James so sticking it into sandbox is easier for me.
Cheers, Steve.
>
> cheers,
>
> - Leo
>
>
>
> --
> 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: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Leo Simons wrote:
> Stephen McConnell wrote:
>
>> It looks like my earlier note concerning success with James was
>> premature. I'm back experiencing an loop inside James mail
>> processing and have not been able to isolate the problem.
>>
> <snip/>
>
>>
>> In order to resolve this problem I would like to import the modified
>> James sources into avalon-sandbox to enable James and Avalon people
>> to dig into this.
>
>
> If it is temporary only and the james team agrees (I think they are
> indeed interested in seeing this code soon, right?) it's fine by me,
> even if from your e-mail it sounds like it makes more sense to me to
> add a branch to james cvs.
Temporary - Yes.
Is an immediate concern - for me yes, for the James commitee - it as
thorn in the side.
The reason for propsing avalon-sandbox is that (a) I consider this to be
our problem - not a James problem - i.e I'm confident this is a
Cornerstone/Exalibur change issue and we will need assistance from James
people to sort ot out, and (b) its more convinient because I'm not a
comitter over on James so sticking it into sandbox is easier for me.
Cheers, Steve.
>
> cheers,
>
> - Leo
>
>
>
> --
> 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: Excalibur/Cornerstone/James woes
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> It looks like my earlier note concerning success with James was
> premature. I'm back experiencing an loop inside James mail processing
> and have not been able to isolate the problem.
>
<snip/>
>
> In order to resolve this problem I would like to import the modified
> James sources into avalon-sandbox to enable James and Avalon people to
> dig into this.
If it is temporary only and the james team agrees (I think they are
indeed interested in seeing this code soon, right?) it's fine by me,
even if from your e-mail it sounds like it makes more sense to me to add
a branch to james cvs.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Nicola:
I agree 1000% with the objectives your outlining below - but I have an
immediate priority which I'm going to address is a seperate email. For
the moment, I would like move forward on what you have described below
with the establishment of the following CVS repositories:
* avalon
* avalon-site
* avalon-components
* avaon-sandbox (already in-place)
Cheers, Steve.
Nicola Ken Barozzi wrote:
>
> Stephen McConnell wrote:
> [...]
>
>> In order to resolve this problem I would like to import the modified
>> James sources into avalon-sandbox to enable James and Avalon people
>> to dig into this.
>
>
> Seeing that this was coming, I had suggested some time back to create
> Avalon Components and have James friends be part of it.
>
> The proposal would be to make a avalon-components CVS module and move
> there (or symlink) all the components in excalibur and Cornerstone CVS.
> Then unify the build of the two systems and give access to James
> developers that are willing to help.
>
> It has been said that package names shouldn't change, and I agree.
> This is just about moving the components in a single CVS space.
> It has also been said that it's a hassle for little gain. Well, in
> fact it really seems so.
>
> So we could as well still make the Avalon Components subproject, have
> access for James friends (and Turbine and others if/when needed), and
> keep the two repositories for now. Basically the same gains without
> the hassle. New components would go to excalibur, and our Avalon
> Components project would have a double personality (e-c) till we get
> to a completely unified component system.
>
> Now, this poses a problem though. Fortress is in excalibur, but it's
> not a component, but a container. Given that we are uniting the
> framework and the container under a single CVS module, and that
> Fortress is the first step in that direction given the tentative
> roadmap in STATUS, IMHO it could make sense to move it with the
> framework in the new "avalon" repository. More practically, rename
> jakarta-avalon to avalon, make jakarta-avalon, symlink to concrete
> repo. Then move the Fortress dirs under "avalon".
>
> The bottom line: IMHO it would be a bonus for us if outer-avalon
> project friends collaborate with us on the components, and the above
> suggestion is just one possible way of doing it.
>
> Thoughts, suggestions, ideas?
>
--
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: Excalibur/Cornerstone/James woes
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Stephen McConnell wrote:
[...]
> In order to resolve this problem I would like to import the modified
> James sources into avalon-sandbox to enable James and Avalon people to
> dig into this.
Seeing that this was coming, I had suggested some time back to create
Avalon Components and have James friends be part of it.
The proposal would be to make a avalon-components CVS module and move
there (or symlink) all the components in excalibur and Cornerstone CVS.
Then unify the build of the two systems and give access to James
developers that are willing to help.
It has been said that package names shouldn't change, and I agree. This
is just about moving the components in a single CVS space.
It has also been said that it's a hassle for little gain. Well, in fact
it really seems so.
So we could as well still make the Avalon Components subproject, have
access for James friends (and Turbine and others if/when needed), and
keep the two repositories for now. Basically the same gains without the
hassle. New components would go to excalibur, and our Avalon Components
project would have a double personality (e-c) till we get to a
completely unified component system.
Now, this poses a problem though. Fortress is in excalibur, but it's not
a component, but a container. Given that we are uniting the framework
and the container under a single CVS module, and that Fortress is the
first step in that direction given the tentative roadmap in STATUS, IMHO
it could make sense to move it with the framework in the new "avalon"
repository. More practically, rename jakarta-avalon to avalon, make
jakarta-avalon, symlink to concrete repo. Then move the Fortress dirs
under "avalon".
The bottom line: IMHO it would be a bonus for us if outer-avalon project
friends collaborate with us on the components, and the above suggestion
is just one possible way of doing it.
Thoughts, suggestions, ideas?
--
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: Excalibur/Cornerstone/James woes
Posted by Leo Simons <le...@apache.org>.
Stephen McConnell wrote:
> It looks like my earlier note concerning success with James was
> premature. I'm back experiencing an loop inside James mail processing
> and have not been able to isolate the problem.
>
<snip/>
>
> In order to resolve this problem I would like to import the modified
> James sources into avalon-sandbox to enable James and Avalon people to
> dig into this.
If it is temporary only and the james team agrees (I think they are
indeed interested in seeing this code soon, right?) it's fine by me,
even if from your e-mail it sounds like it makes more sense to me to add
a branch to james cvs.
cheers,
- Leo
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur/Cornerstone/James woes
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Stephen,
> >
> >Are you sure this isn't a config problem?
> >
>
> The config elements are cut and paste from the current James CVS HEAD.
> If it's a config problem then its a James bug we need to fix because I'm
> not getting any errors.
A configuration problem doesn't necessarily generate errors. Noel has
informed me that the current James HEAD still has the buggy patch - as he
mentions in his recent Avalon-dev email.
> >Ignoring the empty command for
> >the moment, it looks like your mail to "test@localhost" is being routed
> to
> >RemoteDelivery for processing. Maybe because it's in the spammer
> blacklist?
> >A posted configuration file might help immensely.
> >
>
> The configuration is defintioned by a combination of two files:
>
> 1. avalon-sandbox/merlin/blocks.zml
> 2. avalon-sandbox/merlin/src/test/config/james.xml
I don't see anything immediately wrong, but I'm very concerned that only one
blacklist check is listed. It looks like the source IP is matching the RBL
blacklist, which is causing it to be rerouted. But I don't see why that
would induce an outgoing connection.
How many emails did you try to send over the course of this log? 1, 2, or
3?
I'd also recommend that you check your spam repository to see if it contains
any received mails.
> Debug level is already enabled on the parent. In principal any child
> loggers should be inheriting log priority levels of DEBUG unless James
> is explicity overulling this - i.e. what is running should be full DEBUG
> for everything unless I'm missing something or some explicit
> configuration is required.
You're missing something. :)
Mailets do not use Avalon logging mechanisms. Here is neither the time nor
place to address why this is the case, but it is nonetheless so. For
interminable discussions please consult james-dev archives. :)
That said, in order to get some debugging info you'll need to add a
<debug>true</debug> child element to each of the mailets. Substantially
more info should come through. Especially if RemoteDelivery is getting
triggered.
> I'm interested - but before posting something to me can you try
> the following against your code base using the attache build file:
>
> The related resource you will need include:
>
> <james-dir>
>
> james.xml
> james.properties
>
> <james-dir>/tests
>
> test.xml
> test.properties
>
> The build files for both james and the tests simply point to the current
> CVS builds for excalibur and cornerstone. Note - to build corenrstone
> you will need excalibur-thead-1.1 which includes the bug fix concerning
> pool max size control. You will also need to replace the
> excalibur-thread-1.0 in phoenix lib with version 1.1.
Not going to happen this minute, but I'll see if I can do it tonight.
> This smells of something possible - I know I updated the CVS and made a
> bunch of other changes and retured to the james test and things were
> broken again. I'll resync against the James CVS and post results to
> James Dev.
See above comments.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Excalibur/Cornerstone/James woes
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Stephen,
> Note - I have just updated the corenerstone.xml buildfile (in CVS - now
> references excalibur-pool-1.2.jar).
Ok. Will update and rebuild. See my many messages to Avalon-dev about
build issues in Excalibur and Logkit. Once those were fixed, I built
Cornerstone without a hitch.
> Two things here:
>
> 1. the exception handling in Merlin had a bug in that it was not
> passing the causal exception and as such the error report is not so
> helpful. This is now fixed and some of the related error message have
> been brushed up.
Ok. That will probably make analysis of issues easier.
> 2. my guess is that you didn't update xinfo files contianing
> references to the *.service.datasource" to the ...s package name. This
> would cause the assembly stage exception (which would a lot clearer
> based on the updates in Merlin I've just mentioned)
That is correct. I have now updated my source.
> That should not have happen - have made some changes in Merlin - but
> anyway its not central to the James deployment question.
Ok. Sounds good.
> I confident the issue is inconsitentcy in the packkage names for the
> "...service.datasources". Also the updates on Merlin should make things
> clearer what is happening. IIf you want to see what is happening inside
> Merlin - go into the kernel.xml file and look for the fololowing
> categories defintion and set it to DEBUG instead of INFO (and you will
> get a lot more information about what is or is not happening).
>
> <categories>
> <category name="/sys" priority="INFO"/>
> </categories>
Going to see if I can get this done tonight and see what I get - maybe yes,
maybe no.
> >
> >Now, onto Phoenix. I've built a sar file out of the latest and greatest
> >files, and am having issues deploying it in Phoenix 4.0.3.
> >
> >When I try and use the excalibur-thread-1.1 in this version of Phoenix,
> >nothing works. This is kind of what I expected from Peter D.'s earlier
> >comments, so I wasn't surprised.
> >
> >
>
> I didn't have any problems (build against excalibur thread 1., replaced
> Phoenix thread jar with 1.1 and everything worked OK).
Did you rebuild Phoenix, or just the james.sar? I used an out of the box
Phoenix 4.0.3 distribution, as much as I enjoy rebuilding most of Avalon
with every change. :) Because I definitely encountered an issue when I just
rebuilt the james.sar and replaced Excalibur-thread-1.0.jar with
Excalibur-thread-1.1.jar
> Yep - there seems to be a problem in Phoenix concerning extension
> handling. I've already committed updated to the cornerstone build
> procedure to disable the extension depedency declarations. It seems
> that Phoenix is not considering the jar files that are loaded from the
> sar lib as extension candidates. Anyway - with the current
> corenerstone.xml based build - you will not have this problem.
Ok, I'll let you handle the Phoenix issue.
> >i) We need a version of Phoenix that runs with the Excalibur-thread-
> 1.1.jar,
> >but that is reasonably stable (4.0.4?)
> >
>
> I agree - but my hunch is that there will be a few other updates for
> 4.0.4 relating to getting the Excalibur releases done (e.g. pool 1.2,
> configuration 1.0, etc.).
Yes. Phoenix 4.0.4 should use all stable, release Excalibur stuff. That'd
be good.
> >ii) The DefaultThreadManager patch needs to be fixed
> >
>
> It is fixed - not following you here.
Right now the DefaultThreadManager passes maxThreads, maxThreads for the
minimum and maximum parameters. Should be passing minThreads, maxThreads.
> Switch on DEBUG for the "/sys" category and what you will see will
> explain a lot.
> Secodly - once we have something running I'll talking a lot more about
> packaging and deploying a james block - basically a deployment unit that
> hides all of the assembly and config and structures it as a single
> component. That will introduce questions about what services are
> exposed, and a lot of stuff about mailet registration and so on. This
> is only the starting point .. :-).
Ok.
> >Or take my code base
> >and figure out what needs to be done to make it run in Merlin.
> >
>
> I think its a good idea - can you email it to me?
Can this email address take a large (~7MB I think) file? Let me know
offline and I'll send.
> My position on this is that we should be using the standard extension
> mechanisms - but I'm going to have to dig into Phoienix to gfigure out
> what is broken. Once that it resolved - getting jar depedencies
> documetation can be done formally in the manifest.
My position on this is that as a client of Avalon/Phoenix/Merlin I shouldn't
have to worry about this. Conceptually, I agree with you. But I'm more
focused on getting it all working and extracting myself from some of this
Avalon stuff.
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Peter M. Goldstein wrote:
>Stephen,
>
>
>
>>Then ...
>>
>>$ cd <avalon-dir>
>>$ ant
>>
>>
>
>Done.
>
>
>
>>$ cd <excalibur-dir>
>>$ ant
>>
>>
>
>Done.
>
>
>
>>$ cd <cornerstone-dir>
>>$ ant -buildfile cornerstone.xml
>>
>>
>
>Done.
>
Note - I have just updated the corenerstone.xml buildfile (in CVS - now
references excalibur-pool-1.2.jar).
>
>
>
>>$ cd <james-dir>
>>$ ant -buildfile james.xml
>>
>>
>
>Done. Although I needed to make an interesting change here. Specifically,
>I needed to change the import statement:
>
>import org.apache.avalon.cornerstone.services.datasource.DataSourceSelector;
>
>to
>
>import
>org.apache.avalon.cornerstone.services.datasources.DataSourceSelector;
>
>I suspect this is a packaging issue with the cornerstone-datasource-1.0.jar,
>since the former appears to still be present in source control.
>
>
Sorry about that - I've updated the james.xml build file to include a
patch target to replace all occureses of "*.service.datasource." with
"*.service.datasources." - this reflects a datasource package that uses
the ServiceSelector as opposed to CompoentSelector. You will need to do
the update on all your sources in James the reference service.datasource
(including the James.xinfo file).
>
>
>>$ cd <avalon-sandbox>
>>$ cd merlin
>>$ ant
>>
>>
>
>Done. Found a bug in the config (it uses the old
>File_Persistent_Stream_Repository, File_Persistent_Object_Repository).
>Fixed it.
>
Thanks - fixed.
>>// edit the blocks.xml file to make sure the james block is enabled
>>// and that the demos are disabled then launch merlin
>>
>>$
>>$ start demo
>>
>>
>
>And here we have a problem. When I type "start demo" I get:
>
>C:\development\apache-cvs\avalon-sandbox\merlin>java -classpath
>build\lib\avalon
>-merlin-bootstrap-2.1.jar org.apache.avalon.merlin.bootstrap.Merlin
>merlin.prope
>rties
>[INFO ] (sys): initialization from:
>C:\development\apache-cvs\avalon-sandbox\m
>erlin on localhost
>[INFO ] (sys):
>
>commencing block construction phase
>
>[INFO ] (sys): block count = 3
>[INFO ] (sys): [james/14780827]
>[INFO ] (sys): [playground/17905186]
>[INFO ] (sys): [demo/16316379]
>[INFO ] (sys):
>
>commencing structural assembly phase
>
>[ERROR ] (sys): Message: Unable to deploy block: [james/14780827] due to a
>structural assembly failure.
>===================================================================
>
>Exception: org.apache.avalon.assembly.lifecycle.AssemblyException
>Assembly failure attributable to embedded appliance.
>
>Cause: org.apache.avalon.assembly.lifecycle.AssemblyException
>Unable to deploy a supplier for a service dependency:
>[org.apache.james.services
>.MailStore] org.apache.james.services.MailStore:1.0.0
>
>Cause: org.apache.avalon.assembly.appliance.ApplianceException
>Unresolvable assembly graph for appliance: [mailstore/29086271]
>
Two things here:
1. the exception handling in Merlin had a bug in that it was not
passing the causal exception and as such the error report is not so
helpful. This is now fixed and some of the related error message have
been brushed up.
2. my guess is that you didn't update xinfo files contianing
references to the *.service.datasource" to the ...s package name. This
would cause the assembly stage exception (which would a lot clearer
based on the updates in Merlin I've just mentioned)
>[INFO ] (sys):
>
>commencing decommissioning phase
>
>[INFO ] (sys):
>
>commencing termination phase
>
>java.lang.NullPointerException
>
That should not have happen - have made some changes in Merlin - but
anyway its not central to the James deployment question.
>>$ cd <james-dir>
>>$ cd tests
>>$ ant -buildfile test.xml
>>$
>>
>>
>
>And obviously I don't get here.
>
>I find the problem difficult to debug because I know absolutely nothing
>about Merlin. It happens both before and after I make the changes to the
>configuration file, so it's not due to the changes I cite above. Any help
>in debugging this would be appreciated. Thanks.
>
I confident the issue is inconsitentcy in the packkage names for the
"...service.datasources". Also the updates on Merlin should make things
clearer what is happening. IIf you want to see what is happening inside
Merlin - go into the kernel.xml file and look for the fololowing
categories defintion and set it to DEBUG instead of INFO (and you will
get a lot more information about what is or is not happening).
<categories>
<category name="/sys" priority="INFO"/>
</categories>
>
>Now, onto Phoenix. I've built a sar file out of the latest and greatest
>files, and am having issues deploying it in Phoenix 4.0.3.
>
>When I try and use the excalibur-thread-1.1 in this version of Phoenix,
>nothing works. This is kind of what I expected from Peter D.'s earlier
>comments, so I wasn't surprised.
>
>
I didn't have any problems (build against excalibur thread 1., replaced
Phoenix thread jar with 1.1 and everything worked OK).
>Then I tried something different - I reverted the DefaultThreadManager
>change (side note, this change is wrong - the constructor arguments should
>be minThreads,maxThreads not maxThreads,maxThreads) and reverted the
>cornerstone dependencies to excalibur-thread-1.0.jar .
>
>However when I tried to deploy these individual Cornerstone jar files, I got
>an error on starting up Phoenix that referred to 7 missing extensions.
>
>
Yep - there seems to be a problem in Phoenix concerning extension
handling. I've already committed updated to the cornerstone build
procedure to disable the extension depedency declarations. It seems
that Phoenix is not considering the jar files that are loaded from the
sar lib as extension candidates. Anyway - with the current
corenerstone.xml based build - you will not have this problem.
>Finally, I deployed with a single cornerstone.jar built off the current
>Cornerstone sources with the aforementioned revert. This worked fine. My
>Phoenix deployment passed basic tests, including the EndToEnd test. So my
>current code appears to work fine, and there isn't a single
>Component/ComponentManager to be found anywhere in it.
>
>Based on these tests it seems that:
>
>i) We need a version of Phoenix that runs with the Excalibur-thread-1.1.jar,
>but that is reasonably stable (4.0.4?)
>
I agree - but my hunch is that there will be a few other updates for
4.0.4 relating to getting the Excalibur releases done (e.g. pool 1.2,
configuration 1.0, etc.).
>ii) The DefaultThreadManager patch needs to be fixed
>
It is fixed - not following you here.
>iii) Someone needs to give me some advice on Merlin :)
>
Switch on DEBUG for the "/sys" category and what you will see will
explain a lot.
Secodly - once we have something running I'll talking a lot more about
packaging and deploying a james block - basically a deployment unit that
hides all of the assembly and config and structures it as a single
component. That will introduce questions about what services are
exposed, and a lot of stuff about mailet registration and so on. This
is only the starting point .. :-).
>Or take my code base
>and figure out what needs to be done to make it run in Merlin.
>
I think its a good idea - can you email it to me?
>iv) The dependency issues for the individual Cornerstone jar files needs to
>be clarified.
>
My position on this is that we should be using the standard extension
mechanisms - but I'm going to have to dig into Phoienix to gfigure out
what is broken. Once that it resolved - getting jar depedencies
documetation can be done formally in the manifest.
>
>Thoughts?
>
>
Lots - but in another email :-)
Cheers, Steve.
>--Peter
>
>
>
>
>--
>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: Excalibur/Cornerstone/James woes
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Stephen,
> Then ...
>
> $ cd <avalon-dir>
> $ ant
Done.
> $ cd <excalibur-dir>
> $ ant
Done.
> $ cd <cornerstone-dir>
> $ ant -buildfile cornerstone.xml
Done.
> $ cd <james-dir>
> $ ant -buildfile james.xml
Done. Although I needed to make an interesting change here. Specifically,
I needed to change the import statement:
import org.apache.avalon.cornerstone.services.datasource.DataSourceSelector;
to
import
org.apache.avalon.cornerstone.services.datasources.DataSourceSelector;
I suspect this is a packaging issue with the cornerstone-datasource-1.0.jar,
since the former appears to still be present in source control.
> $ cd <avalon-sandbox>
> $ cd merlin
> $ ant
Done. Found a bug in the config (it uses the old
File_Persistent_Stream_Repository, File_Persistent_Object_Repository).
Fixed it.
>
> // edit the blocks.xml file to make sure the james block is enabled
> // and that the demos are disabled then launch merlin
>
> $
> $ start demo
And here we have a problem. When I type "start demo" I get:
C:\development\apache-cvs\avalon-sandbox\merlin>java -classpath
build\lib\avalon
-merlin-bootstrap-2.1.jar org.apache.avalon.merlin.bootstrap.Merlin
merlin.prope
rties
[INFO ] (sys): initialization from:
C:\development\apache-cvs\avalon-sandbox\m
erlin on localhost
[INFO ] (sys):
commencing block construction phase
[INFO ] (sys): block count = 3
[INFO ] (sys): [james/14780827]
[INFO ] (sys): [playground/17905186]
[INFO ] (sys): [demo/16316379]
[INFO ] (sys):
commencing structural assembly phase
[ERROR ] (sys): Message: Unable to deploy block: [james/14780827] due to a
structural assembly failure.
===================================================================
Exception: org.apache.avalon.assembly.lifecycle.AssemblyException
Assembly failure attributable to embedded appliance.
Cause: org.apache.avalon.assembly.lifecycle.AssemblyException
Unable to deploy a supplier for a service dependency:
[org.apache.james.services
.MailStore] org.apache.james.services.MailStore:1.0.0
Cause: org.apache.avalon.assembly.appliance.ApplianceException
Unresolvable assembly graph for appliance: [mailstore/29086271]
===================================================================
org.apache.avalon.assembly.appliance.ApplianceException: Unresolvable
assembly g
raph for appliance: [mailstore/29086271]
at
org.apache.avalon.assembly.engine.EngineClassLoader.resolve(EngineCla
ssLoader.java:809)
at
org.apache.avalon.assembly.appliance.DefaultAppliance.executeAssembly
(DefaultAppliance.java:828)
at
org.apache.avalon.assembly.appliance.DefaultAppliance.assemble(Defaul
tAppliance.java:479)
at
org.apache.avalon.merlin.block.impl.DefaultBlock.assembleComponents(D
efaultBlock.java:408)
at
org.apache.avalon.merlin.block.impl.DefaultBlock.assemble(DefaultBloc
k.java:334)
at
org.apache.avalon.merlin.kernel.impl.DefaultKernel.initialize(Default
Kernel.java:414)
at
org.apache.avalon.merlin.kernel.impl.KernelLoader.<init>(KernelLoader
.java:117)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstruct
orAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingC
onstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
at org.apache.avalon.merlin.bootstrap.Merlin.<init>(Merlin.java:190)
at org.apache.avalon.merlin.bootstrap.Merlin.main(Merlin.java:64)
===================================================================
[INFO ] (sys):
commencing decommissioning phase
[INFO ] (sys):
commencing termination phase
java.lang.NullPointerException
at
org.apache.avalon.merlin.block.impl.DefaultBlock.handleDisassembly(De
faultBlock.java:728)
at
org.apache.avalon.merlin.block.impl.DefaultBlock.handleTermination(De
faultBlock.java:768)
at
org.apache.avalon.merlin.block.impl.DefaultBlock.terminate(DefaultBlo
ck.java:480)
at
org.apache.avalon.merlin.kernel.impl.DefaultKernel.dispose(DefaultKer
nel.java:520)
at
org.apache.avalon.merlin.kernel.impl.KernelLoader$1.run(KernelLoader.
java:83)
C:\development\apache-cvs\avalon-sandbox\merlin>
> $ cd <james-dir>
> $ cd tests
> $ ant -buildfile test.xml
> $
And obviously I don't get here.
I find the problem difficult to debug because I know absolutely nothing
about Merlin. It happens both before and after I make the changes to the
configuration file, so it's not due to the changes I cite above. Any help
in debugging this would be appreciated. Thanks.
Now, onto Phoenix. I've built a sar file out of the latest and greatest
files, and am having issues deploying it in Phoenix 4.0.3.
When I try and use the excalibur-thread-1.1 in this version of Phoenix,
nothing works. This is kind of what I expected from Peter D.'s earlier
comments, so I wasn't surprised.
Then I tried something different - I reverted the DefaultThreadManager
change (side note, this change is wrong - the constructor arguments should
be minThreads,maxThreads not maxThreads,maxThreads) and reverted the
cornerstone dependencies to excalibur-thread-1.0.jar .
However when I tried to deploy these individual Cornerstone jar files, I got
an error on starting up Phoenix that referred to 7 missing extensions.
Finally, I deployed with a single cornerstone.jar built off the current
Cornerstone sources with the aforementioned revert. This worked fine. My
Phoenix deployment passed basic tests, including the EndToEnd test. So my
current code appears to work fine, and there isn't a single
Component/ComponentManager to be found anywhere in it.
Based on these tests it seems that:
i) We need a version of Phoenix that runs with the Excalibur-thread-1.1.jar,
but that is reasonably stable (4.0.4?)
ii) The DefaultThreadManager patch needs to be fixed
iii) Someone needs to give me some advice on Merlin :) Or take my code base
and figure out what needs to be done to make it run in Merlin.
iv) The dependency issues for the individual Cornerstone jar files needs to
be clarified.
Thoughts?
--Peter
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Peter M. Goldstein wrote:
>Stephen,
>
>Are you sure this isn't a config problem?
>
The config elements are cut and paste from the current James CVS HEAD.
If it's a config problem then its a James bug we need to fix because I'm
not getting any errors.
>Ignoring the empty command for
>the moment, it looks like your mail to "test@localhost" is being routed to
>RemoteDelivery for processing. Maybe because it's in the spammer blacklist?
>A posted configuration file might help immensely.
>
The configuration is defintioned by a combination of two files:
1. avalon-sandbox/merlin/blocks.zml
2. avalon-sandbox/merlin/src/test/config/james.xml
Both availble in the CVS:
http://cvs.apache.org/viewcvs/avalon-sandbox/merlin/
>Also, it would probably
>be desirable to flip on debug for all the individual mailets if you haven't
>done so already.
>
>
Debug level is already enabled on the parent. In principal any child
loggers should be inheriting log priority levels of DEBUG unless James
is explicity overulling this - i.e. what is running should be full DEBUG
for everything unless I'm missing something or some explicit
configuration is required.
>
>I've got a (somewhat modified) version of James that uses the current
>Cornerstone classes (haven't upgraded all of the Excalibur ones), has
>undergone the Composable->Serviceable change, and runs inside Phoenix.
>Seems to work ok. I'd be happy to share source code with you if you so
>desire.
>
I'm interested - but before posting something to me can you try
the following against your code base using the attache build file:
The related resource you will need include:
<james-dir>
james.xml
james.properties
<james-dir>/tests
test.xml
test.properties
The build files for both james and the tests simply point to the current
CVS builds for excalibur and cornerstone. Note - to build corenrstone
you will need excalibur-thead-1.1 which includes the bug fix concerning
pool max size control. You will also need to replace the
excalibur-thread-1.0 in phoenix lib with version 1.1.
Then ...
$ cd <avalon-dir>
$ ant
$
$ cd <excalibur-dir>
$ ant
$
$ cd <cornerstone-dir>
$ ant -buildfile cornerstone.xml
$
$ cd <james-dir>
$ ant -buildfile james.xml
$
$ cd <avalon-sandbox>
$ cd merlin
$ ant
$
// edit the blocks.xml file to make sure the james block is enabled
// and that the demos are disabled then launch merlin
$
$ start demo
$ cd <james-dir>
$ cd tests
$ ant -buildfile test.xml
$
>Also, does your source have the post-2.1 patch that altered the SMTP handler
>data buffering?
>
Not sure. I've synced with the James CVS a couple of time in the last
couple of weeks (but its a painful process so I'm not doing it
frequently). When was the post-2.1 reverted?
>As that patch was in error, and has since been reverted, it
>may be causing some of your empty command woes. The empty command you are
>observing is symptomatic of a bug introduced with that patch. Please see
>james-dev for a discussion.
>
This smells of something possible - I know I updated the CVS and made a
bunch of other changes and retured to the james test and things were
broken again. I'll resync against the James CVS and post results to
James Dev.
Cheers, Steve.
>
>--Peter
>
>
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Sent: Wednesday, January 22, 2003 3:17 AM
>>To: Avalon Developers List; James Developers List
>>Subject: Excalibur/Cornerstone/James woes
>>
>>
>>Guys:
>>
>>It looks like my earlier note concerning success with James was
>>premature. I'm back experiencing an loop inside James mail processing
>>and have not been able to isolate the problem.
>>
>>Relevant points:
>>
>> 1. build of James, Cornerstone and Excalibur related resources
>> are all from current CVS
>> 2. James sources have been updated locally to support the service
>> package (to sync with Cornerstone changes)
>>
>>Some important notes:
>>
>> 1. james extends several Cornerstone classes based on Cornerstone
>> implementations from back in June and I suspect that there may
>> be a runtime disconnect here somewhere
>> 2. problem occurs when running under Phoenix or Merlin so I think
>> we can rule out containers as the issue
>>
>>I've put up a log with full debug level on at the following URL:
>>
>> http://www.osm.net/technical/james/james-log.txt
>>
>>Comments added to the log file are prefixed by ##.
>>
>>In order to resolve this problem I would like to import the modified
>>James sources into avalon-sandbox to enable James and Avalon people to
>>dig into this.
>>
>>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>
>>
>>
>
>
>
>--
>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
Re: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>We haven't reverted the HEAD, yet, just the v2.1 branch. My plan was to
>submit Peter's revised handler to replace the HEAD. Stephen should pull
>smtphandler.java from branch_2_1_fcs.
>
Tried that and started to get myself into trouble. Seems that the
branch_2_1_fcs version of SMTPHandler is referencing classes that don't
exist in HEAD. Maybe it would be easier if you reverted the HEAD?.
>>In order to resolve this problem I would like to import the modified
>>James sources into avalon-sandbox to enable James and Avalon people
>>to dig into this.
>>
>>
>
>Actually, I'm not sure that I see the point, so please clarify.
>
>
Because I don't want to bring in something that isn't working.
>>from your e-mail it sounds like it makes more sense to me to
>>add a branch to james cvs.
>>
>>
>
>If there is something in James that needs to change that might make sense,
>and we can arrange for commit rights, as was done previously for PeterD and
>PaulH.
>
While working though the code I've been doing little tings like putting
in leg priority test occasional javadoc and stuff like that - comit
privs would help with that - but more useful is the fact that I would be
able to commit and take care of the build and property files I'm using
(no conflict with existing setup - just a couple of build file that tie
into the avalon jars.
>
>
>>I'm confident this is a Cornerstone/Exalibur change issue
>>and we will need assistance from James people
>>
>>
>
>If it isn't in James code, then why do we need a separate copy of the James
>source in the CVS? And if it is, then I think it should be done in our
>module.
>
I'm happy to go with whatever you think is best. Given that this was all
working at one point (post SM rollever), I'm now suspecting that the
problem may be in the James HEAD - but I havn't updated for a few days -
and I'll do that later this evening and see where that leads me.
Cheers, Steve.
p.s. more feedback comming in replay to Pete's email in a moment.
>
> --- Noel
>
>-----Original Message-----
>From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
>Sent: Wednesday, January 22, 2003 13:39
>To: 'Avalon Developers List'
>Subject: RE: Excalibur/Cornerstone/James woes
>
>Stephen,
>
>Are you sure this isn't a config problem? Ignoring the empty command for
>the moment, it looks like your mail to "test@localhost" is being routed to
>RemoteDelivery for processing. Maybe because it's in the spammer blacklist?
>A posted configuration file might help immensely. Also, it would probably
>be desirable to flip on debug for all the individual mailets if you haven't
>done so already.
>
>I've got a (somewhat modified) version of James that uses the current
>Cornerstone classes (haven't upgraded all of the Excalibur ones), has
>undergone the Composable->Serviceable change, and runs inside Phoenix.
>Seems to work ok. I'd be happy to share source code with you if you so
>desire.
>
>Also, does your source have the post-2.1 patch that altered the SMTP handler
>data buffering? As that patch was in error, and has since been reverted, it
>may be causing some of your empty command woes. The empty command you are
>observing is symptomatic of a bug introduced with that patch. Please see
>james-dev for a discussion.
>
>--Peter
>
>
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Sent: Wednesday, January 22, 2003 3:17 AM
>>To: Avalon Developers List; James Developers List
>>Subject: Excalibur/Cornerstone/James woes
>>
>>
>>Guys:
>>
>>It looks like my earlier note concerning success with James was
>>premature. I'm back experiencing an loop inside James mail processing
>>and have not been able to isolate the problem.
>>
>>Relevant points:
>>
>> 1. build of James, Cornerstone and Excalibur related resources
>> are all from current CVS
>> 2. James sources have been updated locally to support the service
>> package (to sync with Cornerstone changes)
>>
>>Some important notes:
>>
>> 1. james extends several Cornerstone classes based on Cornerstone
>> implementations from back in June and I suspect that there may
>> be a runtime disconnect here somewhere
>> 2. problem occurs when running under Phoenix or Merlin so I think
>> we can rule out containers as the issue
>>
>>I've put up a log with full debug level on at the following URL:
>>
>> http://www.osm.net/technical/james/james-log.txt
>>
>>Comments added to the log file are prefixed by ##.
>>
>>In order to resolve this problem I would like to import the modified
>>James sources into avalon-sandbox to enable James and Avalon people to
>>dig into this.
>>
>>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>
>
>
>
>
>
--
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: Excalibur/Cornerstone/James woes
Posted by Stephen McConnell <mc...@apache.org>.
Noel J. Bergman wrote:
>We haven't reverted the HEAD, yet, just the v2.1 branch. My plan was to
>submit Peter's revised handler to replace the HEAD. Stephen should pull
>smtphandler.java from branch_2_1_fcs.
>
Tried that and started to get myself into trouble. Seems that the
branch_2_1_fcs version of SMTPHandler is referencing classes that don't
exist in HEAD. Maybe it would be easier if you reverted the HEAD?.
>>In order to resolve this problem I would like to import the modified
>>James sources into avalon-sandbox to enable James and Avalon people
>>to dig into this.
>>
>>
>
>Actually, I'm not sure that I see the point, so please clarify.
>
>
Because I don't want to bring in something that isn't working.
>>from your e-mail it sounds like it makes more sense to me to
>>add a branch to james cvs.
>>
>>
>
>If there is something in James that needs to change that might make sense,
>and we can arrange for commit rights, as was done previously for PeterD and
>PaulH.
>
While working though the code I've been doing little tings like putting
in leg priority test occasional javadoc and stuff like that - comit
privs would help with that - but more useful is the fact that I would be
able to commit and take care of the build and property files I'm using
(no conflict with existing setup - just a couple of build file that tie
into the avalon jars.
>
>
>>I'm confident this is a Cornerstone/Exalibur change issue
>>and we will need assistance from James people
>>
>>
>
>If it isn't in James code, then why do we need a separate copy of the James
>source in the CVS? And if it is, then I think it should be done in our
>module.
>
I'm happy to go with whatever you think is best. Given that this was all
working at one point (post SM rollever), I'm now suspecting that the
problem may be in the James HEAD - but I havn't updated for a few days -
and I'll do that later this evening and see where that leads me.
Cheers, Steve.
p.s. more feedback comming in replay to Pete's email in a moment.
>
> --- Noel
>
>-----Original Message-----
>From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
>Sent: Wednesday, January 22, 2003 13:39
>To: 'Avalon Developers List'
>Subject: RE: Excalibur/Cornerstone/James woes
>
>Stephen,
>
>Are you sure this isn't a config problem? Ignoring the empty command for
>the moment, it looks like your mail to "test@localhost" is being routed to
>RemoteDelivery for processing. Maybe because it's in the spammer blacklist?
>A posted configuration file might help immensely. Also, it would probably
>be desirable to flip on debug for all the individual mailets if you haven't
>done so already.
>
>I've got a (somewhat modified) version of James that uses the current
>Cornerstone classes (haven't upgraded all of the Excalibur ones), has
>undergone the Composable->Serviceable change, and runs inside Phoenix.
>Seems to work ok. I'd be happy to share source code with you if you so
>desire.
>
>Also, does your source have the post-2.1 patch that altered the SMTP handler
>data buffering? As that patch was in error, and has since been reverted, it
>may be causing some of your empty command woes. The empty command you are
>observing is symptomatic of a bug introduced with that patch. Please see
>james-dev for a discussion.
>
>--Peter
>
>
>
>>-----Original Message-----
>>From: Stephen McConnell [mailto:mcconnell@apache.org]
>>Sent: Wednesday, January 22, 2003 3:17 AM
>>To: Avalon Developers List; James Developers List
>>Subject: Excalibur/Cornerstone/James woes
>>
>>
>>Guys:
>>
>>It looks like my earlier note concerning success with James was
>>premature. I'm back experiencing an loop inside James mail processing
>>and have not been able to isolate the problem.
>>
>>Relevant points:
>>
>> 1. build of James, Cornerstone and Excalibur related resources
>> are all from current CVS
>> 2. James sources have been updated locally to support the service
>> package (to sync with Cornerstone changes)
>>
>>Some important notes:
>>
>> 1. james extends several Cornerstone classes based on Cornerstone
>> implementations from back in June and I suspect that there may
>> be a runtime disconnect here somewhere
>> 2. problem occurs when running under Phoenix or Merlin so I think
>> we can rule out containers as the issue
>>
>>I've put up a log with full debug level on at the following URL:
>>
>> http://www.osm.net/technical/james/james-log.txt
>>
>>Comments added to the log file are prefixed by ##.
>>
>>In order to resolve this problem I would like to import the modified
>>James sources into avalon-sandbox to enable James and Avalon people to
>>dig into this.
>>
>>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>
>
>
>
>
>
--
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: Excalibur/Cornerstone/James woes
Posted by "Noel J. Bergman" <no...@devtech.com>.
We haven't reverted the HEAD, yet, just the v2.1 branch. My plan was to
submit Peter's revised handler to replace the HEAD. Stephen should pull
smtphandler.java from branch_2_1_fcs.
> In order to resolve this problem I would like to import the modified
> James sources into avalon-sandbox to enable James and Avalon people
> to dig into this.
Actually, I'm not sure that I see the point, so please clarify.
> from your e-mail it sounds like it makes more sense to me to
> add a branch to james cvs.
If there is something in James that needs to change that might make sense,
and we can arrange for commit rights, as was done previously for PeterD and
PaulH.
> I'm confident this is a Cornerstone/Exalibur change issue
> and we will need assistance from James people
If it isn't in James code, then why do we need a separate copy of the James
source in the CVS? And if it is, then I think it should be done in our
module.
--- Noel
-----Original Message-----
From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
Sent: Wednesday, January 22, 2003 13:39
To: 'Avalon Developers List'
Subject: RE: Excalibur/Cornerstone/James woes
Stephen,
Are you sure this isn't a config problem? Ignoring the empty command for
the moment, it looks like your mail to "test@localhost" is being routed to
RemoteDelivery for processing. Maybe because it's in the spammer blacklist?
A posted configuration file might help immensely. Also, it would probably
be desirable to flip on debug for all the individual mailets if you haven't
done so already.
I've got a (somewhat modified) version of James that uses the current
Cornerstone classes (haven't upgraded all of the Excalibur ones), has
undergone the Composable->Serviceable change, and runs inside Phoenix.
Seems to work ok. I'd be happy to share source code with you if you so
desire.
Also, does your source have the post-2.1 patch that altered the SMTP handler
data buffering? As that patch was in error, and has since been reverted, it
may be causing some of your empty command woes. The empty command you are
observing is symptomatic of a bug introduced with that patch. Please see
james-dev for a discussion.
--Peter
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, January 22, 2003 3:17 AM
> To: Avalon Developers List; James Developers List
> Subject: Excalibur/Cornerstone/James woes
>
>
> Guys:
>
> It looks like my earlier note concerning success with James was
> premature. I'm back experiencing an loop inside James mail processing
> and have not been able to isolate the problem.
>
> Relevant points:
>
> 1. build of James, Cornerstone and Excalibur related resources
> are all from current CVS
> 2. James sources have been updated locally to support the service
> package (to sync with Cornerstone changes)
>
> Some important notes:
>
> 1. james extends several Cornerstone classes based on Cornerstone
> implementations from back in June and I suspect that there may
> be a runtime disconnect here somewhere
> 2. problem occurs when running under Phoenix or Merlin so I think
> we can rule out containers as the issue
>
> I've put up a log with full debug level on at the following URL:
>
> http://www.osm.net/technical/james/james-log.txt
>
> Comments added to the log file are prefixed by ##.
>
> In order to resolve this problem I would like to import the modified
> James sources into avalon-sandbox to enable James and Avalon people to
> dig into this.
>
> 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: Excalibur/Cornerstone/James woes
Posted by "Noel J. Bergman" <no...@devtech.com>.
We haven't reverted the HEAD, yet, just the v2.1 branch. My plan was to
submit Peter's revised handler to replace the HEAD. Stephen should pull
smtphandler.java from branch_2_1_fcs.
> In order to resolve this problem I would like to import the modified
> James sources into avalon-sandbox to enable James and Avalon people
> to dig into this.
Actually, I'm not sure that I see the point, so please clarify.
> from your e-mail it sounds like it makes more sense to me to
> add a branch to james cvs.
If there is something in James that needs to change that might make sense,
and we can arrange for commit rights, as was done previously for PeterD and
PaulH.
> I'm confident this is a Cornerstone/Exalibur change issue
> and we will need assistance from James people
If it isn't in James code, then why do we need a separate copy of the James
source in the CVS? And if it is, then I think it should be done in our
module.
--- Noel
-----Original Message-----
From: Peter M. Goldstein [mailto:peter_m_goldstein@yahoo.com]
Sent: Wednesday, January 22, 2003 13:39
To: 'Avalon Developers List'
Subject: RE: Excalibur/Cornerstone/James woes
Stephen,
Are you sure this isn't a config problem? Ignoring the empty command for
the moment, it looks like your mail to "test@localhost" is being routed to
RemoteDelivery for processing. Maybe because it's in the spammer blacklist?
A posted configuration file might help immensely. Also, it would probably
be desirable to flip on debug for all the individual mailets if you haven't
done so already.
I've got a (somewhat modified) version of James that uses the current
Cornerstone classes (haven't upgraded all of the Excalibur ones), has
undergone the Composable->Serviceable change, and runs inside Phoenix.
Seems to work ok. I'd be happy to share source code with you if you so
desire.
Also, does your source have the post-2.1 patch that altered the SMTP handler
data buffering? As that patch was in error, and has since been reverted, it
may be causing some of your empty command woes. The empty command you are
observing is symptomatic of a bug introduced with that patch. Please see
james-dev for a discussion.
--Peter
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, January 22, 2003 3:17 AM
> To: Avalon Developers List; James Developers List
> Subject: Excalibur/Cornerstone/James woes
>
>
> Guys:
>
> It looks like my earlier note concerning success with James was
> premature. I'm back experiencing an loop inside James mail processing
> and have not been able to isolate the problem.
>
> Relevant points:
>
> 1. build of James, Cornerstone and Excalibur related resources
> are all from current CVS
> 2. James sources have been updated locally to support the service
> package (to sync with Cornerstone changes)
>
> Some important notes:
>
> 1. james extends several Cornerstone classes based on Cornerstone
> implementations from back in June and I suspect that there may
> be a runtime disconnect here somewhere
> 2. problem occurs when running under Phoenix or Merlin so I think
> we can rule out containers as the issue
>
> I've put up a log with full debug level on at the following URL:
>
> http://www.osm.net/technical/james/james-log.txt
>
> Comments added to the log file are prefixed by ##.
>
> In order to resolve this problem I would like to import the modified
> James sources into avalon-sandbox to enable James and Avalon people to
> dig into this.
>
> 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: Excalibur/Cornerstone/James woes
Posted by "Peter M. Goldstein" <pe...@yahoo.com>.
Stephen,
Are you sure this isn't a config problem? Ignoring the empty command for
the moment, it looks like your mail to "test@localhost" is being routed to
RemoteDelivery for processing. Maybe because it's in the spammer blacklist?
A posted configuration file might help immensely. Also, it would probably
be desirable to flip on debug for all the individual mailets if you haven't
done so already.
I've got a (somewhat modified) version of James that uses the current
Cornerstone classes (haven't upgraded all of the Excalibur ones), has
undergone the Composable->Serviceable change, and runs inside Phoenix.
Seems to work ok. I'd be happy to share source code with you if you so
desire.
Also, does your source have the post-2.1 patch that altered the SMTP handler
data buffering? As that patch was in error, and has since been reverted, it
may be causing some of your empty command woes. The empty command you are
observing is symptomatic of a bug introduced with that patch. Please see
james-dev for a discussion.
--Peter
> -----Original Message-----
> From: Stephen McConnell [mailto:mcconnell@apache.org]
> Sent: Wednesday, January 22, 2003 3:17 AM
> To: Avalon Developers List; James Developers List
> Subject: Excalibur/Cornerstone/James woes
>
>
> Guys:
>
> It looks like my earlier note concerning success with James was
> premature. I'm back experiencing an loop inside James mail processing
> and have not been able to isolate the problem.
>
> Relevant points:
>
> 1. build of James, Cornerstone and Excalibur related resources
> are all from current CVS
> 2. James sources have been updated locally to support the service
> package (to sync with Cornerstone changes)
>
> Some important notes:
>
> 1. james extends several Cornerstone classes based on Cornerstone
> implementations from back in June and I suspect that there may
> be a runtime disconnect here somewhere
> 2. problem occurs when running under Phoenix or Merlin so I think
> we can rule out containers as the issue
>
> I've put up a log with full debug level on at the following URL:
>
> http://www.osm.net/technical/james/james-log.txt
>
> Comments added to the log file are prefixed by ##.
>
> In order to resolve this problem I would like to import the modified
> James sources into avalon-sandbox to enable James and Avalon people to
> dig into this.
>
> 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>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>