Title: Message
Hi everyone,
            I've just encountered the dreaded ClassCastException error that's thrown due to the fact that the type of the
java class is now a function of the class loader as well as the name.
 
I read the Classloader excerpt from the 3.x documentation that Jonathan recommended. (Thanks again for that Jonathan).
 
My problem is as follows for those who have a minute.
I'm developing a small workflow engine comprised of a number of beans deployed in JBoss3.2.1.
A number of remote components that perform the work externally of the engine may or may not be deployed witihin the same instance of the server.
However they must be able to communicate events back to my with my engine so I put all the interfaces for the engine into a jar called client-interfaces.jar
and bundled it within an remote components ear file that that would need to talk to my interact with the workflow..
 
Inevitably I got a huge ClassCastException when attempting to run the overall process due to so many versions of the same interface classes being deployed.
I've thought about it and I can see two possible solutions.
 
1 Take all the interfaces out from everywhere including the workflow engine itself and deploy them in a separate interfaces-jar file.
If I do I should have only one version of the class deployed although the engine would be fragmented.
Also if I do this by deploying say interfaces.jar will this make the classes available to the remote components that are deployed along side it?
If not then how do I specify that this jar file is part of the classpath?
 
2. The second involves the use of hte jboss-app.xml file described in the Classloader excerpt. Unfortunately I have no experience writing classloaders whatsoever.
And can't get my head around where the jboss-app file should be included and whether or not I have to actually write a class loader for each remote component.
 
Any explanation of the jboss-app.xml file or indeed any help in answering any of the above questions would be greatly appreciated.
 
Thanks again,
Mark.
 
 
 
 
 

Reply via email to