Scott, Holger,
In the patches that Holger sent me, ServletContextResourceLocator.java
is missing. Could you send this file to me ASAP, since I can't apply
the patch without it. This delays the release.
Thanks.
Andrus
On Friday, April 18, 2003, at 11:08 AM, Scott Finnerty wrote:
> I should also note that with the use of ServletContextResourceLocator,
> resources can be in the classpath - i.e., /WEB-INF/classes, a jar in
> /WEB-INF/lib or the container's classpath.
>
> I just noticed that BasicServletConfiguration effectively assumes the
> default domain file name as defined by
> Configuration.DEFAULT_DOMAIN_FILE.
> To allow for different names, additional constructors would need to be
> added... I can fix and submit a new patch if you like.
>
> Scott
>
> -----Original Message-----
> From: Scott Finnerty [mailto:scot..odefuey.com]
> Sent: Friday, April 18, 2003 9:47 AM
> To: cayenne-deve..bjectstyle.org
> Subject: RE: Status of BasicServletConfiguration
>
>
> 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 : Sat Apr 19 2003 - 11:24:00 EDT