From ooo_saturn7 at mail.ru  Tue Mar  6 06:10:51 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Tue, 06 Mar 2018 14:10:51 +0300
Subject: [weld-dev] =?utf-8?q?How_to_inject_in_servlet_CDI_beans_from_war/?=
 =?utf-8?q?lib=3F?=
Message-ID: <1520334651.477448427@f481.i.mail.ru>

Hi all.

Could anyone help me with the following problem. I have a war that contains one servlet.
In WEB-INF of the war I have beans.xml. Besides, inside this war, in lib folder I have
a jar archive. Jar archive has beans.xml in META-INF.

I use GlassFish 5 that uses Weld. When I want to inject in servlet CDI bean from jar,
container doesn't inject anything - field is null, and no errors I get. However, when
I inject in servlet EJB bean everything works fine.

How to fix it?

-- 
Best regards, Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180306/0ae68265/attachment.html 

From manovotn at redhat.com  Tue Mar  6 07:02:20 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 6 Mar 2018 07:02:20 -0500 (EST)
Subject: [weld-dev] How to inject in servlet CDI beans from war/lib?
In-Reply-To: <1520334651.477448427@f481.i.mail.ru>
References: <1520334651.477448427@f481.i.mail.ru>
Message-ID: <359593343.8227971.1520337740082.JavaMail.zimbra@redhat.com>

Hi Alex,

could you share your code?
Or, ideally, a reproducer?

Your scenario sounds valid to me and so does your deployment.
But I suppose there is a catch somewhere which I cannot glance from just the description.

Regards,
Matej

----- Original Message -----
> From: "Alex Sviridov" <ooo_saturn7 at mail.ru>
> To: "weld-dev" <weld-dev at lists.jboss.org>
> Sent: Tuesday, March 6, 2018 12:10:51 PM
> Subject: [weld-dev] How to inject in servlet CDI beans from war/lib?
> 
> Hi all.
> 
> Could anyone help me with the following problem. I have a war that contains
> one servlet.
> In WEB-INF of the war I have beans.xml. Besides, inside this war, in lib
> folder I have
> a jar archive. Jar archive has beans.xml in META-INF.
> 
> I use GlassFish 5 that uses Weld. When I want to inject in servlet CDI bean
> from jar,
> container doesn't inject anything - field is null, and no errors I get.
> However, when
> I inject in servlet EJB bean everything works fine.
> 
> How to fix it?
> 
> --
> Best regards, Alex Sviridov
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

From EMIJIANG at uk.ibm.com  Wed Mar  7 06:22:44 2018
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Wed, 7 Mar 2018 11:22:44 +0000
Subject: [weld-dev] https://issues.jboss.org/browse/WELD-1130
Message-ID: <OFE9C45F8A.92202C8C-ON00258249.003E44BD-80258249.003E817C@notes.na.collabserv.com>

This issue https://issues.jboss.org/browse/WELD-1130 has been around for a 
while. Can some investigation be done? We are happy to assist with testing 
a patch if needed.

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI & MicroProfile Development Lead
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180307/68481080/attachment.html 

From mkouba at redhat.com  Wed Mar  7 08:41:38 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Wed, 7 Mar 2018 14:41:38 +0100
Subject: [weld-dev] https://issues.jboss.org/browse/WELD-1130
In-Reply-To: <OFE9C45F8A.92202C8C-ON00258249.003E44BD-80258249.003E817C@notes.na.collabserv.com>
References: <OFE9C45F8A.92202C8C-ON00258249.003E44BD-80258249.003E817C@notes.na.collabserv.com>
Message-ID: <eea5127f-071c-5090-67b7-fa6a842d2065@redhat.com>

This issue is currently not on our radar. It would probably require 
quite intensive investigation and non-trivial refactoring.

If anyone from the community is interested in this area, contributions 
are always welcome! ;-)

Martin

Dne 7.3.2018 v 12:22 Emily Jiang napsal(a):
> This issue https://issues.jboss.org/browse/WELD-1130has been around for 
> a while. Can some investigation be done? We are happy to assist with 
> testing a patch if needed.
> 
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI & MicroProfile Development Lead
> 
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone: ?+44 (0)1962 816278 ?Internal: 246278
> 
> Email: emijiang at uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From BENJAMIC at uk.ibm.com  Mon Mar 12 13:40:27 2018
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Mon, 12 Mar 2018 17:40:27 +0000
Subject: [weld-dev] Potential bug with Typed not affecting if a
	ProducerMethod is proxiable.
Message-ID: <OFF080918C.F7732FC8-ON0025824E.005F9919-8025824E.0061164A@notes.na.collabserv.com>

Hello

I can see something that might be a bug in weld. I attempted to work 
around https://issues.jboss.org/projects/WELD/issues/WELD-2466 by using 
the at Typed annotation on a Producer Method to exclude the unproxiable Types 
and thus avoid getting caught by the failing isBeanProxiable check. 
However the annotation did not affect whether or not the ProducerMethod is 
proxiable. This might be a second bug. 

I have uploaded a recreate application which I have verified against 
Wildfly 11.0.0 here: https://github.com/benjamin-confino/TypedProducerBug

To recreate you can download the pre-compiled binary from github, deploy 
it to a version of Wildfly without the fix for WELD-2466, and visit the 
url http://localhost:8080/WeldRecreateProducesExtendedAbstract/inheritance 
this will trigger a call to getInjectableReference() which will fail 
because the ProducerMethod for recreate.BeanProducer.produceBean() is not 
proxiable. 

