to give the question its correct context:
Jeff said:
You need to support both per container and per app. Thats the way the
Tomcat clustering works today and it allows for the most flexible
ability to choose what level. There are certain web applications that
you don't want clustered, like the console.
then I said :
well then, you wouldn't use the <distributed/> tag in the app's
WEB-INF/web.xml, would you ?
than Jeff said :
Why not?
now I say :
Jeff, putting <distributable/> in your app's WEB-INF/web.xml signals to
the container that it wishes to be clustered.
An app which does not wish to be clustered would not include this tag
and the container would make no attempt to cluster it.
So, if the console did not wish to be clustered it would not include
this tag....
The decision about clustering is made on a per-app basis in a standard
descriptor as laid out in the spec.
How that clustering is achieved is left to the container and may usually
be configured in a proprietary descriptor or plan.
Is that clearer ?
Jules
Jules
in a per-container situation, as I ultimately envisage the Geronimo
integration, apps will simply need to declare a <distributable/> tag,
unless they want to override the container's choice (see per-app in next
para). No infra jars or wadi dd should be required in the app - all
should be provided/defaulted by the container...
The above should not preclude the possibility of the per-app approach,
where the app can take total control of how it is clustered - our
current approach to the Geronimo integration, by shipping the whole
infra and dd itself (possibly reusing existing container infra like jars
whose presence is guaranteed in the container).
These are two different approaches and I would have concerns about
muddling them up.
There is one further possibility, already touched on, that rather than
these two approaches being exclusive the per-app stuff might somehow be
overlaid ontop of the per-container stuff.... My jury is still out on
whether this could be done simply enough to make it worthwhile...
With regards to Axion - its just there to illustrate a point - when we
have more time, we can test WADI with other DBs that Geronimo might
easily be hooked to.
Regardless, its wrong and I -1d it from a Geronimo perspective. We
should not be testing with HEAD and hardcoding application based
dependencies at the container level. I suspect the others would agree.
According to the emails, Jan has gotten past this...so this should be a
dead issue.
With regards to other ClassLoader issues - these are always going to be
an issue with the per-app approach - I think... Hopefully, we will move
to a per-container approach soon (See Gianny's work) and resolve all of
these issues.
Not necessarily. The entire plan with specific configuration
should get past this issue. David Jencks has some good ideas for WADI
in its own configuration and I think he is spot on.
Jules
Jeff Genender wrote:
Greg Wilkins wrote:
Jeff Genender wrote:
This would be a big issue. This would tie the connector to the
container.
There is a better solution. Please move the Spring jar out of the
container and place it in the WEB-INF/lib. Same for Axion.
Then in your plan...please add the following to your plan:
<hidden-classes><filter>org.springframework</filter></hidden-classes>
This should force the web app to use the local Spring which has
access
to the Axion lib in the web app.
I really think we need to take a step back and look at the whole
deployment
and configuration issue.
A webapp should be able to be distributed simply by saying
<distributable/> in its web.xml. It should not have to include
spring jars or any other jars for
that matter in it's WEB-INF. Any per web-app configuration for wadi
should be
able to be achieved without any jars - either in a wadi-web.xml file
or perhaps
just as context init-params in the web.xml?
I agree somewhat with you...but not completely. The <distributable>
tag
is only one small component. We should be able to swap out with any
clustering engine, so I think it goes beyond this. I do agree,
however,
that there should be no need for WADI jars in the WEB-INF/lib. The
configuration really should come from a WADI configuration car that is
imported into the plan. This along with a distributable tag can
make it
happen. But I would like to see the imported car in the
geronimo-web.xml or plan file to be the clustering engine of choice.
Having said that, adding spring to the hidden classes is a good
idea. Actually
ALL the classes used by Wadi should be hidden, as the servlet
specification says
that container implementation classes should not be visible to a web
application.
It is a bit of a hack to allow them to be seen and manipulated by
individual
web applications.
This is a bigger issue that you think and affects far more than just
WADI. Yesterday I just helped a friend deploy a simple
Spring/Hibernate
application to Geronimo and it failed. The only way to have it happen
was provide the hidden-classes filter for Spring and Antlr. The
problem
here was that we injected the Spring libs at the container level and
via
the J2EE specs, it was using that for certain calls and the WEB-INF/lib
for others, thus offering ClassNotFoundExceptions (sound familiar?).
This goes back to the old commons logging problem that is so common,
even with other app servers and containers. I don't think this is
avoidable due to the class loading engine and the very large amount of
components that Geronimo uses. We will be filtering out a lot in the
future.
I think the idea of having the full clustering solution within
WEB-INF was a good
idea to get Wadi running on multiple containers.... but for real
deployments it
is not sufficient and we need to look at container support for Wadi.
I agree with you 100% on this point.
cheers
--
"Open Source is a self-assembling organism. You dangle a piece of
string into a super-saturated solution and a whole operating-system
crystallises out around it."
/**********************************
* Jules Gosnell
* Partner
* Core Developers Network (Europe)
*
* www.coredevelopers.net
*
* Open Source Training & Support.
**********************************/
