weld/user

Welcome to the public discussion channel for Weld - the CDI reference implementation (http://weld.cdi-spec.org/)

Laird Nelson

@ljnelson

(Error code is WELD-001301, and from tracing the source code in ResolvableBuilder I can see that the backing bean store doesn't like my annotation. If I change the array element to a simple String everything is OK.)

Relevant source link: https://github.com/weld/core/blob/cc685fb1929b7c990ae2462dd5f24552949fe306/impl/src/main/java/org/jboss/weld/resolution/ResolvableBuilder.java#L219-L221

Laird Nelson

@ljnelson

Ah, wait, found it; one sentence in this section: https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#qualifier_annotation_members

"If an array-valued or annotation-valued member of a qualifier type is not annotated @Nonbinding, non-portable behavior results." Carry on!

Matej Novotny

@manovotn

Yep, that's exactly the bit :)

René Vangsgaard

@rvangsgaard

I am trying to run tests using https://github.com/guhilling/cdi-test

But I keep getting this error - any idea on where to start?
```java.lang.NoClassDefFoundError: org/jboss/weld/resources/spi/ResourceLoader

at org.apache.deltaspike.cdise.weld.WeldContainerControl.boot(WeldContainerControl.java:71)
at de.hilling.junit.cdi.ContextControlWrapper.<init>(ContextControlWrapper.java:39)
at de.hilling.junit.cdi.ContextControlWrapper.<clinit>(ContextControlWrapper.java:22)
at de.hilling.junit.cdi.CdiTestJunitExtension.<init>(CdiTestJunitExtension.java:24)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
at org.junit.platform.commons.util.ReflectionUtils.newInstance(ReflectionUtils.java:500)
at org.junit.platform.commons.util.ReflectionUtils.newInstance(ReflectionUtils.java:475)
at org.junit.jupiter.engine.extension.MutableExtensionRegistry.registerExtension(MutableExtensionRegistry.java:182)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at org.junit.jupiter.engine.extension.MutableExtensionRegistry.createRegistryFrom(MutableExtensionRegistry.java:123)
at org.junit.jupiter.engine.descriptor.ExtensionUtils.populateNewExtensionRegistryFromExtendWithAnnotation(ExtensionUtils.java:77)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.prepare(ClassBasedTestDescriptor.java:142)
at org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.prepare(ClassBasedTestDescriptor.java:77)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$prepare$1(NodeTestTask.java:107)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.prepare(NodeTestTask.java:107)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:75)
at java.util.ArrayList.forEach(ArrayList.java:1257)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:38)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$5(NodeTestTask.java:139)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$7(NodeTestTask.java:125)
at org.junit.platform.engine.support.hierarchical.Node.around(Node.java:135)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:123)
at org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:122)
at org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:80)
at org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.submit(SameThreadHierarchicalTestExecutorService.java:32)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestExecutor.execute(HierarchicalTestExecutor.java:57)
at org.junit.platform.engine.support.hierarchical.HierarchicalTestEngine.execute(HierarchicalTestEngine.java:51)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:229)
at org.junit.platform.launcher.core.DefaultLauncher.lambda$execute$6(DefaultLauncher.java:197)
at org.junit.platform.launcher.core.DefaultLauncher.withInterceptedStreams(DefaultLauncher.java:211)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:191)
at org.junit.platform.launcher.core.DefaultLauncher.execute(DefaultLauncher.java:128)
at com.intellij.junit5.JUnit5IdeaTestRunner.startRunnerWithArgs(JUnit5IdeaTestRunner.java:69)
at com.intellij.rt.junit.IdeaTestRunner$Repeater.startRunnerWithArgs

where can I find the ResourceLoader dependency?

Matej Novotny

@manovotn

@rvangsgaard, Hello, I can see you are running some DS there, are you sure you included necessary Weld dependencies?

ResourceLoader is under Weld API - https://github.com/weld/api/blob/master/weld-spi/src/main/java/org/jboss/weld/resources/spi/ResourceLoader.java

This is normally brought in by Weld Core, or shaded SE jar (not sure what are you using there); double check what JARs get into your final deployments and if you aren't making any exclusions in maven for instance

René Vangsgaard

@rvangsgaard

I managed to include the weld-spi - now I get this error:

java.lang.NoClassDefFoundError: javax/el/ExpressionFactory

    at org.jboss.weld.bootstrap.WeldStartup.startContainer(WeldStartup.java:212)

I am trying to add integration testing to an existing Wildfly app - what is the recommended approach?

I guess this is the relevant Maven snippet:

        <dependency>
            <groupId>de.hilling.junit.cdi</groupId>
            <artifactId>cdi-test-core</artifactId>
            <version>2.3.0</version>
        </dependency>
        <dependency>
            <groupId>org.jboss.weld.se</groupId>
            <artifactId>weld-se-core</artifactId>
            <version>2.3.5.Final</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.weld</groupId>
            <artifactId>weld-spi</artifactId>
            <version>2.3.SP2</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.apache.deltaspike.cdictrl</groupId>
            <artifactId>deltaspike-cdictrl-weld</artifactId>
            <version>1.9.1</version>
            <scope>test</scope>
        </dependency>

Matej Novotny

@manovotn

Hmm, something seems pretty off with the dependencies as most of those APIs you are missing should be pulled in as dependencies of Weld itself

try replacing weld-se-core (and SPI) with weld-se-shaded

For integration testing on WFLY I would recommend using arquillian instead. The setup you are trying looks more like a a junit testing to me

also for junit testing I would recommend you drop delta spike and take a look at weld-junit (https://github.com/weld/weld-junit)

it is basically a Junit5 extension (or a junit4 rule if you use that) that allows you to control the container and do some testing

but again, I recommend that for junit testing and for integration, arquillian

you can take a look at weld tests here, most of them are runnable in container (actually on WFLY) and use arquillian

René Vangsgaard

@rvangsgaard

thank you! I will have a look at the links

Laird Nelson

@ljnelson

If I'm in an observer method, and I want to invoke a business method elsewhere in the same class that is bound to an interceptor, is there a reason I can't use the this object in such a case? After all, Weld invoked the observer method, so presumably this is already a proxy? Nevertheless, I'm noticing that if I invoke the business method using this interception does not occur. (I seem to recall this is possible in OpenWebBeans but can't remember for sure.)

Laird Nelson

@ljnelson

For now, I'm just adding an instance of my class as a parameter in the observer method, and naming the parameter "self", and making sure that I invoke business methods on it. Then interception happens just fine.

Matej Novotny

@manovotn

Hi @ljnelson,
like you discovered, executing the method directly from the OM does not trigger interception and this is intended.
Basically, if you do it via this.myMethod(), it won't be considered a business method invocation (as you aren't going through a contextual reference) and as such it won't be intercepted.
This part of spec talks about it, although I do recall some discussions about this and it might be the case that OWB interpreted the spec differently.

The solution you used (e.g. injecting the proxy and invoking method on it) is correct - that way you always invoke the method via proxy and it will be considered business method invocation.

Laird Nelson

@ljnelson

Thanks. Yes, if I remember right OWB allows usage of the this object in this case. I'll continue to use self-injection.

Björn Kautler

@Vampire

Can you exclude classes in beans.xml based on their name as pattern, like *Fooor **.*Foo or net.kautler.command.*Foo* or similar, or can you only say fully-qualified class, package and package with "sub"-packages?

Laird Nelson

@ljnelson

Full details here: https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#exclude_filters

Björn Kautler

@Vampire

I have first read that and then I asked

How about a simple answer to a simple question?

Matej Novotny

@manovotn

What CDI allows in that regard is limited like you discovered.
Weld itself allows for more variety in this regard, so long as you follow this schema.

I think that's what you might be after

Björn Kautler

@Vampire

Thanks Matej, actually this is for my production artefact, so I probably better stay with what CDI allows

Björn Kautler

@Vampire

Given this:

parameterParsers.select(new TypeLiteral<ParameterConverter<? super Message, ?>>() { }, new ParameterType.Literal("number")).get()

Can I do the type literal somehow dynamic?
Specifically Message I get dynamically as a parameter of the method using that.
I can maybe build a registry like Map<Class<?>, TypeLiteral<?> for all possible types and then get it from there,
but if there is a more elegant and dynamic way, I'd prefer that I guess.

Matej Novotny

@manovotn

Not sure I can see how CDI/Weld can aid you with this. Sounds like you need either the registry or have a parameterized method param (T extends Message) that will carry over the type for you?

Björn Kautler

@Vampire

Do you mean like this?

public <M> ... getParsedTypedParameters(M message, ...) {
    ...
    parameterConverters.select(
            (TypeLiteral<ParameterConverter<?, ?>>) (Object) new TypeLiteral<ParameterConverter<? super M, ?>>() { },
            new ParameterType.Literal(type));
    ...
}

I guess not, because that does not work due to

org.jboss.weld.exceptions.IllegalArgumentException: WELD-000623: Unknown type null.
    at org.jboss.weld.resolution.CovariantTypes.isAssignableFrom(CovariantTypes.java:76) ~[weld-core-impl-3.1.2.Final.jar:3.1.2.Final]

Matej Novotny

@manovotn

Uff, that looks very confusing. Why do you cast the created TypeLiteral to Object and to another TypeLiteral with wildcards only?

I guess I would need a more complete example to see what's going on here. However, like I said, I don't think CDI can help you here to make it any more "elegant".

Matej Novotny

@manovotn

Also, I am not even sure you can make TypeLiteral dynamic, after all it is a Literal so I would expect an immutable state. CDI spec doesn't seem to mention it but the examples there don't have it. Neither do TCKs from a quick scan that I did.

Björn Kautler

@Vampire

The relevant code is not something I can push right now, it is still heavily wip and playing around to find the best way.

The cast to Object is necessary to fool the compiler as Weld is more intelligent / flexible than the compiler.
What I mean is,

parameterConverters is defined as @Inject @Any private volatile Instance<ParameterConverter<?, ?>> parameterConverters;

if I use new TypeLiteral<ParameterConverter<? super Message, ?>>() { } compiler says error: incompatible types: inference variable U has incompatible equality constraints ParameterConverter<?,?>,ParameterConverter<? super Message,?>
if I use (TypeLiteral<ParameterConverter<?, ?>>) new TypeLiteral<ParameterConverter<? super Message, ?>>() { } compiler says error: incompatible types: <anonymous TypeLiteral<ParameterConverter<? super Message,?>>> cannot be converted to TypeLiteral<ParameterConverter<?,?>>
if I use (TypeLiteral<ParameterConverter<?, ?>>) (Object) new TypeLiteral<ParameterConverter<? super Message, ?>>() { } is works as expected for that class Message
if I use (TypeLiteral<ParameterConverter<?, ?>>) (Object) new TypeLiteral<ParameterConverter<? super M, ?>>() { } with signature as shown above, I get at runtime the Unknown type null. exception shown above

So I guess I'm really bound to the Class -> TypeLiteral registry tactic.

Björn Kautler

@Vampire

Totally different question, are there happens-before guarantees regarding injection and post-construct methods in CDI?

What I mean is, if you traditionally instantiate a class and then set fields, for example using setters, you have to make sure to do it in a thread-safe way, either by thread-confinement, synchronisation or volatile.
I'm using CDI in a highly multi-threaded environment.
So if I inject beans by annotating the fields or setter methods and there-in set some fields or annotating some fields or methods and then use a post-construct method to set some fields.

Do I have to care for thread-safety, like marking the fields volatile or using AtomicReferences or synchronizing the access or are there some happens-before guarantees that make sure that injections and post-construction actions are completely done before exposing a bean instance to other threads?

Matej Novotny

@manovotn

Hmm, I think you should be mostly safe as the bean storage where all the contextual instances are held implement some form of locking (and bean storage is where you look for a CDI bean and if it isn't there, you create it). You can check the usage of LockedBean throughout Weld - https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/contexts/beanstore/LockedBean.java
That is, all bound contexts do this, under certain conditions you might encounter unbound contexts (for instance manually activated req. context) where this wouldn't hold true. But that's not what you should usually do anyway.

Your question is very general though, so hard to say what you will actually encounter :)

Björn Kautler

@Vampire

But is this a WELD implementation detail, or somehow mandated by the CDI spec?
I'm developing a CDI-based library right now, so theoretically it could be run with a different CDI implementation.

Björn Kautler

@Vampire

And additionally another question, I just managed to produce a stack overflow error.

given interfaces A, B and C, several ApplicationScoped beans of A and B and one bean for C
one of the A beans gets Instance<B> injected into an @Inject method
and there actually calls some method on the beans directly to derive some data needed later
one of the B beans gets C injected into the constructor and calls a method on it directly
the C bean gets Instance<A> injected into an @Inject method
and there actually calls some method on the beans directly to derive some data needed later

This results in a stackoverflow error due to the hen-and-egg problem that is not solved by the proxies in this case,
as the real instances are immediately needed in the @Inject methods.

If I do not call the method on C in the B constructor but call the method later in the program, no stack overflow error happens and everything is working fine.

Now my question is, how to properly solve this.
Do I need to use lazy initialization instead of the eager calculation of the derived data?
Or is there some better tactic available?
Using @PostConstruct in A and Cto derive the data is not sufficient and B is code coming from the user of my library, so it should work no matter how it is used in B.

Matej Novotny

@manovotn

But is this a WELD implementation detail, or somehow mandated by the CDI spec?

That's Weld thing, I am not aware of spec enforcing that.

Now my question is, how to properly solve this.

Honestly, if you want to solve it properly, then redesign the code to get rid of the circular dependency ;-)

Other than that, avoid calling the bean so early on.
If I recall correctly then:

one of the B beans gets C injected into the constructor and calls a method on it directly

is the problematic part that even proxies cannot workaround, at least I am not aware of to do that.

Where communities thrive

People

Repo info

Activity