geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From anita kulshreshtha <a_kuls...@yahoo.com>
Subject Re: svn commit: r485321 - in /geronimo/server/trunk/modules: geronimo-kernel/src/main/java/org/apache/geronimo/gbean/ geronimo-kernel/src/main/java/org/apache/geronimo/gbean/runtime/ geronimo-kernel/src/test/java/org/apache/geronimo/gbean/ geronimo-k
Date Wed, 13 Dec 2006 14:00:50 GMT
Thanks Dain!

--- Dain Sundstrom <dain@iq80.com> wrote:

> On Dec 12, 2006, at 5:32 AM, anita kulshreshtha wrote:
> 
> >  Thanks Gianny, David J and Dain for providing feedback. I could
> have
> > certainly used it before commiting rev 485321. IIUC, here is what  
> > needs
> > to be done:
> > 1. .....Make the necessary code changes to
> > GBeanInfoBuilder while keeping the signatures of addOperation
> methods same.
   
   API compatibility - yes
   Serialization compatibility - depends on GOparationInfo

> > 2. GoperationInfo must contain a field named targetClass
> > (declaringClass?). There are 2 options:
> >    a.. Just add the field and maintain backward compatibility

       API compatibility - yes
       Serialization compatibility - yes
 
> >    b.. Clean the code, i.e. remove unused field methodName and
> break
> > the compatibility.

       API compatibility - no
       Serialization compatibility - no
    Even in Geronimo GOperationInfo does not seem to be used outside of
the kernel, hence it will be safe to remove the constructors without
the targetClass. I think we should not allow incomplete GOpeartionInfo
objects. But then I do not know what is the protocol for fixing the
API...
 
>      
> Which backward compatibility API, serialization or both?
> 
> I prefer we don't break backwards compatibility in the GBean apis  
> since they are used everywhere.
> 
> >      I am leaning towards b.
> > 3. The fact that in some cases GBeanInfoBuilder.addInterfaces()
> Line
> > 295 ends up with two methods with same name and signatures but
> > different return type, it is not by design. Most of the time it is
> due
> > to a badly overridden getter/setter/operation, and it is not the
> > responsibility of GBeanInfoBuilder to flag that as an error.
> 
> In Java5 a method is allowed to override/implement a method with a  
> return type that is more specific.  For example:
> 
> public interface Intf {
>    Object getSomething();
> }
> 
> public class Clazz implements Intf {
>    public String getSomething() {
>        return "something"
>    }
> }
> 
> -dain

  Ah.. java 5... One more question :)
    Why do we allow bad operations in GBeanInfo ? For example it is
possible to add a non existent operation to GBeanInfo.

Thanks
Anita
 



 
____________________________________________________________________________________
Any questions? Get answers on any topic at www.Answers.yahoo.com.  Try it now.

Mime
View raw message