If you debug into constructor for ProducerMethod at line 76 you will see 
that the proxiable flag is set using method.getTypeClosures() ; which 
returns all the associated types, rather than just those specified with 
the Typed() paramater. 

Is this the correct behaviour? Should a ProducerMethod be unproxiable even 
with Typed limiting the bean types to proxiable types? 

Regards
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180312/e761ab4a/attachment.html 

From manovotn at redhat.com  Tue Mar 13 05:36:28 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 13 Mar 2018 05:36:28 -0400 (EDT)
Subject: [weld-dev] Potential bug with Typed not affecting if
	a	ProducerMethod is proxiable.
In-Reply-To: <OFF080918C.F7732FC8-ON0025824E.005F9919-8025824E.0061164A@notes.na.collabserv.com>
References: <OFF080918C.F7732FC8-ON0025824E.005F9919-8025824E.0061164A@notes.na.collabserv.com>
Message-ID: <1056673766.10619893.1520933788342.JavaMail.zimbra@redhat.com>

Hi,

comments inline.

Matej

----- Original Message -----
> From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
> To: weld-dev at lists.jboss.org
> Cc: "Emily Jiang" <EMIJIANG at uk.ibm.com>
> Sent: Monday, March 12, 2018 6:40:27 PM
> Subject: [weld-dev] Potential bug with Typed not affecting if a	ProducerMethod is proxiable.
> 
> Hello
> 
> I can see something that might be a bug in weld. I attempted to work
> around https://issues.jboss.org/projects/WELD/issues/WELD-2466 by using
> the at Typed annotation on a Producer Method to exclude the unproxiable Types
> and thus avoid getting caught by the failing isBeanProxiable check.
> However the annotation did not affect whether or not the ProducerMethod is
> proxiable. This might be a second bug.
> 
> I have uploaded a recreate application which I have verified against
> Wildfly 11.0.0 here: https://github.com/benjamin-confino/TypedProducerBug

Thanks for reproducer, checking it now.

> 
> To recreate you can download the pre-compiled binary from github, deploy
> it to a version of Wildfly without the fix for WELD-2466, and visit the
> url http://localhost:8080/WeldRecreateProducesExtendedAbstract/inheritance
> this will trigger a call to getInjectableReference() which will fail
> because the ProducerMethod for recreate.BeanProducer.produceBean() is not
> proxiable.
> 
> If you debug into constructor for ProducerMethod at line 76 you will see
> that the proxiable flag is set using method.getTypeClosures() ; which
> returns all the associated types, rather than just those specified with
> the Typed() paramater.
> 
> Is this the correct behaviour? Should a ProducerMethod be unproxiable even
> with Typed limiting the bean types to proxiable types?

I think this is correct behaviour because:
* Weld needs to proxy whole class hierarchy, we cannot just skip one underlying class when creating the proxy object
* @Typed is then used to determine where can this bean be injected, e.g. which bean types are used to match it against required types of each injection point

Therefore, @Typed is not really connected to proxyability but rather to assignability of that produced bean to a given injection point.

I'll double check this but I really think it's correct behaviour.

> 
> Regards
> Benjamin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

From BENJAMIC at uk.ibm.com  Tue Mar 13 06:05:19 2018
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Tue, 13 Mar 2018 10:05:19 +0000
Subject: [weld-dev] Potential bug with Typed not affecting if
 a	ProducerMethod is proxiable.
In-Reply-To: <1056673766.10619893.1520933788342.JavaMail.zimbra@redhat.com>
References: <OFF080918C.F7732FC8-ON0025824E.005F9919-8025824E.0061164A@notes.na.collabserv.com>
	<1056673766.10619893.1520933788342.JavaMail.zimbra@redhat.com>
Message-ID: <OFCA1897C7.922039DE-ON0025824F.0036E24F-8025824F.00376B41@notes.na.collabserv.com>

Thank you Matej that's good to know. 



From:   Matej Novotny <manovotn at redhat.com>
To:     Benjamin Confino <BENJAMIC at uk.ibm.com>
Cc:     weld-dev at lists.jboss.org, Emily Jiang <EMIJIANG at uk.ibm.com>
Date:   13/03/2018 09:36
Subject:        Re: [weld-dev] Potential bug with Typed not affecting if a 
ProducerMethod is proxiable.



Hi,

comments inline.

Matej

----- Original Message -----
> From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
> To: weld-dev at lists.jboss.org
> Cc: "Emily Jiang" <EMIJIANG at uk.ibm.com>
> Sent: Monday, March 12, 2018 6:40:27 PM
> Subject: [weld-dev] Potential bug with Typed not affecting if a  
ProducerMethod is proxiable.
> 
> Hello
> 
> I can see something that might be a bug in weld. I attempted to work
> around 
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_projects_WELD_issues_WELD-2D2466&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=ScbAGiokKoG8J7UIq97SogIlYzc6sVEtHpdb4KOqFw8&s=Tv24CjpIwcNluyXRoaRewFcbDniYgUcUn6thtVXNjwY&e= 
by using
> the at Typed annotation on a Producer Method to exclude the unproxiable 
Types
> and thus avoid getting caught by the failing isBeanProxiable check.
> However the annotation did not affect whether or not the ProducerMethod 
is
> proxiable. This might be a second bug.
> 
> I have uploaded a recreate application which I have verified against
> Wildfly 11.0.0 here: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_benjamin-2Dconfino_TypedProducerBug&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=ScbAGiokKoG8J7UIq97SogIlYzc6sVEtHpdb4KOqFw8&s=7eRe_h7ECCu90QwZkeL2f8vjrGk8-Ky3F6KKRI9eroI&e=


