[jboss-dev] How to bind object to JNDI from jmx-jboss-beans.xml

David M. Lloyd david.lloyd at redhat.com
Thu Mar 25 15:57:11 EDT 2010


On 03/25/2010 02:05 PM, Adrian Brock wrote:
> On Thu, 2010-03-25 at 13:35 -0500, David M. Lloyd wrote:
>> The latter is roughly
>> what we do today with RMIAdaptor (sic), so it seems the least invasive to
>> me since one would think that things like Twiddle would then only have to
>> change the interface of what they pull out of JNDI.
>
> Not really because RMIAdaptor extends
> javax.management.MBeanServerConnection
> the later is what people should be using rather a jboss api.

Yeah, I'm just saying we ought to use the JMX connector - that's why it exists.

> P.S. I don't really understand this change.
> It breaks a number of "features".
>
> By using the JMX connector in the JDK you loose the ability to do
> remote JMX invocations that are involved in user transactions.

How is this a bad thing?  That there's even an expectation that 
transactions will "work" over JMX seems crazy to me.  It's ok to 
discontinue features which don't make sense.

> You're also missing a way to integrate the security with the
> java:/jaas/jmx-console policy.
>
> You can't add load balancing/failover which the old
> jmx-invoker could do if you configured it.

This _is_ just management we're talking about; management is a per-system 
kind of thing.  What is the use case for clustering/load-balancing?  This 
is a non-requirement as far as I can see.

> Finally, you loose the serialization workarounds, e.g.
> <!-- Interceptor that deals with non-serializable results -->
> <interceptor
> code="org.jboss.jmx.connector.invoker.SerializableInterceptor"
>                       policyClass="StripModelMBeanInfoPolicy"/>
>
> and the swapping of the MBeanServer to an MBeanServerConnection
> when passing MBeanProxys over the network.

The expectation that non-serializable results will work is the wrong one, 
not the lack of support for it.  What's the use case?

> Also, it means you pretty much have to use RMI (that's
> all that is implemented in the JDK) which a lot
> of people don't want to do, its painful through a proxy.

Nah, for jconsole you can add a plugin (via -plungpath), and in other 
applications you can use the "jmx.remote.protocol.provider.pkgs" system 
property if you want to use other transports.  I'd like to add a remoting 
transport, if I ever get time.

> While the old jmx-invoker can be swapped out to use the
> HTTPInvoker.
> There was a customer on the support list asking about that
> only last week.

Getting HTTP working over Remoting 3 is a prereq for AS6.0.0.GA anyway, so 
I wouldn't be too bothered if we had to add a JSR-160 connector to that 
list.  It doesn't really represent much work from what I can see.

-- 
- DML ☍



More information about the jboss-development mailing list