geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hiram Chirino <hi...@coredevelopers.net>
Subject Re: JBoss Exhibit "D" : similarity between org.apache.geronimo.common.Invocation and org.jboss.invocation.Invocation
Date Sat, 15 Nov 2003 19:30:15 GMT
Geir Magnusson Jr. wrote:

>
> 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.
>
Your summary of the issue is right on.  To further clarify the issue I 
removed the idea of the 3 hashmaps since it was just pain dumb and could 
be more efficiently handled with a single hashmap.

Regards,
Hiram




Mime
View raw message