BEA Logo BEA WebLogic Server Release 6.1

  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

Troubleshooter

 

The following sections outline some common problems with WebLogic jCOM and useful tips to workaround them:

 


Improving WebLogic jCOM's performance

Use the reduced logging runtime

The easiest way to improve performance is to use the reduced logging WebLogic jCOM runtime: instead of putting jcom.jar in your CLASSPATH, use jcom_reduced_logging.jar, which is in the same directory.

Using this runtime inhibits the ability to generate WebLogic jCOM log files to help resolve issues, but it can in some circumstances result in an extremely substantial performance gain.

Run in native mode

If you are running in WebLogic jCOM's DCOM mode (the default) and your JVM is running under MS Windows, you might want to think about switching to Native Mode, which makes the WebLogic jCOM runtime use native code instead of DCOM to interact between Java and COM. You will not have to change your code at all - this switch to native mode is made simply by defining a runtime property.

See the section on Native Mode in the WebLogic jCOM reference guide, for more information.

 


DOS Errors

If the error is

Then your PATH environment variable does not include the JDK bin directory.

If the error is

Tell the compiler to use more memory. Compile using:
java -Jmx64m -J-ms64m YourProgram.java

If the error is

when trying to use regtlb or regjvm

Then your PATH environment variable does not include the WebLogic jCOM's bin directory.

 


Java Errors

If the error is

Then your CLASSPATH environment variable does not include the WebLogic jCOM runtime (jcom.jar).

If the error is

If running under Windows NT then check the NT event log (Start|Programs|Adminstrative Tools|Event Viewer->Log|System), which will often give you the reason for the launch failure.

A typical cause of this error is that the PATH in the registry for the server is incorrect.

There are also a couple of NT bugs which can also cause this error: http://support.microsoft.com/support/kb/articles/q185/1/26.asp and http://support.microsoft.com/support/kb/articles/q158/5/08.asp

If the error is

You may well get this when running Excel. We are assuming that this is an Excel restriction. From one of the Microsoft support answers: This error usually occurs when the server application is too busy to respond to the client.

The 'com2java' tool has an option in the Options dialog box which causes the WebLogic jCOM code to retry if this error occurs -- check that option and regenerate the proxies.

If the error is

If you are using 'ocxhost' and attempting to load an ActiveX Control, then it is likely that the prog ID you are specifying is incorrect, or the control has not been properly registered on your machine.

You can find the correct progid by using the 'checkconfig' command:

checkconfig /typelib  config.log

If you look at the generated config.log file you will see the progid to use.

If the error is

Doublecheck that your CLASSPATH is defined correctly. If you are using a Servlet environment or other environment which loads classes in different class loaders, you should ensure that your generated proxies and the jcom.jar file are loaded by the same class loader.

If the error is

Check that your jcom.jar file is being loaded by the system class loader. This means that you are trying to use native authentication but the JNI is not working correctly because only classes loaded by the system class loader can use JNI. To ensure that the you use the system class loader, place the jcom.jar in your CLASSPATH environment variable at system level. See also the previous troubleshooting entry.

If the error is

If there is no error message related to the error code, in the case an AutomationException, you can look up the error code in the Microsoft Developer Network documentation or if you have Visual C++ installed the file winerr.h or the utility error lookup may help.

 


Visual BASIC Errors

If the error is

You will get this error if you are attempting to instanciate a Java object using:

Set o = GetObject("SomeJvmId:SomeJavaClass")

where SomeJvmId has not been registered on this machine using the regjvm command.

If the error is

You will get this error if the JVM is not running, or not registered correctly, or if the Java class could not be instanciated. Start your JVM with logging enabled using:

java -DJCOM_DCOM_PORT=??? -DJCOM_LOG_LEVEL=3 YourMainClassName

When you run your VB client, look and see if the WebLogic jCOM runtime receives a connection from the VB client. If no connection is received, then either:

The jvmId used when you are calling com.bea.jcom.Jvm.register("jvmId") is wrong

The port you specified when starting the JVM is wrong, or is already in use. You can see which port the WebLogic jCOM runtime uses when you have logging enabled:

929376053810 : OXID Resolver started. Listening on port 1111

You made a mistake when registering the JVM, either you specified the wrong JvmID, wrong host, or wrong port when invoking regjvm jvmId host[port] on the VB client machine.

The VB environment is very old, and does not support the "MyJvm:MyClass" parameter format to GetObject. A workaround is to use WebLogic jCOM's 'regprogid' command to map a progid to the JVM/class:

regprogid My.ProgId "MyJvm:MyClass"

Then in your code use GetObject("My.ProgId")

If the error is

You will get this error when using early-bound access to a COM object, and you attempt to invoke a method on that object. You have either not compiled the Java wrapper files generated by the 'java2com' tool, or they can not be loaded by the WebLogic jCOM runtime (jcom.jar) because they are not in your CLASSPATH.

