avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Hammant <Paul_Hamm...@yahoo.com>
Subject Re: [altrmi] usage questions
Date Fri, 12 Apr 2002 06:06:45 GMT
Peter,

>>>It appears that the authentication information is passed on each remote
>>>method invocation, correct?
>>>
>>Not so.  There are two methods for use at the lookup stage.  One has an
>>(untested) authentication parameter.  Once the lookup has a returned the
>>remote refernece, it there is no sunsequent passing of authentication
>>stuff.
>>
>
>I meant each call to lookup(), which it does. Most excellent! Any known 
>harm's to calling lookup() multiple times on an AltrmiInterfaceLookup w/o 
>corresponding close() calls?
>
No,

The OpenConnection (hidden from you) establishes 'session' .  If X is 
bought back on lookup and given a refId (hidden again) of 123, andy 
other lookup on it is just going to give the same instance and refId. 
 Harmless.  Having said that, I would split my app into two ... a 
container concept that knows of AltRMI and does the lookup, and a comp 
tha uses it, and has no handle on the interface that can be used for 
lookup.  I think you have moved beyong the cornerstone transport 
packaged yes?

>>A guy called Juozas Baliuka (whom gerhard works with for SimpleStore in
>>Commons) says that JAAS should be targeted for compatibility.  We also
>>have an issue re transactions.  In EJB, transaction is not passed as a
>>paremter on methods but as ssomething that is associated with the
>>thread.  If we go down that road, then thread safety will be affected
>>(referring to your prev questions).  It has not been settled yet as we
>>were pushing towards distributed garbage collection and callbacks.
>>
>
>I briefly looked at JAAS for my own app's security but decided against it for 
>something much simpler and home grown. I may be interested in that in the 
>future, mainly to authenticate against NT/W2k domains (but from what I read 
>that's kinda a pain due to missing/incomplete docs)
>
My only lingering fear is that it is Thread-context using and thus will 
hugely change AltRMI.

>>Leid uses AltRMI in Instrument.  It could be useful to have some
>>Component wrapper (optional packages) for an increased integration with
>>Avalon family applications.  The design was driven from a bean
>>perspective though -> A tool that can be instantiated and used by any
>>client or server app, with few external dependencies.
>>
>
>I broke down and wrote one :)
>
>It is modeled after Berin's JdbcConnectionPool (ie copy-class in IDEA and 
>change as neeed). I need to get a formal "yes" from management here before 
>contributing back as it'll be the first non-patch donation and I want to make 
>sure all the i & t's are covered.
>
IDEA is sooo cool :-)

Fingers crossed!  

>>Thank us when it is bullet proof :-)
>>
>
>I'll try and help you get there. Otherwise my initial tests went well.
>
>I was also getting this sending one of my classes from the client to the 
>server (most things go from server->client, this is the most complex thing 
>going back to the server):
>
>java.io.StreamCorruptedException: Type code out of range, is 1
>        at java.io.ObjectInputStream.peekCode(ObjectInputStream.java:1556)
>        at 
>java.io.ObjectInputStream.skipToEndOfBlockData(ObjectInputStream.java:1480)
>        at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1216)
>        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
>        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
>        at 
>org.apache.excalibur.altrmi.server.impl.ServerObjectStreamReadWriter.readRequest(ServerObjectStreamReadWriter.java:78)
>        at 
>org.apache.excalibur.altrmi.server.impl.ServerObjectStreamReadWriter.writeReplyAndGetRequest(ServerObjectStreamReadWriter.java:66)
>
>The class was simply Serializable with no UID set.
>
>Then I made it Externalizable and set a UID and started getting
>
>java.io.InvalidClassException: 
>com.pace2020.appbox.common.objectbundle.ValidatedBundle; Local class not 
>compatible: stream classdesc serialVersionUID=-1436348206578395418 local 
>class serialVersionUID=0
>        at 
>java.io.ObjectStreamClass.validateLocalClass(ObjectStreamClass.java:523)
>        at java.io.ObjectStreamClass.setClass(ObjectStreamClass.java:567)
>        at 
>java.io.ObjectInputStream.inputClassDescriptor(ObjectInputStream.java:936)
>        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:366)
>        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:236)
>        at java.io.ObjectInputStream.inputObject(ObjectInputStream.java:1186)
>        at java.io.ObjectInputStream.readObject(ObjectInputStream.java:386)
>
>Which is odd because they both have the same class file!
>
>I will mess around more later tonight, stripping down the class until it goes 
>through and then adding back data members to see what the cause is. But if 
>you have any ideas off the top of your head! :)
>
Did you remember super.externalize() ?  And that it is FIFO no LIFO ?

- Paul


--
To unsubscribe, e-mail:   <mailto:avalon-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:avalon-dev-help@jakarta.apache.org>


Mime
View raw message