So to move the TCL handling to the invoker, I need the MBeanEntry
in the AbstractMBeanInvoker. This really could replace the current
resource reference since this is encapsulated by the MBeanEntry.
This would have to be looked up during the preRegister call into
the invoker. Anyone see a problem with this change?


xxxxxxxxxxxxxxxxxxxxxxxx
Scott Stark
Chief Technology Officer
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx 
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
Adrian Brock
Sent: Monday, January 05, 2004 9:39 AM
To: [EMAIL PROTECTED]
Subject: Re: [JBoss-dev] What is this codeblock in BasicMBeanRegistry

If I remember correctly, this was a fix for some changes in the service
controller made in 4.0.0DR1

AFAIK the code that required this fix is no longer present since the
rollback by Bill.

You are correct that the invocation of the MBean's preRegister should be
done with the classloader.
You can argue that the TCL should be a responsibilty of the invoker via
an interceptor rather than the MBeanServer.

Regards,
Adrian

On Mon, 2004-01-05 at 15:44, Scott M Stark wrote:
> org.jboss.mx.server.registry.BasicMBeanRegistry.registerMBean
> is the following codeblock:
> 
>       // This is a fix for the SAR TCL problem in 4.0
>       // Allow the classloader in the value map to be an ObjectName
>       if (valueMap != null)
>       {
>          Object obj = valueMap.get(CLASSLOADER);
>          if (obj != null && obj instanceof ObjectName)
>          {
>             MBeanEntry clEntry = null;
>             try
>             {
>                 clEntry = get((ObjectName) obj);
>             }
>             catch (InstanceNotFoundException e)
>             {
>                throw new RuntimeOperationsException(
>                   new IllegalArgumentException(e.toString()));
>             }
>             valueMap.put(CLASSLOADER, clEntry.getResourceInstance());
>          }
>       }
> 
> What is this for? The following dispatch to the invokePreRegister is 
> not using the correct thread context class loader. It needs to be 
> using the class loader of the mbean being registered so that any 
> scoped classes that are loaded as part of the registration are 
> available. I'm correcting this, but I need to know what the source of 
> this duality of type is.
> 
> xxxxxxxxxxxxxxxxxxxxxxxx
> Scott Stark
> Chief Technology Officer
> JBoss Group, LLC
> xxxxxxxxxxxxxxxxxxxxxxxx
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IBM Linux Tutorials.
> Become an expert in LINUX or just sharpen your skills.  Sign up for 
> IBM's Free Linux Tutorials.  Learn everything from the bash shell to
sys admin.
> Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
> _______________________________________________
> JBoss-Development mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/jboss-development
--
xxxxxxxxxxxxxxxxxxxxxxxx
Adrian Brock
Director of Support
Back Office
JBoss Group, LLC
xxxxxxxxxxxxxxxxxxxxxxxx 



-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for
IBM's Free Linux Tutorials.  Learn everything from the bash shell to sys
admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
JBoss-Development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development

Reply via email to