Thanks for reproducer, checking it now.

> 
> To recreate you can download the pre-compiled binary from github, deploy
> it to a version of Wildfly without the fix for WELD-2466, and visit the
> url 
https://urldefense.proofpoint.com/v2/url?u=http-3A__localhost-3A8080_WeldRecreateProducesExtendedAbstract_inheritance&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=ScbAGiokKoG8J7UIq97SogIlYzc6sVEtHpdb4KOqFw8&s=UBmyUqqsPVaalvwahMH_dEjkrRsQcwOheatneSMHVNQ&e=

> this will trigger a call to getInjectableReference() which will fail
> because the ProducerMethod for recreate.BeanProducer.produceBean() is 
not
> proxiable.
> 
> If you debug into constructor for ProducerMethod at line 76 you will see
> that the proxiable flag is set using method.getTypeClosures() ; which
> returns all the associated types, rather than just those specified with
> the Typed() paramater.
> 
> Is this the correct behaviour? Should a ProducerMethod be unproxiable 
even
> with Typed limiting the bean types to proxiable types?

I think this is correct behaviour because:
* Weld needs to proxy whole class hierarchy, we cannot just skip one 
underlying class when creating the proxy object
* @Typed is then used to determine where can this bean be injected, e.g. 
which bean types are used to match it against required types of each 
injection point

Therefore, @Typed is not really connected to proxyability but rather to 
assignability of that produced bean to a given injection point.

I'll double check this but I really think it's correct behaviour.

> 
> Regards
> Benjamin
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=hl8XiFr1UrTSgyXVc4KO_i51sM3Gyhlu1KZ4TkyseEQ&m=ScbAGiokKoG8J7UIq97SogIlYzc6sVEtHpdb4KOqFw8&s=zfPYGJTeMlNEu9b6uzEuu9Jh5DudVi-PdbzlGSY0EAg&e=





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180313/f8e2672a/attachment-0001.html 

From marko.prykladna at gmail.com  Tue Mar 13 09:38:12 2018
From: marko.prykladna at gmail.com (Marko Bekhta)
Date: Tue, 13 Mar 2018 14:38:12 +0100
Subject: [weld-dev]  Class#getGenericInterfaces() on a CDI proxy
Message-ID: <CACYzyeupvPpg_1fX4NycXAs+6er=nXdVTgL4KfHgtj6Z9XA==w@mail.gmail.com>

Hi all!

While working on an issue [1] in Hibernate Validator, We've stumbled on,
what
seems to be, a bug in Weld. We have a generic interface:

@ValidateOnExecution(type = { ExecutableType.NON_GETTER_METHODS,
ExecutableType.GETTER_METHODS })
public interface Repeater<T> {
String repeat(@NotNull String in);

@NotNull
T reverse(T in);

@NotNull
String getHelloWorld();
}

and then it's impl:

@ValidateOnExecution
public class DefaultRepeater implements Repeater<String> {

@Override
public String repeat(String in) {
return in;
}

@Override
public String reverse(String in) {
return null;
}

@Override
public String getHelloWorld() {
return null;
}
}

In the internals of HV we need to make a call to
`Class#getGenericInterfaces()`.
In case of calling it on `DefaultRepeater` class we will get something
similar
to:

result = {Type[1]@4948}
 0 = {ParameterizedTypeImpl at 4863} "org.hibernate.validator.test.
cdi.internal.methodvalidation.Repeater<java.lang.String>"

But in case when validation run in CDI context we receive a proxy instead
(something like org.hibernate.validator.test.cdi.internal.methodvalidation.
DefaultRepeater$Proxy$_$$_WeldSubclass).
And if we call `Class#getGenericInterfaces()` on such proxy we'd get next
results:

 result = {Class[6]@4880}
 0 = {Class at 3049} "interface org.hibernate.validator.test.
cdi.internal.methodvalidation.Repeater"
 1 = {Class at 327} "interface java.io.Serializable"
 2 = {Class at 4636} "interface org.jboss.weld.proxy.WeldConstruct"
 3 = {Class at 4638} "interface org.jboss.weld.interceptor.util.proxy.
TargetInstanceProxy"
 4 = {Class at 4637} "interface org.jboss.weld.interceptor.
proxy.LifecycleMixin"
 5 = {Class at 4639} "interface org.jboss.weld.bean.proxy.ProxyObject"

 The only line of interest here is 0. As you can see it gives a raw,
non-generic
 type, while `ParameterizedType` was expected (Repeater<java.lang.String>).

 Is that expected/intended behavior of `Class#getGenericInterfaces()`
 (returning raw types) for CDI proxies?

 Have a nice day,
 Marko

 [1] https://github.com/hibernate/hibernate-validator/pull/931#
issuecomment-372619324
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180313/c677c04a/attachment-0001.html 

From mkouba at redhat.com  Thu Mar 15 03:21:40 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 15 Mar 2018 08:21:40 +0100
Subject: [weld-dev] Class#getGenericInterfaces() on a CDI proxy
In-Reply-To: <CACYzyeupvPpg_1fX4NycXAs+6er=nXdVTgL4KfHgtj6Z9XA==w@mail.gmail.com>
References: <CACYzyeupvPpg_1fX4NycXAs+6er=nXdVTgL4KfHgtj6Z9XA==w@mail.gmail.com>
Message-ID: <496d45b0-7d79-4421-d3a8-3f21f2e7b60e@redhat.com>

