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

>>>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
>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?

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 
>        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 
>        at 
>The class was simply Serializable with no UID set.
>Then I made it Externalizable and set a UID and started getting
>com.pace2020.appbox.common.objectbundle.ValidatedBundle; Local class not 
>compatible: stream classdesc serialVersionUID=-1436348206578395418 local 
>class serialVersionUID=0
>        at 
>        at java.io.ObjectStreamClass.setClass(ObjectStreamClass.java:567)
>        at 
>        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>

View raw message