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
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.

Ghost
@ghost~5dad0338d73408ce4fce776d

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.

yoginivpatil
@yoginivpatil
Hello all, I am trying to install gazelle security suite. But facing issue in deployment- startexception in service jboss.deployment.unit."gazelle-gss.ear".weldstartservice: failed to start service caused by org.jboss.weld.exceptions.DefinitionException: WELD-000071: Managed bean with a parameterized bean class must be @Dependent: class org.jboss.seam.resteasy.ResourceHome ..
Installation steps: https://gazelle.ihe.net/gazelle-documentation/Gazelle-Security-Suite/installation.html .. Any help on this will be greatly appreciated
Matej Novotny
@manovotn
Hi, sorry I am not familiar with gazelle.
However, the error seems to be with org.jboss.seam.resteasy.ResourceHome and that is fishy. Seam is dead for a loong time now and was essentially replaced by CDI (and Weld), you shouldn't be using that class. Try to see who/what is bringing in that dependency.
Varsha Chahal
@VarshaChahal
Hi everyone, new to the chat group. I was wondering if anyone else has seen a memory leak relating to BeanManagerImpl when analysing heap dumps. Weld version: 2.3.0.Final.
Matej Novotny
@manovotn
Hello @VarshaChahal
that is a pretty ancient version of Weld. I cannot tell you from the top of my head whether there was a leak or not (it's like 5y old release?) but I can tell you for sure that the version won't be getting updates ;-)
So you can try upgrading to newer version to see if it resolves your problem.
Other common source of user error causing leaks is using Instance<T> to resolve dependent beans and not destryong them properly - I am just guessing here but maybe you're doing that?
Varsha Chahal
@VarshaChahal
Hi @manovotn, thanks for the information. I totally understand the issues due to the older version. On analysis, mine was found to be more specific to Hibernate Validator and as usual due to an older version :P
and yes, coming across the leak with Instance<T> too.
Matej Novotny
@manovotn

@VarshaChahal Ok, so the trick with Instance<T> is that any dependent scoped bean resolved via programmatic lookup has its lifecycle bound to the Instance(instead of bean injection it which is what happens when you @Inject it normally) which won't go away until you shut down Weld. That means you need to call Instance.destroy()for each such bean when you no longer need it. Or implement your own caching to prevent repetitive resolution of such bean.
Alternatively, you could also make the resolved bean application scoped (or any other scope) because then it as a lifecycle of that given scope and will be destroyed whenever the given context is destroyed.

Then spec mentions this behavior here.
Or you can just check the API javadoc here.

Varsha Chahal
@VarshaChahal
thanks again @manovotn :)
bingo
@finesoft
Does Weld have plans to support Graal VM?
Matej Novotny
@manovotn
Hi @finesoft,
no we don't plan to support Graal VM or build time approach; Weld is to stay a runtime implementation. CDI as it is now (2.0/3.0 is not really a good fit for build time approach anyway and there is work being done to amend that (aka CDI Lite).
There are also other projects springing up that offer CDI behavior in build time environment with Graal VM - Quarkus being a good CDI solution on that forefront if you ask me.
bingo
@finesoft
Thanks @manovotn
duschata
@duschata:matrix.org
[m]

Hello All,

In the documentation is written: Portable extensions are encouraged to fire an event with qualifier @Initialized(X.class) when a custom context is initialized ...

... but how (and where) must I fire this event in MyCustomScopeExtension?

Matej Novotny
@manovotn
Hi @duschata:matrix.org
those events should be fired based on your context activation/deactivation which fully depends on how your context works. It doesn't need to be fired from your extension (for some it may make sense, for other it might not); you just need to fire the @Initialized whenever you activate the context and then the other two when you are about to destroy it and have destroyed it.
3 replies
Hantsy Bai
@hantsy

Hi everybody,

Currently, I am working on a boilerplate project for servlet 5.0,

https://github.com/hantsy/jakartaee9-servlet-starter-boilerplate

Firstly I want to run the application via cargo maven plugin(tomcat) and jetty maven plugin. But I encountered an issue with configuring Jetty maven plugin.

When running the following command and failed.

mvn clean package jetty:run-war -Pjetty

Apr 03, 2021 10:04:58 PM org.jboss.weld.environment.servlet.WeldServletLifecycle initialize
INFO: WELD-ENV-001001: No supported servlet container detected, CDI injection will NOT be available in Servlets, Filters or Listeners
[WARNING] Failed startup of context o.e.j.m.p.MavenWebAppContext@c79780{/jakartaee9-servlet-starter-boilerplate,[file:///D:/hantsylabs/jakartaee9-servlet-starter-boilerplate/target/jak
artaee9-servlet-starter-boilerplate/, jar:file:///D:/hantsylabs/jakartaee9-servlet-starter-boilerplate/target/jakartaee9-servlet-starter-boilerplate/WEB-INF/lib/jakarta.faces-3.0.0.jar
!/META-INF/resources],UNAVAILABLE}{D:\hantsylabs\jakartaee9-servlet-starter-boilerplate\target\jakartaee9-servlet-starter-boilerplate.war}
java.lang.LinkageError: loader constraint violation: when resolving interface method 'void jakarta.servlet.jsp.JspApplicationContext.addELResolver(jakarta.el.ELResolver)' the class loa
der org.eclipse.jetty.webapp.WebAppClassLoader @51c6e775 of the current class, org/jboss/weld/environment/servlet/WeldServletLifecycle, and the class loader org.codehaus.plexus.classwo
rlds.realm.ClassRealm @cef885d for the method's defining class, jakarta/servlet/jsp/JspApplicationContext, have different Class objects for the type jakarta/el/ELResolver used in the s
ignature (org.jboss.weld.environment.servlet.WeldServletLifecycle is in unnamed module of loader org.eclipse.jetty.webapp.WebAppClassLoader @51c6e775, parent loader org.codehaus.plexus
.classworlds.realm.ClassRealm @cef885d; jakarta.servlet.jsp.JspApplicationContext is in unnamed module of loader org.codehaus.plexus.classworlds.realm.ClassRealm @cef885d, parent loade
r 'bootstrap')

I have read the weld doc, and jetty doc, I can not find how to fix it.

Matej Novotny
@manovotn
@hantsy I cannot speak for whether Weld 4 (EE 9) works with Jetty or not. We currently lack an Arq. container to test it with (see arquillian/arquillian-container-jetty#43 issue) as there were changes in never version so there might very well be bugs - we haven't done any testing on Jetty for Weld 4 (servlets were tested mainly on Tomcat and partially on Undertow).
That being said, if you have the time and will to figure it out, PRs are surely welcome ;-)
Hantsy Bai
@hantsy
@manovotn Currently just started to run the application via jetty maven plugin, there are some stoppers I encountered. And the Jetty APIs seems changed frequently, there some config in Weld4.0 is not worked in Jetty 11.
Matej Novotny
@manovotn

And the Jetty APIs seems changed frequently...

Yeah, that's unfortunately very common. If you figure out what it is, we can sure adjust relevant parts of Weld.