+1. This is really great stuff. Jeff
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 container-level, these issues will disappear and >>> WADI will be able to be hooked to whatever persistance mechanism is >>> shipped in Geronimo by default. >>> >>> - Jan & Jeff , you may want to consider pushing some of this session >>> manager selection code up into a shared GeronimoWebContainer abstraction >>> so that you don't both end up maintaining similar but diverging code... >>> >>> - I may have overlooked a couple of issues. If I come across them, I >>> shall post them. >>> >>> Further work on Geronimo integration : >>> >>> - more testing >>> - make a new WADI release and update geronimo-trunk to use it >>> - look at applying diffs to a G1.0 tree and producing a binary patch for >>> 1.0 distros. >>> - update website and release it >>> >>> >>> Jules >>> >>> >>> >>> Jules Gosnell wrote: >>> >>> >>>> Guys, >>>> >>>> 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. >>>> >>>> Each top level web container GBean now supports a pair of attributes - >>>> LocalSessionManager and DistributableSessionManager. These may be used >>>> to override the container's choice of SessionManager for webapps with >>>> and without the <distributable/> tag present in the WEB-INF/web.xml, >>>> respectively. >>>> >>>> The attributes expect to be given a classname, if required, this class >>>> will be loaded and instantiated. The resulting instance will be used >>>> as the session manager. If not provided, the container will use a >>>> sensible default. Currently Jetty and TC are set up to use their own >>>> default session managers in the local case and the correct WADI >>>> session manager in the distributable case. >>>> >>>> This means that the same WADI-enabled webapp, with its plan held >>>> internally (WEB-INF/geronimo-web.xml) may now be hot-deployed on >>>> either a Jetty or a Tomcat based Geronimo, without changes :-) >>>> >>>> I will post specific WADI issues to the WADI dev lists >>>> ([email protected], [EMAIL PROTECTED]). >>>> >>>> This shouldn't be seen as a final position on the subject - there is >>>> still much to talk about, but is a useful interim step, that allows us >>>> to have something working whilst we figure out how to go forward. >>>> >>>> Enjoy, >>>> >>>> >>>> Jules >>>> >>>> >>> > >
