> On Jul 28, 2005, at 3:54 PM, [EMAIL PROTECTED] wrote:
> >> 1) How to trigger a reload()? Via a request to the servlet or some
> >> kind of API call, or a process that is "watching" the config files.
> >> Could maybe work like JSP, when you ask for a definition, the factory
> >> will look to see if it has changed.
> >>
> >
> > Ya, I kind of had the same question. I guess that we are free to fire
> > up our own threads in the servlet container. Maybe a thread object
> > could be placed in application scope that spins up and looks at the
> > File? I've not implemented a servlet container. I suspect there are
> > some folks listening that have...
>
> If so that would be a change from previous versions of J2EE -- at least
> my understanding is that an application spawning threads is considered
> bad practice.
>
I thought that threads where ok in the web container but unsupported in the EJB
container. Regardless it seems like a bad idea.
> The JSP-like approach would be more intrusive. The DefinitionsFactory
> would have to store the modified date of a definition and the
> getDefinition() method would have to check the date against the date of
> the file and reload if necessary.
>
Maybe a Shale preprocess command would be a good fit?
<!-- Define preprocessing command chain for Shale to execute -->
<catalog name="shale">
<!-- Disallow direct access to JSP and JSFP resources -->
<chain name="preprocess">
<command
className="org.apache.shale.application.ContextRelativePathFilter"
includes="\S*\.faces,\S*\.html,\S*\.gif,\S*\.jpg,/index\.jsp"
excludes="\S*\.jsp,\S*\.jspf"/>
<!-- listen for tiles config file changes -->
<command className="org.apache.shale.application.TilesReloadFilter"
includes="\S*\.faces,\S*\.html,\S*\.jsp"/>
<!-- listen for clay config file changes -->
<command
className="org.apache.shale.clay.application.ClayReloadFilter"
includes="\S*\.faces,\S*\.html,\S*\.jsp"/>
</chain>
</catalog>
Gary
> >> 3) Should the enable/disable feature be through a context parameter
> >> or
> >> some other method?
> >>
> >
> > How about an init parameter in the web deployment descriptor?
>
> That's what I meant :-)
>
> Greg
>
>
> ---------------------------------------------------------------------
> 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]
