Here's a weird thing I didn't expect from merlin...
Let's say I have Service A in a composite block that exports the following method:
byte[] fetchObject(String key)
This method returns a serialized object from some third-party jar. I built the byte[] method so that I would have to include my third-party jar (and it's dependencies) in my container descriptor. Being a byte[], merlin was quite content to start this composite block and the other composites that depended on the service with only adding the Service A's api jar to the container descriptor.
However, as soon a consumer composite invoked fetchObject, and attempted to reconstitute the byte[] into it's original object type, I get a ClassCastException, even though the block.xml of the consumer block included the same third-party jar (and its dependent jars) in its own classloader.
It wasn't until I added the third-party (and it's dependendt jars) to the outer container's classloader that the ClassCastException went away, even those these jars were contained in the block.xml of both consumer and provider.
Your creating different instances of the same class in different classloaders. Bottom line is that the class must be *shared* which means that the APIs must exist in a classloader that is common to both the consumer and the supplier - i.e. a common parent as you discovered.
Steve.
Does merlin not like serialized objects across composite block boundaries?
Timothy
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
|------------------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org/merlin | | http://dpml.net/merlin/distributions/latest | |------------------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
