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

Yeah, figured as much by now, thanks.
Just wanted to make sure by expert statement. :-)

Hm, I am not even sure this use case is intended to be fair. I can't find a single test that would use this

Yeah, doesn't make much sense imho, that's why I said it should probably be prevented, but that would be a breaking change actually in case someone actually used it.
In weld-spock I prevent it right away.

It's btw. already finished, just need to do the readme, the rest is ready to go already :-)
Matej Novotny
@manovotn

but that would be a breaking change actually in case someone actually used it.

We could probably prevent it anyway, the result of this could have been pretty unpredictable already. I think we just never imagined someone would attempt this when adding the annotation approach.

Is the parallel execution a requirement for you? Or just nice to have? Frankly speaking, it can be difficult for users because lots of people use some form of current() method invocation here and there but I can see why you'd want it

Björn Kautler
@Vampire

We could probably prevent it anyway, the result of this could have been pretty unpredictable already. I think we just never imagined someone would attempt this when adding the annotation approach.

Well, it actually is not unpredictable, if a valid @WeldSetup is found, it is used and all other information or annotation is completely ignored.
Whether you wan to prevent it as it is unintuitive is up to you, I just wondered about it when reading the code to adapt it for weld-spock.

Is the parallel execution a requirement for you? Or just nice to have? Frankly speaking, it can be difficult for users because lots of people use some form of current() method invocation here and there but I can see why you'd want it

Mainly nice to have. Being able to run tests in parallel speeds things up. And both, Jupiter and Spock 2 support it.
So it would of course be amazing if the whole thing would support parallel execution.
But if not, it is probably also acceptable that specific aspects are not parallelizable.
You can use resource locks for those cases.
I made the weld-spock tests parallel and for the few tests where it is relevant, I required the global lock so that the test is run in isolation and it works fine.
I also enabled the parallel execution for the weld-junit5 tests and also there just had to make the few relevant tests isolated.

If people use current(), well, they will simply not be able to use parallel tests for those tests.

Matej Novotny
@manovotn
Ok, if you don't mind, create a Weld-junit issue for it. Even if we don't resolve it now, it doesn't hurt to have it tracked.
But since it is a singular place where we actually use it, it shouldn't be too difficult to replace it.
Björn Kautler
@Vampire
So, PR for Spock is sent @manovotn, I hope we can soon get a 3.1 with it included. :-)
Björn Kautler
@Vampire
And here the issue for parallel execution: weld/weld-junit#131
Mayank Kunwar
@mayankkunwar

Hi Guys,
I wanted to check if the weld standalone still supports arquillian, as when I tried to execute on JDK 17 getting some error as below [3]. We are using arquillian-weld-ee-embedded-1.1 [1] and tried to run [2] test class. The test works fine when executed on JDK8 and JDK11

[1] https://github.com/jbosstm/narayana/blob/master/compensations/pom.xml#L426
[2] https://github.com/jbosstm/narayana/blob/master/compensations/src/test/java/org/jboss/narayana/compensations/integration/beanManager/BeanManagerUtilTestWeld.java
[3]

