Jeff,
I really can't understand your -1, let alone the backing out of
the changes, nor all of the hullabaloo.
It is quite straightforward: in 1.0 WADI did not work in Tomcat
nor Jetty. Unfortunate and disappointing, but true. Period.
We have made minimal changes to make it work in the 1.0.1 bug-fix release,
and started to move us toward a container-based configuration solution
(which all of us agree on) instead of a per-webapp configuration solution
(which all of us agree is not desirable). So we are actually all in
agreement!
There is much more work to be done on the architecture as we all
know, but that is something for a 1.1 release, not another rushed
solution for the 1.0.1 bugfix release (and rushing is what caused
us both to miss the 1.0 deadline).
I really feel you have attacked me inappropriately and quite wrongly
over this Axion jar issue. You said:
Greg, based on the fact that I -1'd Jan's inclusion of Axion on 1/5, and
it was never tended too, am I to believe the same would have occurred
here? If you think I should have waited a few days, then perhaps I
could have. But based on past history with you guys and handling -1s, I
don't think it was unreasonable for me to think that you weren't going
to remove it. Its now a full week (1/5-1/12) after the -1, and it has
not been removed. How long is a reasonable time to wait for you to back
out -1s?
If you check the SVN log you will find this:
r366693 | janb | 2006-01-07 09:19:14 +0100 (Sat, 07 Jan 2006) | 2 lines
removing axion and special activemq wadi versions and therefore jgenenders'
codehaus repository from repo list
I did this shortly after I replied to your email of 6th January. Here is what I
said to you:
Jeff,
Thanks for that, I will remove the unnecessary ones. I wasn't
sure whether the activemq WADI version was needed or not, so
thanks for clarifying that. I will fix up Geronimo tomorrow.
cheers
Jan
And I did exactly just that - removed Axion (and the WADI-3.2 of activemq).
So can we just leave the accusations aside, put the code back in place,
and get on with working together to ensure the code works and addresses
all immediate concerns, or otherwise we will miss the 1.0.1 deadline too.
sincerely,
Jan
I sat in the room with Jules and Jan for three days while they worked on this.
They certainly were discussing all the threads about this and they tried
several times for a more minimal solution (name spaces etc.) but
nothing else proved workable.
That, in and of itself is the problem Greg. Lets bring this out on the
lists, not in a room with Jules, Jan, and yourself. Jules said, "Jan and
Greg are staying with me for a few days, starting monday. We will go
through the integration together and keep the list up to date with any
issues that we find."
He never brought the discussion as he stated, and then followed it up
today (1/12) with: "Jan and I have just refactored the Geronimo Jetty
and Tomcat integrations to take the same approach to the installation of
a 3rd party session manager, to ease the integration of WADI. This is
now checked in on Geronimo's trunk."
Where was the list up to date on discussion of what you have found,
relative to the requests we made previously on the lists about what we
want to see in the integration? Am I missing something here?
So they moved one aspect of the config out of the WEB-INF and as a result
they were able to get a webapp deployed on a mixed cluster of geronimo-jetty
and geronimo-tomcat - HOORAY!
Great...lets chat about it...I am all for open discussion on this! Lets
see what they came up with...and work with the ideas into something that
is a good solution for the team and community! But I wouldn't say the
change (one aspect) was that simple from an impact perspective, Greg.
They deserve thanks for a good achievement and some peer review to
help them improve it. The certainly don't deserve unilateral action
to erase their work and send every body back to square -1.
Peer review? And where did that occur? See the above comments about
Jules working with you on this, then checking it all in. I saw no peer
review. Remember, this is an Apache project (Geronimo)...you should be
sharing info with the community.
Nobody said it wasn't a valiant attempt, nor that the intentions weren't
good. Based on the Axion issues, one of my -1s has nothing to do with
intentions, it has to do with putting the database hard coded dependency
in the container. That is a serious architectural flaw. I -1'd that on
the Jetty side as well.
If you needed to try things out...and get a review afterwards, why
didn't you just cut a quick branch and show off your changes? Nobody
would have -1d that.
I agree with David that the session manager configuration should be moved
again to a clustering GBean, but that does not mean that we should move it back
to WEB-INF while we wait for a better solution. This was a minimal solution
that can be put in place in time for 1.0.1. We don't have time to create
a clustering module before then.
Greg, I think the point here is we all need to discuss this before doing
this. The Apache way, remember? If you all discussed this openly,
perhaps the config could be built by now, yes?
As for the axion dependancy, I do believe this is a container dependancy.
Axion is being used to persist the session - which is a web container
function, not a webapp function. We had discussed this and I thought you had
agreed with me on this point - that we should not have to put WADI dependancies
into WEB-INF/lib of the apps so they can be clustered.
Greg, that is a complete fabrication of the truth. I am sorry Greg, I
never agreed with Axion being in the container. I did agree with the
ability to inject the clustering as a pluggable configuration at the
container or context level. That is as far as I agreed. If we need a
connector (READ: RAR) to be used for the database, then this is
fine...its a pluggable component. But as a hard code, its simply wrong.
As for Axion being used to persist the session and is a container
dependency, I disagree...lets look at where axion is being used in WADI:
./modules/core/src/test/org/codehaus/wadi/sandbox/jcache/TestJCache.java
./modules/core/src/test/org/codehaus/wadi/test/activecluster/TestCluster.java
./modules/core/src/test/org/codehaus/wadi/test/TestContextualiser.java
./modules/core/src/test/org/codehaus/wadi/test/TestGianni.java
./modules/core/src/test/org/codehaus/wadi/test/TestMotables.java
./modules/core/src/test/org/codehaus/wadi/test/TestReplication.java
./modules/itest/src/test/java/org/codehaus/wadi/itest/ContainerTestDecorator.java
These are all test cases Greg. I am not understanding why its not using
a connector if it needs a database.
Of you 4 points, which is the one that is driving your -1? Ie, if point
4) is address (not clashing with tomcat clustering), is that sufficient?
I do think that 1,2 and 3 have been addressed and none seam worth a -1 in
any case.
Sorry, I don't think any of the points have been addressed at all. You
want a list, here are some: The hard code of the wadi manager...the
Axion dependency, lack of pluggable configuration, lack of ability to
set Clustering options (properties) at the clustering component level.
Shall I go on?
I think we have been through this. Lets stop this nonsense and move
forward on an open discussion with David Jencks' thread. I think if we
can concentrate on the positive aspects, we can get this properly going.
Can we work together as a team, Greg?
Lets move on guys...we all should be moving forward here and stop
dwelling on this.
regards