Hi Marko,

I don't think Class#getGenericInterfaces() is defined for CDI proxies. 
In any case, there are some generics-related problems with proxies (see 
for example WELD-1539 and WELD-1914). So I would recommend to detect 
client proxies and subclasses and inspect the superclass (i.e. the 
original class, DefaultRepeater in your case) via reflection. Since 
2.3.0.Beta1 and 3.0.0.Alpha11 classes generated by Weld are marked with 
the SYNTHETIC modifier. And the name of the proxy class should always 
contain "$Proxy$". In Weld 3.0.1+ you can even use 
org.jboss.weld.proxy.WeldConstruct and 
org.jboss.weld.proxy.WeldClientProxy interfaces to distinguish such classes.

Martin

Dne 13.3.2018 v 14:38 Marko Bekhta napsal(a):
> Hi all!
> 
> While working on an issue [1] in Hibernate Validator, We've stumbled on, 
> what
> seems to be, a bug in Weld. We have a generic interface:
> 
> @ValidateOnExecution(type = { ExecutableType.NON_GETTER_METHODS, 
> ExecutableType.GETTER_METHODS })
> public interface Repeater<T> {
> String repeat(@NotNull String in);
> 
> @NotNull
> T reverse(T in);
> 
> @NotNull
> String getHelloWorld();
> }
> 
> and then it's impl:
> 
> @ValidateOnExecution
> public class DefaultRepeater implements Repeater<String> {
> 
> @Override
> public String repeat(String in) {
> return in;
> }
> 
> @Override
> public String reverse(String in) {
> return null;
> }
> 
> @Override
> public String getHelloWorld() {
> return null;
> }
> }
> 
> In the internals of HV we need to make a call to 
> `Class#getGenericInterfaces()`.
> In case of calling it on `DefaultRepeater` class we will get something 
> similar
> to:
> 
> result = {Type[1]@4948}
>  ?0 = {ParameterizedTypeImpl at 4863} 
> "org.hibernate.validator.test.cdi.internal.methodvalidation.Repeater<java.lang.String>"
> 
> But in case when validation run in CDI context we receive a proxy instead
> (something like 
> org.hibernate.validator.test.cdi.internal.methodvalidation.DefaultRepeater$Proxy$_$$_WeldSubclass). 
> 
> And if we call `Class#getGenericInterfaces()` on such proxy we'd get 
> next results:
> 
>  ?result = {Class[6]@4880}
>  ?0 = {Class at 3049} "interface 
> org.hibernate.validator.test.cdi.internal.methodvalidation.Repeater"
>  ?1 = {Class at 327} "interface java.io.Serializable"
>  ?2 = {Class at 4636} "interface org.jboss.weld.proxy.WeldConstruct"
>  ?3 = {Class at 4638} "interface 
> org.jboss.weld.interceptor.util.proxy.TargetInstanceProxy"
>  ?4 = {Class at 4637} "interface 
> org.jboss.weld.interceptor.proxy.LifecycleMixin"
>  ?5 = {Class at 4639} "interface org.jboss.weld.bean.proxy.ProxyObject"
> 
>  ?The only line of interest here is 0. As you can see it gives a raw, 
> non-generic
>  ?type, while `ParameterizedType` was expected (Repeater<java.lang.String>).
> 
>  ?Is that expected/intended behavior of `Class#getGenericInterfaces()`
>  ?(returning raw types) for CDI proxies?
> 
>  ?Have a nice day,
>  ?Marko
> 
>  ?[1]https://github.com/hibernate/hibernate-validator/pull/931#issuecomment-372619324 <https://github.com/hibernate/hibernate-validator/pull/931#issuecomment-372619324>
> 
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From mkouba at redhat.com  Thu Mar 15 04:18:59 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 15 Mar 2018 09:18:59 +0100
Subject: [weld-dev] Potential bug with Typed not affecting if a
 ProducerMethod is proxiable.
In-Reply-To: <1056673766.10619893.1520933788342.JavaMail.zimbra@redhat.com>
References: <OFF080918C.F7732FC8-ON0025824E.005F9919-8025824E.0061164A@notes.na.collabserv.com>
	<1056673766.10619893.1520933788342.JavaMail.zimbra@redhat.com>
Message-ID: <149641a0-cf09-0228-73c7-169ae55b4b71@redhat.com>

It is true that @Typed is only used to restrict the set of bean types 
used during resolution. And so it has no direct effect on proxyability 
checks, except that WELD-2466 is about the fact that Weld incorrectly 
checks all the bean types of a bean in 
BeanManager#getInjectableReference. So Benjamin's attempt makes some 
sense ;-). Unfortunately, it seems the only way to fix this is the PR 
attached to WELD-2466.

Martin

