oghenez / mycila Goto Github PK

MycilaTestNGTest throws an exception on the shutdown() method if you have
tests classes without any method as part of the suite.

It seems that the @BeforeClass on the prepareTestInstance() is not executed
if the class has no tests to run for the suite, which will make the
testNotifier to not be initialized.

The @AfterSuite is executed regardless, making the shutdown() method throw
a NPE since testNotifier is null.

Not available LICENSE and NOTICE file in source directory structure
Please. Added license and copyright notice.
the fedora pakaging guideline is very strictly precise about this problem
https://fedoraproject.org/wiki/Packaging:LicensingGuidelines?rd=Packaging/Licens
ingGuidelines#License_Text
thanks
regards

When a webapp is reloaded in JBoss, Jboss clears the old webapp
classlaoder, but the classloader and some of its classes may remain available.

A call to a cleared wbapp classlaoder's getURL() throws a NPE.

java.lang.NullPointerException
    org.apache.catalina.loader.WebappClassLoader.getURLs(WebappClassLoader.java:1406)
    com.mycila.ujd.impl.LoaderImpl.getContainers(LoaderImpl.java:62)
    com.mycila.ujd.impl.DefaultJVMAnalyzer.getClassPath(DefaultJVMAnalyzer.java:84)
    com.mycila.ujd.impl.DefaultJVMAnalyzer.getUnusedClassPath(DefaultJVMAnalyzer.java:180)
    com.mycila.ujd.mbean.JmxAnalyzer.getUnusedClassPath(JmxAnalyzer.java:83)
    sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    java.lang.reflect.Method.invoke(Method.java:585)
    com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
    com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
    com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)

getUnusedClasses  returns some used classes

The currently implemented support for Spring JavaConfig (@Configuration and 
@Bean annotations) is not compatible with Spring 3.0. The problem is the 
implementation of the setupJavaConfig-Method in the MycilaContextLoader class 
of the mycila-testing-spring plugin.

Do you plan to add compatibility to Spring 3? The corresponding code line would 
be:

context.setParent(new 
org.springframework.context.annotation.AnnotationConfigApplicationContext(ctx.cl
asses()));

Regards,
Raöf

We've been profiling our application and noticed that the TypeListeners for 
@PostConstruct and @Resource add a significant overhead. They are called when 
new instances are created and loop over the method cache in 
com.mycila.inject.internal.Reflect. This loop does a lot of method calls to 
find the methods to invoke. In one unit of operation (a complex task) in our 
application these loops caused over 30.000 invocations of 
com.mycila.inject.internal.Signature#equals, which does 2 calls to 
Method.getName() and one String.equals().

Now, we profiled using instrumentation which adds overhead, especially for tiny 
methods where the overhead easily outweighs the real implementation. Never the 
less, I think this can be improved.

To see the performance impact without profiling I've written a simple test 
creating a million instances with and without Mycila for both a class with a 
@PostConstruct method and a class without one. See the class below.

These are the results:

To create 1000000 instances of a class with a @PostConstruct method
Time without Mycila: 155 ms     0 invocations
Time with Mycila: 4009 ms     1000000 invocations

To create 1000000 instances of a class without @PostConstruct method
Time without Mycila: 198 ms     0 invocations
Time with Mycila: 3740 ms     0 invocations

I think this can be improved significantly by changing the implementation to 
find the methods before registering the MembersInjector instead of going to the 
method cache. Also, if no methods are found there's no need to add the 
MembersInjector at all so the overhead for such classes would be zero.

Not using the cache will increase memory consumption of course. To make sure 
the increase is as small as possible the list of methods can be copied to an 
array of the exact size required. I.e: Method[] methods = 
methodsList.toArray(methodsList.size());

Code for the test:

public class NewInstanceTest {

    private static long invocations;

    public static class TestClassWithPostConstruct {

        public void method1() {
        }

        public void method2() {
        }

        @PostConstruct
        public void method3() {
            invocations++;
        }

        public void method4() {
        }
    }

    public static class TestClassWithoutPostConstruct {

        public void method1() {
        }

        public void method2() {
        }

