You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@geronimo.apache.org by de...@geronimo.apache.org on 2004/07/13 22:44:39 UTC

[jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Message:

  A new issue has been created in JIRA.

---------------------------------------------------------------------
View the issue:
  http://issues.apache.org/jira/browse/GERONIMO-267

Here is an overview of the issue:
---------------------------------------------------------------------
        Key: GERONIMO-267
    Summary: NoSuchOperationError on deployment of SSB
       Type: Bug

     Status: Unassigned
   Priority: Major

    Project: Apache Geronimo
 Components: 
             deployment
   Versions:
             1.0-M2

   Assignee: 
   Reporter: toby cabot

    Created: Tue, 13 Jul 2004 1:44 PM
    Updated: Tue, 13 Jul 2004 1:44 PM
Environment: fedora core 2
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_04-b05)


Description:
i'm trying to deploy and run the test ejb in ./modules/j2ee/target/test-ejb.jar.  after fixing the ejb-jar.xml (see bug 266) it deploys cleanly but when I bring the server up I get a org.apache.geronimo.gbean.jmx.NoSuchOperationError:

10:24:17,874 DEBUG [GBeanMBean] geronimo.server:J2EEApplication=skeleton/app,J2EEServer=geronimo,j2eeType=WebModule,name=skeleton-web.war State changed from starting to running
10:24:17,920 DEBUG [GBeanMBean] geronimo.server:J2EEApplication=skeleton/app,J2EEModule=skeleton-ejb.jar,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=StatelessSession State changed from starting to running
10:24:17,987 ERROR [CollectionProxy] Listener threw exception
org.apache.geronimo.gbean.jmx.NoSuchOperationError: No implementation method: objectName=geronimo.server:J2EEApplication=skeleton/app,J2EEModule=skeleton-ejb.jar,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=StatelessSession, method=public abstract org.openejb.EJBContainer org.openejb.EJBContainer.getUnmanagedReference()
	at org.apache.geronimo.gbean.jmx.CGLibMethodInterceptor.intercept(CGLibMethodInterceptor.java:108)
	at org.openejb.EJBContainer$$EnhancerByCGLIB$$9c51bc0b.getUnmanagedReference(<generated>)
	at org.openejb.ContainerIndex.addContainer(ContainerIndex.java:137)
	at org.openejb.ContainerIndex.memberAdded(ContainerIndex.java:168)
	at org.apache.geronimo.gbean.jmx.CollectionProxy$ClientCollection.fireMemberAdddedEvent(CollectionProxy.java:180)
	at org.apache.geronimo.gbean.jmx.CollectionProxy$ClientCollection.access$200(CollectionProxy.java:151)
	at org.apache.geronimo.gbean.jmx.CollectionProxy.addTarget(CollectionProxy.java:117)
	at org.apache.geronimo.gbean.jmx.GBeanMBeanReference.handleNotification(GBeanMBeanReference.java:298)
	at mx4j.server.interceptor.NotificationListenerMBeanServerInterceptor$ListenerWrapper.handleNotification(NotificationListenerMBeanServerInterceptor.java:57)
	at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:346)
	at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:320)
	at org.apache.geronimo.gbean.jmx.AbstractManagedObject.sendNotification(AbstractManagedObject.java:244)
	at org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:500)
	at org.apache.geronimo.gbean.jmx.SingleProxy.attemptFullStart(SingleProxy.java:154)
	at org.apache.geronimo.gbean.jmx.SingleProxy.addTarget(SingleProxy.java:119)
	at org.apache.geronimo.gbean.jmx.GBeanMBeanReference.handleNotification(GBeanMBeanReference.java:298)
	at mx4j.server.interceptor.NotificationListenerMBeanServerInterceptor$ListenerWrapper.handleNotification(NotificationListenerMBeanServerInterceptor.java:57)
	at javax.management.NotificationBroadcasterSupport.handleNotification(NotificationBroadcasterSupport.java:346)
	at javax.management.NotificationBroadcasterSupport.sendNotification(NotificationBroadcasterSupport.java:320)
	at org.apache.geronimo.gbean.jmx.AbstractManagedObject.sendNotification(AbstractManagedObject.java:244)
	at org.apache.geronimo.gbean.jmx.AbstractManagedObject.attemptFullStart(AbstractManagedObject.java:500)
	at org.apache.geronimo.gbean.jmx.AbstractManagedObject.start(AbstractManagedObject.java:279)
	at org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:303)
	at org.apache.geronimo.gbean.jmx.GBeanMBean$9.invoke(GBeanMBean.java:940)
	at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
	at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:767)
	at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:218)
	at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
	at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86)
	at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
	at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
	at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:205)
	at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079)
	at org.apache.geronimo.gbean.jmx.AbstractManagedObject.startRecursive(AbstractManagedObject.java:310)
	at org.apache.geronimo.gbean.jmx.GBeanMBean$9.invoke(GBeanMBean.java:940)
	at org.apache.geronimo.gbean.jmx.GBeanMBeanOperation.invoke(GBeanMBeanOperation.java:142)
	at org.apache.geronimo.gbean.jmx.GBeanMBean.invoke(GBeanMBean.java:767)
	at mx4j.server.interceptor.InvokerMBeanServerInterceptor.invoke(InvokerMBeanServerInterceptor.java:218)
	at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
	at mx4j.server.interceptor.SecurityMBeanServerInterceptor.invoke(SecurityMBeanServerInterceptor.java:86)
	at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
	at mx4j.server.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:121)
	at mx4j.server.interceptor.ContextClassLoaderMBeanServerInterceptor.invoke(ContextClassLoaderMBeanServerInterceptor.java:205)
	at mx4j.server.MX4JMBeanServer.invoke(MX4JMBeanServer.java:1079)
	at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:231)
	at org.apache.geronimo.kernel.Kernel.invoke(Kernel.java:226)
	at org.apache.geronimo.kernel.Kernel.startRecursiveGBean(Kernel.java:272)
	at org.apache.geronimo.system.main.Daemon.main(Daemon.java:137)
