Calling EJB from windows ,EJB was deployed in Websphere on AIX machine

[nagc...@gmail.com]

I am trying to call an EJB which is deployed in websphere on AIX machine.The EJB is creating an object for "Afflcode" which will load the ".so" files.I am able to access all other services on EJB except the one which try to load the ".so" files.I am getting the following error.

Exception in thread "P=677466:O=0:CT" java.rmi.ServerException: RemoteException occurred in server

thread; nested exception is:
java.rmi.RemoteException:

Trace from server: 1696074012 at host vistaintest >>
java.rmi.RemoteException: ; nested exception is:
java.lang.NoClassDefFoundError: com/ibm/re/zas/Afflcode
at com.ibm.vista.re.zas.ZASValidationSessionBean.test1(ZASValidationSessionBean.java:54)
at

com.ibm.vista.re.zas.EJSRemoteStatelessZASValidationSession_8f9f06d2.test1(EJSRemoteStatelessZASVal

idationSession_8f9f06d2.java:27)
at

com.ibm.vista.re.zas._EJSRemoteStatelessZASValidationSession_8f9f06d2_Tie.test1(_EJSRemoteStateless

ZASValidationSession_8f9f06d2_Tie.java:170)
at

com.ibm.vista.re.zas._EJSRemoteStatelessZASValidationSession_8f9f06d2_Tie._invoke(_EJSRemoteStatele

ssZASValidationSession_8f9f06d2_Tie.java:84)
at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:610)
at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:463)
at com.ibm.rmi.iiop.ORB.process(ORB.java:439)
at com.ibm.CORBA.iiop.ORB.process(ORB.java:1737)
at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2260)
at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:65)
at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:95)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java(Compiled Code))
Caused by: java.lang.NoClassDefFoundError: com/ibm/re/zas/Afflcode
... 12 more
<< END server: 1696074012 at host vistaintest

Please suggest me to solve this problem.
Thanks in Advance

[Brian S Paskin]

Hi,

I think the error is obvious:
java.lang.NoClassDefFoundError: com/ibm/re/zas/Afflcode

Make sure the class is in the classpath.

I am not sure what you mean that the class will load the .so. What exactly are you trying to do? Are you trying to load a shared object from your java class?

Brian

[nagc...@gmail.com]

Hi Brian,
Thanks for u reply.

Actually I am trying to call an COBOL programs from java.I have created a library files (.so ) which contains the COBOL stuff and loading them in a java program.

The following is the class which i am accessing through an SLSB.
public class Afflcode
{

public static native Afflcode newdate(byte byte0, byte byte1, byte byte2, byte byte3, byte byte4, byte byte5, byte byte6, byte byte7,
byte byte8);

public native void Inputs1(byte byte0, byte byte1, byte byte2, byte byte3, byte byte4, byte byte5, byte byte6,
byte byte7, byte byte8);

public native void Inputs();

public native short Returns1();

private static native void _classInit();

public Afflcode()
{
Afflcode_instanceData = new byte[19];
}

private byte Afflcode_instanceData[];

static
{
System.loadLibrary("com_ibm_re_zas_Afflcode");
_classInit();
}
}

"com_ibm_re_zas_Afflcode" is an library name.

This is client code:
public class HelloEJB {

public static void main(String[] args) throws Exception {

Properties p = new Properties();
p.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory");
p.put(Context.PROVIDER_URL, "iiop://9.182.249.90:30400");

InitialContext ctx = new InitialContext(p);

Object obj = ctx.lookup("ejb/com/ibm/re/zas/ZASValidationSessionHome");

PortableRemoteObject x = new PortableRemoteObject();
ZASValidationSessionHome ejbHome = (ZASValidationSessionHome)
x.narrow(obj, ZASValidationSessionHome.class);

ZASValidationSession abc = ejbHome.create();

String message = abc.sayHello();
System.out.println(message);
Afflcode afflcode = abc.test1();
}
}

Pls provide solution.

[Brian S Paskin]

Hi,

It has nothing to do with the call to your object. If it could not find the system object, you would receive an UnsatisfiedLinkError. And the problem is not with the actual RMI call, as you are able to connect to your Session Bean.

