[cas-dev] thoughts on org.jasig.cas.web.init.SafeContextLoaderListener..

[Scott Battaglia]

Andrew,

(sorry for the completely delayed response on this).

I completely understand the intent for which they were created.  However my
concern is that most people do not disable it before they enter production.
It should not be enabled in production as it deploys CAS in an inconsistent
state rather than failing completely as it should (in fact the only
configuration file we really recommend people change is the
deployerConfigContext.xml so most people probably don't even realize these
things exist).  Its also inconsistent with the way most other Spring
applications fail with respect to configuration errors (which may or may not
be a huge deal but its something to note).

As for why people were unclear about whether it was okay to remove the
additional listeners and servlets, I have no explanation.  I can merely
comment that I've had to clarify for people that it is safe to remove them
and replace them.

I'm curious as to other people's opinions on whether these are significantly
useful for them vs. the traditional Spring exceptions at deployment.

-Scott

On 2/6/07, Andrew Petro < apetro at unicon.net> wrote:
>
> Scott,
>
> The wrappers for the Spring context loader and dispatcher servlet were
> implemented in order to soften the experience for a quickstart CAS
> adopter.  As of when they were created, the experience for a CAS and
> Spring newbie in modifying a Spring bean declaration XML file and
> introducing a fatal misconfiguration (say failing to close a tag) would
> be that context initialization would fail entirely.
>
> The thought was that a more friendly newbie experience on having
> introduced a fatal misconfiguration is for the CAS application to
> successfully start and present an error user experience advising the new
> deployer of what might be wrong.
>
> When the Yale folks gave the getting started with CAS JA-SIG
> pre-conference seminar, this behavior did in fact make the hands-on CAS
> customization exercises go more smoothly.
>
> I sympathize with the "additional options cause confusion" problem but I
> wonder why the thorough commenting in web.xml indicating that they are
> replacable and what they might be replaced with is insufficient to help
> people understand that they are optional and to make an informed choice
> among the options.
>
> web.xml file as exposed by FishEye:
>
> http://tinyurl.com/2kwe7t
>
> Andrew
>
> Scott Battaglia wrote:
> > We currently wrap the Spring ContextLoaderListener and DispatcherServlet
> > in order to show a "pretty" error message for a FATAL start up, which in
>
> > general should be caught during testing (or within 30 seconds of
> > deploying to production).
> >
> > Does anyone see any benefit to these? We disable them at Rutgers (why
> > have the extra method calls).  I have also seen them cause confusion as
> > people think they can't replace them and they are necessary for CAS to
> > function.
> >
> > Any objection to removing them?
> >
> > -Scott
> >
> >
> > ------------------------------------------------------------------------
>
> >
> > _______________________________________________
> > cas-dev mailing list
> > cas-dev at tp.its.yale.edu
> > http://tp.its.yale.edu/mailman/listinfo/cas-dev
> _______________________________________________
> cas-dev mailing list
> cas-dev at tp.its.yale.edu
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://tp.its.yale.edu/pipermail/cas-dev/attachments/20070226/74d8881d/attachment.html