On 8/29/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>From: "David Geary" <[EMAIL PROTECTED]>
>
> It might be worthwhile to sufficiently generalize this so that it can be
> used by applications that have their own config files.
>
Yea, even if it was not used by something other than Clay, it would clean
up that monster ComponentConfigBean class :-)
It would be great to pull this out into a common utility class in shale-core
(or perhaps even conceive of a separate little non-Shale-dependent utility
module that can do all the dirty work of watching for changes for you.
Craig
> david
>
Gary
> 2006/8/28, Gary VanMatre :
> >
> > >From: "Craig McClanahan"
> > >
> > > On 8/28/06, Paul Spencer wrote:
> > > >
> > > > Should the following be added as a requirements:
> > > >
> > > > o A managed bean can be populated by one or more action and views
> > solely
> > > > via
> > > > configuration. The use of the dialog API by the user's application
is
> > > > not needed.
> > > > Said another way, an existing JSF Bean and view, view.jsp, can be
> > > > broken up into
> > > > a dialog by configuring the dialog and breaking apart view.jspinto
> > > > many
> > > > jsp files.
> > > > (Currently this is possible when using session managed beans.)
> > >
> > >
> > > I'm not quite sure how to articulate this as a requirement. Woutd it
be
> > > sufficient to say "You should be able to utilize the dialog
> > functionality
> > > WITHOUT being required to use the provided state storage mechanism (
i.e.
> > #{
> > > dialog.data.foo}), as long as the application manages this state
itself"
> > or
> > > something like that?. If so, I think that might be a reasonable
> > requirement
> > > to add -- although in practice I'm having a hard time figuring out
how a
> > > dialog framework could make this NOT work.
> > >
> > > o Changes to the dialog configuration will not require a restart of
the
> > > > application
> > > > in order to take affect. (Currently the servlet engine must be
> > > > restarted or the
> > > > web application must be reloaded for changes to dialog-config.xmlto
> > > > take affect.)
> > >
> > >
> > > Makes sense ... and it should apply to any and all configuration
files,
> > not
> > > just the dialog one. I think Clay has a mechanism for this already
that
> > we
> > > should be able to reuse.
> > >
> >
> > Clay's file reload mechanism is wired into the ComponentConfigBean as
an
> > inner class called WatchDog.
> >
> >
> >
>
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/
> apache/shale/clay/config/beans/ComponentConfigBean.java?view=markup
> >
> > A group or single file is defined by a logical name. If one of the
files
> > in the group is dirty, the entire group is reloaded. You can also
force a
> > reload. This is necessary if one group has a dependency with another
> > group. For example, in Clay, if a common config file is changed, all
files > > need to be reloaded since definitions in one file can extend
definitions in
> > the commons config files. We might be able to abstract out with a
couple
> > hooks you need to implement or register a callback adapter. Commons
chains
> > might also work here.
> >
> > The files are define using a top level interface. It could also be
pulled
> > out.
> >
> >
> >
>
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/
> apache/shale/clay/config/beans/ConfigBean.java?view=markup
> >
> > It uses a preprocess filter command as the timer so there are not any
> > threads not controlled by the container.
> >
> >
> >
>
http://svn.apache.org/viewvc/shale/framework/trunk/shale-clay/src/main/java/org/
>
apache/shale/clay/config/beans/ConfigDefinitionsWatchdogFilter.java?view=markup
> >
> >
> >
> > > Paul Spencer
> > >
> > >
> > > Craig
> >
> > Gary
> >