10:24:18,048 DEBUG [GBeanMBean] geronimo.server:J2EEApplication=skeleton/app,J2EEModule=skeleton-ejb.jar,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=StatelessSession invoking startRecursive

I get the same exception when I try to deploy one of my stateless session EJB's (a really simple one) but I thought that the jar in the source tree would make a better test case.  Not sure if this is tragic or not but it looks kinda scary.



---------------------------------------------------------------------
JIRA INFORMATION:
This message is automatically generated by JIRA.

If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa

If you want more information on JIRA, or have a bug to report see:
   http://www.atlassian.com/software/jira

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by toby cabot <to...@caboteria.org>.

On Wed, Jul 14, 2004 at 11:01:18AM +1000, Gianny Damour wrote:
> This was the behavior before my updates and I have restored it.

Thanks for the speedy fix Gianny, it seems to work: the exception's no
longer being thrown.

Regards,
Toby

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by toby cabot <to...@caboteria.org>.

On Fri, Jul 16, 2004 at 01:44:38PM -0700, Dain Sundstrom wrote:
> I think is should be consistent with the other two, but this needs
> to be cleared with David Jencks first, as the connector code is the
> biggest (only) user of dynamic gbeans.

OK, here's a patch.  It puts each attribute in the maps twice, once
upper-case and once lower-case so users should be able to put either
in their config files (I've tested it with ra.xml config-property and
it works).

Also added a class comment and I cache the targetClass so if something
goes wrong the error messages indicate which class they're talking
about.  I found this to be helpful when I, ahem, cough, botched one of
my config files.

Should I file an improvement issue in Jira or will someone pick it up
from here?

Thanks,
Toby