-------------------------------------------------------------------------------
Test set: org.jboss.narayana.compensations.integration.beanManager.BeanManagerUtilTestWeld
-------------------------------------------------------------------------------
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.767 s <<< FAILURE! - in org.jboss.narayana.compensations.integration.beanManager.BeanManagerUtilTestWeld
org.jboss.narayana.compensations.integration.beanManager.BeanManagerUtilTestWeld  Time elapsed: 0.766 s  <<< ERROR!
java.lang.reflect.GenericSignatureFormatError: 
Signature Parse error: Expected Field Type Signature
    Remaining input: org.jboss.narayana.compensations.api.CompensationTransactionType
    at java.base/sun.reflect.generics.parser.SignatureParser.error(SignatureParser.java:124)
    at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:291)
    at java.base/sun.reflect.generics.parser.SignatureParser.parseFieldTypeSignature(SignatureParser.java:277)
    at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeSignature(SignatureParser.java:469)
    at java.base/sun.reflect.generics.parser.SignatureParser.parseTypeSig(SignatureParser.java:188)
    at java.base/sun.reflect.annotation.AnnotationParser.parseSig(AnnotationParser.java:438)
    at java.base/sun.reflect.annotation.AnnotationParser.parseEnumValue(AnnotationParser.java:473)
    at java.base/sun.reflect.annotation.AnnotationParser.parseMemberValue(AnnotationParser.java:344)
    at java.base/sun.reflect.annotation.AnnotationParser.parseAnnotation2(AnnotationParser.java:282)
    at java.base/sun.reflect.annotation.AnnotationParser.parseAnnotations2(AnnotationParser.java:121)
    at java.base/sun.reflect.annotation.AnnotationParser.parseAnnotations(AnnotationParser.java:73)
    at java.base/java.lang.reflect.Executable.declaredAnnotations(Executable.java:625)
    at java.base/java.lang.reflect.Executable.declaredAnnotations(Executable.java:623)
    at java.base/java.lang.reflect.Executable.getDeclaredAnnotations(Executable.java:611)
    at java.base/java.lang.reflect.Method.getDeclaredAnnotations(Method.java:747)
    at java.base/java.lang.reflect.AccessibleObject.getAnnotations(AccessibleObject.java:549)
    at org.jboss.weld.resources.HotspotReflectionCache.internalGetAnnotations(HotspotReflectionCache.java:58)
    at org.jboss.weld.resources.DefaultReflectionCache$1.apply(DefaultReflectionCache.java:82)
    at org.jboss.weld.resources.DefaultReflectionCache$1.apply(DefaultReflectionCache.java:79)
    at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache$1.apply(ReentrantMapBackedComputingCache.java:55)
    at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache$1.apply(ReentrantMapBackedComputingCache.java:51)
    at org.jboss.weld.util.cache.ReentrantMapBackedComputingCache.getValue(ReentrantMapBackedComputingCache.java:64)
    at org.jboss.weld.resources.DefaultReflectionCache.getAnnotationSet(DefaultReflectionCache.java:152)
    at org.jboss.weld.annotated.slim.backed.BackedAnnotated.getAnnotations(BackedAnnotated.java:36)
    at org.jboss.weld.annotated.enhanced.jlr.EnhancedAnnotatedMethodImpl.of(EnhancedAnnotatedMethodImpl.java:62)
    at org.jboss.weld.annotated.enhanced.jlr.EnhancedAnnotatedTypeImpl.<init>(EnhancedAnnotatedTypeImpl.java:227)
    at org.jboss.weld.annotated.enhanced.jlr.EnhancedAnnotatedTypeImpl.of(EnhancedAnnotatedTypeImpl.java:136)
    at org.jboss.weld.resources.ClassTransformer$TransformSlimAnnotatedTypeToEnhancedAnnotatedType.apply(ClassTransformer.java:90)
Matej Novotny
@manovotn

Hi @mayankkunwar
Weld does run on Arq with JDK 17, that's what our CI does (for Weld 5 and Weld 4).
However, the Arq. adapter you linked (https://github.com/arquillian/arquillian-weld-embedded-1.1) has been obsolete since 2017.

I don't know that one and its capabilities but what we're using can be seen here - https://github.com/arquillian/arquillian-container-weld

Mayank Kunwar
@mayankkunwar
Thanks for the info @manovotn
Björn Kautler
@Vampire

Can a mock bean not be a producer like

MockBean.builder()
        .scope(ApplicationScoped)
        .creating(new Object() {
            @Produces
            @Internal
            Logger getLogger(InjectionPoint injectionPoint) {
                loggerContext.getLogger(injectionPoint.member.declaringClass)
            }
        })
        .build()

?
Is there a proper way to do that?

Matej Novotny
@manovotn

A MockBean is just a custom Bean<?> implementation that will then be registered via an extension for you.
And you couldn't do that in an extension either.

If you want to have a bean that has a producer in it, you will need to have a standard class-based bean.
You could perhaps try to create a synthetic AnnotatedTypeand register that but I am not even sure that would work.

Björn Kautler
@Vampire
If there is another way, tell me. I'm not bound to it being a producer. I just need a way to provide beans for injection points that depend on the injection point instance and the logic has to involve a field of the test class (loggerContext).
In worst case I guess I'm have to make a bean class with the logic and inject the field as mock bean.
Matej Novotny
@manovotn
Why does it need to be a MockBean? Couldn't you have an ordinary producer method directly on the test class?
You could still access loggerContext from there and the test class is automatically a bean (at least in Jupiter module)
I am not sure what exactly is loggerContext but you are basically doing what this sample shows - https://jakarta.ee/specifications/cdi/2.0/cdi-spec-2.0.html#_injection_point_metadata_example
Björn Kautler
@Vampire
Yep, did it like that now, just with a dedicated class. That worked. Unfortunately then in realized it does not sufficiently help for what I needed. :-D
Matej Novotny
@manovotn
I guess I am missing more information about what you actually want to achieve to help you further :)
Björn Kautler
@Vampire
Nothing you can do anymore besides reviewing the PR, thanks. :-D
CDI-wise I solved it, I just realized it will not help me sufficiently to do it that way.
Matej Novotny
@manovotn
Alright
I am working through the PR now
Björn Kautler
@Vampire
♥️
Björn Kautler
@Vampire
@manovotn you have seen that the PR is ready for re-review, right? :-)
Matej Novotny
@manovotn
Yes I did but I was away for a bit and now my focus is slightly elsewhere. I'll try to get to it by the end of this week.
N.S.KARTHIK
@nskarthik_k_twitter
I need some examples of CDI-2 on TOMCAT-10+ using JSP ( Not JSF ), If any please provide links/git....
Matej Novotny
@manovotn
@Vampire both weld-junit (actually, weld-testing) versions are now released and available in central. Thanks for contributing and happy testing :)
Björn Kautler
@Vampire
Great. 🎉 👍👌
asbachb
@asbachb:matrix.org
[m]
From my understanding the test package should be scanned for beans. But when I run my test case it does not find C: https://github.com/asbachb/junkyard/blob/main/src/test/java/it/impl/junkyard/AIT.java
asbachb
@asbachb:matrix.org
[m]
In the end I want that CDI works as outside the test method but with replacing some classes with test implementations.
Björn Kautler
@Vampire
C is not a bean, just a POJO, isn't it?
Matej Novotny
@manovotn
Hello @asbachb:matrix.org
Try putting some bean defining annotation onto C - for instance @Dependent

