+1
On Jan 14, 2006, at 4:46 AM, Jules Gosnell wrote:
OK, Folks - here is how I see it -
Everyone knows that they are right and the other guy is wrong.
Result - DEADLOCK - everyone loses.
Solution - release locks, back off, coordinate, retry.
Releasing locks involves us all making concessions :
I suggest -
Jan, Greg and I conceded that Jeff could have been more involved in
discussion before this change went in.
Jeff concedes that Jan, Greg and I should have been involved in
discussion before he backed the change out.
We all agree to overlook all current technical differences.
We all agree to put aside whatever bad feelings may have arisen
from this incident.
OK - locks released, backing-off complete.
Now, coordination :
WADI side :
I will downgrade the log.info to a log.debug
I will remove the axion dependency.
I will resubmit the change as a patch to Jan and Jeff.
Jetty/Tomcat side :
Jan and Jeff will take this patch, and all relevant input.
If they feel that they need further discussion, they will have it.
They will implement a simple, unified solution to the issue for all
existing cases and get it in to Geronimo 1.0.1
I simply want a speedy, painless resolution so we can continue
forward.
If everyone else is happy with these terms, then here is my '+1'
Jules
Jeff Genender wrote:
Hi Jules.
A few comments. First, you made changes without discussing them
on the
dev lists.
As per the discussions in the past, both Aaron and David Jencks,
as well
as I threw in our .02 on how to integrate the clustering. I would
appreciate you discuss code ideas and changes that have such a
drastic
impact on the Geronimo code base. Here are the issues with your
check in:
1) I explained before for Jetty, and obviously now I need to do it
for
Tomcat, a -1 on Axion as a dependency. There should not be any web
application dependencies injected at the container level. This means
there is a severe architectural issue with WADI when we are injecting
these dependencies into the container.
2) You hard coded in org.codehaus.wadi.tomcat55.TomcatManager as the
distributablesession manager in the TomcatContainer. Hardcoding a
pluggable session engine is very bad, and defeats the pluggability
of a
configuration that we requested.
3) You placed log.info() in the code, and Aaron worked pretty hard to
clean those up.
4) Your integration of setting the manager (no matter what) is a
direct
clash with the
Jules, I am giving a complete -1 of checkin of 368344. These are all
for technical reasons. Please back out these changes, and bring this
discussion to the Geronimo lists as this needs some significant
discussion for implementation. I would appreciate that you please
involve the Apache way and open discussions on the lists before doing
this sort of thing in the future.
Again, I will CC the G lists to make this clear, that I would like
this
change backed out.
Jeff
Jules Gosnell wrote:
Here is a list of outstanding issues associated with this work:
- ActiveMQ's shutdown hook seems to trigger when Geronimo is
shutdown,
removing AMQ before WADI - WADI doesn't like this. I have added a
property to the node.sh script which suppresses this behaviour. I
will
document it in the Getting Started doc.
- There 'may' be issues with nodes finding each other, when a
Geronimo
node is introduced into a WADI cluster - investigating.
- Jeff - you should look over the changes and make sure that they
do not
impact on any other TC fn-ality. They were done with Emacs, so the
formatting may be offensive. Please feel free to make them your
own and
bring any issues back to the list. The WADIGBean, is no longer
used, so
you may want to remove this from the repo.
- Jan and Jeff - since this config is now done on the container
bean and
not in the geronimo-web.xml, you may no longer need to implement
your
own geronimo-web.xml schemas (I haven't looked very closely at
TC). You
may want to consider this and perhaps lose them.
- In order to get the same webapp to work in all containers
(tomcat5[05], jetty[56], geronimo-[tomcat/jetty], jboss-tomcat),
I had
to move deps back to Geronimo container-level. These include Axion,
which I know will upset Jeff. As I have stated before, WADI's
dependence
on Axion is easily removed. If Jeff or anyone wants to look at
replacing
it with Derby, it is fine with me, as long as they do some
testing and
confirm that having created a session on a single node and
restarted it,
the session survives (if the DB is still running). This needs to be
tested on all supported containers. Axion was used because it is an
in-VM DB (so imposes no further integration dependencies on the
Getting
Started stuff and is useful for unit-testing) and was in use by
Geronimo
at the time. So I suggest that any replacement needs to also be
able to
run in-vm aswell. As we go further and move WADI's actual
configuration
from the app to the
