Being eager to release the Beta, I decided to write my own
ServletContextResourceLocator. It is called WebappResourceLocator.This
allowed me to apply all the patches. Let me know if anything is
missing.
Also I followed the suggestion by Scott to rename ServletConfiguration
(new class is called WebappCayenneListener). ServletConfiguration
inherits from it with a deprecation note.
This is all in CVS, though untested yet. I will do the testing and
documentation update later today.
Andrus
On Saturday, April 19, 2003, at 11:18 AM, Andrus Adamchik wrote:
> 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 - 15:37:27 EDT