Index: DynamicGBeanDelegate.java
===================================================================
RCS file: /home/cvspublic/incubator-geronimo/modules/kernel/src/java/org/apache/geronimo/gbean/DynamicGBeanDelegate.java,v
retrieving revision 1.7
diff -u -c -r1.7 DynamicGBeanDelegate.java
*** DynamicGBeanDelegate.java	27 May 2004 01:05:58 -0000	1.7
--- DynamicGBeanDelegate.java	16 Jul 2004 20:57:40 -0000
***************
*** 27,41 ****
  
  
  /**
   * @version $Revision: 1.7 $ $Date: 2004/05/27 01:05:58 $
   */
  public class DynamicGBeanDelegate implements DynamicGBean {
      protected final Map getters = new HashMap();
      protected final Map setters = new HashMap();
      protected final Map operations = new HashMap();
  
      public void addAll(Object target) {
!         Class targetClass = target.getClass();
          Method[] methods = targetClass.getMethods();
          for (int i = 0; i < methods.length; i++) {
              Method method = methods[i];
--- 27,44 ----
  
  
  /**
+  * Wraps an <code>Object</code> in a <code>DynamicGBean</code> facade.
+  *
   * @version $Revision: 1.7 $ $Date: 2004/05/27 01:05:58 $
   */
  public class DynamicGBeanDelegate implements DynamicGBean {
      protected final Map getters = new HashMap();
      protected final Map setters = new HashMap();
      protected final Map operations = new HashMap();
+     private Class targetClass;
  
      public void addAll(Object target) {
!         this.targetClass = target.getClass();
          Method[] methods = targetClass.getMethods();
          for (int i = 0; i < methods.length; i++) {
              Method method = methods[i];
***************
*** 52,62 ****
      public void addGetter(Object target, Method method) {
          String name = method.getName();
          if (name.startsWith("get")) {
!             addGetter(method.getName().substring(3), target, method);
          } else if (name.startsWith("is")) {
!             addGetter(method.getName().substring(2), target, method);
          } else {
!             throw new IllegalArgumentException("Method method name must start with 'get' or 'is' " + method);
          }
      }
  
--- 55,65 ----
      public void addGetter(Object target, Method method) {
          String name = method.getName();
          if (name.startsWith("get")) {
!             addGetter(name.substring(3), target, method);
          } else if (name.startsWith("is")) {
!             addGetter(name.substring(2), target, method);
          } else {
!             throw new IllegalArgumentException("Method name must start with 'get' or 'is' " + method);
          }
      }
  
***************
*** 64,75 ****
          if (!(method.getParameterTypes().length == 0 && method.getReturnType() != Void.TYPE)) {
              throw new IllegalArgumentException("Method must take no parameters and return a value " + method);
          }
!         getters.put(name, new Operation(target, method));
      }
  
      public void addSetter(Object target, Method method) {
          if (!method.getName().startsWith("set")) {
!             throw new IllegalArgumentException("Method method name must start with 'set' " + method);
          }
          addSetter(method.getName().substring(3), target, method);
      }
--- 67,81 ----
          if (!(method.getParameterTypes().length == 0 && method.getReturnType() != Void.TYPE)) {
              throw new IllegalArgumentException("Method must take no parameters and return a value " + method);
          }
!         // we want to be user-friendly so we put the attribute name in
!         // the Map in both lower-case and upper-case
!         getters.put(name.substring(0,1).toUpperCase() + name.substring(1), new Operation(target, method));
!         getters.put(name.substring(0,1).toLowerCase() + name.substring(1), new Operation(target, method));
      }
  
      public void addSetter(Object target, Method method) {
          if (!method.getName().startsWith("set")) {
!             throw new IllegalArgumentException("Method name must start with 'set' " + method);
          }
          addSetter(method.getName().substring(3), target, method);
      }
***************
*** 78,84 ****
          if (!(method.getParameterTypes().length == 1 && method.getReturnType() == Void.TYPE)) {
              throw new IllegalArgumentException("Method must take one parameter and not return anything " + method);
          }
!         setters.put(name, new Operation(target, method));
      }
  
      public void addOperation(Object target, Method method) {
--- 84,93 ----
          if (!(method.getParameterTypes().length == 1 && method.getReturnType() == Void.TYPE)) {
              throw new IllegalArgumentException("Method must take one parameter and not return anything " + method);
          }
!         // we want to be user-friendly so we put the attribute name in
!         // the Map in both lower-case and upper-case
!         setters.put(name.substring(0,1).toUpperCase() + name.substring(1), new Operation(target, method));
!         setters.put(name.substring(0,1).toLowerCase() + name.substring(1), new Operation(target, method));
      }
  
      public void addOperation(Object target, Method method) {
***************
*** 107,113 ****
      public Object getAttribute(String name) throws Exception {
          Operation operation = (Operation) getters.get(name);
          if (operation == null) {
!             throw new IllegalArgumentException("Unknown attribute " + name);
          }
          return operation.invoke(null);
      }
--- 116,122 ----
      public Object getAttribute(String name) throws Exception {
          Operation operation = (Operation) getters.get(name);
          if (operation == null) {
!             throw new IllegalArgumentException(this.targetClass.getName() + ": no get() method for " + name);
          }
          return operation.invoke(null);
      }
***************
*** 115,121 ****
      public void setAttribute(String name, Object value) throws Exception {
          Operation operation = (Operation) setters.get(name);
          if (operation == null) {
!             throw new IllegalArgumentException("Unknown attribute " + name);
          }
          operation.invoke(new Object[]{value});
      }
--- 124,130 ----
      public void setAttribute(String name, Object value) throws Exception {
          Operation operation = (Operation) setters.get(name);
          if (operation == null) {
!             throw new IllegalArgumentException(this.targetClass.getName() + ": no get() method for " + name);
          }
          operation.invoke(new Object[]{value});
      }
***************
*** 123,129 ****
      public Object invoke(String name, Object[] arguments, String[] types) throws Exception {
          Operation operation = (Operation) operations.get(new GOperationSignature(name, types));
          if (operation == null) {
!             throw new IllegalArgumentException("Unknown attribute " + name);
          }
          return operation.invoke(arguments);
      }
--- 132,138 ----
      public Object invoke(String name, Object[] arguments, String[] types) throws Exception {
          Operation operation = (Operation) operations.get(new GOperationSignature(name, types));
          if (operation == null) {
!             throw new IllegalArgumentException(this.targetClass.getName() + ": no get() method for " + name);
          }
          return operation.invoke(arguments);
      }

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by Dain Sundstrom <da...@coredevelopers.net>.

On Jul 16, 2004, at 12:11 PM, toby cabot wrote:

> Gianny,
>
> On Thu, Jul 15, 2004 at 08:33:25PM +1000, Gianny Damour wrote:
>> So, to sum it up, in a first pass one applies the JMX standards; and 
>> in
>> case of failure, a case insensitive match of method and attribute 
>> names
>> is performed.
>
> Does this algorithm need to be coded in
> o.a.g.gbean.DynamicGBeanDeleagate?  At the moment it looks as if it
> only does a straight match, so it requires parameter names to be
> upper-case, i.e. if I have setGroup() and getGroup() it slices off the
> "get" and "set" and uses what's left for comparison so then I need to
> put that parameter in config files (in my case geronimo-ra.xml) as
> Group.  My (naive) understanding is that the javabean approach prefers
> lower-case names.

Good catch.  I think is should be consistent with the other two, but 
this needs to be cleared with David Jencks first, as the connector code 
is the biggest (only) user of dynamic gbeans.

-dain

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by Gianny Damour <gi...@optusnet.com.au>.

On 17/07/2004 5:11 AM, toby cabot wrote:

>Gianny,
>
>On Thu, Jul 15, 2004 at 08:33:25PM +1000, Gianny Damour wrote:
>  
>
>>So, to sum it up, in a first pass one applies the JMX standards; and in 
>>case of failure, a case insensitive match of method and attribute names 
>>is performed.
>>    
>>
>
>Does this algorithm need to be coded in
>o.a.g.gbean.DynamicGBeanDeleagate?  At the moment it looks as if it
>only does a straight match, so it requires parameter names to be
>upper-case, i.e. if I have setGroup() and getGroup() it slices off the
>"get" and "set" and uses what's left for comparison so then I need to
>put that parameter in config files (in my case geronimo-ra.xml) as
>Group.  My (naive) understanding is that the javabean approach prefers
>lower-case names.
>  
>
Many thanks for that Toby! Indeed, this guy should also been impacted.

Cheers,
Gianny

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by toby cabot <to...@caboteria.org>.

Gianny,

On Thu, Jul 15, 2004 at 08:33:25PM +1000, Gianny Damour wrote:
> So, to sum it up, in a first pass one applies the JMX standards; and in 
> case of failure, a case insensitive match of method and attribute names 
> is performed.

Does this algorithm need to be coded in
o.a.g.gbean.DynamicGBeanDeleagate?  At the moment it looks as if it
only does a straight match, so it requires parameter names to be
upper-case, i.e. if I have setGroup() and getGroup() it slices off the
"get" and "set" and uses what's left for comparison so then I need to
put that parameter in config files (in my case geronimo-ra.xml) as
Group.  My (naive) understanding is that the javabean approach prefers
lower-case names.

Thanks,
Toby

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by Gianny Damour <gi...@optusnet.com.au>.

On 15/07/2004 3:10 AM, Dain Sundstrom wrote:

> On Jul 14, 2004, at 4:47 AM, Gianny Damour wrote:
>
>> Sorry; indeed, this is perhaps not the right approach. However, I was 
>> pretty confident that this new behavior was more correct:
>> As far as I understand, the JMX GBeanInvokers are used only when the 
>> "framework" mounts a reference, which does not have an attribute 
>> named GBeanMBean.RAW_INVOKER. Most of the time, this means that the 
>> reference is an "home-made" MBean (an MBean, which is not a 
>> GBeanMBean). So, I thought that we could safely say that programmers 
>> have applied the JMX standards. In other words, if the attribute is 
>> named "serverVersion", then the getter must be "getserverVersion".
>
>
> When you want to interact with a GBean over a remote MBean server (JSR 
> 160), you will use the JMXGBeanInvokers.  Also, this is an attempt to 
> make our interactions through JMX easier.

Thanks for that; it was a missing block in my reasoning.

> I definitely think the two should work exactly the same and the 
> programmer should not know which one is being used (other then the JMX 
> one is way slower).  My biggest reason to have these work the same is 
> the person using the GBeanInvoker is caller, and the caller would have 
> to know how the target GBean was implemented in order to get the 
> calling code correct.

You are right.

So, to sum it up, in a first pass one applies the JMX standards; and in 
case of failure, a case insensitive match of method and attribute names 
is performed.

Thanks,
Gianny

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by Dain Sundstrom <da...@coredevelopers.net>.

On Jul 14, 2004, at 4:47 AM, Gianny Damour wrote:

> On 14/07/2004 12:09 PM, Dain Sundstrom wrote:
>
>>
>>> On 14/07/2004 9:17 AM, Gianny Damour wrote:
>>>
>>> I have just updated the way GBean attribute names are derived:
>>> When GBeans are proxied via RawGBeanInvokers, attribute names may 
>>> start with an upper-case letter. For instance, if a GBean has a 
>>> method "getFoo", then the implementation tries to find an attribute 
>>> having the name "Foo". This was the behavior before my updates and I 
>>> have restored it. Now, if such an attribute is not defined, then the 
>>> implementation tries to find an attribute having the name "foo".
>>>
>>> When GBeans are proxied via JMXGBeanInvokers, attribute names are 
>>> derived based on the "exact" name embedded in the method name. For 
>>> instance, if a GBean has a method "getfoo", then the implementation 
>>> tries to find an attribute having the name "foo". This was the 
>>> behavior before my updates and I have restored it.
>>
>>
>> Uh, I think you lost me.  I suggest we first try an exact match using 
>> JMX standard MBean rules (getFoo looks for a method Foo) and if that 
>> fails we do a case insensitive match.  What ever we do, it must be 
>> consistent between the GBeanInvokers, since the programmer has not 
>> input into the invoker type the container chooses.
>
> Sorry; indeed, this is perhaps not the right approach. However, I was 
> pretty confident that this new behavior was more correct:
> As far as I understand, the JMX GBeanInvokers are used only when the 
> "framework" mounts a reference, which does not have an attribute named 
> GBeanMBean.RAW_INVOKER. Most of the time, this means that the 
> reference is an "home-made" MBean (an MBean, which is not a 
> GBeanMBean). So, I thought that we could safely say that programmers 
> have applied the JMX standards. In other words, if the attribute is 
> named "serverVersion", then the getter must be "getserverVersion".

When you want to interact with a GBean over a remote MBean server (JSR 
160), you will use the JMXGBeanInvokers.  Also, this is an attempt to 
make our interactions through JMX easier.  Having to name methods 
getfoo, just to get a lowercase attribute name is one of the bad side 
effects of the JMX standard mbean model.

> Having said that, the RawGBeanInvokers are used, most of the time, 
> when the reference is a GBeanMBean. Based on the naming conventions of 
> the attribute names (lower-case for the first character), I saw two 
> approaches:
> - renaming of the getters and setters of the various GBeans in order 
> to be aligned with the JMX standards; or
> - update of the way methods and attribute names were matched.
>
> The second approach has been implemented. This means that from a 
> method getFoo, the implementation will look for Foo. In case of 
> failure, it will then look for foo.
> I am happy to make this second look-up case insensitive. Yet, I am not 
> sure that JMX GBeanInvokers should mirror this behavior.
>
> In other words, and as far as I understand, programmers know the 
> invoker type, which will be used by the container:
> - if they use a GBean, it will be the Raw type;
> - if they implement an MBean having an attribute 
> GBeanMBean.RAW_INVOKER, then it will also be the Raw type; otherwise
> - it will be the JMX type. In this specific case, one could assume 
> that the JMX naming conventions have been applied.

I definitely think the two should work exactly the same and the 
programmer should not know which one is being used (other then the JMX 
one is way slower).  My biggest reason to have these work the same is 
the person using the GBeanInvoker is caller, and the caller would have 
to know how the target GBean was implemented in order to get the 
calling code correct.

-dain

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by Gianny Damour <gi...@optusnet.com.au>.

On 14/07/2004 12:09 PM, Dain Sundstrom wrote:

>
>> On 14/07/2004 9:17 AM, Gianny Damour wrote:
>>
>> I have just updated the way GBean attribute names are derived:
>> When GBeans are proxied via RawGBeanInvokers, attribute names may 
>> start with an upper-case letter. For instance, if a GBean has a 
>> method "getFoo", then the implementation tries to find an attribute 
>> having the name "Foo". This was the behavior before my updates and I 
>> have restored it. Now, if such an attribute is not defined, then the 
>> implementation tries to find an attribute having the name "foo".
>>
>> When GBeans are proxied via JMXGBeanInvokers, attribute names are 
>> derived based on the "exact" name embedded in the method name. For 
>> instance, if a GBean has a method "getfoo", then the implementation 
>> tries to find an attribute having the name "foo". This was the 
>> behavior before my updates and I have restored it.
>
>
> Uh, I think you lost me.  I suggest we first try an exact match using 
> JMX standard MBean rules (getFoo looks for a method Foo) and if that 
> fails we do a case insensitive match.  What ever we do, it must be 
> consistent between the GBeanInvokers, since the programmer has not 
> input into the invoker type the container chooses.

Sorry; indeed, this is perhaps not the right approach. However, I was 
pretty confident that this new behavior was more correct:
As far as I understand, the JMX GBeanInvokers are used only when the 
"framework" mounts a reference, which does not have an attribute named 
GBeanMBean.RAW_INVOKER. Most of the time, this means that the reference 
is an "home-made" MBean (an MBean, which is not a GBeanMBean). So, I 
thought that we could safely say that programmers have applied the JMX 
standards. In other words, if the attribute is named "serverVersion", 
then the getter must be "getserverVersion".

Having said that, the RawGBeanInvokers are used, most of the time, when 
the reference is a GBeanMBean. Based on the naming conventions of the 
attribute names (lower-case for the first character), I saw two approaches:
- renaming of the getters and setters of the various GBeans in order to 
be aligned with the JMX standards; or
- update of the way methods and attribute names were matched.

The second approach has been implemented. This means that from a method 
getFoo, the implementation will look for Foo. In case of failure, it 
will then look for foo.
I am happy to make this second look-up case insensitive. Yet, I am not 
sure that JMX GBeanInvokers should mirror this behavior.

In other words, and as far as I understand, programmers know the invoker 
type, which will be used by the container:
- if they use a GBean, it will be the Raw type;
- if they implement an MBean having an attribute GBeanMBean.RAW_INVOKER, 
then it will also be the Raw type; otherwise
- it will be the JMX type. In this specific case, one could assume that 
the JMX naming conventions have been applied.

There is something wrong in my reasoning; nonetheless, I do not know where.

Thanks,
Gianny

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by Dain Sundstrom <da...@coredevelopers.net>.

On Jul 13, 2004, at 6:01 PM, Gianny Damour wrote:

> On 14/07/2004 9:17 AM, Gianny Damour wrote:
>
> I have just updated the way GBean attribute names are derived:
> When GBeans are proxied via RawGBeanInvokers, attribute names may 
> start with an upper-case letter. For instance, if a GBean has a method 
> "getFoo", then the implementation tries to find an attribute having 
> the name "Foo". This was the behavior before my updates and I have 
> restored it. Now, if such an attribute is not defined, then the 
> implementation tries to find an attribute having the name "foo".
>
> When GBeans are proxied via JMXGBeanInvokers, attribute names are 
> derived based on the "exact" name embedded in the method name. For 
> instance, if a GBean has a method "getfoo", then the implementation 
> tries to find an attribute having the name "foo". This was the 
> behavior before my updates and I have restored it.

Uh, I think you lost me.  I suggest we first try an exact match using 
JMX standard MBean rules (getFoo looks for a method Foo) and if that 
fails we do a case insensitive match.  What ever we do, it must be 
consistent between the GBeanInvokers, since the programmer has not 
input into the invoker type the container chooses.

-dain

Re: [jira] Created: (GERONIMO-267) NoSuchOperationError on deployment of SSB

Posted by Gianny Damour <gi...@optusnet.com.au>.

On 14/07/2004 9:17 AM, Gianny Damour wrote:

>> org.apache.geronimo.gbean.jmx.NoSuchOperationError: No implementation 
>> method: 
>> objectName=geronimo.server:J2EEApplication=skeleton/app,J2EEModule=skeleton-ejb.jar,J2EEServer=geronimo,j2eeType=StatelessSessionBean,name=StatelessSession, 
>> method=public abstract org.openejb.EJBContainer 
>> org.openejb.EJBContainer.getUnmanagedReference()
>>  
>>
> This is my fault.... I have recently changed the way GBean attributes 
> names are derived from a method name: basically, from the 
> getUnmanagedReference method, the new implementation looks for an 
> attribute name "unmanagedReference". As the name of this attribute is 
> actually "UnmanagedReference", this exception is raised.

I have just updated the way GBean attribute names are derived:
When GBeans are proxied via RawGBeanInvokers, attribute names may start 
with an upper-case letter. For instance, if a GBean has a method 
"getFoo", then the implementation tries to find an attribute having the 
name "Foo". This was the behavior before my updates and I have restored 
it. Now, if such an attribute is not defined, then the implementation 
tries to find an attribute having the name "foo".

When GBeans are proxied via JMXGBeanInvokers, attribute names are 
derived based on the "exact" name embedded in the method name. For 
instance, if a GBean has a method "getfoo", then the implementation 
tries to find an attribute having the name "foo". This was the behavior 
before my updates and I have restored it.

Gianny