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

Similar Messages

Difference between RMI-IIOP and CORBA-IIOP

Hello,
What is the difference between RMI-IIOP and CORBA-IIOP?
Thanks
Larry

Lawrence Manickam <[email protected]> writes:
What is the difference between RMI-IIOP and CORBA-IIOP? RMI-IIOP is the protocol represented by the mapping of Java RMI
artifacts to IDL, i.e. you start with Java and use the RMI programming
model. CORBA / IIOP is really just the protocol used for IDL sourced
objects, i.e. you start with IDL and use the CORBA programming model.
andy

RMI-IIOP and glassfish naming service

I have some very basic test applications to test RMI-IIOP. The applications are one server (registers the Remote object) and one client (tries to retreive the remote object stub and invoke a simple hello() method).
I've been trying to get it to work by registering the Remote object (see below) in glassfish naming service (JNDI) but I get the following an error saying: "Class rmi.ListenerRemoteImpl not exported, or else is actually a JRMP stub". I haven't been able to figure out why...
Then I found another guide which I followed and managed to get to work. The only difference there was that I used orbd as naming service.
Why is this? Doesn't Glassfish JNDI support RMI-IIOP in this way?
Any help is greatly appreciated!
I followed the following steps in creating the application:
-Created the following classes:
Client.java //The client
Server.java //The server
ListenerRemote.java //Remote interface implementing Remote
ListenerRemoteImpl.java //Implemtation extends PortableRemoteObject and implements ListenerRemote
-Generated stubs with rmic using -iiop
-Compile and run...

