Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • Jan 31 2019 15:34
    manovotn commented #1897
  • Jan 31 2019 15:33
    manovotn commented #1899
  • Jan 31 2019 15:33

    manovotn on master

    Upgrade SpotBugs versions, Supp… (compare)

  • Jan 31 2019 15:33
    manovotn closed #1898
  • Jan 31 2019 14:41
    nziakova commented #1899
  • Jan 31 2019 14:40
    nziakova commented #1899
  • Jan 31 2019 14:18
    nziakova commented #1899
  • Jan 31 2019 14:12
    nziakova review_requested #1899
  • Jan 31 2019 14:12
    nziakova opened #1899
  • Jan 31 2019 11:18
    JavaTesting1 commented #64
  • Jan 31 2019 10:20
    manovotn review_requested #1898
  • Jan 31 2019 10:20
    manovotn opened #1898
  • Jan 31 2019 09:14

    manovotn on master

    WELD-2517: Weld SE - fix Securi… (compare)

  • Jan 31 2019 09:14
    manovotn closed #1895
  • Jan 31 2019 09:01
    nziakova edited #1897
  • Jan 31 2019 09:01
    nziakova edited #1897
  • Jan 31 2019 09:00
    nziakova review_requested #1897
  • Jan 31 2019 08:58
    nziakova opened #1897
  • Jan 30 2019 12:51
    manovotn review_requested #1896
  • Jan 30 2019 12:51
    manovotn review_requested #1896
Matej Novotny
@manovotn
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?
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.

Syed Seth
@Sethii_gitlab

Sorry, just wanted to ask a question about Weld and DeltaSpike.
I'm currently trying to use Weld + DeltaSpike + Java SE, in a minimal new project to test and learn them together but can't get away from:

Could not find beans for Type=class org.elypia.deltaspike.ConfigWrapper

I believe I'm following the documentation as closely as I can and have been stuck on this for a few days now. ^-^'
This gist basically summarizes the entire mini-test I was trying to create:
https://gist.github.com/SethiPandi/b6c52bbcf40a48be0449728c074ccb93

Could anyone here potentially point me in the right direction?

Björn Kautler
@Vampire
Is there an easy way to validate whether an annotation is a valid qualifier?
Some utility method that you can give the annotation or the annotation class and that gives you true or false?
I'm using weld-junit so a method in there would be sufficient too for my use-case.
Björn Kautler
@Vampire
Or alternatively a way to get an InjectionPoint from a java.lang.reflect.Field where I then can call getQualifiers()
Björn Kautler
@Vampire
Ah, nevermind, found the proper way to do what I need in weld-junit :-)
dforce
@df0rce_twitter
Hi, I'm using weld-junit5 and have implemented a CDI Extension catching the AfterBeanDiscovery event. Sadly this events never happens in my junit tests. It works during normal runtime. Any advice? Thanks
@EnableAutoWeld is present
E.g. it works when I'm doing this in my junit test: new Weld().initialize()
Matej Novotny
@manovotn
Hello @df0rce_twitter,
I am not sure about your exact deployment, I would have to have a reproducer. But a quick guess is, try registering the extension. If you are using the autoweld, then try looking at @AddExtensions
dforce
@df0rce_twitter
@manovotn thanks! that was it. cheers m8
bingo
@finesoft

I run Weld 3.1.5 (Final) in JDK 11.0.8, some warning occurred when bootstrap see below:

Bootstrap : WELD-ENV-000020: Using jandex for bean discovery
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by org.jboss.weld.util.bytecode.ClassFileUtils$1 (file:/D:/booster/lib/weld-core-impl-3.1.5.Final.jar) to method java.lang.ClassLoader.defineClass(java.lang.String,byte[],int,int)
WARNING: Please consider reporting this to the maintainers of org.jboss.weld.util.bytecode.ClassFileUtils$1
WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
WARNING: All illegal access operations will be denied in a future release

