Derek Slager wrote:
>
> Forgive me if I am being a complete idiot (which has been known to
> happen)
> -- but I am confronted with a problem I can't seem to find an answer to.
> Basically, I came across the rather infamous ClassCastException in
> working
> with an EJB in jBoss. Alas, after *@$#ing around with it for a few hours
> I
> found some of Rickard's clues on the mailing list archives which helped
> me
> find the solution. The problem was a mismatch in the ClassLoader
> implementation for my ProjectBean.class and my proxy reference.
>
> The results of:
>
> System.out.println(ref.getClass().getClassLoader());
> System.out.println(ProjectHome.class.getClassLoader());
>
> came out as:
>
> [java] sun.misc.Launcher$AppClassLoader@7fdcde
> [java] junit.runner.TestCaseClassLoader@4e3f41
>
> Only when these matched would the cast succeed. Problem solved, right?
> Wrong, this actually brings me to my dilemna. As you may have noticed
> I'm
> using jUnit to test my EJB in this scenario. I would like to find a way
> to
> get around this problem such that my testing framework can be used for
> EJBs
> in the same way it is for all other portions of my application.
>
> So far, I can't think of much. Briefly, I considered dynamically loading
> my
> ProjectHome class using the remote reference's class loader, but I don't
> see
> how a cast can be accomplished with that method. Regardless, it would
> make
> the testing code rather nasty looking. I assume at this point that the
> casting issue is really a Java language issue, and there is no way to
> solve
> it that way obviously.
>
> For some insight, I snagged the recent jbosstest module from cvs to see
> if
> the team had already come across a solution, but didn't see any real
> utilization of the jUnit framework other than extending the classes --
> which
> weren't even used as far as I could tell. Should I assume it is for the
> above reasons? If yes or no, I'd appreciate any thoughts you could
> provide
> on this issue.
This is from a standalone client, right? Well, if you're getting
classcast's that means the client has the same class two times
somewhere, or otherwise this wouldn't happen.
What you can do, is that in the setup method of your jUnit test do:
Thread.currentThread().setContextClassLoader(getClass().getClassLoader());
This should set the CCL to the jUnit CL, which should be used when
getting JBoss EJBObjects, and thus avoid the class casts.
If this works it is only a workaround for a bad setup, but at least it
might get you going.
regards,
Rickard
--
Rickard �berg
Email: [EMAIL PROTECTED]
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
List Help?: [EMAIL PROTECTED]
