Holger,
I hope you do check them in so that others can review the code and what I
say
below will have a context. But read my explanations to some of your queries
before doing so to be sure you are okay with the change. Nothing I did
should
break anyone's use of these classes, but I did refactor them.
> - while looking over Scott's patches it occurred to me that I do not
> really understand the separation between BasicServletConfiguration and
> ServletConfiguration. Shouldn't we merge the two into one working, instead
> of two that both don't work anymore and somehow seem to be linked together
> for no (?) good reason?
IMHO, there should be two classes and the "link" should be changed. You'll
notice, Holger, that I broke the inheritance of ServletConfiguration from
BasicServletConfiguration. I'll explain why, but first let me say why I
think there should be two:
Prior to servlets 2.3, initialization in a servlet context occurred by
having
a servlet load on startup and do some things in its init method.
-- one scenario is a developer using a container based on servlets 2.2.
With servlets 2.3, initialization can still take place that way though there
is now an explicit context/container initialization hook with
ServletContextListener. It is reported that the 2.2 method is risky in
that the container could load more than one copy, unload and load at
will(?).
-- second scenario is a developer using a container based on servlets 2.3.
Thus in support of the two scenarios - I vote for two classes.
> - Scott, you introduced a new parameter cayenne.configuration.path - why?
> It seems to add a search path to the RL and comes from the ServletContext.
> Is this a common way to configure Servlet apps? (I really don't know). The
> previous ServletConfig works without external parameters (always a good
> cause for setup difficulties) and I'd like to keep it that way, simply
> because it's IMHO yet another thing that people will most likely get
> wrong. This was one of the ideas behind the ResourceLocator, as I
> understood it. It seems to work without, if I read the code correctly.
I changed BasicServletConfiguration to extend DefaultConfiguration since
all we need to do in a servlet context is add a new location to look for
configuration files based on the ServletContext.
Toward that end I created a ServletContextResourceLocator that utilizes
the ServletContext to locate a resource. By default (as I agree with
the philosophy that it should be as easy as possible to use), the
ServletContextResourceLocator will look for resources in "/WEB-INF"
relative to the context - this was the existing behavior. Also, it will
handle paths that begin with "/WEB-INF" in this special way (relative to
the context), other paths it defaults to the ResourceLocator behavior -
this forces resources to be somewhere under "/WEB-INF" in the servlet
context.
I added the optional (you were correct, Holger) context parameter to
allow a developer to specify an additional location relative to the
context to look. So if the developer prefers to put their configuration
files in "/WEB-INF/conf" they could specify a context parameter and the
ServletContextResourceLocator would add that to its paths to search.
E.g., in the application's web.xml:
<context-param>
<param-name>cayenne.configuration.path</param-name>
<param-value>/WEB-INF/conf</param-value>
</context-param>
As I said its optional - it adds a path in addition to the default
"/WEB-INF" location. I seem to remember a request for this on the
list - allowing for a different location under "/WEB-INF"....
So, BasicServletConfiguration takes care of providing a Configuration
in the servlets world.
As I said, in what I gave to Holger, ServletConfiguration no longer
inherits from BasicServletConfiguration. Rather it uses
BasicServletConfiguration. ServletConfiguration is just a
ServletContextListener and HttpSessionListener. It is an means for
integrating cayenne into a servlets 2.3 container using its hooks.
I struggled with renaming it to CayenneListener since it no longer
extends from Configuration. I also added some extension points to
ServletConfiguration to allow a developer to use some other
Configuration, possibly their own extension of
BasicServletConfiguration... that is why you see the newConfiguration
(ServletContext), setConfiguration(Configuration) and
getConfiguration() methods.
Scott Finnerty
This archive was generated by hypermail 2.0.0 : Fri Apr 18 2003 - 10:52:27 EDT