It might be worthwhile to sufficiently generalize this so that it can be
used by applications that have their own config files.
david
2006/8/28, Gary VanMatre <[EMAIL PROTECTED]>:
>From: "Craig McClanahan" <[EMAIL PROTECTED]>
>
> 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.jsp into
> > 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.xml to
> > 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
