From manovotn at redhat.com Mon Nov 14 03:47:58 2016 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 14 Nov 2016 03:47:58 -0500 (EST) Subject: [weld-dev] [cdi-dev] Think I found bug with interceptor In-Reply-To: <871484121.2996663.1479098607794@mail.yahoo.com> References: <871484121.2996663.1479098607794.ref@mail.yahoo.com> <871484121.2996663.1479098607794@mail.yahoo.com> Message-ID: <940495864.7938509.1479113278420.JavaMail.zimbra@redhat.com> Hi, first of all let us take this conversation off the cdi list, as it is a Weld related question (moving to weld-dev list). Now to your question(s)... If you could attach a tiny reproducer, this would probably be resolved within minutes, so if you can send one, do so please. > Now here's the problem, If I use this annotation on just a regular method > which I call myself, it DOES NOT work. This feels like very basic use case do I doubt it isn't working. What are the classes where you declare these methods? How to you obtain a reference to the bean which has `doSend` method? Again, reproducer would make all this very obvious and I could help you quickly :) > @Priority set on it and that works fine. But I've also tried setting > in beans.xml @Priority enables in for whole application, while beans.xml for the given bean archive. And you should not combine both approaches. Regards Matej ----- Original Message ----- > From: "Michael Remijan" > To: cdi-dev at lists.jboss.org > Sent: Monday, November 14, 2016 5:43:27 AM > Subject: [cdi-dev] Think I found bug with interceptor > > Greetings, > > I am using: > > > org.jboss.weld.se > weld-se-core > 3.0.0.Alpha15 > > > and I think I found a bug with the interceptors. I wanted to ask about it > first before I put it in Jira. > > Basically, the interceptor I have defined works great if I annotate a method > called by the CDI container, which in my case is an method observing for an > event. I have an ExceptionRetryInterceptor class and an ExceptionRetry > annotation. If I annotate an observer method like this: > > @ExceptionRetry > public void send( > @Observes @Priority(SEND_EMAIL_MESSAGE) EmailEvent evnt > ) throws MessagingException, IOException {....} > > > No problem, everything works fine. I can see the interceptor code being > called in my logs. > > Now here's the problem, If I use this annotation on just a regular method > which I call myself, it DOES NOT work. So if I refactor the above example so > the annotation is NOT on the observer method called by the container, then > the doSend() method below does NOT get wrapped by the interceptor: > > > public void send( > @Observes @Priority(SEND_EMAIL_MESSAGE) EmailEvent evnt > ) throws MessagingException, IOException { > //.... > doSend(); > } > > @ExceptionRetry > public void doSend() {....} // this method does not get wrapped by the > interceptor > > > I'm trying to figure out why. My ExceptionRetryInterceptor class has a > @Priority set on it and that works fine. But I've also tried setting > in beans.xml but the doSend(){...} method still doesn't get > wrapped. > > Any thoughts/help? > > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. From EMIJIANG at uk.ibm.com Mon Nov 14 05:31:43 2016 From: EMIJIANG at uk.ibm.com (Emily Jiang) Date: Mon, 14 Nov 2016 10:31:43 +0000 Subject: [weld-dev] [cdi-dev] Think I found bug with interceptor In-Reply-To: <940495864.7938509.1479113278420.JavaMail.zimbra@redhat.com> References: <871484121.2996663.1479098607794.ref@mail.yahoo.com> <871484121.2996663.1479098607794@mail.yahoo.com> <940495864.7938509.1479113278420.JavaMail.zimbra@redhat.com> Message-ID: If I understand you question correctly, the reason that the interceptor is not working is that it directly calls the method instead of going through the proxy. It is a known feature. Many thanks, Emily =========================== Emily Jiang WebSphere Application Server, CDI 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: Matej Novotny To: Michael Remijan Cc: weld-dev at lists.jboss.org Date: 14/11/2016 08:49 Subject: Re: [weld-dev] [cdi-dev] Think I found bug with interceptor Sent by: weld-dev-bounces at lists.jboss.org Hi, first of all let us take this conversation off the cdi list, as it is a Weld related question (moving to weld-dev list). Now to your question(s)... If you could attach a tiny reproducer, this would probably be resolved within minutes, so if you can send one, do so please. > Now here's the problem, If I use this annotation on just a regular method > which I call myself, it DOES NOT work. This feels like very basic use case do I doubt it isn't working. What are the classes where you declare these methods? How to you obtain a reference to the bean which has `doSend` method? Again, reproducer would make all this very obvious and I could help you quickly :) > @Priority set on it and that works fine. But I've also tried setting > in beans.xml @Priority enables in for whole application, while beans.xml for the given bean archive. And you should not combine both approaches. Regards Matej ----- Original Message ----- > From: "Michael Remijan" > To: cdi-dev at lists.jboss.org > Sent: Monday, November 14, 2016 5:43:27 AM > Subject: [cdi-dev] Think I found bug with interceptor > > Greetings, > > I am using: > > > org.jboss.weld.se > weld-se-core > 3.0.0.Alpha15 > > > and I think I found a bug with the interceptors. I wanted to ask about it > first before I put it in Jira. > > Basically, the interceptor I have defined works great if I annotate a method > called by the CDI container, which in my case is an method observing for an > event. I have an ExceptionRetryInterceptor class and an ExceptionRetry > annotation. If I annotate an observer method like this: > > @ExceptionRetry > public void send( > @Observes @Priority(SEND_EMAIL_MESSAGE) EmailEvent evnt > ) throws MessagingException, IOException {....} > > > No problem, everything works fine. I can see the interceptor code being > called in my logs. > > Now here's the problem, If I use this annotation on just a regular method > which I call myself, it DOES NOT work. So if I refactor the above example so > the annotation is NOT on the observer method called by the container, then > the doSend() method below does NOT get wrapped by the interceptor: > > > public void send( > @Observes @Priority(SEND_EMAIL_MESSAGE) EmailEvent evnt > ) throws MessagingException, IOException { > //.... > doSend(); > } > > @ExceptionRetry > public void doSend() {....} // this method does not get wrapped by the > interceptor > > > I'm trying to figure out why. My ExceptionRetryInterceptor class has a > @Priority set on it and that works fine. But I've also tried setting > in beans.xml but the doSend(){...} method still doesn't get > wrapped. > > Any thoughts/help? > > > > > > _______________________________________________ > cdi-dev mailing list > cdi-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/cdi-dev > > Note that for all code provided on this list, the provider licenses the code > under the Apache License, Version 2 > (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas > provided on this list, the provider waives all patent and other intellectual > property rights inherent in such information. _______________________________________________ weld-dev mailing list weld-dev at lists.jboss.org https://lists.jboss.org/mailman/listinfo/weld-dev 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/20161114/defc54f6/attachment-0001.html From mkouba at redhat.com Fri Nov 18 03:37:39 2016 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 18 Nov 2016 09:37:39 +0100 Subject: [weld-dev] Weld 2.4.1.Final released Message-ID: <60e818c7-726f-7aa7-7e6e-acacabe49890@redhat.com> http://weld.cdi-spec.org/news/2016/11/18/weld-241Final/ -- Martin Kouba Software Engineer Red Hat, Czech Republic From BENJAMIC at uk.ibm.com Mon Nov 28 10:56:12 2016 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Mon, 28 Nov 2016 15:56:12 +0000 Subject: [weld-dev] Specializes bean in war causes unsatisfied resolution exception Message-ID: Hello A customer of mine sent in a test application with the following structure: A war file inside ear Two jar files inside ear/lib One jar file inside ear/war/WEB-INF/lib There is a class inside one of the ear/lib jar files which @Injects a bean from the other ear/lib jar file And there is a class inside the ear/war/WEB-INF/lib jar file that @Specializes the bean inside an ear/lib jar file (You can see the application at was_bugs/was_bug22 at master ? thikade/was_bugs ? GitHub ) Attempting to run this application on Weld results in an Unsatisfied Resolution Exception. When I remove the jar containing the @Specializes bean the application works correctly. My first thought was that this application should not work, because the war file and it's internal jar would have a second classloader that would be invisible to the application classloader. However the customer attested, and I confirmed that this application works fine on OpenWebBeans. I do not think this is an integration issue, because I tested this on Wildfly and got the same error. So it seems that Weld throws an Unsatisfied Resolution Exception if @specializes exists in a class that is loaded by a classloader which is not visible . What do you think is the correct behaviour is in this instance? From a classloading perspective a class inside ear/lib should not be able to see a class inside ear/war; but on the other hand the entire purpose of a @Specializes bean is that you drop it into your application and it replaces the original bean. It feels appropriate that you can drop in a war file containing the @Specializes bean and it just works without you having to do anything extra. Best 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/20161128/e0d80ff9/attachment.html From manovotn at redhat.com Tue Nov 29 01:06:25 2016 From: manovotn at redhat.com (Matej Novotny) Date: Tue, 29 Nov 2016 01:06:25 -0500 (EST) Subject: [weld-dev] Specializes bean in war causes unsatisfied resolution exception In-Reply-To: References: Message-ID: <425811502.514922.1480399585459.JavaMail.zimbra@redhat.com> Hello Benjamin Thanks for well written question! > (You can see the application at was_bugs/was_bug22 at master ? > thikade/was_bugs ? GitHub ) Thanks! Took a glance and it looks like the infamous EAR visibility issue. > My first thought was that this application should not work I agree with that. Anything located in EAR/lib cannot really "see" into WAR. Hence the bean with @Specializes (in WAR) will disable the original bean (in EAR/lib) and the injection cannot be performed as the specialized bean is not visible to the archive in EAR/lib. > I confirmed that this application works fine on OpenWebBeans. The fact that it does NOT work should be in accord with Java EE spec and its visibility restrictions. Maybe you should be asking OWB guys why does it work at all? I am no EAR expert but I really think this is Java EE spec (not CDI) intended behavior. Matej ----- Original Message ----- > From: "Benjamin Confino" > To: weld-dev at lists.jboss.org > Cc: "Tom Evans" , "Emily Jiang" > Sent: Monday, November 28, 2016 4:56:12 PM > Subject: [weld-dev] Specializes bean in war causes unsatisfied resolution exception > > Hello > > A customer of mine sent in a test application with the following structure: > > A war file inside ear > Two jar files inside ear/lib > One jar file inside ear/war/WEB-INF/lib > > There is a class inside one of the ear/lib jar files which @Injects a bean > from the other ear/lib jar file > > And there is a class inside the ear/war/WEB-INF/lib jar file that > @Specializes the bean inside an ear/lib jar file > > (You can see the application at was_bugs/was_bug22 at master ? > thikade/was_bugs ? GitHub ) > > Attempting to run this application on Weld results in an Unsatisfied > Resolution Exception. When I remove the jar containing the @Specializes bean > the application works correctly. > > > My first thought was that this application should not work, because the war > file and it's internal jar would have a second classloader that would be > invisible to the application classloader. However the customer attested, and > I confirmed that this application works fine on OpenWebBeans. > > I do not think this is an integration issue, because I tested this on Wildfly > and got the same error. > > > So it seems that Weld throws an Unsatisfied Resolution Exception if > @specializes exists in a class that is loaded by a classloader which is not > visible . > > What do you think is the correct behaviour is in this instance? From a > classloading perspective a class inside ear/lib should not be able to see a > class inside ear/war; but on the other hand the entire purpose of a > @Specializes bean is that you drop it into your application and it replaces > the original bean. It feels appropriate that you can drop in a war file > containing the @Specializes bean and it just works without you having to do > anything extra. > > Best 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 mkouba at redhat.com Tue Nov 29 02:42:40 2016 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 29 Nov 2016 08:42:40 +0100 Subject: [weld-dev] Specializes bean in war causes unsatisfied resolution exception In-Reply-To: <425811502.514922.1480399585459.JavaMail.zimbra@redhat.com> References: <425811502.514922.1480399585459.JavaMail.zimbra@redhat.com> Message-ID: <99d4d597-fd16-4a55-327e-8db5556b8b0c@redhat.com> Matej is correct. The specializing bean from the war disables the specialized bean from ear/lib. And since the bean from war is not visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an unsatisfied dependency exists. By the way, what instance of SnapshotData gets injected into KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the war/lib? Martin Dne 29.11.2016 v 07:06 Matej Novotny napsal(a): > Hello Benjamin > > Thanks for well written question! > >> (You can see the application at was_bugs/was_bug22 at master ? >> thikade/was_bugs ? GitHub ) > > Thanks! Took a glance and it looks like the infamous EAR visibility issue. > >> My first thought was that this application should not work > > I agree with that. Anything located in EAR/lib cannot really "see" into WAR. > Hence the bean with @Specializes (in WAR) will disable the original bean (in EAR/lib) and the injection cannot be performed as > the specialized bean is not visible to the archive in EAR/lib. > >> I confirmed that this application works fine on OpenWebBeans. > > The fact that it does NOT work should be in accord with Java EE spec and its visibility restrictions. > Maybe you should be asking OWB guys why does it work at all? > > I am no EAR expert but I really think this is Java EE spec (not CDI) intended behavior. > > Matej > > ----- Original Message ----- >> From: "Benjamin Confino" >> To: weld-dev at lists.jboss.org >> Cc: "Tom Evans" , "Emily Jiang" >> Sent: Monday, November 28, 2016 4:56:12 PM >> Subject: [weld-dev] Specializes bean in war causes unsatisfied resolution exception >> >> Hello >> >> A customer of mine sent in a test application with the following structure: >> >> A war file inside ear >> Two jar files inside ear/lib >> One jar file inside ear/war/WEB-INF/lib >> >> There is a class inside one of the ear/lib jar files which @Injects a bean >> from the other ear/lib jar file >> >> And there is a class inside the ear/war/WEB-INF/lib jar file that >> @Specializes the bean inside an ear/lib jar file >> >> (You can see the application at was_bugs/was_bug22 at master ? >> thikade/was_bugs ? GitHub ) >> >> Attempting to run this application on Weld results in an Unsatisfied >> Resolution Exception. When I remove the jar containing the @Specializes bean >> the application works correctly. >> >> >> My first thought was that this application should not work, because the war >> file and it's internal jar would have a second classloader that would be >> invisible to the application classloader. However the customer attested, and >> I confirmed that this application works fine on OpenWebBeans. >> >> I do not think this is an integration issue, because I tested this on Wildfly >> and got the same error. >> >> >> So it seems that Weld throws an Unsatisfied Resolution Exception if >> @specializes exists in a class that is loaded by a classloader which is not >> visible . >> >> What do you think is the correct behaviour is in this instance? From a >> classloading perspective a class inside ear/lib should not be able to see a >> class inside ear/war; but on the other hand the entire purpose of a >> @Specializes bean is that you drop it into your application and it replaces >> the original bean. It feels appropriate that you can drop in a war file >> containing the @Specializes bean and it just works without you having to do >> anything extra. >> >> Best 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 > From BENJAMIC at uk.ibm.com Wed Nov 30 12:01:38 2016 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Wed, 30 Nov 2016 17:01:38 +0000 Subject: [weld-dev] Specializes bean in war causes unsatisfied resolution exception In-Reply-To: <99d4d597-fd16-4a55-327e-8db5556b8b0c@redhat.com> References: <425811502.514922.1480399585459.JavaMail.zimbra@redhat.com> <99d4d597-fd16-4a55-327e-8db5556b8b0c@redhat.com> Message-ID: Thank you for the prompt replies. In answer to your question. It is UiSnapshotData which gets injected under OWB. Regards Benjamin From: Martin Kouba To: Matej Novotny , Benjamin Confino/UK/IBM at IBMGB, Cc: Emily Jiang/UK/IBM at IBMGB, Tom Evans/UK/IBM at IBMGB, weld-dev at lists.jboss.org Date: 29/11/2016 07:42 Subject: Re: [weld-dev] Specializes bean in war causes unsatisfied resolution exception Matej is correct. The specializing bean from the war disables the specialized bean from ear/lib. And since the bean from war is not visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an unsatisfied dependency exists. By the way, what instance of SnapshotData gets injected into KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the war/lib? Martin Dne 29.11.2016 v 07:06 Matej Novotny napsal(a): > Hello Benjamin > > Thanks for well written question! > >> (You can see the application at was_bugs/was_bug22 at master ? >> thikade/was_bugs ? GitHub ) > > Thanks! Took a glance and it looks like the infamous EAR visibility issue. > >> My first thought was that this application should not work > > I agree with that. Anything located in EAR/lib cannot really "see" into WAR. > Hence the bean with @Specializes (in WAR) will disable the original bean (in EAR/lib) and the injection cannot be performed as > the specialized bean is not visible to the archive in EAR/lib. > >> I confirmed that this application works fine on OpenWebBeans. > > The fact that it does NOT work should be in accord with Java EE spec and its visibility restrictions. > Maybe you should be asking OWB guys why does it work at all? > > I am no EAR expert but I really think this is Java EE spec (not CDI) intended behavior. > > Matej > > ----- Original Message ----- >> From: "Benjamin Confino" >> To: weld-dev at lists.jboss.org >> Cc: "Tom Evans" , "Emily Jiang" >> Sent: Monday, November 28, 2016 4:56:12 PM >> Subject: [weld-dev] Specializes bean in war causes unsatisfied resolution exception >> >> Hello >> >> A customer of mine sent in a test application with the following structure: >> >> A war file inside ear >> Two jar files inside ear/lib >> One jar file inside ear/war/WEB-INF/lib >> >> There is a class inside one of the ear/lib jar files which @Injects a bean >> from the other ear/lib jar file >> >> And there is a class inside the ear/war/WEB-INF/lib jar file that >> @Specializes the bean inside an ear/lib jar file >> >> (You can see the application at was_bugs/was_bug22 at master ? >> thikade/was_bugs ? GitHub ) >> >> Attempting to run this application on Weld results in an Unsatisfied >> Resolution Exception. When I remove the jar containing the @Specializes bean >> the application works correctly. >> >> >> My first thought was that this application should not work, because the war >> file and it's internal jar would have a second classloader that would be >> invisible to the application classloader. However the customer attested, and >> I confirmed that this application works fine on OpenWebBeans. >> >> I do not think this is an integration issue, because I tested this on Wildfly >> and got the same error. >> >> >> So it seems that Weld throws an Unsatisfied Resolution Exception if >> @specializes exists in a class that is loaded by a classloader which is not >> visible . >> >> What do you think is the correct behaviour is in this instance? From a >> classloading perspective a class inside ear/lib should not be able to see a >> class inside ear/war; but on the other hand the entire purpose of a >> @Specializes bean is that you drop it into your application and it replaces >> the original bean. It feels appropriate that you can drop in a war file >> containing the @Specializes bean and it just works without you having to do >> anything extra. >> >> Best 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 > 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/20161130/7937f8a6/attachment-0001.html