Dne 13.3.2018 v 10:36 Matej Novotny napsal(a):
> Hi,
> 
> comments inline.
> 
> Matej
> 
> ----- Original Message -----
>> From: "Benjamin Confino" <BENJAMIC at uk.ibm.com>
>> To: weld-dev at lists.jboss.org
>> Cc: "Emily Jiang" <EMIJIANG at uk.ibm.com>
>> Sent: Monday, March 12, 2018 6:40:27 PM
>> Subject: [weld-dev] Potential bug with Typed not affecting if a	ProducerMethod is proxiable.
>>
>> Hello
>>
>> I can see something that might be a bug in weld. I attempted to work
>> around https://issues.jboss.org/projects/WELD/issues/WELD-2466 by using
>> the at Typed annotation on a Producer Method to exclude the unproxiable Types
>> and thus avoid getting caught by the failing isBeanProxiable check.
>> However the annotation did not affect whether or not the ProducerMethod is
>> proxiable. This might be a second bug.
>>
>> I have uploaded a recreate application which I have verified against
>> Wildfly 11.0.0 here: https://github.com/benjamin-confino/TypedProducerBug
> 
> Thanks for reproducer, checking it now.
> 
>>
>> To recreate you can download the pre-compiled binary from github, deploy
>> it to a version of Wildfly without the fix for WELD-2466, and visit the
>> url http://localhost:8080/WeldRecreateProducesExtendedAbstract/inheritance
>> this will trigger a call to getInjectableReference() which will fail
>> because the ProducerMethod for recreate.BeanProducer.produceBean() is not
>> proxiable.
>>
>> If you debug into constructor for ProducerMethod at line 76 you will see
>> that the proxiable flag is set using method.getTypeClosures() ; which
>> returns all the associated types, rather than just those specified with
>> the Typed() paramater.
>>
>> Is this the correct behaviour? Should a ProducerMethod be unproxiable even
>> with Typed limiting the bean types to proxiable types?
> 
> I think this is correct behaviour because:
> * Weld needs to proxy whole class hierarchy, we cannot just skip one underlying class when creating the proxy object
> * @Typed is then used to determine where can this bean be injected, e.g. which bean types are used to match it against required types of each injection point
> 
> Therefore, @Typed is not really connected to proxyability but rather to assignability of that produced bean to a given injection point.
> 
> I'll double check this but I really think it's correct behaviour.
> 
>>
>> Regards
>> Benjamin
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From BENJAMIC at uk.ibm.com  Mon Mar 19 08:35:16 2018
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Mon, 19 Mar 2018 12:35:16 +0000
Subject: [weld-dev] WIP fix for https://issues.jboss.org/browse/WELD-1130
Message-ID: <OFC008CB8E.333BC4C0-ON00258255.003E02F4-80258255.004525B7@notes.na.collabserv.com>

Hello everyone

I have a work in progress fix for WELD-1130 which can be seen here: 
https://github.com/benjamin-confino/core/commit/35d055cd9a841cfbdf2bcb2aaa3e0d8d6116ec1c


I have tested a prototype of this fix on Liberty and wanted to solicit 
feedback from the community. In particular I would like advice on how to 
write a test for this, I tried modifying a test inside NaiveClusterTest to 
update a bean twice but it seems that the explicit session replication 
bypasses WELD-1130. 

Currently this test only handles the SessionScoped side of WELD-1130, but 
I have no objection to expanding it to cover both parts if people agree 
with this design and it can be extended to conversation scopes. 
(suggestions for what to call the combined property would also be 
appreciated) 

Regards
Benjamin
Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180319/74731152/attachment.html 

From manovotn at redhat.com  Tue Mar 20 10:45:04 2018
From: manovotn at redhat.com (Matej Novotny)
Date: Tue, 20 Mar 2018 10:45:04 -0400 (EDT)
Subject: [weld-dev] Weld 2.4.7.Final released && maintenance mode
In-Reply-To: <1099859740.12314140.1521556976110.JavaMail.zimbra@redhat.com>
Message-ID: <162743781.12315080.1521557104911.JavaMail.zimbra@redhat.com>

Hello everyone,

Weld 2.4.7.Final (CDI 1.2) was released -> http://weld.cdi-spec.org/news/2018/03/20/weld-247Final

NOTE: With this release, Weld 2 enters maintenance mode; there will be no further active development on 2.x branch.

Regards
Matej

From EMIJIANG at uk.ibm.com  Thu Mar 22 07:10:05 2018
From: EMIJIANG at uk.ibm.com (Emily Jiang)
Date: Thu, 22 Mar 2018 11:10:05 +0000
Subject: [weld-dev] https://issues.jboss.org/browse/WELD-1130
In-Reply-To: <eea5127f-071c-5090-67b7-fa6a842d2065@redhat.com>
References: <OFE9C45F8A.92202C8C-ON00258249.003E44BD-80258249.003E817C@notes.na.collabserv.com>
	<eea5127f-071c-5090-67b7-fa6a842d2065@redhat.com>
Message-ID: <OF550CD8E9.90285243-ON00258258.003D2B2E-80258258.003D597C@notes.na.collabserv.com>

Hi Martin,

Ben on cc proposed a PR. Can you please take a look and provide comments 
on whether the solution was ok? Your help is very much appreciated!

Many thanks,
Emily
===========================
Emily Jiang
WebSphere Application Server, CDI & MicroProfile Development Lead
 
MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
Phone:  +44 (0)1962 816278  Internal: 246278

Email: emijiang at uk.ibm.com 
Lotus Notes: Emily Jiang/UK/IBM at IBMGB




From:   Martin Kouba <mkouba at redhat.com>
To:     Emily Jiang <EMIJIANG at uk.ibm.com>, weld-dev 
<weld-dev at lists.jboss.org>
Date:   07/03/2018 13:47
Subject:        Re: [weld-dev] https://issues.jboss.org/browse/WELD-1130
Sent by:        weld-dev-bounces at lists.jboss.org



