[infinispan-issues] [JBoss JIRA] Commented: (ISPN-776) Add configurable properties for each configuration lookup class

[Paul Ferraro (JIRA)]

    [ https://jira.jboss.org/browse/ISPN-776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563814#comment-12563814 ] 

Paul Ferraro commented on ISPN-776:
-----------------------------------

Not a showstopper (that's why the minor priority).
Specifically, the AS currently utilizes custom lookup classes for the following components:
* JGroupsChannelLookup - to provide a channel from an injected ChannelFactory that uses a muxing up handler.
* MBeanServerLookup - so that infinispan uses the default JBoss mbean server

Since ISPN-379, I've been able to pass a ChannelFactory to our custom JGroupsChannelLookup by putting a non-string value into the GlobalConfiguration.getTransportProperties().  While this seems less than ideal, it works fine.

However, MBeanServerLookup.getMBeanServer() has no such parameterization facility.  Consequently, it makes it hard to pass anything to a custom implementation.  Currently, we rely on a hacky static reference, which is very awkward:
See:
http://anonsvn.jboss.org/repos/jbossas/projects/cluster/ha-server-ispn/trunk/src/main/java/org/jboss/ha/ispn/DefaultCacheContainerFactory.java

While an simple solution could involve adding a properties parameter that could be specified in GlobalConfiguration (a la transport properties), I have to wonder why not just allow users to specify the instances directly (instead of just by class name)?

> Add configurable properties for each configuration lookup class
> ---------------------------------------------------------------
>
>                 Key: ISPN-776
>                 URL: https://jira.jboss.org/browse/ISPN-776
>             Project: Infinispan
>          Issue Type: Feature Request
>            Reporter: Paul Ferraro
>            Assignee: Manik Surtani
>            Priority: Minor
>
> See ISPN-379.
> Currently, most pluggable components can only be specified by a lookup class name.  While some accept a configurable Properties object (e.g. JGroupsChannelLookup), not all do (e.g. MBeanServerLookup).  Consequently, it is very awkward to implement a parameterized MBeanServerLookup implementation (e.g. to find the server using a jmx agent id, use an injected mbean server instance, etc.).
> I can think of 2 ways to improve this:
> 1. Add the ability to specify properties objects for each pluggable component.  e.g. GlobalConfiguration.setMBeanServerProperties(...), MBeanServerLookup.getMBeanServer(Properties properties)
> 2. Allow the user to define the instance directly.  e.g. GlobalConfiguration.setMBeanServerLookup(MBeanServerLookup lookup)
> Ideally, Infinispan could support both mechanisms. The 1st allows flexible declarative configuration.  The 2nd allows even more flexible programmatic configuration.
> Thinking this through a bit more - we can support both approaches using the following (using MBeanServerLookup as an example):
> * Leave MBeanServerLookup interface as is
> * Replace GlobalConfiguration.setMBeanServerLookup(String) with GlobalConfiguration.setMBeanServerLookup(MBeanServerLookup lookup)
> * Create generic implementation of MBeanServerLookup that delegates to an instance constructed via class name and java bean properties
> * If lookup class is specified in the xml, construct generic MBeanServerLookup object accordingly (using class name + properties)
> Just a thought.  Approach #1 is good enough.

-- 
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira