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