        public void method3() {
        }

        public void method4() {
        }
    }

    public static void main(String[] args) {

        int n = 1 * 1000 * 1000;

        System.out.println("To create " + n + " instances of a class with a @PostConstruct method");
        time("without Mycila", n, createSimpleInjector(), TestClassWithPostConstruct.class);
        time("with Mycila", n, createInjectorWithMycila(), TestClassWithPostConstruct.class);

        System.out.println("To create " + n + " instances of a class without @PostConstruct method");
        time("without Mycila", n, createSimpleInjector(), TestClassWithoutPostConstruct.class);
        time("with Mycila", n, createInjectorWithMycila(), TestClassWithoutPostConstruct.class);
    }

    private static void time(String name, int n, Injector injector, Class<?> clazz) {

        // warm up
        for (int i = 0; i < 1000 * 1000; i++) {
            injector.getInstance(clazz);
        }

        invocations = 0;
        long start = System.currentTimeMillis();

        for (int i = 0; i < n; i++) {
            injector.getInstance(clazz);
        }

        long end = System.currentTimeMillis();

        System.out.println("Time " + name + ": " + (end - start) + " ms     " + invocations + " invocations");
    }

    private static Injector createInjectorWithMycila() {
        return Guice.createInjector(Stage.PRODUCTION, Jsr250.newJsr250Module());
    }

    private static Injector createSimpleInjector() {
        return Guice.createInjector(Stage.PRODUCTION);
    }
}

I've tried to run the guice2 plugin sample on your wiki and got the
following error :  "Method setupTest() should be static"

I have added the following repositories in my maven pom.xml  :

<repositories>
  <repository>
    <id>mc-release</id>
    <name>mc-release</name>
    <url>http://mc-repo.googlecode.com/svn/maven2/releases</url>
    <snapshots>
        <enabled>false</enabled>
    </snapshots>
    <releases>
        <enabled>true</enabled>
    </releases>
  </repository>
</repositories>


And the dependecies :

        <dependency>
            <groupId>com.mycila.testing</groupId>
            <artifactId>mycila-testing-api</artifactId>
            <version>1.2</version>
        </dependency>
        <dependency>
            <groupId>com.mycila.testing.plugins</groupId>
            <artifactId>mycila-testing-jmock</artifactId>
            <version>1.2</version>
        </dependency>
        <dependency>
            <groupId>com.mycila.testing.plugins</groupId>
            <artifactId>mycila-testing-guice</artifactId>
            <version>1.2</version>
        </dependency>


Here is the exception stack trace : 


java.lang.Exception: Method setupTest() should be static
    at
org.junit.internal.runners.MethodValidator.validateTestMethods(MethodValidator.j
ava:67)
    at
org.junit.internal.runners.MethodValidator.validateStaticMethods(MethodValidator
.java:36)
    at
org.junit.internal.runners.MethodValidator.validateMethodsForDefaultRunner(Metho
dValidator.java:42)
    at
org.junit.internal.runners.JUnit4ClassRunner.validate(JUnit4ClassRunner.java:36)
    at
org.junit.internal.runners.JUnit4ClassRunner.<init>(JUnit4ClassRunner.java:27)
    at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
    at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorI
mpl.java:39)
    at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorA
ccessorImpl.java:27)
    at java.lang.reflect.Constructor.newInstance(Constructor.java:513)
    at org.junit.internal.requests.ClassRequest.buildRunner(ClassRequest.java:33)
    at org.junit.internal.requests.ClassRequest.getRunner(ClassRequest.java:28)
    at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.<init>(JUnit4TestRefe
rence.java:28)
    at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestClassReference.<init>(JUnit4Tes
tClassReference.java:24)
    at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.createTest(JUnit4TestLoa
der.java:40)
    at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestLoader.loadTests(JUnit4TestLoad
er.java:30)
    at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner
.java:445)
    at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner
.java:673)
    at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java
:386)
    at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.jav
a:196)

I use assumptions (see the Assumption class in junit) to conditionally run 
tests.
I case where I use Mycila and the test doesn't actually run due to the 
assumption not being evaluated to execute Mycila fails with a nullpointer:

