Geir Magnusson Jr. wrote:
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.
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.
Regards, Hiram