If you are using JDK1.2, you should not put the WebLogic jCOM runtime in the "ext" directory, since if it is in that directory it will unable to load classes in your CLASSPATH (such as the wrapper classes). Instead put the runtime in your CLASSPATH.

You can see this if you start the JVM with WebLogic jCOM logging set to '3' (full).:
java -DJCOM_LOG_LEVEL=3 Main

 


Visual C++ Errors

If the error is

Follow the same steps as for the VB Error 429.

If the error is

Follow the same steps as for the VB Error 8000004.

 


DCOM security problems when running under certain environments

Java applications running under certain environments (servlets/IDEs) may result in DCOM security errors despite the fact that they run successfully from the command line.

The behaviour you are seeing may be caused by one of the following:

  1. The Java code is running as a different user. Native authentication picks up the user running the Java code and this user may not have sufficient DCOM access.

  2. The jcom\bin directory is not in your PATH at system level or the Servlet/IDE environment has not been restarted to pick up any changes in the PATH.

  3. The WebLogic jCOM runtime is not being loaded by the system class loader. Native authentication uses JNI and JNI calls must be made from classes loaded by the system class loader. Some environments allow you to specify a classpath which is loaded by a different class loader. Java files in such a classpath will not be able to use JNI. A safe way to ensure that the system class loader is used is to specify the inclusion of jcom.jar in the classpath environment variable or using the -cp/-classpath/-Djava.class.path options when running java.exe. An additional thing to take into account is that WebLogic jCOM proxies files, and the jcom.jar runtime should be loaded by the same class loader.

If you enable WebLogic jCOM logging as specified in the trouble shooter, issues 2 and 3 will show that the native authentication DLL failed to load or run correctly. WebLogic jCOM logging also shows you which class loader the jcom.jar is run under - bootstrap is the system class loader.

Another solution to the problem may be to use com.bea.jcom.AuthInfo.setDefault(...) which uses pure java authentication (no JNI) and hence will also run on non-Windows platforms.

Also read entries in the trouble shooter and in the Security section of the documentation for further information on security issues.

 


The IID*.java Wrappers Generated by java2com do not compile

You may get errors like this:

tlb\remote\IID6cce3097_00e5_1000_500a_bf09cf1e0000Wrapper.java:2: IID6cce3097_00e5_1000_500a_bf09cf1e0000Wrapper should

be declared abstract; it does not define getHomeInterfaceClass() in IID6cce3097_00e5_1000_500a_bf09cf1e0000Wrapper

public class IID6cce3097_00e5_1000_500a_bf09cf1e0000Wrapper extends com.bea.jcom.Dispatch implements javax.ejb.EJB

MetaData {

or

D:\pure\JCOM\TLB\Bean>javac IID828d8ad4_00e5_1000_502a_bf09cf1e0000Wrapper.java

IID828d8ad4_00e5_1000_502a_bf09cf1e0000Wrapper.java:2: IID828d8ad4_00e5_1000_502a_bf09cf1e0000Wrapper should be declared

abstract; it does not define toString(boolean) in IID828d8ad4_00e5_1000_502a_bf09cf1e0000Wrapper

public class IID828d8ad4_00e5_1000_502a_bf09cf1e0000Wrapper extends com.bea.jcom.Dispatch implements java.security

.Certificate {

By default the java2com tool ignores certain classes and methods, in order to attempt to reduce the number of generated wrappers. It may be that it is ignoring classes such as java.lang.Class (in the first case above), or methods such as toString() (in the second case). You will need to look at the error you are getting in order to determine which class or method is being ignored when it is actually required.

Unregister the type library (if you have already registered it), delete the generated wrappers, re-run java2com, and click on the "Names..." button, and remove the mapping of the required class or method to "".

 


The error I am getting is not listed

Email support@bea.com and include the following information:

Certain configuration problems may be recognized by running the checkconfig tool in the jcom\bin directory. Run "checkconfig /?" for further details on usage.

Depending on the nature of the error you are getting, it may be useful to include the extensive logging information which WebLogic jCOM can generate.

To cause the WebLogic jCOM Java runtime to generate logging information to the file jcom.log add the call com.bea.jcom.Log.logImmediately. You must call this only once in your Java code -- the easiest way of including this is to put the call in a static block in the first Java class you use (when calling from Java to COM or from Java to COM):

public class YourClass {
  static {
    com.bea.jcom.Log.logImmediately(3, "c:\\jcom.log");
  }
  ...
}
If using an Applet then you can cause logging to go to the Java 
console like this:

static {
  com.bea.jcom.Log.logImmediately(3, System.err);
}

3 is the log level -- it means verbose. You can specify any file name as the second parameter.

To enable logging inside the WebLogic jCOM Moniker (jintmk.dll -- the 'glue'), use the registry editor to create a value under the following key HKEY_LOCAL_MACHINE\SOFTWARE\Linar\JintMkr. The value should be called logFile and should be set to a file name, such as c:\temp\jcommk.log.

Please send us both of the above logs if you run into problems.

 

back to top previous page