Webservice client JNDI lookup problem(classCastexception)

[Former Member]

I have created jndi in my application in ejb-j2ee-engine.xml

<server-component-ref>

<description>

</description>

<name>AddParametersToLocationService</name>

<type>interface</type>

<jndi-name>/wsclients/proxies/xxx.com/admin~WS/com.xxx.folio.admin.wsproxy.lparam.Proxy</jndi-name>

</server-component-ref>

2.created reference in application-j2ee-engine.xml

<reference reference-type="weak">

<reference-target provider-name="sap.com"

target-type="application">admin~WS</reference-target>

</reference>

When i look up for the class it is throwing classcastexception

XXX service = (XXX) context.lookup("java:comp/env/AddService");

I printed the classname and package name of the returned Object. all are ok

Can anyone guide me to resolve classCastexception

Regards

Ganesan S

[Former Member]

>

> <name>AddParametersToLocationService</name>
> <type>interface</type>
>.....
> XXX  service = (XXX) context.lookup("java:comp/env/AddService");		
> 

Two things,

1. If you are defining JNDI-Mapping for a Proxy, the type should be service and not interface.

2. The name that you have given as JNDI is AddParametersToLocationService and while referring it in the lookup you are using AddService. It explains the classCastException.

Hope it helps.

Regards,

Alka.

[Former Member]

Dear Ganesan,

Here is some explaination for Class Casteexception and some ways to fix problem:

When does this happen?

If there are several ClassLoaders and they do not share all their classes. Classes loaded with separate loaders cannot see Class objects from each other and reload binaries. This is usally the case when you are using applications servers and you have several applications that interact together.

If you are loading classes explicitly using Class.forName() or by passing their codes directly to the class loader. Explicit class construction can even be used to reconstruct the situation in question.

If you are using a system that automatically reloads classes that have been modified. This is usually the case with JSPs. The Servlet engine re-compiles JSPs and loads them although old instances still remain somewhere in memory. You might also meet this problem with some IDEs for the same reason.

Some possible ways to fix the problem

You can try to specify the problematic classes in the beginning of the CLASSPATH of the default ClassLoader. This usually prevents custom loaders from creating their local copies because default classes are usually visible for all of them.

In case of the rare JSP problems it might be enough if you just restart the servlet engine after page modifications to dispose old classes.

Use explicit ClassLoader definitions in your code to makes sure that you are using the correct ClassLoader for all classes.

If you are getting this problem because you have written your own ClassLoader it usually means that you are not accessing the base loader properly. By default you should always ask if the default ClassLoader already has an instance for the requested class type.

Reward Points if useful