I didn't finish #4..sorry... 4) Your integration of setting the manager (no matter what) is a direct clash with the Tomcat clustering components (GBeans). We need a more unified approach to selecting a clustering component.
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 >>> >>
