geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr. <ge...@optonline.net>
Subject Re: JBoss Exhibit "D" : similarity between org.apache.geronimo.common.Invocation and org.jboss.invocation.Invocation
Date Sat, 15 Nov 2003 11:16:24 GMT

On Thursday, November 13, 2003, at 07:21 AM, Geir Magnusson Jr. wrote:

> Claim : both files contain "AsIs", "Transient" and "Marhsalled", which  
> are believed to be JBoss-specific payloads, and thus could only be  
> there via copying. Further, the Invocation file is central to the  
> JBoss architecture, and thus copying could have great impact  
> throughout Geronimo.
>
> (I forgot this - the JBoss lawyer's letter just calls it out in text,  
> not as a specific exhibit)
>
> Comment : The last part, about architectural similarity, is a  
> non-issue, I believe.  You can't copyright the idea, just the  
> expression of the idea.


I think I understand this all now.  The following analysis is mostly  
based on guesswork as to the whole architecture, so if I have  
assumptions wrong, someone let me know.

As I said before, org.apache.geronimo.core.service.Invocation currently  
is a riff on java.util.Map, namely :

public interface Invocation {

     Object get(InvocationKey key);
     void put(InvocationKey key, Object value);
}

However, it used to be, when the code first placed into Geronimo,  
slightly different :

http://cvs.apache.org/viewcvs/incubator-geronimo/modules/core/src/java/ 
org/apache/geronimo/common/Attic/Invocation.java?rev=1.1&content- 
type=text/vnd.viewcvs-markup

public interface Invocation {
     Object getMarshal(Object key);

     void putMarshal(Object key, Object value);

     Object getAsIs(Object key);

     void putAsIs(Object key, Object value);

     Object getTransient(Object key);

     void putTransient(Object key, Object value);
}

still an interface, but dealing with the three notions of 'Marshal',  
'AsIs', and 'Transient'.  This is what the JBoss Group LLCs lawyers are  
referring to.  Now, looking at the Interceptor class in JBoss, and  
looking at the version in their CVS at the time of the import into  
Geronimo, 1.10.2.6, there is an implementation of the same notion in a  
method - following snipped out for brevity :

/**
     * Advanced store
     * Here you can pass a TYPE that indicates where to put the value.
     * TRANSIENT: the value is put in a map that WON'T be passed
     * AS_IS: no need to marshall the value when passed (use for all JDK
     *    java types)
     * PAYLOAD: we need to marshall the value as its type is application  
specific
     */
    public void setValue(Object key, Object value, PayloadKey type)
    {
       if(type == PayloadKey.TRANSIENT)
       {
           transient_payload.put(key,value);
       }
       else if(type == PayloadKey.AS_IS)
       {
           as_is_payload.put(key,value);
       }
       else if(type == PayloadKey.PAYLOAD)
       {
           payload.put(key,value);
       }
       else
       {
          throw new IllegalArgumentException("Unknown PayloadKey: " +  
type);
       }
    }

No, I don't completely understand the whole architecture, but it  
appears that this is a storage class for moving bits through their  
invocation/interceptor mechanism, and that they are doing what appears  
to be an early optimization by having the caller define via the keytype  
if a) the data doesn't need to be marshalled as it's staying put on  
this side of the wire (TRANSIENT), b) the data doesn't need to have any  
special care and feeding as it's a JDK data type (ASIS), or c) it will  
need to be marshalled (PAYLOAD).

So it's clear to me that the code originally in Geronimo (and now in  
the Attic) implemented this *idea* in their interface, moving it  
outside of the Invocation implementation and into the interface.  This  
is an implementation of the idea. [And I'm struggling very hard to keep  
from editorializing on the idea because I wonder why the caller has to  
be involved in the marshalling mechanics...]

Now, I guess we have to come back to the code as it exists today in the  
o.a.g.core.service package.  Repeating for Invocation.java, it is now  
much simpler - the got rid of the 'Asis', 'Marshal' and 'Transient'  
'modifiers' on the methods and reduced it to

public interface Invocation {

     Object get(InvocationKey key);
     void put(InvocationKey key, Object value);
}

where

public interface InvocationKey {

     boolean isTransient();
}

so now the idea of declaring something as not going over the wire (my  
assumption) is taken care of in the key itself into this map, letting I  
assume the endpoint doing the serialzation decide if the element in the  
map needs to go based on the isTransient() method, and how marshalled  
based on the class. [Yay!]

Summary so far : the original code had an expression of the idea of  
'Marshall', 'AsIs' and 'Transient'.  66% of the idea was dropped.  All  
that remains of the idea is letting the caller declare the data as  
transient [something only the caller knows, I guess].  I don't know  
enough about this subject to wonder if other implementations of  
invocation/marshalling frameworks have the same thing.

Here's the kicker.  The JBoss lawyers assert that "the Invocation file  
is central to the architecture of both JBoss and Geronimo".  This claim  
is utterly false because if this notion of AsIs, Transient and  
Marshalled was 'central to the architecture', it couldn't be dropped to  
the degree that the Geronimo developers did.  IOW, the notions of AsIs  
and Marshalled are NOT central to the architecture at all - they don't  
exist anymore.  So to summarize :

1) The original code in Geronimo (w/ getAsIs()) is not a copy of JBoss  
code in any way - it's a different implementation of an idea in the  
JBoss implementation.

2) The current code has thrown out all but the idea that the user of an  
Invocation implementation declare that data placed into that  
implementation is transient.

Comments please.

-- 
Geir Magnusson Jr                                   203-247-1713(m)
geirm@optonline.net


Mime
View raw message