java.lang.NullPointerException
    at com.mycila.testing.junit.MycilaJunitRunner$2.evaluate(MycilaJunitRunner.java:68)
    at org.junit.runners.ParentRunner.run(ParentRunner.java:300)
    at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
    at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
    at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)


There should be a test for the testNotifier being null or not.
testNotifier.fireAfterClass();

Added a lot of javadoc documentation

I often forgot to add -static {Loggers.useJDK();}- when creating testing file 
and then I lost time searching why I don't get any log.

It would be useful to allow declaration of the default provider from a property 
file.

Actual behaviour:
# try use system property
# use to noop

Expected behaviour:
# try use system property
# try use resource mycila-log.properties property
# use to noop

I have a patch proposal.
I think some part of System.property and Resource property could be merged, but 
I prefer to keep the patch simple.

Anyway, thanks the great work done on mycila.

Weak references wraps the Subscription object in SubscriptionList instead of 
Subscriber. So Dispatcher with weakly-referenced Subscribers doesn't work as 
expected due to Subscriptions may be lost due to garbage collection in 
SubscribtionList and they may disappaer.

Affected versions: 4.2.ga and 3.5

@SpringContext annotations on parent beans are not taken into consideration 
when doing injection - even if the annotation is declared as @Inhert.

i suggest changing the annotation into the same way the @ContextConfiguration 
works for the spring-testing framework - or just support the one in the spring 
framework and have the same semantics for it.

I have a problem in my project when i use requireExplicitBindings(). I want to 
do this for safety and extra control.

The problem is that Mycila does not explicitly bind:
com.mycila.inject.jsr250.Jsr250KeyProvider
com.mycila.inject.jsr250.Jsr250PostConstructHandler

Also in Jsr250Module when destroying singletons it uses getAllBindings() which 
in requireExplicitBindings() -mode returns all explicit bindings (which we want 
to destroy) AND any JIT bindings it created internally for linked bindings 
(these are constructor bindings).

Support Spring javaConfig

Review wiki doc + migration guide

When a webapp is reloaded in JBoss, Jboss clears the old webapp
classlaoder, but the classloader and some of its classes may remain available.

A call to a cleared wbapp classlaoder's getURL() throws a NPE.

java.lang.NullPointerException
    org.apache.catalina.loader.WebappClassLoader.getURLs(WebappClassLoader.java:1406)
    com.mycila.ujd.impl.LoaderImpl.getContainers(LoaderImpl.java:62)
    com.mycila.ujd.impl.DefaultJVMAnalyzer.getClassPath(DefaultJVMAnalyzer.java:84)
    com.mycila.ujd.impl.DefaultJVMAnalyzer.getUnusedClassPath(DefaultJVMAnalyzer.java:180)
    com.mycila.ujd.mbean.JmxAnalyzer.getUnusedClassPath(JmxAnalyzer.java:83)
    sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
    sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
    java.lang.reflect.Method.invoke(Method.java:585)
    com.sun.jmx.mbeanserver.StandardMetaDataImpl.invoke(StandardMetaDataImpl.java:414)
    com.sun.jmx.mbeanserver.MetaDataImpl.invoke(MetaDataImpl.java:220)
    com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:815)

It would be handy with powermock-mockito support in mycila for mocking static 
methods.
Now I just mycila-spring and mycila-mockito, but powermock-mockito needs to 
have it's own PowerMock runner in order to be able to override the static 
method.

check why server/lib jars are not shown. Perhaps JBoss has its proper
classloader not extending URLClassLoader.

Example of plugin using hoit patching of classes with jdk 6:

See 

http://www.fasterj.com/articles/hotpatch1.shtml

Mocks injected using the @Mock annotation of the EasyMock plugin have an 
automatically generated mock name that is very long and difficult to read.

Steps to reproduce:
1. Create an interface, say my.package.MyClass
2. Create a test case with a field MyClass called myField and decorate it with 
a @Mock annotation
3. Make EasyMock.verify(...) fail with the MyClass mock to get an error message

Sample expected output:
  Unexpected method call my_package_MyClass_myField.someMethod(): ...