In the end I want that CDI works as outside the test method but with replacing some classes with test implementations.

if you want a test-only replacements for standard app beans, you might want to look into CDI Alternative

asbachb
@asbachb:matrix.org
[m]
@Vampire: Yea it's just a Pojo.
@manovotn: I'm trying to use Alternative but as part of test code and struggle how to add it to the weld environment.
Matej Novotny
@manovotn
@asbachb:matrix.org note that you also need to enable the alternative - easiest way is to add a @Priority(x) annotation to the class which is also @Alternative.
This is called 'global enablement' but since the alternative resides in test code, this should be a way to go for you
Björn Kautler
@Vampire
What was the proper way to programmatically add multiple beans?
Observing AfterBeanDiscovery in a CDI extension and using addBean there?
Matej Novotny
@manovotn
@Vampire there are several options depending on whether you need this as a synth bean or just need to add an annotated type to scan.
You can do BeforeBeanDiscovery .addAnnotatedType() to add an AT and CDI will pick it up from there - you can use BeanManager to generate AT from a class if it is a class based bean that you need to pick up or use the configurator.
Or, like you said, you can use AfterBeanDiscovery to add a completely synthetic bean via configurator.
AfterBeanDiscovery is fine and probably easier to use (just my guess since I know both well :))
Björn Kautler
@Vampire
The current use-case is multiple beans from the same class. So I think BeforeBeanDiscovery is not an option because I see no way to add multiple beans of the same type, just to register the type. Actually optimally would be to take all properties from the annotated type, but being able to just have a custom creator so that a constructor with some parameter can be called, or some field set to a specific value after creation.
Matej Novotny
@manovotn

Actually optimally would be to take all properties from the annotated type

You can do that, see https://github.com/jakartaee/cdi/blob/master/api/src/main/java/jakarta/enterprise/inject/spi/configurator/BeanConfigurator.java#L158-L173

@Vampire ^^
Björn Kautler
@Vampire

Ah, right, forgot the read, thanks @manovotn.
So like

afterBeanDiscovery
        .addBean()
        .read(afterBeanDiscovery.getAnnotatedType(clazz, clazz.name + "_variantA"))
        .createWith(__ -> new MyBean("my argument A"));

right?

Matej Novotny
@manovotn

There is no afterBeanDiscovery.getAnnotatedType(clazz, clazz.name + "_variantA") method.
Use BeanManager#createAnnotatedType()

Otherwise, you are correct

Björn Kautler
@Vampire
@manovotn ?
Dzek
@Dzek
Is it possible to propagate a conversation scoped bean's conversation manually via a servlet filter by appending or adding the cid param or is the only way to accomplish propagation to use the cid url param on the initial request?
Matej Novotny
@manovotn
Björn, you are right, I probably misread your code there. getAT works as does createAT.
Matej Novotny
@manovotn
@Dzek you need to propagate the cid parameter for CDI to know if and what conversation should be activated. How you do that is up to you; I'd assume appending it is just fine. Are you seeing any issues with that?
See this bit - https://docs.jboss.org/weld/reference/latest/en-US/html_single/#_conversation_propagation
4 replies