-
1. Re: Duplicate jmx remoting in jbossas5
dimitris Jun 24, 2008 2:49 PM (in response to starksm64)I understand that jmx-remoting.sar is just a wrapper on top of the jdk provided remoting implementation. AFAIR, tomL had started writing his own but then jdk5 came so he just wrapped that in a service mbean.
I think people want that because it's the standard way now to access remotely an mbeanserver using service url:
service:jmx:rmi://127.0.0.1/jndi/rmi://127.0.0.1:1090/jmxconnector
In this regard, I don't see how they can be merged in an mcbean implementation?
Or maybe we can retire RMIAdaptor. -
2. Re: Duplicate jmx remoting in jbossas5
starksm64 Jun 24, 2008 3:00 PM (in response to starksm64)Ok, I see. There is a current failing test due to problems with not implmenting callback handlers. Perhaps the jdk version does not support that. The problem with the RMIAdaptor is that its been the connector interface for years now. I would expect we would have to at least provide a mapping of a proxy onto the jmx impl or at least the ability to continue to deploy the RMIAdaptor.
-
3. Re: Duplicate jmx remoting in jbossas5
adrian.brock Jun 24, 2008 3:03 PM (in response to starksm64)"dimitris@jboss.org" wrote:
I think people want that because it's the standard way now to access remotely an mbeanserver using service url:
service:jmx:rmi://127.0.0.1/jndi/rmi://127.0.0.1:1090/jmxconnector
In this regard, I don't see how they can be merged in an mcbean implementation?
Or maybe we can retire RMIAdaptor.
You should be able to bind the JSR160 MBeanServerConnection
in place of the RMIAdapter - assuming you're not bothered about implementing
the old interfaces?
But I think you'll find classloading issues? I don't think it will understand how
to unmarshal objects into scoped deployments
see InvokerAdapterService::invoke -
4. Re: Duplicate jmx remoting in jbossas5
dimitris Jun 24, 2008 5:32 PM (in response to starksm64)I had a quick look at the jmx_remote-1_0-fr-spec. If I understand correctly the server is supposed to buffer the notifications emitted on the server (up to some limit?), and then push them to interested clients, according to the filters they have set.
A plain NotificationLister is needed, nothing special here. Maybe timing is different then?
I agree with Adrian about the classloading issues. Not sure how to deal with that, more reading is needed. -
5. Re: Duplicate jmx remoting in jbossas5
alesj Jun 24, 2008 6:20 PM (in response to starksm64)Chat transcript I had with TomEl.
"tomel" wrote:
However, the jmx remoting implementation I did was written from scratch based on the spec (i.e. I didn't wrap the one provide with jdk 5).
http://jira.jboss.com/jira/secure/ReleaseNote.jspa?version=12310202&styleName=Html&projectId=10031&Create=Create shows what was implemented of the spec
http://jira.jboss.com/jira/secure/IssueNavigator.jspa?reset=true&mode=hide&sorter/order=DESC&sorter/field=priority&resolution=-1&pid=10031&fixfor=12310319 show what remains to be implemented
Since jdk 5 included a jmx remoting implementation, I didn't spend much effort on completing the JBoss implementation.
The jmx-remoting.sar will actually check to see if running jdk 5, an if it is, will not deploy my implementation, but use the jdk 5 one. If it is running within jdk 1.4, it will use my implementation.
We have failing tests with jmx client listeners:"tomel" wrote:
could be due to http://jira.jboss.com/jira/browse/JBREM-150 ? -
6. Re: Duplicate jmx remoting in jbossas5
alesj Jun 25, 2008 7:15 AM (in response to starksm64)Should we include JBoss Remoting guys to help here, since it's their (TElrod's) legacy.
Or is Adrian gonna single-handedly solve this? :-) -
7. Re: Duplicate jmx remoting in jbossas5
adrian.brock Jun 25, 2008 7:26 AM (in response to starksm64)"alesj" wrote:
Should we include JBoss Remoting guys to help here, since it's their (TElrod's) legacy.
Or is Adrian gonna single-handedly solve this? :-)
If the remoting guys aren't going to solve/fix it, I'm happy with just using
the old RMIAdapter.
Another problem with the JSR160 stuff, is that it has the Serialization problem
for values in the MBeanInfo. -
8. Re: Duplicate jmx remoting in jbossas5
dmlloyd Jun 25, 2008 2:38 PM (in response to starksm64)None of us remaining on the Remoting team (as far as I am aware) have enough experience with the JMX stuff to make an informed decision, let alone carry it out before CR1 (apart from the name, the JMX remoting implementation has little to do with JBoss Remoting as far as I can tell). If there's nobody else who is able/willing to take this code over, then I'd say we should just get rid of it, unless there's some value being added that I'm not aware of?
-
9. Re: Duplicate jmx remoting in jbossas5
starksm64 Jun 25, 2008 2:45 PM (in response to starksm64)Its not really a CR1 issue. We just need to decide on what the spec jmx-remoting support is and how the legacy RMIAdaptor interface is to be supported for GA.
-
10. Re: Duplicate jmx remoting in jbossas5
ron_sigal Jun 25, 2008 5:59 PM (in response to starksm64)Yeah, jmx-remoting was Tom's baby. I've never touched it.
-
11. Re: Duplicate jmx remoting in jbossas5
ron_sigal Jun 27, 2008 8:59 PM (in response to starksm64)"scott.stark@jboss.org" wrote:
We just need to decide ... how the legacy RMIAdaptor interface is to be supported for GA.
From "Design of JBoss Remoting, Unified Invokers" forum, http://www.jboss.com/index.html?module=bb&op=viewtopic&t=134003:"adrian@jboss.org wrote:
I'm wondering why the JMX invoker in trunk is still using the jrmp invoker instead of the unified invoker?
[Because telrod left.]
I've been working on JBAS-4456 "Replace JRMPProxyService with a remoting based bean.", though I haven't committed anything yet. When that's done RMIAdaptor could be reborn as a bean-configured proxy running over the unified invoker.