BEA Home | Events | Solutions | Partners | Products | Services | Download | Developer Center | WebSUPPORT
| WebLogic Server Doc Home | WebLogic jCOM Reference Guide | Previous Topic | Next Topic | Contents | View as PDF

Native Mode

The Java-COM bridge not only supports the use of network based DCOM to allow Java objects to interact with COM objects, WebLogic jCOM also gives you an alternative: native code (DLLs) can be used to perform the bridging.

Your Java code stays the same whether it is using native mode or DCOM mode.

Note: By default WebLogic jCOM uses DCOM; you have to explicitly enable native mode.

The following sections look at:

- What Is Supported?

- How to run Java clients in native mode

- How to run COM clients in native mode (JVM out-of-process)

- How to run COM clients in native mode (JVM in-process)

- Unsupported features and known issues

What is supported?

Both IDispatch and vtable

The native mode allows both IDispatch and Custom (vtable) method invocations, in both directions. The COM interfaces do not have to be dual (they can derive directly from IUnknown).

In-process and out-of-process

WebLogic jCOM's native mode supports:

- Java clients talking to out-of-process (including remote) COM components

- Java clients talking to in-process COM components, where the COM component's DLL is loaded in-process into the JVM's process

- COM clients talking to Java objects where the JVM is running in a separate process (on the same machine)

- COM clients talking to Java objects where the JVM is loaded in-process, into the address space of the COM client

All JVMs

WebLogic jCOM can be used with any JVM running on any platform.

Microsoft Transaction Server / COM+

We have successfully loaded a Java object into MTS (in-process) and invoked methods on it from a VB base client.

We have made the Java object implement the standard IObjectControl COM interface (which it saw as a normal Java interface, generated by 'com2java'), and MTS invoked the usual methods (activate, canBePooled, etc.).

Finally using a special hook in the WebLogic jCOM runtime we have accessed the IObjectContext MTS/COM+ interface from the Java object and tested some of the attributes -- it correctly detected when it was operating in a transaction, for example.

How to run Java clients in native mode

In order to let a Java client access a COM object using native mode, run the 'com2java' tool on the COM object's type library, and generate the Java proxies as you would when using WebLogic jCOM in DCOM mode.

When running the JVM, define the JCOM_NATIVE_MODE property to enable native mode:
java -DJCOM_NATIVE_MODE JCOMBridge

Pass a host name to the COM object's constructor to create a remote COM component.

The WebLogic jCOM runtime first attempts a CoCreateInstanceEx with flags set to CLSCTX_ALL. If this fails, it retries with flags set to CLSCTX_SERVER.

Threading Models

By default the WebLogic jCOM runtime initializes COM using the COINIT_MULTITHREADED flag. If you wish to have COM initialized using a different flag, set the JCOM_COINIT_VALUE property. For example:

>     java -DJCOM_NATIVE_MODE -DJCOM_COINIT_VALUE=2 JCOMBridge

If you get a Class Not Registered Message when using native mode and trying to talk to a COM component hosted in a DLL, try setting the JCOM_COINIT_VALUE to 2 as above.

The WebLogic jCOM runtime attempts to put all COM object references into a special COM table called the Global Interface Table (GIT). Whenever a call is made from Java-to-COM the object reference is retrieved from the GIT, which ensures that the call can be made from the current thread.

Unfortunately some COM object references (such as the Frames collection in MSHTML) cannot be placed in the GIT, and so WebLogic jCOM stores a direct pointer reference. In this situation you may have to ensure that only the creating thread makes calls onto that object. This situation is very rare, and a message is logged to the WebLogic jCOM log (if logging is enabled) to let you know that it has happened.

How to run COM clients in native mode (JVM out-of-process)

Prior to reading this section, please read through (and ideally run) the standard DCOM Java examples (VB to Java early and late binding).

If you want your JVM to run out of process (but allow COM client access to the Java objects contained therein using native code), you must use the 'regjvm' command to register it as being native. The regjvm command sets up various registry entries to facilitate WebLogic jCOM's COM-to-Java mechanism:

In your main you then tell the WebLogic jCOM runtime that the JVM is ready to receive calls by calling com.bea.jcom.Jvm.register("MyJvm").

You would then start your JVM:
java -DJCOM_NATIVE_MODE YourMain

From VB you can now use late binding to instantiate instances of any Java class that can be loaded in that JVM:
Set aHashtable = GetObject("MyJvm:java.util.Hashtable")

"MyJvm" is just a string to identify the JVM -- you can use anything.

This would only work if the JVM were already running. Additional parameters to the regjvm command can specify a command to be used to launch the JVM if it is not already running.

Having registered the JVM, use the standard WebLogic jCOM 'regtlb' command to allow early bound access to Java objects (regtlb takes as parameters the name of a type library, and a JVM name, and registers all the COM objects defined in that type library as being located in that JVM).

You can also control the instantiation of Java objects on behalf of COM clients by associating your own Instanciator with a JVM (additional parameter to com.bea.jcom.Jvm.register(...)) -- a kind of object factory. This is used in most of the standard COM->EJB examples in the WebLogic jCOM documentation.

How to run COM clients in native mode (JVM in-process)

Use this technique to actually load the JVM into the COM client's address space.

Again, use the 'regjvm' command, but this time specify additional parameters.

The simplest example would be to use Visual Basic to perform late bound access to Java objects. First register the JVM. If you are using Sun's JDK 1.3.1, which is installed under d:\bea\jdk131, and WebLogic jCOM is installed in d:\bea\wlserver6.1\jcom, and your Java classes are in c:\pure, you would use

As you can see, you specify the JVM name, the CLASSPATH, and the JVM bin directory path.

From VB you should now be able to do:
MessageBox GetObject("MyJvm:java.util.Hashtable")

If you wish to specify properties to be set for the JVM, add them at the end of the regjvm command line, in the form name=value, separated by spaces (don't use -Dname=value). For example if you run into problems, enable logging by adding JCOM_LOG_LEVEL=3 and JCOM_LOG_FILE=c:\temp\jcom.log to the end of the 'regjvm' command. The mechanism described above (calling com.bea.jcom.Log.logImmediately(...)) only works when your Java class has had a chance to run -- there may be a problem before then.

If you get the E_NOMONIKER error, please enable logging in the WebLogic jCOM moniker (jintmk.dll) and examine the classpath that is being used to ensure it has any JVM classes that are required, as well as the WebLogic jCOM runtime (jcom.jar) and any classes you may need.

Unsupported features and known issues

The following features are not yet supported in native mode, or are bugs. Tell us if you would like them added/resolved as a matter of priority.

1. Structures as parameters

Copyright © 2001 BEA Systems, Inc. All rights reserved. Required browser: Netscape 4.0 or higher, or Microsoft Internet Explorer 4.0 or higher.