Re: [JBoss-user] JMX and ear-scope (too much protection?)

2002-09-13 Thread Michael Bartmann

David Jencks wrote:
 Did you look at how ServiceCreator does it? That might work for you also. 
 Basically you ask the mbeanserver to create your object (sub-service) for
 you using a specific classloader, then it remembers for you, you don't need
 to worry about the mbeanRegistry.
 

I want to _register_ (not create) an existing Service.

The method I use (from MBeanServerImpl) has:

public ObjectInstance registerMBean(Object object, ObjectName name)
   throws InstanceAlreadyExistsException,
  MBeanRegistrationException,
  NotCompliantMBeanException
{
   return registerMBean(object, name, (ClassLoader)null);
}

and

   protected ObjectInstance registerMBean(Object object, ObjectName name, ClassLoader 
cl)
   {
  ...
   }

Should it be that JBoss denies me the feature to register inside my ear-scope in a 
way,
that the TCL is the right one by making things protected?

Or maybe I don't think about it in the right way?

Michael Bartmann



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] JMX and ear-scope

2002-09-12 Thread Michael Bartmann

Hi Adrian,

Your workaround sounds ok, but I have some 20 ear-scoped applications, with
the same single offending method in each, so I decided to stay with my 
serialization
below the API with a byte[] arg. (I can do this by myself, but the 
management
GUI is written by Mehrdad (remember him?), and I don't wan't to bother him
with like managing 20 different Adaptors...8-)

But now I came around another problem with this classloading deficiency:

I have quite some management methods of the type setSomeURL(String x),
which are typically with a default setting like 
ressource:someFile.xml, which
points to a file inside the ear.

The setters are implemented through TCL, and so these setters fail, even 
when
the provided String is the same as previously obtained through the getter.
(Pressing the Apply-Button on the console)

I probably should save a copy of the TCL during create() or even use the
(banned!) Class.forName. Or do we have a standard method to obtain the
MBean classloader at runtime from another Thread (beside looking up the
UCL throgh JMX)?

Thank you,
Michael




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] JMX and ear-scope

2002-09-12 Thread Adrian Brock

I'm not sure I understand what you are doing.

The setSomeURL(String) should be invoked with the
MBean's context classloader, regardless of which thread
initiates the invocation.
This works for me, including inside a loader-repository

Can you try
log.info(Thread.currentThread().getContextClassLoader());
at the start of your setSomeURL method.

Alternatively,
if you look at the MBean JMImplementation:type=MBeanRegsitry
there is a getValue operation.
Type your object name and org.jboss.mx.classloader in the key.
It will tell you the MBean's context classloader.

Regards,
Adrian

From: Michael Bartmann [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-user] JMX and ear-scope
Date: Thu, 12 Sep 2002 15:03:15 +0200

Hi Adrian,

Your workaround sounds ok, but I have some 20 ear-scoped applications, with
the same single offending method in each, so I decided to stay with my 
serialization
below the API with a byte[] arg. (I can do this by myself, but the 
management
GUI is written by Mehrdad (remember him?), and I don't wan't to bother him
with like managing 20 different Adaptors...8-)

But now I came around another problem with this classloading deficiency:

I have quite some management methods of the type setSomeURL(String x),
which are typically with a default setting like ressource:someFile.xml, 
which
points to a file inside the ear.

The setters are implemented through TCL, and so these setters fail, even 
when
the provided String is the same as previously obtained through the getter.
(Pressing the Apply-Button on the console)

I probably should save a copy of the TCL during create() or even use the
(banned!) Class.forName. Or do we have a standard method to obtain the
MBean classloader at runtime from another Thread (beside looking up the
UCL throgh JMX)?

Thank you,
Michael




---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user


_
Send and receive Hotmail on your mobile device: http://mobile.msn.com



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] JMX and ear-scope

2002-09-12 Thread Michael Bartmann

Ok, this is what I found out so far:

In my root-service I implement MBeanRegistration to obtain
the jmxserver to register further sub-services to.

This implements MBeanServer.
This is where I register my MBeans calling registerMBean(..).

But the class I queried the org.jboss.mx.classloader value
from was an Implementation of MBeanRegisty. If I would have
registered here, I could have used the third Map argument
to set the CLASSLOADER key to my TCL which happens to be
the ear-scoped thing.

But where the heck to I get the MBeanRegistry from. Do
I have to register there, or shouldn't this be done
when I call MBeanServer.registerMBean.

H...

Regards,
Michael Bartmann



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] JMX and ear-scope

2002-09-12 Thread Michael Bartmann

