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:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
