I'd like to see this mechanism generalized to be able to listen to changes from an arbitrary Blacklist provider, such as that provided sometime in the future by directory servers for instance. The proposed solution would be a subclass of that.
--John On Tue, Jan 22, 2008 at 12:28 PM, Kevin Brown (JIRA) <[EMAIL PROTECTED]> wrote: > > [ > https://issues.apache.org/jira/browse/SHINDIG-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561451#action_12561451] > > Kevin Brown commented on SHINDIG-27: > ------------------------------------ > > I like the solution as proposed, though I'm not that familiar with the > file change listener implementation, and I'd want to take a look at it to > make sure that it's not a performance concern. I was favoring a signaling > mechanism, but this might work just as well. > > > Hookup Gadget blacklist implementation to the Gadget Server > > ----------------------------------------------------------- > > > > Key: SHINDIG-27 > > URL: https://issues.apache.org/jira/browse/SHINDIG-27 > > Project: Shindig > > Issue Type: Improvement > > Components: Gadgets Server - Java > > Reporter: Chak Nanga > > Assignee: John Hjelmstad > > Priority: Minor > > > > Currently there is a BasicGadgetBlacklist class, however, it's not being > utilized (i.e. being init'd and read in) by the Gadget Server. While we're > at it, we should also implement a mechanism to be able to dynamically update > the blacklist file without having to restart the server. > > Proposed solution: > > 1. Read in the black list file name from web.xml (as a context-param) > > 2. Implement a file change listener mechanism that can be used to > monitor changes to the blacklist file and reload it on changes. > > I can work on the patch if you agree on the proposed solution > > -- > This message is automatically generated by JIRA. > - > You can reply to this email to add a comment to the issue online. > >
