Hi Morten,

I like your suggestion to use Instance<Runnable>, and will likely end up taking that on board as an additional barrier against users experiencing this exception. However I first want to understand why you are experiencing this exception at all.

In my experience, since RunnableDecorator is a decorator, then unless it is enabled as a decorator in beans.xml it shouldn't be a target for injection at all, unless you are instantiating it some other way. I've just done a test which demonstrates this, which I'll attach. Try running the project (most easily done in NetBeans since that's where it was created, but also possible from the command line with some maven building and manual classpath wizardry) with the decorator enabled versus commented out.

I don't suppose you have the decorator enabled in your beans.xml?

Are you causing RunnableDecorator to be instantiated any other way? Injecting it somewhere perhaps?

Otherwise, what am I missing?

Thanks for your feedback.

Demonstrates that without the decorator enabled, the unsatisfied dependency exception does not occur.

I did not have the decorator enabled in my beans.xml and I do use RunnableDecorator at all but I am using a lot of 3rd party jars and one of them might do something that causes this (see the recently logged bug about performance that I created - it lists the jars I use under java SE and it is mostly the same I use under java EE). Note also, that this bug only happens under glassfish in a WAR - it does not happen when I use Weld in a Java SE app.

So I am sorry, I have no more idea then you why this happen but I am sure that you DO need to use Instance<Runnable> because even if you have the decorator enabled in beans.xml you should be able to handle the case where there are 0 Runnables.

correction: I did not have the decorator enabled in my beans.xml and I do NOT use RunnableDecorator at all ...

Hi,

+1 on this issue. In my case this happens when I run a SE environment and also do have other Weld JARs on the classpath.

It would come handy to have this working without the workaround. In my case I need to be able to run my application both inside a container and parts of it outside, in a SE environment. Arguably I could separate the JARs / define fitting classpaths, nonetheless a fix (or at least a notice in the doc saying that the weld-se.jar can't be used in combination with other Weld JARs on the classpath) would be nice to have.

Thanks,

Manuel

>> Demonstrates that without the decorator enabled, the unsatisfied dependency exception does not occur.

With this, I don't see this as an issue.
Can it be closed?

Unless someone can come up with non-enabled RunnableDecorator test still resulting in error.