You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by "Chak Nanga (JIRA)" <ji...@apache.org> on 2008/01/22 17:34:34 UTC

[jira] Created: (SHINDIG-27) Hookup Gadget blacklist implementation to the Gadget Server

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.


Re: [jira] Commented: (SHINDIG-27) Hookup Gadget blacklist implementation to the Gadget Server

Posted by John Hjelmstad <fa...@google.com>.
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) <ji...@apache.org>
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.
>
>

[jira] Commented: (SHINDIG-27) Hookup Gadget blacklist implementation to the Gadget Server

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
    [ 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.


[jira] Assigned: (SHINDIG-27) Hookup Gadget blacklist implementation to the Gadget Server

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SHINDIG-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Brown reassigned SHINDIG-27:
----------------------------------

    Assignee: Kevin Brown  (was: John Hjelmstad)

> 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: Kevin Brown
>            Priority: Minor
>         Attachments: blacklist_patch.txt
>
>
> 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.


[jira] Closed: (SHINDIG-27) Hookup Gadget blacklist implementation to the Gadget Server

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SHINDIG-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kevin Brown closed SHINDIG-27.
------------------------------

    Resolution: Fixed

Simple file based implementation connected; implementations may customize as appropriate.

> 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: Kevin Brown
>            Priority: Minor
>         Attachments: blacklist_patch.txt
>
>
> 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.


[jira] Commented: (SHINDIG-27) Hookup Gadget blacklist implementation to the Gadget Server

Posted by "Chak Nanga (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SHINDIG-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12564022#action_12564022 ] 

Chak Nanga commented on SHINDIG-27:
-----------------------------------

Hi Kevin, Not a problem. Please feel free to modify the patch as you see fit and please delete the author related stuff to conform to the Shindig standards. Thanks again for getting to this....Chak


> 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
>         Attachments: blacklist_patch.txt
>
>
> 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.


[jira] Updated: (SHINDIG-27) Hookup Gadget blacklist implementation to the Gadget Server

Posted by "Chak Nanga (JIRA)" <ji...@apache.org>.
     [ https://issues.apache.org/jira/browse/SHINDIG-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chak Nanga updated SHINDIG-27:
------------------------------

    Attachment: blacklist_patch.txt

Notes for the attached patch:

Introduced a basic GadgetBlacklistChangeListener interface and modified the BasicGadgetBlacklist impl to listen for black list change notifications. Uses simple file modification timestamps to refresh the blacklist.

The blacklist file (as it's currently specified in the web.xml file) should be in a dir named "conf". The "conf" dir is expected to be at the same level as WEB-INF. Of course, the location can be changed via the conf. file.


> 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
>         Attachments: blacklist_patch.txt
>
>
> 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.


[jira] Commented: (SHINDIG-27) Hookup Gadget blacklist implementation to the Gadget Server

Posted by "Kevin Brown (JIRA)" <ji...@apache.org>.
    [ https://issues.apache.org/jira/browse/SHINDIG-27?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563885#action_12563885 ] 

Kevin Brown commented on SHINDIG-27:
------------------------------------

Sorry for the late follow up on this. 

I think this works, but I think the extra interface is overkill. I'm a little hesitant on the implementation because it starts a separate executor which can't be configured, and this can complicate debugging.

Also, Shindig code should not include authorship information.

I'll try to get this in sometime this weekend, but I'd like your thoughts first.

> 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
>         Attachments: blacklist_patch.txt
>
>
> 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.