RMI-IIOP specification

I look out for an exact specification of the RMI-IIOP,similarly to the
specification of the RMI (http://java.sun.com/products/jdk/rmi/).
My special interest concerns the 'Parameter Transmission'. Probably there
are no hardly differences between RMI and RMI-IIOP, but I would like to know
it exactly.
Thanks in advance,
Frank

I'm not sure I understand what it is that you are looking for. The IIOP
specification is defined by OMG. How Java types map to IDL types is defined by
the first spec on this site. How IDL valuetypes map to IIOP is defined on the
second.
I do not believe that there is a separate specification for RMI/IIOP since it
really depends on these other OMG specifications. There is a separate
specification for EJB-CORBA interoperability at:
http://java.sun.com/products/ejb/docs.html
Hope this helps,
Robert
"Frank Thomas Aßmann" wrote:
Hi Robert!
Thank you, but I knew that site before. It only contains the two
specifications of the Object Management Group, on which RMI over IIOP is
based on. I search for an exact specification of the RMI-IIOP itself.
Thanks,
Frank
"Robert Patrick" wrote
http://java.sun.com/products/rmi-iiop/
"Frank Thomas Aßmann" wrote:
I look out for an exact specification of the RMI-IIOP,similarly to the
specification of the RMI (http://java.sun.com/products/jdk/rmi/).
My special interest concerns the 'Parameter Transmission'. Probably
there
are no hardly differences between RMI and RMI-IIOP, but I would like toknow
it exactly.

Similar Messages

Use RMI-IIOP with wls 5.1 or 6.0 ???

Morning,
I was wondering if is was possible to use RMI-IIOP with
WebLogic Server 5.1 or 6.0 and if possible with which version
of the RMI-IIOP specification ???
I've not seen any information about that in the documentation ; if anybody could
help, I would appreciate !
Thanks a lot.
Pierre-Yves FOURMOND
Axway Software. a Sopra Group Company
Direction Edition de Progiciels
EAI - R&D XTalk
Puteaux 2 - Bureau n°204
[email protected]
01 47 17 22 55

"Pierre-Yves Fourmond" <[email protected]> writes:
I was wondering if is was possible to use RMI-IIOP with
WebLogic Server 5.1 or 6.0 and if possible with which version
of the RMI-IIOP specification ???WLS 5.1SP11 has the same RMI-IIOP runtime as WLS6.1SP2. 6.0 contains
the old runtime, at the moment it seems most customers are happy to
upgrade to 6.1 from 6.0
andy
>
I've not seen any information about that in the documentation ; if anybody could
help, I would appreciate !
Thanks a lot.
Pierre-Yves FOURMOND
Axway Software. a Sopra Group Company
Direction Edition de Progiciels
EAI - R&D XTalk
Puteaux 2 - Bureau n°204
[email protected]
01 47 17 22 55--
" .sigs are like your face - rarely seen by you and uglier than you think"
mail: [email protected]

RMI/IIOP and WTC

The web docs talk about modifying RMI/IIOP applications to use WTC.
Just need a confirmation that RMI/IIOP calls to EJBs in WLS will not be
transactional. That XA transactions will require the ATMI interface to
Tuxedo EJBs. (Beta in WLS 6.1)

Carl,
I for one would be interested to hear how you are using the Tuxedo/WTC (I
assume you mean Java ATMI) in your application. We need some feedback here
in development land so that we can see which things you like about jATMI and
which things you like less...
Of course, anyone using jATMI can reply as well...
John Wells (Aziz)
[email protected]
[email protected]
"Carl Lawstuen" <[email protected]> wrote in message
news:3bba357d$[email protected]..
Thanks for the clarification. While we will need to support CORBA style
access at some time, the Tuxedo/WTC interface fits nicely in our current
legacy to WLS architecture.
"Andy Piper" <[email protected]> wrote in message
news:[email protected]..
"Carl Lawstuen" <[email protected]> writes:
Yes, the ATMI interface to WTC should be transactional.
But I would assume that RMI/IIOP applications that uses WTC for access
to
WLS naming service would not be transactional due to limitations in
the
RMI/IIOP specification regarding transactions.
Just looking for confirmation that BEA has not done anything to make
RMI/IIOP calls into WLS transactional.RMI-IIOP calls over wtc (i.e. RMI-TGIOP) are transactional and
secure. RMI-IIOP calls over vanilla IIOP are not transactional, but
can be secure. OTS support is coming in Acadia.
RMI-IIOP over wtc totally leverages the ATMI support so you get all
the same features + CORBA-style access. The RMI-IIOP spec is fairly
irrelevant in this instance since we do not have to to support
interoperable transactions to support transaction propagation from Tux
over WTC. That's kind of the whole point - the specs have their rough
edges when it comes to defining transactions and security over IIOP
but we give you exactly what you want (transactions and security)
using the internal tux domains protocol.
andy

How to get InitialContextFactory using RMI/IIOP without using weblogic.jar

Hi Robert
I know this is an old post. but I am interested in knowing how to get the
initial context using RMI/IIOP without the use weblogic specific classes
like weblogic.jndi.WLInitialContextFactory . If you have a code snippet that
you can provide as an example, it would be just great.
thanx in advance
Daya Sharma
See comments inline...
Stewart Wachs wrote:
I would like to get an initial context to Weblogic JNDI from a client.
code snippet:
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFacorty");
ht.put(Context.PROVIDER_URL, "t3://localhost:7001");
try {
Context ctx = new InitialContext(ht);
catch(...) {
This works fine when I include weblogic.jar (and other dependend weblogic
jar's) in the classpath.
Is there a way to access WL JNDI from a client without the weblogicclasses
in the classpath?If you are using WLS 6.1, you could use RMI/IIOP to do this but in general,
the
answer is no, you will need at least some of the weblogic classes on the
client.
If not, is there a lightweight jar available for distribution for client
JNDI connectivity?This is something in the works. In addition, a colleague and I are working
on
a white paper that describes the "Thin Client Options with WebLogic Server"
that we hope to make available in the not too distant future...
Are there any licencing issues with distributing the weblogic classes to
clients that need to access WL JNDI?No. WLS is licensed by the server so you are free to distribute
weblogic.jar
to your clients.
Hope this helps,
Robert

Take a look at the RMI/IIOP section of our whitepaper "Small Footprint
Client options for BEA WebLogic Server" at:
http://dev2dev.bea.com/resourcelibrary/whitepapers.jsp?highlight=whitepapers
Daya Sharma wrote:
Hi Robert
I know this is an old post. but I am interested in knowing how to get the
initial context using RMI/IIOP without the use weblogic specific classes
like weblogic.jndi.WLInitialContextFactory . If you have a code snippet that
you can provide as an example, it would be just great.
thanx in advance
Daya Sharma
See comments inline...
Stewart Wachs wrote:
I would like to get an initial context to Weblogic JNDI from a client.
code snippet:
Hashtable ht = new Hashtable();
ht.put(Context.INITIAL_CONTEXT_FACTORY,
"weblogic.jndi.WLInitialContextFacorty");
ht.put(Context.PROVIDER_URL, "t3://localhost:7001");
try {
Context ctx = new InitialContext(ht);
catch(...) {
This works fine when I include weblogic.jar (and other dependend weblogic
jar's) in the classpath.
Is there a way to access WL JNDI from a client without the weblogic
classes
in the classpath?
If you are using WLS 6.1, you could use RMI/IIOP to do this but in general,
the
answer is no, you will need at least some of the weblogic classes on the
client.
If not, is there a lightweight jar available for distribution for client
JNDI connectivity?
This is something in the works. In addition, a colleague and I are working
on
a white paper that describes the "Thin Client Options with WebLogic Server"
that we hope to make available in the not too distant future...
Are there any licencing issues with distributing the weblogic classes to
clients that need to access WL JNDI?
No. WLS is licensed by the server so you are free to distribute
weblogic.jar
to your clients.
Hope this helps,
Robert

Error while using RMI IIOP

Hi all,
this is my client code which access EJB 2.1 and SUN JES AS 8.1 using RMI IIOP
i get the remote home interface well but when i use home.create(), it retruns null.
can anyone help me???
Here is the coding,
Properties props = new Properties();
//props.put("javax.rmi.CORBA.UtilClass",
// "com.sun.corba.ee.impl.javax.rmi.CORBA.Util");
props.put("org.omg.CORBA.ORBClass","com.ooc.OBServer.ORB");
props.put("org.omg.CORBA.ORBSingletonClass","com.ooc.CORBA.ORBSingleton");
props.put(Context.INITIAL_CONTEXT_FACTORY,
"com.sun.jndi.cosnaming.CNCtxFactory");
props.put(Context.PROVIDER_URL, "iiop://10.24.17.68:3360"); // the port of the application server
props.put("ooc.orb.service.NameService",
"corbaloc:iiop:10.24.17.68:3360/NameService");
String[] args = null;
ORB orb = ORB.init(args, props);
Context ctx;
Object obj;
try {
ctx = new InitialContext(props);
System.out.println("RMI: 1");
obj = ctx.lookup("ejb/NewSessionBean");
System.out.println("RMI: 2");
System.out.println("object name: "+obj.getClass().getName());
System.out.println("object class loader: "+obj.getClass().getClassLoader());
NewSessionRemoteHome home = (NewSessionRemoteHome) PortableRemoteObject.
narrow(obj, NewSessionRemoteHome.class);
System.out.println("Interface name: "+home.getClass().getName());
System.out.println("RMI: 3: " + home.toString());
if (home == null){
System.out.println("home is null");
NewSessionRemote remo = (NewSessionRemote)home.create();
System.out.println("RMI: 4");
remo.printText("Welcome to RMI world"); //the message send by the client
System.out.println("The sending of RMI is succeed");
} catch (Exception ex) {
System.out.println("exception starts:");
ex.printStackTrace();
System.out.println("Exception occurs. Exception: " + ex.getMessage());
Here is the traces,
RMI: 1
RMI: 2
object name: com.ooc.CORBA.StubForObject
object class loader: null
Interface name: fr.teleca.orangebenchosa.cdrstat._NewSessionRemoteHome_Stub
RMI: 3: IOR:000000000000004b524d493a66722e74656c6563612e6f72616e676562656e63686f73612e6 36472737461742e4e657753657373696f6e52656d6f7465486f6d653a30303030303030303030303 0303030300000000000010000000000000188000102000000000c31302e32342e31372e3638000d2 0000000000056afabcb00000000260000003f00000009533141532d4f52420000000000000002000 00008526f6f74504f41000000001237353732393838353136303237353936380000000000000d010 d0bede7dc000000000001ff140000000000070000000100000020000000000001000100000002050 10001000100200001010900000001000101000000002600000002000200000000000300000016000 000000000000c31302e32342e31372e3638000d1600000000000300000016000000000000000c313 02e32342e31372e3638000d1300000000001f0000000400000003000000200000000400000001000 000210000007c000000000000000100000000000000240000001e000000660000000000000001000 0000c31302e32342e31372e3638000d1600400000000000000008060667810201010100000017040 1000806066781020101010000000764656661756c740004000000000000000000000100000008060 66781020101010000000f
exception starts:
java.lang.ClassCastException
at com.sun.corba.se.internal.iiop.ShutdownUtilDelegate.isLocal(Unknown Source)
at javax.rmi.CORBA.Util.isLocal(Unknown Source)
at fr.teleca.orangebenchosa.cdrstat._NewSessionRemoteHome_Stub.create(Unknown Source)
at fr.teleca.orangebenchosa.servicelogic.CallHandler$EndState.sendCDRStat(CallHand ler.java:1385)
at fr.teleca.orangebenchosa.servicelogic.CallHandler$EndState.start(CallHandler.ja va:1047)
at com.appium.TAS.SessionContainer.StatefulObject.enterState(StatefulObject.java)
at fr.teleca.orangebenchosa.servicelogic.CallHandler.access$4800(CallHandler.java: 61)
at fr.teleca.orangebenchosa.servicelogic.CallHandler$SuccessfulLogicState.routeRes (CallHandler.java:902)
at com.appium.TAS.SessionComponents.CallControl.a.exec(a.java)
at com.appium.Basement.Synchronization.Asynchronizer.d(Asynchronizer.java)
at com.appium.Basement.Synchronization.g.run(g.java)
Exception occurs. Exception: null

Hi ejp,
because my stand alone client application runs on telecom server which uses orbacus. It calls the remote method on sun AS using RMI IIOP
I specifed the properties of the client to use SUN AS naming services.
I added j2ee.jar and appserv-rt.jar in my client program. but i dont know eventhough i specified the Util properties to use as below
props.put("javax.rmi.CORBA.UtilClass","com.sun.corba.ee.impl.javax.rmi.CORBA.Util");
props.put("org.omg.CORBA.ORBClass", "com.sun.corba.ee.impl.orb.ORBImpl");
props.put("org.omg.CORBA.ORBSingletonClass", "com.sun.corba.ee.impl.orb.ORBSingleton");
props.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.cosnaming.CNCtxFactory");
props.put(Context.PROVIDER_URL,"iiop://10.24.17.68:3360"); // the port of the application server
props.put("ooc.orb.service.NameService", "corbaloc:iiop:10.24.17.68:3360/NameService");
ORB orb = ORB.init(args,props);
Context ctx;
Object obj;
try {
ctx = new InitialContext(props);
obj= ctx.lookup("ejb/NewSessionBean");
NamingEnumeration ne = ctx.listBindings("ejb");
while (ne.hasMore()) {
System.out.println("Binding: " + ne.next());
System.out.println("object name"+obj.getClass().getName());
System.out.println("object class loader"+obj.getClass().getClassLoader());
NewSessionRemoteHome home=(NewSessionRemoteHome)PortableRemoteObject.narrow(obj,NewSessionRemoteHome.class);
System.out.println("Interface name: "+home.getClass().getName());
NewSessionRemote remo=home.create();
System.out.println("Remote name: "+remo.getClass().getName());
remo.printText("Welcome"); //the message send by the client
} catch (Exception ex) {
ex.printStackTrace();
but it uses J2SE Util. Is there any other workaround to do?
Thanks
mdb

Help!!!I can not pass the Logger example of Rmi-iiOP

I am using the j2sdk1.4.0 and j2sdkee1.3.1 as back ground.And use Win2000
I try the rmi-iiop example given by Sun.But it doesn't work.
Firstly , compile Logger.java LoggerHome.java LogMessage.java LoggerEJB.java to class
javac -classpath "c:\j2sdkee1.3.1\lib\j2ee.jar;c:\wytestejb\" Logger.java LoggerHome.java LogMessage.java LoggerEJB.java
that was ok.
Then I draw idl from that just like
rmic -idl -noValueMethods -classpath "c:\j2sdkee1.3.1\lib\j2ee.jar;c:\wytestejb\" Logger LoggerHome
then I got Logger.idl LoggerHome.idl javax\ejb\...idl java\lang\...idl
After that I create one directory named client.copying all idl file into it,I transfered idl to java using
idlj -i C:\j2sdk1.4.0\lib -i c:\wytestejb\client -i C:\j2sdkee1.3.1\lib -emitAll -fclient Logger.idl
idlj -i C:\j2sdk1.4.0\lib -i c:\wytestejb\client -i C:\j2sdkee1.3.1\lib -emitAll -fclient LoggerHome.idl
Then I got *.java such as Logger.java LoggerHome.java .....java java\lang\***.class javax\ejb\****.class
I put the LogClient.java in this directory and compile *.java like
C:\wytestejb\client>javac -classpath "c:\j2sdkee1.3.1\lib\j2ee.jar;c:\wytestejb\
client;c:\j2sdk1.4.0\lib;c:\j2sdk1.4.0\bin" *.java
And I got
c:\wytestejb\client\java\lang\_Exception.java:23: cannot resolve symbol
symbol : method _read (org.omg.CORBA.portable.InputStream)
location: class java.lang.Throwable
super._read (istream);
^
c:\wytestejb\client\java\lang\_Exception.java:28: cannot resolve symbol
symbol : method _write (org.omg.CORBA.portable.OutputStream)
location: class java.lang.Throwable
super._write (ostream);
^
LogClient.java:20: cannot resolve symbol
symbol : method println (java.lang.String)
location: interface java.io.PrintStream
System.out.println("Looking for: " + loggerHomeURL);
^
LogClient.java:38: cannot resolve symbol
symbol : method println (java.lang.String)
location: interface java.io.PrintStream
System.out.println("Logging...");
^
LogClient.java:47: cannot resolve symbol
symbol : method println (java.lang.String)
location: interface java.io.PrintStream
System.out.println("Done");
^
LogClient.java:59: cannot resolve symbol
symbol : method println (java.lang.String)
location: interface java.io.PrintStream
System.out.println("Args: corbaname URL of LoggerHome");
^
LogClient.java:66: cannot resolve symbol
symbol : method printStackTrace ()
location: class java.lang.Throwable
t.printStackTrace();
^
7 errors
C:\wytestejb\client>

By the way
My java file is as
Logger.java
The file Logger.java is the enterprise bean's remote interface, and as such, it extends EJBObject . A remote interface provides the remote client view of an EJB object and defines the business methods callable by a remote client.
//Code Example 1: Logger.java
package ejbinterop;
import javax.ejb.EJBObject;
import java.rmi.RemoteException;
* Accepts simple String log messages and prints
* them on the server.
public interface Logger extends EJBObject
* Logs the given message on the server with
* the current server time.
void logString(String message) throws RemoteException;
LoggerHome.java
The file LoggerHome.java extends EJBHome . The EJBHome interface must be extended by all EJB component's remote home interfaces. A home interface defines the methods that allow a remote client to create, find, and remove EJB objects, as well as home business methods that are not specific to an EJB instance.
//Code Example 2: LoggerHome.java
package ejbinterop;
import java.rmi.RemoteException;
import javax.ejb.EJBHome;
import javax.ejb.CreateException;
public interface LoggerHome extends EJBHome
Logger create() throws RemoteException, CreateException;
LoggerEJB.java
The file LoggerEJB.java contains the code for a session bean. A session bean is an enterprise bean that is created by a client and that usually exists only for the duration of a single client-server session. A session bean performs operations such as calculations or accessing a database for the client. In this example, the enterprise bean accepts simple String log messages from the client and prints them on the server.
//LoggerEJB.java
package ejbinterop;
import javax.ejb.*;
import java.util.*;
import java.rmi.*;
import java.io.*;
* Accepts simple String log messages and prints
* them on the server.
public class LoggerEJB implements SessionBean {
public LoggerEJB() {}
public void ejbCreate() {}
public void ejbRemove() {}
public void ejbActivate() {}
public void ejbPassivate() {}
public void setSessionContext(SessionContext sc) {}
* Logs the given message on the server with
* the current server time.
public void logString(String message) {
LogMessage msg = new LogMessage(message);
System.out.println(msg);
LogMessage.java
The file LogMessage.java takes the current date and time, creates a formatted String showing the message, and prints the message to the server.
//LogMessage.java
package ejbinterop;
import java.io.Serializable;
import java.util.Date;
import java.text.*;
* Simple message class that handles pretty
* printing of log messages.
public class LogMessage implements Serializable
private String message;
private long datetime;
* Constructor taking the message. This will
* take the current date and time.
public LogMessage(String msg) {
message = msg;
datetime = (new Date()).getTime();
* Creates a formatted String showing the message.
public String toString() {
StringBuffer sbuf = new StringBuffer();
DateFormat dformat
= DateFormat.getDateTimeInstance(DateFormat.MEDIUM,
DateFormat.LONG);
FieldPosition fpos = new
FieldPosition(DateFormat.DATE_FIELD);
dformat.format(new Date(datetime), sbuf, fpos);
sbuf.append(": ");
sbuf.append(message);
return sbuf.toString();
//Code Example: LogClient.java
package ejbinterop;
import java.rmi.RemoteException;
import javax.rmi.*;
import java.io.*;
import javax.naming.*;
import javax.ejb.*;
* Simple Java RMI-IIOP client that uses an EJB component.
public class LogClient
* Given a corbaname URL for a LoggerHome,
* log a simple String message on the server.
public static void run(String loggerHomeURL)
throws CreateException, RemoveException,
RemoteException, NamingException
System.out.println("Looking for: " + loggerHomeURL);
// Create an InitialContext. This will use the
// CosNaming provider we will specify at runtime.
InitialContext ic = new InitialContext();
// Lookup the LoggerHome in the naming context
// pointed to by the corbaname URL
Object homeObj = ic.lookup(loggerHomeURL);
// Perform a safe downcast
LoggerHome home
= (LoggerHome)PortableRemoteObject.narrow(homeObj,
LoggerHome.class);
// Create a Logger EJB reference
Logger logger = home.create();
System.out.println("Logging...");
// Log our message
logger.logString("Message from a Java RMI-IIOP client");
// Tell the application server we won't use this
// EJB reference anymore
logger.remove();
System.out.println("Done");
* Simple main method to check arguments and handle
* exceptions.
public static void main(String args[])
try {
if (args.length != 1) {
System.out.println("Args: corbaname URL of LoggerHome");
System.exit(1);
LogClient.run(args[0]);
} catch (Throwable t) {
t.printStackTrace();
System.exit(1);

Rmi iiop http ?

Hi,
I'd like to have some precisions about the communication between a
remote java fat client and a weblogic ejb container.
We should use RMI, but what is the protocol we have to use : RMI IIOP
or HTTP
Can we wrap rmi with http ?
thanks in advance

You can use RMI over t3(weblogic specific) or IIOP.
Please take a look at http://edocs.bea.com/wls/docs81/rmi_iiop/index.html
-utpal
"truecolor" <[email protected]> wrote in message
news:[email protected]..
Hi,
I'd like to have some precisions about the communication between a
remote java fat client and a weblogic ejb container.
We should use RMI, but what is the protocol we have to use : RMI IIOP
or HTTP
Can we wrap rmi with http ?
thanks in advance

RMI/IIOP vs CORBA ?

Is there any difference in what you can do with a CORBA implementation as opposed to an RMI/IIOP implementation? Is there anything that can be done in one and not the other? Or were the org.omg.CORBA libraries just a fill-in until the RMI/IIOP framework was developed?
Josh

Hello Sylviae,
I would not put the answer, as quite as what you have.
"RMI/IIOP is a superset of CORBA that is Java specific."
I do not agree with the above statement, as CORBA is more poweful than RMI/IIOP and a comparison will not be accurate. The architecture of CORBA, in my opinion is quite superior to that of RMI and quite distinct.
"then CORBA can make this work, albeit with less flexibility"
On the other hand, the vision with which CORBA started, stated flexibility as a key agreement. CORBA does offer excellent flexibility. What you could be correct in saying, is that, CORBA solutions are difficult to maintain and expensive to construct. As opposed to this, RMI/IIOP (or the framework) provides an easier means to achieve the same.
In any case, RMI over IIOP is actually yet to be proven on mission critical infrastructure. Where CORBA has peformed excellently.
Nice day to you.
Ironluca
P.S.: Your Resume looks great :D

Corba,RMI and RMI-IIOP

Can someone help me understand and analyze the marshaling techniques of CORBA, RMI and RMI-IIOP??

RMI/JRMP is easy, just read the RMI Specification:
http://java.sun.com/j2se/1.5.0/docs/guide/rmi/spec/rmi-protocol.html
CORBA is not so easy. Find the GIOP and IIOP specifications at http://www.omg.org

RMI-IIOP and CORBA version

Hello all,
I am new to CORBA (I understand the concepts, but have never actually programmed anything with it).
I need to write some software in Java that talks to an existing system that has CORBA interfaces. It seems to me that using RMI-IIOP will be a good solution, but in the RMI-IIOP documentation, I have read that it will only work with CORBA version 2.3.
The existing system works with CORBA version 2.0 (as far as I know). Does this mean that I will not be able to use RMI-IIOP at all, or are there some workarounds to get it working with CORBA 2.0?
What would be my alternatives if I cannot use RMI-IIOP because of the version difference?
regards
Jesper

Hi
I have not tried that kombination myself so can not tell you about workarounds, I can tell you that the main difference, in respect to Java, between 2.0 and 2.3 is that the Objects by Value protocoll is incorporated into CORBA 2.3. This extension was specifically designed and added to make RMI-IIOP possible, or atleast more user friendly.
The first workaround I would try is making comunicaitons interfaces built from only basic variable types, but I can not say if it would work. Besides if you are not defining new interfaces (IDL files) you will probably have to work with Java IDL anyway since RMI-IIOP (atleast in jdk1.3) seemed like a one way conversion, Java -> IDL.
Hope this helps
//Samuel

Rmi-iiop authentication and EJB

In WL6.1, I have an Ejb with secured methods. The (Swing) client application accesses the Ejb through rmi-iiop using the JDK1.3.1 Orb.
Unfortunately, it seems that the caller identity (which was supplied in the InitialContext lookup) is not propagated
to the server: any call to a secured method
fails with a CORBA NO_PERMISSION Exception.
Using the t3 protocol the program works fine, but that would require the 25Mb weblogic.jar on all clients, which is unattainable for us.
Any ideas how this situation can be corrected?
-Allard Siemelink

Hello Allard,
My only suggestion (and you have probably looked at this already) would be to
use the Verbosetozip utility, refer to http://e-docs.bea.com/wls/docs61////adminguide/utils.html#1117405
for more information.
Kind Regards,
Richard Wallace
Senior Developer Relations Engineer
BEA Support.
Allard Siemelink <[email protected]> wrote:
In WL6.1, I have an Ejb with secured methods. The (Swing) client application
accesses the Ejb through rmi-iiop using the JDK1.3.1 Orb.
Unfortunately, it seems that the caller identity (which was supplied
in the InitialContext lookup) is not propagated
to the server: any call to a secured method
fails with a CORBA NO_PERMISSION Exception.
Using the t3 protocol the program works fine, but that would require
the 25Mb weblogic.jar on all clients, which is unattainable for us.
Any ideas how this situation can be corrected?
-Allard Siemelink

Rmi-iiop: calling secured method on Ejb -- NO PERMISSION Exception

In WL6.1, I have an Ejb with secured methods. The (Swing) client application accesses the Ejb through rmi-iiop using the JDK1.3.1 Orb.
Unfortunately, it seems that the caller identity (which was supplied in the InitialContext lookup) is not propagated
to the server: any call to a secured method
fails with a CORBA NO_PERMISSION Exception.
Using the t3 protocol the program works fine, but that would require the 25Mb weblogic.jar on all clients, which is unattainable for us.
Any ideas how this situation can be corrected?
-Allard Siemelink

Hi Allard,
Please pose this in the weblogic.developer.interest.rmi-iiop.
Thanks,
Allard Siemelink wrote:
In WL6.1, I have an Ejb with secured methods. The (Swing) client application accesses the Ejb through rmi-iiop using the JDK1.3.1 Orb.
Unfortunately, it seems that the caller identity (which was supplied in the InitialContext lookup) is not propagated
to the server: any call to a secured method
fails with a CORBA NO_PERMISSION Exception.
Using the t3 protocol the program works fine, but that would require the 25Mb weblogic.jar on all clients, which is unattainable for us.
Any ideas how this situation can be corrected?
-Allard Siemelink--
Apurb Kumar
Developer Relations Engineer
BEA Support

RMI-IIOP client - CORBA Server

I already have a CORBA server in C++ which has already been written. I am trying to develop an RMI-IIOP client which would talk to this CORBA Server.
The CORBA server has several interfaces that I would like to use with my RMI-IIOP client. How do I proceed?? Can somebody give me an example of an RMI-IIOP client? Basically my question is: how do I take the IDL and build an RMI-IIOP client with it???

Hello
I already have a CORBA server in C++ which has already
been written. I am trying to develop an RMI-IIOP
client which would talk to this CORBA Server.
The CORBA server has several interfaces that I would
like to use with my RMI-IIOP client. How do I
proceed?? Can somebody give me an example of an
RMI-IIOP client? Basically my question is: how do I
take the IDL and build an RMI-IIOP client with it???The steps to do are the following:
* Creating the Remote interface
* Using the rmic compiler to genarate the IDL and the client stub.
* Generating stub and skeleton of the C++ server using that IDL (the one you already made is no longer compatible)
* Bulding up the new C++ server
* Using a nameservice (tnameserver for example) and binding your server to that.
* Writing the RMI-IIOP client
I proceeded like this (using Visibroker 4.5 on the server side) and I was able to do it... but as you can see from my last post, I wasn't able to pass Strings from the client to the server.
Bye

How to configure OC4J using RMI/IIOP with SSL

Any help?
I just mange configure the OC4J using RMI/IIOP but base on
But when I follow further to use RMI/IIOP with SSL I face the problem with: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
p/s: I use self generate keystore which should be ok as I can use it for https connection.
Any one can help?
Below is the OC4J log:
D:\oc4j\j2ee\home>java -Djavax.net.debug=all -DGenerateIIOP=true -Diiop.runtime.debug=true -jar oc4j.jar
05/02/23 16:43:16 ================ IIOPServerExtensionProvider.preInitApplicationServer
05/02/23 16:43:38 ================= IIOPServerExtensionProvider.postInitApplicationServer
05/02/23 16:43:38 ================== config = {SEPS={IIOP={ssl-port=5556, port=5555, ssl=true, trusted-clients=*, ssl-client-server-auth-port=5557, keystore=D:\\oc4j\\j2ee\\home\\server.keystore, keystore-password=123456, truststore=D:\\oc4j\\j2ee\\home\\server.keystore, truststore-password=123456, ClassName=com.oracle.iiop.server.IIOPServerExtensionProvider, host=localhost}}}
05/02/23 16:43:38 ================== server.getAttributes() = {threadPool=com.evermind.server.ApplicationServerThreadPool@968fda}
05/02/23 16:43:38 ================== pool: null
05/02/23 16:43:38 ====================== In startServer ...
05/02/23 16:43:38 ==================== Creating an IIOPServer ...
05/02/23 16:43:38 ========= IIOP server being initialized
05/02/23 16:43:38 SSL port: 5556
05/02/23 16:43:38 SSL port 2: 5557
05/02/23 16:43:43 com.sun.corba.ee.internal.iiop.GIOPImpl(Thread[Orion Launcher,5,main]): getEndpoint(IIOP_CLEAR_TEXT, 5555, null)
05/02/23 16:43:43 com.sun.corba.ee.internal.iiop.GIOPImpl(Thread[Orion Launcher,5,main]): createListener( socketType = IIOP_CLEAR_TEXT port = 5555 )
05/02/23 16:43:44 com.sun.corba.ee.internal.iiop.GIOPImpl(Thread[Orion Launcher,5,main]): getEndpoint(SSL, 5556, null)
05/02/23 16:43:44 com.sun.corba.ee.internal.iiop.GIOPImpl(Thread[Orion Launcher,5,main]): createListener( socketType = SSL port = 5556 )
05/02/23 16:43:45 ***
05/02/23 16:43:45 found key for : mykey
05/02/23 16:43:45 chain [0] = [
Version: V1
Subject: CN=Server, OU=Bar, O=Foo, L=Some, ST=Where, C=UN
Signature Algorithm: MD5withRSA, OID = 1.2.840.113549.1.1.4
Key: SunJSSE RSA public key:
public exponent:
010001
modulus:
b1239fff 2ae5d31d b01a0cfb 1186bae0 bbc7ac41 94f24464 e92a7e33 6a5b0844
109e30fb d24ad770 99b3ff86 bd96c705 56bf2e7a b3bb9d03 40fdcc0a c9bea9a1
c21395a4 37d8b2ce ff00eb64 e22a6dd6 97578f92 29627229 462ebfee 061c99a4
1c69b3a0 aea6a95b 7ed3fd89 f829f17e a9362efe ccf8034a 0910989a a8573305
Validity: [From: Wed Feb 23 15:57:28 SGT 2005,
To: Tue May 24 15:57:28 SGT 2005]
Issuer: CN=Server, OU=Bar, O=Foo, L=Some, ST=Where, C=UN
SerialNumber: [ 421c3768]
Algorithm: [MD5withRSA]
Signature:
0000: 34 F4 FA D4 6F 23 7B 84 30 42 F3 5C 4B 5E 18 17 4...o#..0B.\K^..
0010: 73 69 73 A6 BF 9A 5D C0 67 8D C3 56 DF A9 4A AC sis...].g..V..J.
0020: 88 AF 24 28 C9 39 16 22 29 81 01 93 86 AA 1A 5D ..$(.9.")......]
0030: 07 89 26 22 91 F0 8F DE E1 4A CF 17 9A 02 51 7D ..&".....J....Q.
0040: 92 D3 6D 9B EF 5E C1 C6 66 F9 11 D4 EB 13 8F 17 ..m..^..f.......
0050: E7 66 58 9F 6C B0 60 7C 39 B4 E0 B7 04 A7 7F A6 .fX.l.`.9.......
0060: 4D A5 89 E7 F4 8A DC 59 B4 E7 A5 D4 0A 35 9A F1 M......Y.....5..
0070: A2 CD 3A 04 D6 8F 16 B1 9E 6F 34 40 E8 C0 47 03 ..:[email protected].
05/02/23 16:43:45 ***
05/02/23 16:43:45 adding as trusted cert:
05/02/23 16:43:45 Subject: CN=Client, OU=Bar, O=Foo, L=Some, ST=Where, C=UN
05/02/23 16:43:45 Issuer: CN=Client, OU=Bar, O=Foo, L=Some, ST=Where, C=UN
05/02/23 16:43:45 Algorithm: RSA; Serial number: 0x421c3779
05/02/23 16:43:45 Valid from Wed Feb 23 15:57:45 SGT 2005 until Tue May 24 15:57:45 SGT 2005
05/02/23 16:43:45 adding as trusted cert:
05/02/23 16:43:45 Subject: CN=Server, OU=Bar, O=Foo, L=Some, ST=Where, C=UN
05/02/23 16:43:45 Issuer: CN=Server, OU=Bar, O=Foo, L=Some, ST=Where, C=UN
05/02/23 16:43:45 Algorithm: RSA; Serial number: 0x421c3768
05/02/23 16:43:45 Valid from Wed Feb 23 15:57:28 SGT 2005 until Tue May 24 15:57:28 SGT 2005
05/02/23 16:43:45 trigger seeding of SecureRandom
05/02/23 16:43:45 done seeding SecureRandom
05/02/23 16:43:45 com.sun.corba.ee.internal.iiop.GIOPImpl(Thread[Orion Launcher,5,main]): getEndpoint(SSL_MUTUALAUTH, 5557, null)
05/02/23 16:43:45 com.sun.corba.ee.internal.iiop.GIOPImpl(Thread[Orion Launcher,5,main]): createListener( socketType = SSL_MUTUALAUTH port = 5557 )
05/02/23 16:43:45 matching alias: mykey
matching alias: mykey
05/02/23 16:43:46 ORB created ..com.oracle.iiop.server.OC4JORB@65b738
05/02/23 16:43:47 com.sun.corba.ee.internal.corba.ClientDelegate(Thread[Orion Launcher,5,main]): invoke(ClientRequest) called
05/02/23 16:43:47 com.oracle.iiop.server.OC4JORB(Thread[Orion Launcher,5,main]): process: dispatching to scid 2
05/02/23 16:43:47 com.oracle.iiop.server.OC4JORB(Thread[Orion Launcher,5,main]): dispatching to sc [email protected]7
05/02/23 16:43:48 com.sun.corba.ee.internal.corba.ClientDelegate(Thread[Orion Launcher,5,main]): invoke(ClientRequest) called
05/02/23 16:43:48 com.oracle.iiop.server.OC4JORB(Thread[Orion Launcher,5,main]): process: dispatching to scid 2
05/02/23 16:43:48 com.oracle.iiop.server.OC4JORB(Thread[Orion Launcher,5,main]): dispatching to sc com.sun.corba.ee.internal.corba.ServerDelegate@9300cc
05/02/23 16:43:48 com.sun.corba.ee.internal.corba.ServerDelegate(Thread[Orion Launcher,5,main]): Entering dispatch method
05/02/23 16:43:48 com.sun.corba.ee.internal.corba.ServerDelegate(Thread[Orion Launcher,5,main]): Consuming service contexts, GIOP version: 1.2
05/02/23 16:43:48 com.sun.corba.ee.internal.corba.ServerDelegate(Thread[Orion Launcher,5,main]): Has code set context? false
05/02/23 16:43:48 com.sun.corba.ee.internal.corba.ServerDelegate(Thread[Orion Launcher,5,main]): Dispatching to servant
05/02/23 16:43:48 com.sun.corba.ee.internal.corba.ServerDelegate(Thread[Orion Launcher,5,main]): Handling invoke handler type servant
05/02/23 16:43:48 NS service created and started ..org.omg.CosNaming._NamingContextExtStub:IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000000000001000000000000007c000102000000000c31302e312e3231342e31310015b3000000000031afabcb0000000020d309e06a0000000100000000000000010000000c4e616d65536572766963650000000004000000000a0000000000000100000001000000200000000000010001000000020501000100010020000101090000000100010100
05/02/23 16:43:48 NS ior = ..IOR:000000000000002b49444c3a6f6d672e6f72672f436f734e616d696e672f4e616d696e67436f6e746578744578743a312e30000000000001000000000000007c000102000000000c31302e312e3231342e31310015b3000000000031afabcb0000000020d309e06a0000000100000000000000010000000c4e616d65536572766963650000000004000000000a0000000000000100000001000000200000000000010001000000020501000100010020000101090000000100010100
05/02/23 16:43:48 Oracle Application Server Containers for J2EE 10g (9.0.4.0.0) initialized
05/02/23 16:45:14 com.sun.corba.ee.internal.iiop.ConnectionTable(Thread[JavaIDL Listener,5,main]): Server getConnection(119e583[Unknown 0x0:0x0: Socket[addr=/127.0.0.1,port=1281,localport=5556]], SSL)
05/02/23 16:45:14 com.sun.corba.ee.internal.iiop.ConnectionTable(Thread[JavaIDL Listener,5,main]): host = 127.0.0.1 port = 1281
05/02/23 16:45:14 com.sun.corba.ee.internal.iiop.ConnectionTable(Thread[JavaIDL Listener,5,main]): Created connection Connection[type=SSL remote_host=127.0.0.1 remote_port=1281 state=ESTABLISHED]
com.sun.corba.ee.internal.iiop.MessageMediator(Thread[JavaIDL Reader for 127.0.0.1:1281,5,main]): Creating message from stream
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, handling exception: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, SEND TLSv1 ALERT: fatal, description = unexpected_message
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, WRITE: TLSv1 Alert, length = 2
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, called closeSocket()
05/02/23 16:45:14 com.sun.corba.ee.internal.iiop.ReaderThread(Thread[JavaIDL Reader for 127.0.0.1:1281,5,main]): IOException in createInputStream: javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
05/02/23 16:45:14 javax.net.ssl.SSLException: Connection has been shutdown: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
05/02/23 16:45:14 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.d(DashoA12275)
05/02/23 16:45:14 at com.sun.net.ssl.internal.ssl.AppInputStream.read(DashoA12275)
05/02/23 16:45:14 at com.sun.corba.ee.internal.iiop.messages.MessageBase.readFully(MessageBase.java:520)
05/02/23 16:45:14 at com.sun.corba.ee.internal.iiop.messages.MessageBase.createFromStream(MessageBase.java:58)
05/02/23 16:45:14 at com.sun.corba.ee.internal.iiop.MessageMediator.processRequest(MessageMediator.java:110)
05/02/23 16:45:14 at com.sun.corba.ee.internal.iiop.IIOPConnection.processInput(IIOPConnection.java:339)
05/02/23 16:45:14 at com.sun.corba.ee.internal.iiop.ReaderThread.run(ReaderThread.java:63)
05/02/23 16:45:14 Caused by: javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
05/02/23 16:45:14 at com.sun.net.ssl.internal.ssl.InputRecord.b(DashoA12275)
05/02/23 16:45:14 at com.sun.net.ssl.internal.ssl.InputRecord.read(DashoA12275)
05/02/23 16:45:14 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
05/02/23 16:45:14 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.j(DashoA12275)
05/02/23 16:45:14 at com.sun.net.ssl.internal.ssl.SSLSocketImpl.a(DashoA12275)
05/02/23 16:45:14 ... 6 more
05/02/23 16:45:14 com.sun.corba.ee.internal.iiop.IIOPConnection(Thread[JavaIDL Reader for 127.0.0.1:1281,5,main]): purge_calls: starting: code = 1398079696 die = true
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, called close()
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, called closeInternal(true)
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, called close()
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, called closeInternal(true)
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, called close()
05/02/23 16:45:14 JavaIDL Reader for 127.0.0.1:1281, called closeInternal(true)
05/02/23 16:45:14 com.sun.corba.ee.internal.iiop.ConnectionTable(Thread[JavaIDL Reader for 127.0.0.1:1281,5,main]): DeleteConn called: host = 127.0.0.1 port = 1281

Good point, I do belive what you are referring to is this:
Any client, whether running inside a server or not, has EJB security properties. Table 15-2 lists the EJB client security properties controlled by the ejb_sec.properties file. By default, OC4J searches for this file in the current directory when running as a client, or in ORACLE_HOME/j2ee/home/config when running in the server. You can specify the location of this file explicitly with the system property setting -Dejb_sec_properties_location=pathname.
Table 15-2 EJB Client Security Properties
Property Meaning
# oc4j.iiop.keyStoreLoc
The path and name of the keystore. An absolute path is recommended.
# oc4j.iiop.keyStorePass
The password for the keystore.
# oc4j.iiop.trustStoreLoc
The path name and name of the truststore. An absolute path is recommended.
# oc4j.iiop.trustStorePass
The password for the truststore.
# oc4j.iiop.enable.clientauth
Whether the client supports client-side authentication. If this property is set to true, you must specify a keystore location and password.
# oc4j.iiop.ciphersuites
Which cipher suites are to be enabled. The valid cipher suites are:
TLS_RSA_WITH_RC4_128_MD5
SSL_RSA_WITH_RC4_128_MD5
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_EXPORT_WITH_RC4_40_MD5
SSL_RSA_EXPORT_WITH_RC4_40_MD5
TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
nameservice.useSSL
Whether to use SSL when making the initial connection to the server.
client.sendpassword
Whether to send user name and password in clear form (unencrypted) in the service context when not using SSL. If this property is set to true, the user name and password are sent only to servers listed in the trustedServer list.
oc4j.iiop.trustedServers
A list of servers that can be trusted to receive passwords sent in clear form. This has no effect if client.sendpassword is set to false. The list is comma-delimited. Each entry in the list can be an IP address, a host name, a host name pattern (for example, *.example.com), or * (where "*" alone means that all servers are trusted.

Screwey rmi-iiop behavior

I got the rmi-iiop example code to work just fine, but I tried extending
it a little and strangeness ensues. Here's what I did:
I'm using a stock weblogic 6.0 install on solaris 8 (sparc). I added
the following new method to the Trader interface:
public void func(javax.naming.Name n) throws RemoteException;
and I added the implementation of that method to TraderBean like so:
public void func(javax.naming.Name n) {
System.out.prinltn("n [" + n + "]");
I then added a call to the new Trader function to the end of the
example() method in Client, just before the trader is removed:
try {
com.sun.jndi.ldap.LdapName lname =
new com.sun.jndi.ldap.LdapName("a=b");
trader.func(lname);
} catch (javax.naming.NamingException ne) {
ne.printStackTrace();
Then I compiled everything using the supplied build.sh, copied the
ejb_over_iiop.jar into config/mydomain/applications, and ran
startWebLogic.sh int the config/mydomain directory to start the server.
I then run the client like so (using the 1.3 java version included with
weblogic 6.0):
java -cp
/opt/bea/wlserver6.0/config/examples/clientclasses:/opt/bea/wlserver6.0/config/mydomain/applications:/opt/bea/wlserver6.0/lib/weblogic.jar
examples.rmi_iiop.ejb.rmi_iiop.Client iiop://localhost:7001
And I get the following output:
Beginning statelessSession.Client...
Creating a trader
Buying 100 shares of BEAS.
Buying 200 shares of MSFT.
Buying 300 shares of AMZN.
Buying 400 shares of HWP.
Selling 100 shares of BEAS.
Selling 200 shares of MSFT.
Selling 300 shares of AMZN.
Selling 400 shares of HWP.
There was an exception while creating and using the Trader.
This indicates that there was a problem communicating with the server:
java.rmi.RemoteException: CORBA UNKNOWN 0 No; nested exception is:
org.omg.CORBA.UNKNOWN: minor code: 0 completed: No
End statelessSession.Client...
Basically the call to the new method fails, and the server communication
error it produces doesn't provide much information. So question #1 is,
what's going on here?
And here's the really weird part: if I change the method signatures in
Trader and TraderBean so that the argument type is the concrete class
com.sun.jndi.ldap.LdapName instead of the interface javax.naming.Name
(which does extend java.io.Serializable, incidentally), it works fine!
I tried this with my own interfaces and concrete classes, and I get the
same strange behavior: calling methods with interface argument types on
the ejb via rmi-iiop fails with the above cryptic error, but methods
with concrete argument types work fine.
I also tried this out on a non-ejb rmi-iiop server object using jdk 1.3
but not weblogic. In that case both interfaces and concrete method
argument types work just fine.
Now I'm wondering if this could be a bug in weblogic.ejbc's iiop
generation. Can anyone else verify this problem?
Edwin Park
[email protected]

Comments in line...
Edwin Park wrote:
I got the rmi-iiop example code to work just fine, but I tried extending
it a little and strangeness ensues. Here's what I did:
I'm using a stock weblogic 6.0 install on solaris 8 (sparc). I added
the following new method to the Trader interface:
public void func(javax.naming.Name n) throws RemoteException;
and I added the implementation of that method to TraderBean like so:
public void func(javax.naming.Name n) {
System.out.prinltn("n [" + n + "]");
I then added a call to the new Trader function to the end of the
example() method in Client, just before the trader is removed:
try {
com.sun.jndi.ldap.LdapName lname =
new com.sun.jndi.ldap.LdapName("a=b");
trader.func(lname);
} catch (javax.naming.NamingException ne) {
ne.printStackTrace();
Then I compiled everything using the supplied build.sh, copied the
ejb_over_iiop.jar into config/mydomain/applications, and ran
startWebLogic.sh int the config/mydomain directory to start the server.
I then run the client like so (using the 1.3 java version included with
weblogic 6.0):
java -cp
/opt/bea/wlserver6.0/config/examples/clientclasses:/opt/bea/wlserver6.0/config/mydomain/applications:/opt/bea/wlserver6.0/lib/weblogic.jar
examples.rmi_iiop.ejb.rmi_iiop.Client iiop://localhost:7001
And I get the following output:
Beginning statelessSession.Client...
Creating a trader
Buying 100 shares of BEAS.
Buying 200 shares of MSFT.
Buying 300 shares of AMZN.
Buying 400 shares of HWP.
Selling 100 shares of BEAS.
Selling 200 shares of MSFT.
Selling 300 shares of AMZN.
Selling 400 shares of HWP.
There was an exception while creating and using the Trader.
This indicates that there was a problem communicating with the server:
java.rmi.RemoteException: CORBA UNKNOWN 0 No; nested exception is:
org.omg.CORBA.UNKNOWN: minor code: 0 completed: No
End statelessSession.Client...
Basically the call to the new method fails, and the server communication
error it produces doesn't provide much information. So question #1 is,
what's going on here?
Marshaling through the interface apparently fails. What orb are you using on the client?
>
And here's the really weird part: if I change the method signatures in
Trader and TraderBean so that the argument type is the concrete class
com.sun.jndi.ldap.LdapName instead of the interface javax.naming.Name
(which does extend java.io.Serializable, incidentally), it works fine!It appears that marshaling an interface (or abstract class) fails, but marshaling a concrete class succeeds.
>
>
I tried this with my own interfaces and concrete classes, and I get the
same strange behavior: calling methods with interface argument types on
the ejb via rmi-iiop fails with the above cryptic error, but methods
with concrete argument types work fine.
I also tried this out on a non-ejb rmi-iiop server object using jdk 1.3
but not weblogic. In that case both interfaces and concrete method
argument types work just fine.
Now I'm wondering if this could be a bug in weblogic.ejbc's iiop
generation. Can anyone else verify this problem?I'll look into this.
>
>
Edwin Park
[email protected]

RMI-IIOP specification

Similar Messages

Maybe you are looking for