This issue is currently not on our radar. It would probably require 
quite intensive investigation and non-trivial refactoring.

If anyone from the community is interested in this area, contributions 
are always welcome! ;-)

Martin

Dne 7.3.2018 v 12:22 Emily Jiang napsal(a):
> This issue 
https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_browse_WELD-2D1130has&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U&m=j1JPWAt1GpdZlalfzTxQx3ZFHOaPnL51hGEiVP7bc2c&s=aVMebBpRwQxPV2Hevh7wmfz6cV5pB5D_3jjIFxlSXOs&e= 
been around for 
> a while. Can some investigation be done? We are happy to assist with 
> testing a patch if needed.
> 
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI & MicroProfile Development Lead
> 
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
> 
> Email: emijiang at uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 

> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
3AU
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> 
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U&m=j1JPWAt1GpdZlalfzTxQx3ZFHOaPnL51hGEiVP7bc2c&s=VAKFpqtPsk5NuD_96GSQZMXUAakf4uXut1Tnzj0ZYr0&e=

> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
_______________________________________________
weld-dev mailing list
weld-dev at lists.jboss.org
https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U&m=j1JPWAt1GpdZlalfzTxQx3ZFHOaPnL51hGEiVP7bc2c&s=VAKFpqtPsk5NuD_96GSQZMXUAakf4uXut1Tnzj0ZYr0&e=





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180322/a8575874/attachment-0001.html 

From mkouba at redhat.com  Thu Mar 22 08:27:34 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 22 Mar 2018 13:27:34 +0100
Subject: [weld-dev] https://issues.jboss.org/browse/WELD-1130
In-Reply-To: <OF550CD8E9.90285243-ON00258258.003D2B2E-80258258.003D597C@notes.na.collabserv.com>
References: <OFE9C45F8A.92202C8C-ON00258249.003E44BD-80258249.003E817C@notes.na.collabserv.com>
	<eea5127f-071c-5090-67b7-fa6a842d2065@redhat.com>
	<OF550CD8E9.90285243-ON00258258.003D2B2E-80258258.003D597C@notes.na.collabserv.com>
Message-ID: <a1d4282b-96db-d519-1419-d7722826b617@redhat.com>

Hi Emily,

review of Benjamin's commit is in our queue. Note that similar changes 
require special attention since they may break other things or reduce 
performance. So we don't want to do a sloppy job.

Martin

Dne 22.3.2018 v 12:10 Emily Jiang napsal(a):
> Hi Martin,
> 
> Ben on cc proposed a PR. Can you please take a look and provide comments 
> on whether the solution was ok? Your help is very much appreciated!
> 
> Many thanks,
> Emily
> ===========================
> Emily Jiang
> WebSphere Application Server, CDI & MicroProfile Development Lead
> 
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone: ?+44 (0)1962 816278 ?Internal: 246278
> 
> Email: emijiang at uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM at IBMGB
> 
> 
> 
> 
> From: Martin Kouba <mkouba at redhat.com>
> To: Emily Jiang <EMIJIANG at uk.ibm.com>, weld-dev <weld-dev at lists.jboss.org>
> Date: 07/03/2018 13:47
> Subject: Re: [weld-dev] https://issues.jboss.org/browse/WELD-1130
> Sent by: weld-dev-bounces at lists.jboss.org
> ------------------------------------------------------------------------
> 
> 
> 
> This issue is currently not on our radar. It would probably require
> quite intensive investigation and non-trivial refactoring.
> 
> If anyone from the community is interested in this area, contributions
> are always welcome! ;-)
> 
> Martin
> 
> Dne 7.3.2018 v 12:22 Emily Jiang napsal(a):
>  > This issue 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_browse_WELD-2D1130has&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U&m=j1JPWAt1GpdZlalfzTxQx3ZFHOaPnL51hGEiVP7bc2c&s=aVMebBpRwQxPV2Hevh7wmfz6cV5pB5D_3jjIFxlSXOs&e=been 
> around for
>  > a while. Can some investigation be done? We are happy to assist with
>  > testing a patch if needed.
>  >
>  > Many thanks,
>  > Emily
>  > ===========================
>  > Emily Jiang
>  > WebSphere Application Server, CDI & MicroProfile Development Lead
>  >
>  > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>  > Phone: ?+44 (0)1962 816278 ?Internal: 246278
>  >
>  > Email: emijiang at uk.ibm.com
>  > Lotus Notes: Emily Jiang/UK/IBM at IBMGB
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire 
> PO6 3AU
>  >
>  >
>  > _______________________________________________
>  > weld-dev mailing list
>  > weld-dev at lists.jboss.org
>  > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U&m=j1JPWAt1GpdZlalfzTxQx3ZFHOaPnL51hGEiVP7bc2c&s=VAKFpqtPsk5NuD_96GSQZMXUAakf4uXut1Tnzj0ZYr0&e=
>  >
> 
> -- 
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev&d=DwIF-g&c=jf_iaSHvJObTbx-siA1ZOg&r=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U&m=j1JPWAt1GpdZlalfzTxQx3ZFHOaPnL51hGEiVP7bc2c&s=VAKFpqtPsk5NuD_96GSQZMXUAakf4uXut1Tnzj0ZYr0&e=
> 
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From john.d.ament at gmail.com  Mon Mar 26 06:48:50 2018
From: john.d.ament at gmail.com (John D. Ament)
Date: Mon, 26 Mar 2018 10:48:50 +0000
Subject: [weld-dev] Integrating with Weld Probe
Message-ID: <CAOqetn9_zP0QnfvwUZrPmB6VFzKb0Cz3Z_1Yk1JiU5e4siTa3g@mail.gmail.com>

