Recent changes to bugs

#4 class loading conflicts with springjunit4classrunner

2014-12-27T10:06:32.799000Z

status: open --> accepted
Priority: 5 --> 8

#4 class loading conflicts with springjunit4classrunner

2014-11-17T14:42:03.460000Z

Ok, I am not sure if this is a valid bug for the project
passing

-Dlog4j.ignoreTCL=true

solved the problem. The logger is working now correctly.

#4 class loading conflicts with springjunit4classrunner

2014-11-17T13:10:49.937000Z

It seems that step 2 is not even required.
It's enough to use step 1 and the error is thrown when spring tries to configure log4j

class loading conflicts with springjunit4classrunner

2014-11-17T11:54:01.030000Z

Using CallbackParams in conjunction with spring test runner results in classloading clashes.

Use Callback Params with conjunction with spring runner:
@RunWith(CallbackParamsRunner.class) @WrappedRunner(SpringJUnit4ClassRunner.class)

Use a logger in your test class
private static Log logger;
Running the test will result in the following error
log4j:ERROR A "org.apache.log4j.RollingFileAppender" object is not assignable to a "org.apache.log4j.Appender" variable. log4j:ERROR The class "org.apache.log4j.Appender" was loaded by log4j:ERROR [org.callbackparams.internal.CallbackTestClassReloader@3e401b01] whereas object of type log4j:ERROR "org.apache.log4j.RollingFileAppender" was loaded by [sun.misc.Launcher$AppClassLoader@17072b90]. log4j:ERROR Could not instantiate appender named "rfile". log4j:WARN No appenders could be found for logger (org.springframework.test.context.TestContextManager). log4j:WARN Please initialize the log4j system properly.


Is this a known issue?

cheers

Artur

class loading conflicts with springjunit4classrunner

2014-11-17T11:54:01.030000Z

Ticket 4 has been modified: class loading conflicts with springjunit4classrunner
Edited By: Henrik Kaipe (kaipe)
Status updated: u'open' => u'accepted'
_priority updated: u'5' => u'8'

#3 Initialization error: can't find a method in the BCEL library

2014-10-27T20:12:09.808000Z

Thank you for this report. I am glad you seem to have found a workaround for the problem but I keep this issue open for a while in hope of more feedback on the effects of this problem. Maybe someone can come up with a small quick-fix to help CallbackParams co-existance with Xalan.

A couple of other thoughts on this issue ...

I am not sure about your specific case but it might be a good idea to put the test-dependencies first on class-path.
This kind of problem was predicted a long time ago and a possible solution has been suggested - maven-shade-plugin: http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html
But so far the drawbacks, such as a more complicated development-and-buld process, have stood out and made us stick with the explicit BCEL-dependency and the potential version-conflicts that come with it.
Do you think it would a better idea to hurry up with BCEL shading and class-relocation? then please let us know

#3 Initialization error: can't find a method in the BCEL library

2014-10-22T14:44:20.227000Z

I discovered the problem. Another library, by the name of Xalan, is used by my project. Inside that library is embedded another version of BCEL. I had to edit my pom.xml file to exclude portions of Xalan from the classpath.

Initialization error: can't find a method in the BCEL library

2014-10-21T17:49:56.465000Z

In Java 7, JUnit 4.11 reports an "initializationError" when I try to run a test through CallbackParamsRunner with CallbackParams 1.0-beta-6. The stack trace is as follows:

java.lang.NoSuchMethodError: org.apache.bcel.generic.Type.getType(Ljava/lang/Class;)Lorg/apache/bcel/generic/Type;
at org.callbackparams.internal.CallbackMethodProxyingRebyter.<clinit>(CallbackMethodProxyingRebyter.java:59)
at org.callbackparams.internal.CallbackTestClassReloader.newInstance(CallbackTestClassReloader.java:98)
at org.callbackparams.junit4.Junit4RunWrapper.<init>(Junit4RunWrapper.java:36)
...

The Dependency Analyzer of the Maven Helper plugin for IntelliJ IDEA shows no BCEL conflicts, the only version of BCEL being the one that's included by CallbackParams: version 5.2. I can see that org.apache.bcel.generic.Type.getType(String) exists, but getType(Class) certainly does not exist in that class. Why is CallbackMethodProxyingRebyter depending on a method that doesn't exist?

Make callbacks eligible candidates for Mockito spying

2010-12-04T14:21:16Z

Using version 1.8.5 of Mockito - try this in a CallbackParams test-class:

@CallbackField Collection<?> callback;
{
callback = Mockito.spy(callback);
}

The initiative will result in a MockitoException with this message:
Cannot mock/spy class $Proxy9
Mockito cannot mock/spy following:
- final classes
- anonymous classes
- primitive types

In short - callbacks are not eligible candidates for Mockito spying. There is a reason for this - the callbacks are created by using the Java SE API for dynamic proxies. However, there is no good reason to why callbacks should be non-eligible for Mockito spying, so this should be fixed. It is probably easy to fix by creating some hand-rolled dynamic-proxy tools that also provide Mockito with desirable class-implementations for the callback instances.

Generics does not work

2010-11-29T22:46:29Z

When a callback declaration used generic type templates, such as ...
MyCallbackInterface<Whatever> callback
... then "callback" will be forwarded to all callback-elements that can produce an instance of MyCallbackInterface, regardless of whether the type-parameter is "Whatever" or not. This should be fixed so that only instances of the specified generic type will be exposed.