Sample actual output:
  Unexpected method call ___________________myField.someMethod(): ...

Cause:
Mock name generation found in EasyMock2TestPlugin@line47 
(mycyla-testing-easymock-2.6.jar) appears to incorrectly use the 
String#replaceAll(String,String) API on the mock's class name.

Actual usage: 
 field.getDeclaringClass().getName().replaceAll(".", "_")

(presumably) Intented usage:
 field.getDeclaringClass().getName().replaceAll("\\.", "_")
  or
 field.getDeclaringClass().getName().replace('.', '_')

Direct link: 
http://www.google.com/codesearch/p?hl=en#jkOSd3dEr64/mycila-testing/tags/mycila-
testing-2.2/mycila-testing-plugins/mycila-testing-easymock/src/main/java/com/myc
ila/testing/plugin/easymock/EasyMock2TestPlugin.java&q=replaceAll%20package:http
://mycila\.googlecode\.com&l=47

If I use

@BeforeClass
   public void setup() {
       TestSetup.setup(this);
   }

All my injections take place, however just extending
AbstractMycilaTestNGTest is not working for me. I'm currently using maven
to run the tests and using Guice2 but I had the same problem using Guice1
as well.

I've tried to narrow things down to as small as possible and I've posted
some relevant information on the setup here

http://pastie.org/362139

associateDAO will be null when the test case runs. 

Attached patch that allows Jsr250 to properly destroy already created objects.

Works best with: 
http://code.google.com/p/google-guice/issues/detail?id=676&thanks=676&ts=1324809
573

There are some changes in the testframework in spring 3.1.
Have you started any migration?

3.0 or 3.1 support can be decided based on reflection.

In 3.1 the locations are now in an instance of the new class 
MergedContextConfiguration which is accessible through the TestContext.

With Junit: through runner
With testNG: through ITestListener

The objects are injected only once for each test instance.
I think it should be possible (maybe the default) that before each test
method is initialized the test objects are reinitialized.

I personally do all my stuff in setup methods annotated with @BeforeMethod
and clean up with @AfterMethod annotated methods.

[deleted issue]

In case of a circular dependency, Guice injects a Proxy instead, that throws an 
Exception upon usage. @PostConstruct methods are called directly after 
injection and therefore do not help doing stuff on creation. Such methods 
should rather be called after Proxies have been resolved.

Hi,

I've found a problem with @PreDestroy methods being invoked more than once. It 
happens when providers return the same object. With linked bindinds Interface 
-> Class, Guice will create an internal jit ConstructorBinding for Class so 
Injector.getAllBindings() will return two providers that return the same object.

It should be solvable by gathering all objects in an IdentityHashSet and then 
destroy them.

Here's a failing test case, http://pastie.org/2176603

The last test shows that when binding a Provider, it will get its 
@PostConstruct called since Guice injects into it, but it will not get its 
@PreDestroy called. Maybe this is intentional. The same things goes for objects 
that get passed to injectMembers(), used with a MembersInjector() and 
Binder.requestInjection() i guess.

@DbUnit
DbUnitTester dbUnitTester; // not sure about this, but here we should
inject either a custom wrapper either a dbunit class which allows
manipulating dbunit internals and data

@BeforeClass
@DataSet(location = "...")
public void before {} // inserts data only once for all test methods

@Test
@DataSet(location = "...")
public void a_test_method {} // inserts data before a test

database plugin which allows datasource creation and transaction management

public class MyDaoTest extends AbstractMycilaTestNGTest {

    @DataSource(driver = MysqlDriver.class, url = "", username = "",
password = "")
    DataSource ds; // create a datasource in db plugin and inject it

    @Test
    public void test_get_dom_data_from_DB() {
    }

    @Test
    @Transactional(readonly = true)
    public void test_all_ops_execute_read_only() {
    }

    @Test
    @Transactional(rollback = true)
    public void test_modify_DB_and_rollback_after_test_completion() {
    }

    [...]
}

For Transactional support, I would support Spring / Warp Persist
@Transaction and i first have to modify Mycila to support test method
listeners.