Hi

I was following the docs online (
https://docs.jboss.org/weld/reference/latest/en-US/html/devmode.html ) to
integrate Weld Probe into an SE application.

It looks like Probe takes care of serving static assets itself via the
filter.

Since this is an SE application, I programmatically register the
ProbeFilter (name="WeldProbeFilter",value= new String[]{"/weld-probe/*"},
            uriPatterns=new String[]{"/weld-probe/*"},
            dispatcherTypes=Constants.DISPATCHER_TYPES, // short cut for all
            initParams=new WebInitParam[]{},
            asyncSupported=true,
            servletName=null,
            filterClass=ProbeFilter.class)

I tried to start the application w/ -Dorg.jboss.weld.development=true and
noticed that it seemed to switch to bean-discovery-mode=all (without trim,
even though all of my JARs are with trim option).  I then tried to manually
enable the extension, but that resulted in

21:08:25.149 [main] WARN  org.jboss.weld.probe.Probe - PROBE-000008:
=====================================
 Weld Development Mode: ENABLED
 ------------------------------------
 Disable this mode in production - it may have negative impact on
performance and/or represent a potential security risk
=====================================
21:08:25.767 [ForkJoinPool.commonPool-worker-7] WARN
org.jboss.weld.Validator - WELD-001473: javax.enterprise.inject.spi.Bean
implementation org.apache.cxf.cdi.CdiBusBean at 74cadd41 declared a normal
scope but does not implement
javax.enterprise.inject.spi.PassivationCapable. It won't be possible to
inject this bean into a bean with a passivating scope (@SessionScoped,
@ConversationScoped). This can be fixed by assigning the Bean
implementation a unique id by implementing the PassivationCapable interface.
Exception in thread "main" org.jboss.weld.exceptions.DeploymentException:
PROBE-000005: Probe is not properly initialized
at
org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:38)
at
org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:489)
at
org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:800)
at org.jboss.weld.environment.se.Weld.initialize(Weld.java:175)
at
ws.ament.hammock.bootstrap.weld3.Weld3Bootstrapper.start(Weld3Bootstrapper.java:58)
at ws.ament.hammock.Bootstrap.main(Bootstrap.java:41)
at
ws.ament.hammock.example.canonical.RestApplication.main(RestApplication.java:31)
Caused by: org.jboss.weld.exceptions.IllegalStateException: PROBE-000005:
Probe is not properly initialized
at org.jboss.weld.probe.InvocationMonitor.init(InvocationMonitor.java:148)
at
org.jboss.weld.probe.InvocationMonitor.monitorCreation(InvocationMonitor.java:103)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
at
org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.invokeNext(WeldInvocationContextImpl.java:92)
at
org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.proceed(WeldInvocationContextImpl.java:124)
at
org.jboss.weld.injection.producer.ConstructorInterceptionInstantiator$1.aroundConstruct(ConstructorInterceptionInstantiator.java:100)
at
org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallback(ConstructorInjectionPoint.java:109)
at
org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallbacks(ConstructorInjectionPoint.java:95)
at
org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:78)
at
org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28)
at
org.jboss.weld.injection.producer.InterceptorApplyingInstantiator.newInstance(InterceptorApplyingInstantiator.java:62)
at
org.jboss.weld.injection.producer.ConstructorInterceptionInstantiator.newInstance(ConstructorInterceptionInstantiator.java:66)
at
org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:112)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:186)
at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
at org.jboss.weld.contexts.AbstractContext.get(AbstractContext.java:96)
at
org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
at
org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:140)
at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
at
org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:102)
at
org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)


Even though based on the docs that should be all that's needed.  Is there
something else required to get Probe running in SE?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180326/9e76d6c1/attachment.html 

From mkouba at redhat.com  Mon Mar 26 07:19:52 2018
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 26 Mar 2018 13:19:52 +0200
Subject: [weld-dev] Integrating with Weld Probe
In-Reply-To: <CAOqetn9_zP0QnfvwUZrPmB6VFzKb0Cz3Z_1Yk1JiU5e4siTa3g@mail.gmail.com>
References: <CAOqetn9_zP0QnfvwUZrPmB6VFzKb0Cz3Z_1Yk1JiU5e4siTa3g@mail.gmail.com>
Message-ID: <3b93ad0a-430f-f18b-ac67-bcfd25520f7c@redhat.com>