Here is some of the code...
Client that fails with glassfish but not with orbd:
=========================================
public static void main(String[] args) throws Exception {
ListenerRemoteImpl listener = new ListenerRemoteImpl();
Properties props = new Properties();
props.load(new FileInputStream("jndi.properties"));
//Uncommenting this and starting orbd makes it work. When default jndi.properties from Glassfish is used, it does not work.
//props.put("java.naming.factory.initial", "com.sun.jndi.cosnaming.CNCtxFactory");
//props.put("java.naming.provider.url", "iiop://localhost:1060");
Context ctx = new InitialContext(props);
ctx.rebind("listener", listener);
System.out.println("Listener bound!");
==================================
ListenerRemoteImpl:
==================================
public class ListenerRemoteImpl extends PortableRemoteObject implements ListenerRemote {
public ListenerRemoteImpl() throws RemoteException {
super();
public void sayHello() throws RemoteException {
System.out.println("Hello!");
==================================
The stacktrace when glassfish naming service is used:
==================================
2007-aug-10 17:24:32 com.sun.corba.ee.impl.util.Utility autoConnect
VARNING: "IOP00511403: (INV_OBJREF) Class rmi.ListenerRemoteImpl not exported, or else is actually a JRMP stub"
org.omg.CORBA.INV_OBJREF: vmcid: SUN minor code: 1403 completed: No
at com.sun.corba.ee.impl.logging.UtilSystemException.objectNotExported(UtilSystemException.java:569)
at com.sun.corba.ee.impl.logging.UtilSystemException.objectNotExported(UtilSystemException.java:592)
at com.sun.corba.ee.impl.util.Utility.autoConnect(Utility.java:147)
at com.sun.corba.ee.impl.javax.rmi.CORBA.Util.writeAny(Util.java:323)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl$10.write(DynamicMethodMarshallerImpl.java:256)
at com.sun.corba.ee.impl.presentation.rmi.DynamicMethodMarshallerImpl.writeArguments(DynamicMethodMarshallerImpl.java:407)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.privateInvoke(StubInvocationHandlerImpl.java:157)
at com.sun.corba.ee.impl.presentation.rmi.StubInvocationHandlerImpl.invoke(StubInvocationHandlerImpl.java:119)
at com.sun.corba.ee.impl.presentation.rmi.bcel.BCELStubBase.invoke(BCELStubBase.java:197)
at com.sun.enterprise.naming._SerialContextProvider_DynamicStub.rebind(_SerialContextProvider_DynamicStub.java)
at com.sun.enterprise.naming.SerialContext.rebind(SerialContext.java:403)
at javax.naming.InitialContext.rebind(InitialContext.java:408)
at rmi.Client.main(Client.java:48)
Exception in thread "main" javax.naming.CommunicationException: java.rmi.NoSuchObjectException: CORBA INV_OBJREF 1398080891 No; nested exception is:
org.omg.CORBA.INV_OBJREF: vmcid: SUN minor code: 1403 completed: No
at com.sun.enterprise.naming.SerialContext.rebind(SerialContext.java:405)
at javax.naming.InitialContext.rebind(InitialContext.java:408)
at rmi.Client.main(Client.java:48)
==================================

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

what support is provided for RMI and IIOP through Firewalls?

"Scot Hale" <[email protected]> wrote:
>
Andy Piper <[email protected]> wrote:
"Uma Patil" <[email protected]> writes:
what support is provided for RMI and IIOP through Firewalls?None, right now. We tried to get support into 7.0 for this but
failed. It will probably be fixed in 7.1. We currently get very few
requests for this.Is it supported in 8.1? I am in a position where I need it.Yes, it looks like it is fixed, now I just have to test it and see if it works.
http://e-docs.bea.com/wls/docs81/notes/resolved.html#1011163
>
>
>>
andy

Difference between Java IDL and RMI-IIOP

Hi,
I am new to CORBA / RMI and I am trying to clear my concepts a little bit. Suppose, we want to create a remote object that should be accesible from CORBA clients. Does anyone know what the difference is between creating this object as an RMI object (with RMI-IIOP) and using the java IDL?
In other words, if I am not wrong, it is possible to write the object in java (pretty much like writting an RMI remore object), generate the IDL with rmic and then any CORBA client can access it provided it has the IDL.
Are there any advantages in doing it the other way (explicitely instantiating an ORB in the code, etc) ?
By the way, if we use the first choice (RMI-IIOP), when is the ORB getting called? Is it called by the Tie class, which is generated by rmic -iiop?
Thanks!

Visit this link
http://java.sun.com/j2se/1.3/docs/guide/idl/jidlFAQ.html#java%20idl%20vs%20rmi-iiop

When we use RMI-IIOP?

Dear,
Can anyone tell me when we use RMI-IIOP? When we use RMI-IIOP and
EJB? When will use JSP? When will use servlet?
Sorry for that silly question, but i really want to know it?
kurt

As I know, If using RMI-IIOP, we have to handle lots of stuffs like
connection pool, security...etc.
Am I right?
Kurt
Tom Barnes <[email protected]> wrote in message
news:[email protected]..
>
>
Andy Piper wrote:
RMI-IIOP is useful for:
a) Interop, i.e. between different appservers
b) C++ client integration
Customers also sometimes want it because they have security
restrictions on what protocols they can put through a firewall.
It is also useful for light-weight Java clients. RMI-IIOP clients need
not use the (large) weblogic.jar jar.
Tom

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

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, C++ and mobile code

Hi,
I'd like to know whether it is possible to use RMI-IIOP [1] to connect a Java component to a C++ component on a remote end and use "mobile code" [2]. In other words, a C++ client connects to a remote Java component, downloads a class file and executes it locally. On the flip side, a C++ component uploads a class file to a Java end for remote execution.
I see much discussion about the value of RMI-IIOP for connecting Java and C++ components but I see little value for this if you lose the "mobile code" capability. What are the advantages of using RMI vs RMI-IIOP vs "web services"? Am I missing something?
Thank you,
Gili
[1] http://java.sun.com/products/rmi-iiop/
[2] http://en.wikipedia.org/wiki/Mobile_code

I'd like to know whether it is possible to use RMI-IIOP [1] to connect a Java component to a C++ component on a remote endYes, provided you start with a Java interface and generate IDL from that.
and use "mobile code" [2]. In other words, a C++ client connects to a remote Java component, downloads a class file and executes it locally. On the flip side, a C++ component uploads a class file to a Java end for remote execution.C++ can execute or create Java objects via JNI but that implies a JVM anyway at the C++ end, so why not just use Java? IOW it's a lot of trouble for nothing.
I see much discussion about the value of RMI-IIOP for connecting Java and C++ components but I see little value for this if you lose the "mobile code" capability.All the rest of RMI and Corba is 'little'?

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 WLS 5.1 and VPN

Hi,
IS RMI/IIOP supported between 2 Weblogic 5.1 server running on machine
connected by VPN ?
Can the EBJ container communicate freely under this configuration ?
thanks
Sandeep

"Sandeep" <[email protected]> writes:
IS RMI/IIOP supported between 2 Weblogic 5.1 server running on machine
connected by VPN ?
Can the EBJ container communicate freely under this configuration ?Should be, although you can only start the server once the VPN is up
since it will change the IP address of the host.
andy

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

Similar Messages

Maybe you are looking for