===========JDK===========
BUILD_TYPE="commercial"
IMPLEMENTOR="Oracle Corporation"
IMPLEMENTOR_VERSION="18.9"
JAVA_VERSION="11.0.8"
JAVA_VERSION_DATE="2020-07-14"
MODULES="java.base java.compiler java.datatransfer java.xml java.prefs java.desktop java.instrument java.logging java.management java.security.sasl java.naming java.rmi java.management.rmi java.net.http java.scripting java.security.jgss java.transaction.xa java.sql java.sql.rowset java.xml.crypto java.se java.smartcardio jdk.accessibility jdk.internal.vm.ci jdk.management jdk.unsupported jdk.internal.vm.compiler jdk.aot jdk.internal.jvmstat jdk.attach jdk.charsets jdk.compiler jdk.crypto.ec jdk.crypto.cryptoki jdk.crypto.mscapi jdk.dynalink jdk.internal.ed jdk.editpad jdk.hotspot.agent jdk.httpserver jdk.internal.le jdk.internal.opt jdk.internal.vm.compiler.management jdk.jartool jdk.javadoc jdk.jcmd jdk.management.agent jdk.jconsole jdk.jdeps jdk.jdwp.agent jdk.jdi jdk.jfr jdk.jlink jdk.jshell jdk.jsobject jdk.jstatd jdk.localedata jdk.management.jfr jdk.naming.dns jdk.naming.ldap jdk.naming.rmi jdk.net jdk.pack jdk.rmic jdk.scripting.nashorn jdk.scripting.nashorn.shell jdk.sctp jdk.security.auth jdk.security.jgss jdk.unsupported.desktop jdk.xml.dom jdk.zipfs"
OS_ARCH="x86_64"
OS_NAME="Windows"
SOURCE=".:e5922053ef73 open:caa265ab222a"

Matej Novotny
@manovotn
Hi @finesoft, are you using Weld in SE or EE?
If it is in SE, then this is expected (and to be fixed) warning because of how we define classes (bean proxies) - we do setAccessible() call on class loader. It is harmless warning for now but needs to be fixed for future releases.
If you are in EE, then this shouldn't happen but it is up to integrator (the EE server you are using) to properly implement Weld SPI in order to avoid this. Namely they need to implement ProxyServices.
bingo
@finesoft
@manovotn thank you, I see
otaconix
@otaconix

Good evening. I'm having some trouble understanding the context for what appears to be a limitation imposed by the CDI spec. It's regarding the use of decorators on the return values of producer methods. The current spec (2.0) says, and I quote:

Decorators are not automatically applied to the return value of a producer method or the current value of a producer field.

The word "automatically" appears to be new in the spec for 2.0, but there's no other reference to this limitation. I guess I felt the wording implied a way to programatically force the binding of a decorator to the return value of a producer method, much like with InterceptionFactory for interceptors.
I also see some tickets in Jira that reference this limitation, but most of those have been closed long ago because Weld is built to spec for 1.2. Is there some place where I can read about how this limitation came to be?

Matej Novotny
@manovotn

Good evening
There is no way to bind decorators to producers, neither automatically nor programmatically.

because Weld is built to spec for 1.2

Not sure what do you mean by that? Weld 3 is CDI 2.0 implementation.

If you feel like the wording should be improved, you can file a spec issue against GH repo. The wording was probably just aligned with what interceptors say - e.g. to make sure people understand that by default no interceptors/decorators are applied to your producers.
otaconix
@otaconix

Not sure what do you mean by that? Weld 3 is CDI 2.0 implementation.

Mostly because of WELD-2078. I'm aware Weld 3 aims to be the reference implementation for CDI 2.0. I found some other relevant issues, of which CDI-580 seems to be the one that asks for ability to bind both interceptors and decorators to producer method results. It has been resolved, as it's now possible to bind interceptors to producer method return values, but nothing has been done for decorators...
Anyway, maybe I'm looking for a solution to a problem I don't have: I think I see the value of producer methods (and I'm kinda used to using them extensively in a competing DI framework), but perhaps they're not needed quite as often as I'd imagine them to be.
Still, my question stands: is there any particular reason this limitation exists? When going through Jira and the mailing lists, it feels like the reasoning is circular. Assuming RedHat was indeed leading the specs for CDI and building the reference implementation, I wish there wouldn't be so much pointing at the spec as an argument for why something is done/not done a particular way.

I don't mean this to be in any way hostile, btw. If it sounds nasty, I apologize.

Anyway, thanks @manovotn for your clarification: at least now I know there's no standard way to achieve this according to the spec.

Matej Novotny
@manovotn

... it's now possible to bind interceptors to producer method return values, but nothing has been done for decorators...

Decorators were deliberately skipped, there were some technical issues in implementing it but i don't recall the details from the top of my head. This was decided sometime prior to CDI 2.0. Maybe @mkouba would remember?

I wish there wouldn't be so much pointing at the spec as an argument for why something is done/not done a particular way

It is still a specification and therefore should be led and developed as such in order to keep it a reliable standard. Also, Weld isn't the only implementation; changing anything in the spec requires agreement from all implementors.