[
https://jira.jboss.org/browse/ISPN-776?page=com.atlassian.jira.plugin.sys...
]
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/tr...
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