I use Mycila testing with Spring and JUnit, and I noticed, that if i
have more than one @Test method in a class, then the dependencies are 
reinjected when executing  each test method. I can see this from a few
facts:

- I have Quartz in the context, and it starts 3 threads for one test
case, and after executing 5 test methods, I will have 5 * 3 = 15
Quartz threads
- I can see closing the persistence contexts only after executing the
last test method

The difference between executing the same tests
with SpringJUnitRunner and MycilaJunitRunner is that the
DependencyInjectionTestExecutionListener's prepareTestInstance()
method is executed before each test method thus dependencies are
reinjected for each execution by Mycila, while Spring executes
prepareTestInstance() only once before executing any test methods, and
then beforeTestMethod() for each tests, which will not reinject
dependecies. 

I use Spring 3.0.2, Mycila Testing Spring 2.4 

Maybe I needed another dependency using Junit4.4?, but when running with
junit4.4 you'll end up with errors referring to
"java.lang.NoClassDefFoundError: org/junit/runners/BlockJUnit4ClassRunner"

But in 4.5 this error goes away. Maybe the package structure changed in 4.5?

upgraded guice 2 beta and mockito version

Make optional name attribute of @Bean

=> Issue fixed in svn, will deploy release 2.3 this evening

MycilaEvent m = new MycilaEvent(dispatcher)
m.proxy()
m.getQueue
m...

I was attempting to utilize Spring's TransactionTestExecutionListener to
manage transaction and do auto-rollbacks on dao integration tests.  These
tests are Mycila annotated.  When the Spring following Spring annotations
were added to test class, a NullPointer Exception is thrown. 

@TestExecutionListeners ( { TransactionalTestExecutionListener.class }) 
@Transactional

Here is the stack trace:
java.lang.NullPointerException
        at foo.DataDaoTest.testSaveData(DataDaoTest.java:75)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:597)
        at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall
(FrameworkMethod.java:44)
        at org.junit.internal.runners.model.ReflectiveCallable.run
(ReflectiveCallable.java:15)
        at org.junit.runners.model.FrameworkMethod.invokeExplosively
(FrameworkMethod.java:41)
        at org.junit.internal.runners.statements.InvokeMethod.evaluate
(InvokeMethod.java:20)
        at com.mycila.testing.junit.MycilaJunitRunner$3.evaluate
(MycilaJunitRunner.java:85)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild
(BlockJUnit4ClassRunner.java:76)
        at org.junit.runners.BlockJUnit4ClassRunner.runChild
(BlockJUnit4ClassRunner.java:50)
        at org.junit.runners.ParentRunner$3.run(ParentRunner.java:193)
        at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:52)
        at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:191)
        at org.junit.runners.ParentRunner.access$000(ParentRunner.java:42)
        at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:184)
        at com.mycila.testing.junit.MycilaJunitRunner$2.evaluate
(MycilaJunitRunner.java:66)
        at org.junit.runners.ParentRunner.run(ParentRunner.java:236)
        at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run
(JUnit4TestReference.java:45)
        at org.eclipse.jdt.internal.junit.runner.TestExecution.run
(TestExecution.java:38)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:460)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests
(RemoteTestRunner.java:673)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run
(RemoteTestRunner.java:386)
        at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main
(RemoteTestRunner.java:196) 

Here is an example of the Mycila test class annotated:

@SpringContext (locations = { "classpath:/applicationContext.xml",
    "classpath:/applicationContext-resources.xml",
    "classpath:/applicationContext-dao.xml",
    "classpath:/applicationContext-test.xml",
    "classpath:/applicationContext-service.xml", })
@TestExecutionListeners
( { TransactionalTestExecutionListener.class })
@Transactional
@RunWith (MycilaJunitRunner.class)
public class DataDaoTest
{
    @Autowired
    private ApplicationContext context;

    @Autowired
    private TestContext testContext;

    @Autowired
    private DataDao dao;

    @Test
    public void testSaveData ()
    {
        Data data = new Data();
        dao.saveData(new Long(1413646L), data);
    }

}

