Error on replicating cache entry

[mikefinn]

Hi all,

Using async_repl with jboss cache 1.0, in a JBoss 3.2.2 cluster.

When I put an object into the cache, the cache svc correctly attempts to replicate the entry to the other node. On the other node, however, when it receives the repl entry, I get a class not found, because it can't find the classloader for the object in the cache:

2004-07-15 07:35:01,620 ERROR [org.javagroups.DefaultPartition] [Thu Jul 15 07:35:01 EDT 2004] [ERROR] RpcDispatcher.handle(): exception=
java.lang.ClassNotFoundException: No ClassLoaders found for: com.frontiercorp.bss.cap.dsl_query.vo.WtnInfo

I am deploying the cache service in a SAR, in an EAR, that has a scoped classloader.

Is this a supported implementation of cache?
Will the svc use the scoped classloader from the EAR?

TIA,
mike

[belaban]

- Do you have the relevant classes available in your EAR ?

- Can you verify that the following should work: (1) put the jboss-cache.jar in jboss-xxx/server/xxx/lib and the XML file for the cache (e.g. tree-service.xml) in server/xxx/deploy. Then deploy your EAR and run your app again. The error should disappear.

- If you want everything in your EAR, you may have to create correct dependencies, e.g. between the SAR and the JAR which contains the offending classes.

Bela

[ben.wang]

I have discovered this problem recently. If you have a "scoped" application (jar, ear, or war), that implies different context class loaders. In this case, you will need to use the jboss utility class wrapper org.jboss.invocation.MarshalledValue to wrap your serializable object first before putting it into the cache.

Here is a snippet:

MyPOJO pojo = new MyPOJO();
MarshalledValue mv = new MarshalledValue(pojo);
cache.put("/ben", mv);

Then to retrieve:
MasahlledValue mv = (MarshalledValue)cache.get("/ben");
MyPOJO pojo = (MyPOJO)mv.get();

Let me know if this doesn't work for you.

-Ben

[belaban]

This should work for now. However, I'm going to add the mechanism used by MarshalledValue to JGroups itself, so this isn't needed. This will probably be in JBoss 3.2.6, I'm going to upgrade JGroups used by JBoss soon.

Bela