Hi Adrian,

arghh, I think I am doing registration terribly wrong.
There is sth which I didn't tell you, because I didn't
think it was of any relevance.

The MBeans involved are my own JMSProvider. The
root-service is:

fs4p.eartest:service=MS4PServer

This one provides a non-null result when I query the
MBeanRegistration for org.jboss.mx.classloader.

But there are lots of MBeans which I registered
programmatically by calling jmxserver.registerMBean(...).
One of these sub-services is:

fs4p.eartest:destination=FLSRBG1,service=destinationagent

This one exists, all MBean methods are callable,
but your query for org.jboss.mx.classloader does not
provide anything. And I got all the problems I whined
about in the last postings.

So now I suspect my way of registering my
own MBeans with the jmxserver isn't complete in a way.
I'll try to RTFM, but then again...

...surely you can tell me...

Thanks,
Michael Bartmann



---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] JMX and ear-scope

2002-09-12 Thread David Jencks

Did you look at how ServiceCreator does it? That might work for you also. 
Basically you ask the mbeanserver to create your object (sub-service) for
you using a specific classloader, then it remembers for you, you don't need
to worry about the mbeanRegistry.

(all of this as I recall)
david jencks

On 2002.09.12 18:32:35 -0400 Michael Bartmann wrote:
 Ok, this is what I found out so far:
 
 In my root-service I implement MBeanRegistration to obtain
 the jmxserver to register further sub-services to.
 
 This implements MBeanServer.
 This is where I register my MBeans calling registerMBean(..).
 
 But the class I queried the org.jboss.mx.classloader value
 from was an Implementation of MBeanRegisty. If I would have
 registered here, I could have used the third Map argument
 to set the CLASSLOADER key to my TCL which happens to be
 the ear-scoped thing.
 
 But where the heck to I get the MBeanRegistry from. Do
 I have to register there, or shouldn't this be done
 when I call MBeanServer.registerMBean.
 
 H...
 
 Regards,
 Michael Bartmann
 
 
 
 ---
 This sf.net email is sponsored by:ThinkGeek
 Welcome to geek heaven.
 http://thinkgeek.com/sf
 ___
 JBoss-user mailing list
 [EMAIL PROTECTED]
 https://lists.sourceforge.net/lists/listinfo/jboss-user
 
 


---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user



Re: [JBoss-user] JMX and ear-scope

2002-09-11 Thread Adrian Brock

Hi Michael,

Your problem is that the marshalling is handled by RMI.
The marshalling starts from the classloader of the remote object.

One fix is to include a jmx-rmi-adaptor.sar in your ear.
This would bind a RemoteObject into jnp that has visibility into
your ear's LoaderRepository.

?xml version=1.0 encoding=UTF-8?
server
  mbean code=org.jboss.jmx.adaptor.rmi.RMIAdaptorService
 name=jboss.jmx:type=Connector,name=RMI,ear=foo
constructor
   arg type=java.lang.String value=bar/
/constructor
  /mbean
/server

This will bind into jndi at jmx:yourhost:rmi:bar

We should look at using a proxy for the RMIAdaptor
and handling the marshalling ourselves based on the MBean classloader
of the ObjectName.
In fact, this wouldn't be RMI specific, it would work with any
invoker.

Regards,
Adrian

From: Michael Bartmann [EMAIL PROTECTED]
Reply-To: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: [JBoss-user] JMX and ear-scope
Date: Tue, 10 Sep 2002 18:59:07 +0200

Suppose I have two classes ClassA (an MBean) and ClassB (implements 
Serializable).
Both classes live inside an ear-scope.
There is an instance of ClassA which is registered with the JMX-server.
ClassA has a method void m(ClassB b).
This method m is called through an RMIAdaptor from an other JVM,
providing a non-null instance of ClassB (the parameter class ClassB is 
known
on the client side).

This does not work with a current JBoss from Branch_3_2.

Who is responsible for loading ClassB on the server-side when
de-serializing the jmx invocation?

Is this even supposed to work?

Thanks,
Michael Bartmann

PS.:
The whole thing of course worked when ClassB is only the return type of a 
method,
because the server only has to serialize an already loaded class.





---
This sf.net email is sponsored by: OSDN - Tired of that same old
cell phone?  Get a new here for FREE!
https://www.inphonic.com/r.asp?r=sourceforge1refcode1=vs3390
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user




_
Join the world’s largest e-mail service with MSN Hotmail. 
http://www.hotmail.com



---
In remembrance
www.osdn.com/911/
___
JBoss-user mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-user