In the Google Group conversation thread regarding this issue
(http://groups.google.com/group/mycila/t/a24fc78c0edcd407) I was asked the
rerun the test with Breakpoints on.  Here is what happens:

- TestContextManager.constructor called
- TestContextManager.prepareTestInstance called
- DataDaoTest.testSaveData called
- NullPointerException thrown from the saveData line.

To be able to build the project from anywhere, Google Guice 2 jar should be
placed in an optional system scope and taken from a lib folder in the project.

There are some cases where the order of arguments for JUnit's assertEquals has 
been reversed.

For example:

DefaultDispatchTest.java L82:
 assertEquals(sequence.toString(), "[]");

if this fails, it gives an error "org.junit.ComparisonFailure: 
expected:<[[Hello for a, hello for b1, hello for b2]]> but was:<[[]]>", where 
expected and actual are the other way around.

Makes no difference in the test result, just the message is confusing.

added class ExtendedAssert:

import static com.mycila.testing.util.ExtendedAssert.*

assertSameXml
assertNotEquals
assertEmpty (on string, arrays, collections)
assertBlank
assertThrow(Exception.class).withMessage(...)
URL resource(String classPath)
readString
readByte

I'm having issues running mycila-guice in OSGi container.
Dependency on Jedis is optional in pom.xml:
<dependency>
    <groupId>redis.clients</groupId>
    <artifactId>jedis</artifactId>
    <version>2.0.0</version>
    <scope>compile</scope>
    <optional>true</optional>
</dependency>

but it is not in MANIFEST.MF:
Import-Package: ...,redis.clients.jedis

Please fix this - it should be:
redis.clients.jedis;resolution:=optional

implement java.util.concurrent.BlockingQueue:

QueueManager queueManager = QueueManagers.create(dispatcher)
Queue queue = queueManager.get("my/topic/name")
while(true) queue.take()

The invocation order for @PostConstruct should be from top to bottom, super 
class before sub class. For @PreDestroy it should be the other way around.

Consider this example:

public class SuperClass {
    @PostConstruct
    private void init() {
        // Establish a database connection
    }
    @PreDestroy
    private void destroy() {
        // Release the database connection
    }
}

public class InheritingClass extends SuperClass {
    @PostConstruct
    private void init() {
        // Read something from database using the connection
    }
    @PreDestroy
    private void destroy() {
        // Write possible changed something to database using the connection
    }
}

I have written a failing test case, source for it is here: 
http://pastie.org/2172732


// Tobias

It would be nice have a status for a plugin.

Why? To be able to enable/disable plugins.

Only activate plugins if the dependencies where correctly activated.  

Singletons are destroyed in the order they are bound. They should be destroyed 
in reverse instantiation order.

I've created a failing test case http://pastie.org/2213224

I'm not aware of a quick quick workaround, the implementation would have to 
change quite a bit to fix it.

What do you think of this alternative approach? A TypeListener that looks for 
singletons and puts them in a list, which will naturally be in instantiation 
order and then destroying them by iterating this list backwards. The list would 
need to be synchronized, and its important that its synchronized in concert 
with the synchronization in Guice for creating singletons so not to create a 
race condition into adding to this list. Also it might be necessary to have 
weak references in this list instead of real references.

// Tobias

Add redirect feature: when refactoring, it is useful to redirect all event
traffic from a channel to another without impacting performance.
=> add redirect method to API ?

Will use mycila-jmx, which is under development

I might be completely off here, but it seems to me that when I use 
Jsr250Injector.createInjector() the modules configure() methods are called 
twice.

Also, if I bind singleton like this:

{{{
   bind(Foo.class).toInstance(new Foo());
}}}

then the two instances of Foo are created. If bean is annotated with @Signleton 
it works as expected.

When the same code is run with plain Guice.createInjector it works as expected.

I attached a JUnit test that tests these issues with plain 
Guice.createInjector() and with Jsr250Injector.createInjector().

Br, Jarppe Lansio

Hi,

could you please consider to move the mycila-junit/testing code as well to 
github. Maybe I'm just overlooking it, but I can't seem to see it over at 
github.

Add plugin version support and comparison