Re: [Rmock-users] [Spam] Re: [Spam] Re: strange exception

[Joakim O. <joa...@ag...>]

Ok,

I think the naming policy of CGLIB tends to put the mocked classes in
the same package as the original class. This is necessary in order to
be able to use package private methods from within the mock. I will
investigate to see if it's possible for us to provide some way around
this issue. I suspect being able to specify the package of the mock
could be a viable solution.

I think you can work around the issue by subclassing the external
class you want to mock and then mock that subclass:

public class MyApplicationContext extends ClasspathXmlApplicationContext {
};

That way your subclass won't be in a signed jar and rMock can mock it.

My general recommendation, regardless of whether the external jar is
signed or not, would be to wrap the external classes behind some
interface you own and then mock that one. I understand this may not
always be possible and maybe more of a longterm strategy than
something that solves your immediate problem.

Let me know if the suggested workaround works for you.
Regards
/Joakim Ohlrogge



On 3/23/07, David Corbin <dc...@al...> wrote:
> In addition to having problems by signing cglib, problems also arise  when you
> attempt to mock  a class that is in a signed jar.
>