Terracotta Discussion Forums (LEGACY READ-ONLY ARCHIVE)

I have problem using DSO in my application containing several classloaders (objects managed by DSO are from those special classloaders).

One instance of application is able to send instances to server, however another instance of application cannot obtain them. ClassNotFoundException occurs as if client side of DSO tried to use classpath classloader for those classes.

I have prepared test case demonstrating this behavior. It can be downloaded here http://www.pb.bsoft.sk/dso/testcase.zip.
Apart from sources, it contains 2 prepackaged JAR files one for each classloader and batch file for execution. Run it once and then for the 2nd time while the 1st is stil running. ClassNotFoundException is shown there.

Is it possible to solve this problem somehow?

Thank you for your answer,
Pavol

Hi Pavol,

First of all thank you for your interest in DSO and the complete test case (both are greatly appreciated!). Your particular use case (user defined class loaders) is not yet fully supported in our current release. The basic problem is that your classloader instance has no strong identity associated with it. Other loaders in the system (the system classloader, extensions loader, web app loaders) are readily identifiable can be located through standard methods.

Since you posted this test case, I’m assuming your application uses its own classloader(s) other than the system loader and/or those provided by a web container (ie. tomcat, weblogic, etc). DSO already correctly handles the more complicated classloader heirarchies in web containers, but as I mentioned before we don’t have a generic mechanism available in the current release.

The problem to solve is that somehow DSO needs to know how to locate your classloader(s) when materializing existing shared objects. This implies some sort of classloader registry where your loader(s) can be associated with a unique name. Does that make sense? How would you expect to interact with such an interface (external config, API, something else)? We already have a few prototypes for this feature, but I’d like to explore your expectations first.

Thanks,
Tim Eck – Terracotta

p.s. While we’re on the topic, if you wanted to serialize/deserialize instances of your StoredDataImpl class, I believe you would need to use a custom version ObjectInputStream that overrides the resolveClass() method to work with your loader(s). Otherwise, standard java serialization will attempt to resolve your class with the system loader and fail with a ClassNotFoundException

Hi Tim, you are right I have several classloaders in my application and it contains also custom ObjectInputStream. Right now weI use only URLClassLoader, but it looks like we will need our own subclass of classloader soon, because extension we need to do does not look like it fits custom stream handler well.

I understand that it is necessary to distinguish between classloaders in order to support materialization of objects, but I cannot imagine how that could be achieved in API-less environment. Also pure configuration approach might not be very flexible. Thus I would probably go with approach similar to approach used in Spring framework - to define hook interface that is registered in DSO. That makes one class of application dependent on DSO, but that is OK, because whole new area of applicability of DSO occured.

Thanks,
Pavol

Hi Pavol. Thanks a lot for your very detailed feedback - it's extremely valuable to us. I think we have a good understanding the problem you're running into, and I agree that solving it only with a declarative, config-based mechanism could be problematic. We'll put our thinking caps on here and see if we can roll out a solution for this.

Cheers,
-p

_________________
Patrick Calahan
Director, Product Management
Terracotta, Inc.