The problem is that the Session Bean cannot find the class com.ibm.re.zas.Afflcode in the classpath. Please make sure that the class is in your classpath and in the correct package.

You could turn on the classloading for the JVM within WebSphere to see what is being loaded, though, I am not sure it is going to help on this case.

Brian

[nagc...@gmail.com]

Hi,

Thanks once again

Yes,I have created a jar which is containing the class files and .so files(eg: Afflcode.class and libcom_ibm_re_zas_Afflcode.so).And i have added this in utilityjars for EAR.
What i am especting is something is wrong while loading the .so file why beacuse in very first call to this EJB i have received that

java.lang.UnsatisfiedLinkError:
Can't find library : libcom_ibm_re_zas_Afflcode.so or .a is not in the java.library.path

After that i have created created an entry in sharedlibrary on WAS.(Environment -> Shared Libraries -> shared_library_name ->).

After that i am getting the exception i have reported.

Pls Need suggestions...

Thanks in Advance.

[Brian S Paskin]

Hi, I would try commenting out the load call and the call to the native method and see if the class is actually found.

Brian

[Paul Ilechko]

nagc...@gmail.com wrote:
> Hi Brian,
> Thanks for u reply.
>
> Actually I am trying to call an COBOL programs from java.I have created a library files (.so ) which contains the COBOL stuff and loading them in a java program.
>
> The following is the class which i am accessing through an SLSB.

The EJB specification forbids loading native code.

From the Sun blueprints site:

Why can't I load native code?

Native code, if allowed in enterprise beans, could cause a host of
problems, including but not limited to:

* Loss of portability. Using native code implies implementing that
native code on every platform you use, or ever will use. Using native
code in enterprise beans would tie those beans to the platforms on which
the code runs.
* Loss of system stability. Native code is typically written in C,
and so will suffer from the liabilities of C programs, such as pointer
errors, memory leaks, invalid memory references, and so forth.
Furthermore, the code is likely to be less stable than the JVM, if only
because the JVM code base is likely to be more mature. If enterprise
beans were allowed to use native code, a native code crash would
probably bring the application server down.
* Loss of scalability. Remember that enterprise beans are
multithreaded. If enterprise beans were allowed to use native code, that
code would either have to be entirely reentrant, with thread management
code at appopriate places; or access to the native calls would have to
be synchronized by the Container. Long-running native calls would lock
enterprise bean instances into memory, preventing them from being
candidates for passivation.
* Compromised security. The EJB container is somewhat like the
applet "sandbox", in that its security policies define what the
contained instances can do. One of the things the container does is
prevent enterprise beans from scribbling on the filesystem anywhere they
please. Native code has no such restriction. So, for example, if someone
breaks the deployment security in your enterprise bean environment, they
have full access to your filesystem. They can read files, read
directories, broadcast file contents, or even download and replace the
server's JVM with a security-compromised (or worse) runtime executable
to commit mayhem or simply make other security breaches easier to create.

How does the container prevent native code from being called? The
container has a SecurityManager whose standard policies (section §
18.2.1.1 of the specification, Table 10) don't set a checkLink
permission for any native library. So, attempts at executing the load()
or loadLibrary() methods of java.lang.Runtime result in a SecurityException.

[Randy Schnier]

Paul is right. When someone needs to invoke native code from an EJB, we usually suggest setting up a simple Java RMI server in a separate process from WAS and having the EJB call that code over RMI. That way if the native code crashes, it takes down only the remote RMI process and not the rest of WAS with it.

By default, WAS has Java2 security turned off. If you were to turn Java2 security on, you'd receive a SecurityException as mentioned at the end of Paul's posting, when trying to load a native library.

[siva...@hotmail.com]

From WAS ClassLoader utility check whether the class is available to your EJB or not and find out which classloader is trying to load that class. In that way you will have some idea how to bundle your classes.

[Paul Ilechko]

That's not going to help him load native code from an EJB. Did you pay
any attention at all to the previous posts?

[nagc...@gmail.com]

Hi,
Thanks for u reply.
I am new to this can u pls give some in detail about how use "WAS ClassLoader utility".