If using Weld SE you can to set Weld.DEV_MODE_SYSTEM_PROPERTY to true 
(using Weld#property() or system property) - this automatically 
registers ProbeExtension. If you also want to expose rest api/html 
client, then register ProbeFilter as a servlet filter mapped to a single 
URL pattern of value "/*".

I'm not sure about the bean-discovery-mode=all issue, but I can't say 
more without the proper knowledge of the app structure. Probe itself 
does not modify anything though.

Martin

Dne 26.3.2018 v 12:48 John D. Ament napsal(a):
> Hi
> 
> I was following the docs online ( 
> https://docs.jboss.org/weld/reference/latest/en-US/html/devmode.html?) 
> to integrate Weld Probe into an SE application.
> 
> It looks like Probe takes care of serving static assets itself via the 
> filter.
> 
> Since this is an SE application, I programmatically register the 
> ProbeFilter (name="WeldProbeFilter",value= new String[]{"/weld-probe/*"},
>  ? ? ? ? ? ? uriPatterns=new String[]{"/weld-probe/*"},
>  ? ? ? ? ? ? dispatcherTypes=Constants.DISPATCHER_TYPES, // short cut 
> for all
>  ? ? ? ? ? ? initParams=new WebInitParam[]{},
>  ? ? ? ? ? ? asyncSupported=true,
>  ? ? ? ? ? ? servletName=null,
>  ? ? ? ? ? ? filterClass=ProbeFilter.class)
> 
> I tried to start the application w/?-Dorg.jboss.weld.development=true 
> and noticed that it seemed to switch to bean-discovery-mode=all (without 
> trim, even though all of my JARs are with trim option).? I then tried to 
> manually enable the extension, but that resulted in
> 
> 21:08:25.149 [main] WARN? org.jboss.weld.probe.Probe - PROBE-000008:
> =====================================
>  ?Weld Development Mode: ENABLED
>  ?------------------------------------
>  ?Disable this mode in production - it may have negative impact on 
> performance and/or represent a potential security risk
> =====================================
> 21:08:25.767 [ForkJoinPool.commonPool-worker-7] WARN  
> org.jboss.weld.Validator - WELD-001473: javax.enterprise.inject.spi.Bean 
> implementation org.apache.cxf.cdi.CdiBusBean at 74cadd41 declared a normal 
> scope but does not implement 
> javax.enterprise.inject.spi.PassivationCapable. It won't be possible to 
> inject this bean into a bean with a passivating scope (@SessionScoped, 
> @ConversationScoped). This can be fixed by assigning the Bean 
> implementation a unique id by implementing the PassivationCapable interface.
> Exception in thread "main" 
> org.jboss.weld.exceptions.DeploymentException: PROBE-000005: Probe is 
> not properly initialized
> at 
> org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:38)
> at 
> org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
> at org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:489)
> at 
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
> at org.jboss.weld.environment.se.Weld.initialize(Weld.java:800)
> at org.jboss.weld.environment.se.Weld.initialize(Weld.java:175)
> at 
> ws.ament.hammock.bootstrap.weld3.Weld3Bootstrapper.start(Weld3Bootstrapper.java:58)
> at ws.ament.hammock.Bootstrap.main(Bootstrap.java:41)
> at 
> ws.ament.hammock.example.canonical.RestApplication.main(RestApplication.java:31)
> Caused by: org.jboss.weld.exceptions.IllegalStateException: 
> PROBE-000005: Probe is not properly initialized
> at org.jboss.weld.probe.InvocationMonitor.init(InvocationMonitor.java:148)
> at 
> org.jboss.weld.probe.InvocationMonitor.monitorCreation(InvocationMonitor.java:103)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at 
> org.jboss.weld.interceptor.reader.SimpleInterceptorInvocation$SimpleMethodInvocation.invoke(SimpleInterceptorInvocation.java:73)
> at 
> org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.invokeNext(WeldInvocationContextImpl.java:92)
> at 
> org.jboss.weld.interceptor.proxy.WeldInvocationContextImpl.proceed(WeldInvocationContextImpl.java:124)
> at 
> org.jboss.weld.injection.producer.ConstructorInterceptionInstantiator$1.aroundConstruct(ConstructorInterceptionInstantiator.java:100)
> at 
> org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallback(ConstructorInjectionPoint.java:109)
> at 
> org.jboss.weld.injection.ConstructorInjectionPoint.invokeAroundConstructCallbacks(ConstructorInjectionPoint.java:95)
> at 
> org.jboss.weld.injection.ConstructorInjectionPoint.newInstance(ConstructorInjectionPoint.java:78)
> at 
> org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28)
> at 
> org.jboss.weld.injection.producer.InterceptorApplyingInstantiator.newInstance(InterceptorApplyingInstantiator.java:62)
> at 
> org.jboss.weld.injection.producer.ConstructorInterceptionInstantiator.newInstance(ConstructorInterceptionInstantiator.java:66)
> at 
> org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:112)
> at 
> org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:186)
> at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
> at org.jboss.weld.contexts.AbstractContext.get(AbstractContext.java:96)
> at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
> at 
> org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:140)
> at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> at 
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:102)
> at 
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
> 
> 
> Even though based on the docs that should be all that's needed.? Is 
> there something else required to get Probe running in SE?
> 
> 
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic

From ooo_saturn7 at mail.ru  Sat Mar 31 07:07:59 2018
From: ooo_saturn7 at mail.ru (=?UTF-8?B?QWxleCBTdmlyaWRvdg==?=)
Date: Sat, 31 Mar 2018 14:07:59 +0300
Subject: [weld-dev] =?utf-8?q?What_is_the_best_way_to_pass_cofiguration_to?=
 =?utf-8?q?_CDI_bean_using_Weld=3F?=
Message-ID: <1522494479.872083739@f159.i.mail.ru>

Hi all

Could anyone suggest solution for the following situation.
Lets suppose we have:

public interface SomeManager{}

@ApplicationScoped
public class SomeManagerImpl implements SomeManager{}

@ApplicationScoped
public class Application {} //application entry point

In Application I need to pass configuration to SomeManagerImpl, but I don't want to 
add setConfiguration method to SomeManager interface. What is the best way
to do it in Weld? Maybe I use some CDI mechanisms, or add extra classes. Please, help.

Best regards, Alex Sviridov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20180331/ff9bcd30/attachment.html