avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@managingpartners.com>
Subject Re: [altrmi] usage questions
Date Thu, 11 Apr 2002 21:49:40 GMT
On Thursday 11 April 2002 02:03 am, Paul Hammant wrote:
> >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?

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

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

> 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! :)

-pete

-- 
peter royal -> proyal@managingpartners.com

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