On 8/18/05, Gary VanMatre <[EMAIL PROTECTED]> wrote:
> > On 7/28/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > >
> > > Now that would be cool.  I think we would have to load all clay config 
> > > files
> > to resolve the inheritance dependencies but that would be way slick.
> > >
> >
> > Yep, you'd need to reload the whole set.  Plus, do it in a way that
> > does not require you to have sync locks on all the *uses* of the old
> > configuration data while the new stuff is being parsed.
> >
> > For production deployment, it's likely that we would want the reload
> > capability disabled (most of the IT guys I know would laugh me out of
> > the room if I proposed to fix a typo in a running JSP page, on a live
> > production app :-).  Indeed, disabled should probably be the default,
> > so that you can turn it on for development via a context parameter or
> > something.
> >
> 
> I was poking around in log4j and found a very similar feature that allows you 
> to configure a file watch dog for the properties files.  It would be pretty 
> simple to extend the abstract  org.apache.log4j.helpers.FileWatchdog 
> implementation.  We don't have a dependency with log4j in Shale.
> 

Besides the issues on creating threads (which could be handled
differently -- say with a Filter -- in environments where they were
disallowed), it's not clear to me that a solution focused solely on
files is the right one.  Yes, that is a very common use case, but I'd
rather see the concept implemented based on using the URL APIs to
detect the "last modified" time.  The input would be the URL returned
by ServletContext.getResourceURL(), and you would thus be able to
operate on servlet containers that, say, stored some of their static
content in a database instead of in the filesystem.

Craig

> Would it be possible to copy in the one class leaving the original Copyright? 
>  I know that we have a similar discussion regarding Clay and Tapestry but I 
> didn't have the courage to ask.
> 
> Gary
> 
> 
> > >
> > > Gary
> > >
> >
> > Craig
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to