From emijiang6 at googlemail.com Wed Jul 1 12:19:58 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 1 Jul 2015 17:19:58 +0100 Subject: [weld-dev] Weld Performance improvement Message-ID: Is it possible to get the following jira fix committed to 2.2.15.Final? https://issues.jboss.org/browse/WELD-1931 I would like to consume this and see how much improvement has been made. -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150701/a6b12bc1/attachment.html From jharting at redhat.com Thu Jul 2 03:35:39 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 02 Jul 2015 09:35:39 +0200 Subject: [weld-dev] Weld Performance improvement In-Reply-To: References: Message-ID: <5594E9CB.3090501@redhat.com> Hi Emily, that should not be a problem. Would it be possible for you to test the performance improvement before we actually do the release? I can prepare a separate branch or send you a binary. I would like to see how much improvement this makes in your benchmark. Jozef On 07/01/2015 06:19 PM, Emily Jiang wrote: > Is it possible to get the following jira fix committed to 2.2.15.Final? > > https://issues.jboss.org/browse/WELD-1931 > > I would like to consume this and see how much improvement has been made. > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150702/ab76e904/attachment.html From emijiang6 at googlemail.com Thu Jul 2 04:30:57 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Thu, 2 Jul 2015 09:30:57 +0100 Subject: [weld-dev] Weld Performance improvement In-Reply-To: <5594E9CB.3090501@redhat.com> References: <5594E9CB.3090501@redhat.com> Message-ID: Thanks Jozef! Sure. Sending me a binary will be good. Can you do it on top of the 2.2.14.Final? On Thu, Jul 2, 2015 at 8:35 AM, Jozef Hartinger wrote: > Hi Emily, > > that should not be a problem. Would it be possible for you to test the > performance improvement before we actually do the release? I can prepare a > separate branch or send you a binary. I would like to see how much > improvement this makes in your benchmark. > > Jozef > > > On 07/01/2015 06:19 PM, Emily Jiang wrote: > > Is it possible to get the following jira fix committed to 2.2.15.Final? > > https://issues.jboss.org/browse/WELD-1931 > > I would like to consume this and see how much improvement has been made. > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150702/fde56b2e/attachment.html From jharting at redhat.com Thu Jul 2 04:31:47 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 02 Jul 2015 10:31:47 +0200 Subject: [weld-dev] Weld Performance improvement In-Reply-To: References: <5594E9CB.3090501@redhat.com> Message-ID: <5594F6F3.9080007@redhat.com> Yes, which artifact are you using? weld-core, weld-core-impl or weld-osgi bundle? On 07/02/2015 10:30 AM, Emily Jiang wrote: > Thanks Jozef! Sure. Sending me a binary will be good. Can you do it on > top of the 2.2.14.Final? > > On Thu, Jul 2, 2015 at 8:35 AM, Jozef Hartinger > wrote: > > Hi Emily, > > that should not be a problem. Would it be possible for you to test > the performance improvement before we actually do the release? I > can prepare a separate branch or send you a binary. I would like > to see how much improvement this makes in your benchmark. > > Jozef > > > On 07/01/2015 06:19 PM, Emily Jiang wrote: >> Is it possible to get the following jira fix committed to >> 2.2.15.Final? >> >> https://issues.jboss.org/browse/WELD-1931 >> >> I would like to consume this and see how much improvement has >> been made. >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150702/e73db637/attachment-0001.html From emijiang6 at googlemail.com Thu Jul 2 04:34:43 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Thu, 2 Jul 2015 09:34:43 +0100 Subject: [weld-dev] Weld Performance improvement In-Reply-To: <5594F6F3.9080007@redhat.com> References: <5594E9CB.3090501@redhat.com> <5594F6F3.9080007@redhat.com> Message-ID: weld-osgi bundle only On Thu, Jul 2, 2015 at 9:31 AM, Jozef Hartinger wrote: > Yes, which artifact are you using? weld-core, weld-core-impl or weld-osgi > bundle? > > > On 07/02/2015 10:30 AM, Emily Jiang wrote: > > Thanks Jozef! Sure. Sending me a binary will be good. Can you do it on top > of the 2.2.14.Final? > > On Thu, Jul 2, 2015 at 8:35 AM, Jozef Hartinger > wrote: > >> Hi Emily, >> >> that should not be a problem. Would it be possible for you to test the >> performance improvement before we actually do the release? I can prepare a >> separate branch or send you a binary. I would like to see how much >> improvement this makes in your benchmark. >> >> Jozef >> >> >> On 07/01/2015 06:19 PM, Emily Jiang wrote: >> >> Is it possible to get the following jira fix committed to 2.2.15.Final? >> >> https://issues.jboss.org/browse/WELD-1931 >> >> I would like to consume this and see how much improvement has been made. >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150702/c8da3174/attachment.html From jharting at redhat.com Thu Jul 2 04:57:37 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 02 Jul 2015 10:57:37 +0200 Subject: [weld-dev] Weld 3.0.0.Alpha11 released Message-ID: <5594FD01.7020307@redhat.com> https://developer.jboss.org/message/935021 From janb at webtide.com Thu Jul 9 02:16:44 2015 From: janb at webtide.com (Jan Bartel) Date: Thu, 9 Jul 2015 16:16:44 +1000 Subject: [weld-dev] @Resource annotation handling by Weld vs Servlet container In-Reply-To: <552D13E2.7000805@redhat.com> References: <552774A7.2020409@redhat.com> <552B88AB.50408@redhat.com> <552D13E2.7000805@redhat.com> Message-ID: Hi Josef, The EE spec group were having a very long discussion about CDI and annotation handling (thread ref: https://java.net/projects/javaee-spec/lists/users/archive/2015-02/message/54) wrt updating EE7 and creating EE8. Do you know where that landed? Is there any clarification on whether the servlet container or CDI impl is supposed to be interpreting the @Resource annotations? cheers Jan On 14 April 2015 at 23:19, Jozef Hartinger wrote: > > > On 04/14/2015 07:17 AM, Jan Bartel wrote: >> >> Hi Jozef, >> >>>>> Looking at the WeldServletLifecyle class on line 124, it will always >>>>> provide an implementation of the ResourceInjectionServices (an >>>>> instance of ServletResourceInjectionServices). If we were to provide >>>>> our own implementation of ResourceInjectionServices, how would we >>>>> override that one? Is there a way to get a hold of the Deployment and >>>>> thus the BeanDeploymentArchives so we could set our own implementation >>>>> up? Ideally we'd like a pure CDI api way of interacting with weld, but >>>>> maybe that's not possible in this case? >>>> >>>> You need to interact with Weld APIs to do this. A service can be >>>> overridden >>>> using ServiceLoader mechanism. See >>>> >>>> http://docs.jboss.org/weld/reference/2.2.10.Final/en-US/html/ri-spi.html#_registering_services >>>> for details. >>> >>> Ok, great, I'll give this a go and report back. >> >> I've implemented the service for the ResourceInjectionServices (for >> now each method simply does a println), and it looks like weld is >> seeing it: >> >> Apr 14, 2015 11:40:34 AM org.jboss.weld.bootstrap.AdditionalServiceLoader >> put >> DEBUG: Installing additional service >> org.jboss.weld.injection.spi.ResourceInjectionServices (class >> org.eclipse.jetty.cdi.servlet.ResourceInjectionServices) >> Weld ResourceInjectionServices jetty constructor called >> >> However, it does not appear to be being used, as I see no output from >> my service, but still get the following error: >> >> java.lang.RuntimeException: Error looking up maxAmount in JNDI >> at >> org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:50) >> at >> org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) >> at >> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) >> at >> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) >> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) >> at >> org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) >> at >> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >> at >> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) >> at >> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >> at >> org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) >> at >> org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) >> at >> org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) >> at >> org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) >> at >> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) >> at >> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) >> >> Any hints? > > Actually I somehow missed the fact the ResourceInjectionServices are > per-module instead of per-deployment type of Service. As a result, it is not > possible to override it using AdditionalServiceLoader. See my other e-mail > for details. Sorry about that. > >> >> thanks, >> Jan >> >>> >>>>> Alternatively, instead of Weld >>>>>> >>>>>> hooking into lifecycle of Jetty-managed components, Jetty could use >>>>>> CDI >>>>>> APIs >>>>>> to perform CDI injection on instances it manages. >>>>>> >>>>> Yes, potentially we could do that, although we'd probably need your >>>>> guidance on the best way to do that. Can @Resource be used by pojo >>>>> beans or only by servlet artifacts (servlet/filter/listeners)? If the >>>>> latter, then I'm fine for Jetty to do all the handling of @Resource. >>>>> If not, then it probably makes sense for weld to handle it, and we'd >>>>> need a way to disable Jetty's implementation if weld is present in a >>>>> webapp ... >>>> >>>> I think the best approach would be to modify the integrating decorator >>>> to >>>> only provide CDI injection to Jetty-managed instances. I have >>>> implemented it >>>> here: >>>> >>>> https://github.com/weld/core/commit/f7420e34355c5c82ef516713c65fc6cd750fb651 >>> >>> So if jetty is handling @Resource (handling making the jndi entries >>> and injecting the fields/methods) for servlets/filters/listeners, what >>> will happen if someone declares this in eg a servlet: >>> >>> public class MyServlet extends HttpServlet >>> { >>> >>> @Producer @Resource (name="foo") >>> @MyDb >>> private DataSource db; >>> } >>> >>> Will weld still inspect this class and find the producer and make it >>> available for injection in other code? >>> >>> cheers >>> Jan >>> >>>>> cheers >>>>> Jan >>>>> >>>>>> Additional comments inline: >>>>>> >>>>>> >>>>>> On 04/10/2015 02:00 AM, Jan Bartel wrote: >>>>>>> >>>>>>> Hi Weld developers, >>>>>>> >>>>>>> The Jetty project is looking at how we can do a tighter integration >>>>>>> with Weld, also with a view to discussions in the Servlet Spec 4 >>>>>>> committee to alleviate the necessity for CDI implementations to >>>>>>> maintain jetty-specific initialisation code. >>>>>>> >>>>>>> During investigations, I noticed that we seem to have a conflict in >>>>>>> the handling of a few annotations for classes that are managed by the >>>>>>> servlet container (ie servlets, filters, listeners etc): >>>>>>> >>>>>>> @Resource >>>>>>> @PostConstruct >>>>>>> @PreDestroy >>>>>>> >>>>>>> As Jetty puts a servlet/filter/listener into service, we introspect >>>>>>> the class and find the above annotations and process them. It seems >>>>>>> that Weld does too, as I see the following failure for this code >>>>>>> snippet: >>>>>>> >>>>>>> public class TestListener implements ServletContextListener >>>>>>> { >>>>>>> @Resource(mappedName="maxAmount") >>>>>>> private Double maxAmount; >>>>>>> } >>>>>>> >>>>>>> >>>>>>> javax.naming.NameNotFoundException; remaining name 'maxAmount' >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:429) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.eclipse.jetty.jndi.local.localContextRoot.lookup(localContextRoot.java:533) >>>>>>> at javax.naming.InitialContext.lookup(InitialContext.java:411) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices.resolveResource(AbstractResourceServices.java:48) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.injection.spi.helpers.AbstractResourceServices$1.createResource(AbstractResourceServices.java:121) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.injection.AbstractResourceInjection.getResourceReference(AbstractResourceInjection.java:44) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.injection.AbstractResourceInjection.injectResourceReference(AbstractResourceInjection.java:53) >>>>>>> at org.jboss.weld.util.Beans.injectEEFields(Beans.java:344) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.injection.producer.ResourceInjector$1.proceed(ResourceInjector.java:69) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:72) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:121) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.environment.servlet.inject.AbstractInjector.inject(AbstractInjector.java:55) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.environment.jetty.JettyWeldInjector.inject(JettyWeldInjector.java:15) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.jboss.weld.environment.jetty.WeldDecorator.decorate(WeldDecorator.java:105) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.eclipse.jetty.util.DecoratedObjectFactory.decorate(DecoratedObjectFactory.java:77) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.eclipse.jetty.servlet.ServletContextHandler.startContext(ServletContextHandler.java:335) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.eclipse.jetty.webapp.WebAppContext.startWebapp(WebAppContext.java:1349) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.eclipse.jetty.webapp.WebAppContext.startContext(WebAppContext.java:1342) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.eclipse.jetty.server.handler.ContextHandler.doStart(ContextHandler.java:743) >>>>>>> at >>>>>>> >>>>>>> >>>>>>> org.eclipse.jetty.servlet.ServletContextHandler.doStart(ServletContextHandler.java:257) >>>>>>> at >>>>>>> >>>>>>> org.eclipse.jetty.webapp.WebAppContext.doStart(WebAppContext.java:505) >>>>>>> >>>>>>> >>>>>>> Googling around, it is not clear to me exactly which of the Common >>>>>>> Annotations (JSR250) that Weld supports and I'd appreciate some input >>>>>>> from the Weld devs in order for Jetty to work out how best to move >>>>>>> forward with Weld integration. >>>>>>> >>>>>>> In particular, I'd appreciate some clear feedback on which of the >>>>>>> following @Resource annotation usages will be handled by Weld: >>>>>>> >>>>>>> @Resource on a class >>>>>>> @Resource on a field >>>>>>> @Resource on a method >>>>>>> @Resource annotations without an accompanying @Producer annotation >>>>>> >>>>>> @Resource on a field (with or without @Producer), @Resource on a >>>>>> method, >>>>>> @PostConstruct and @PreDestroy are handled by Weld on a managed >>>>>> instance >>>>>> (generally). >>>>>>> >>>>>>> >>>>>>> Secondly, as can be seen from the stacktrace above, Weld is failing >>>>>>> to >>>>>>> find the matching JNDI entry for an @Resource annotation. This is >>>>>>> because Weld appears not to be looking in "java:comp/env" namespace, >>>>>>> although IIRC that is mandated by the JavaEE spec for EE managed >>>>>>> classes (servlets/filters/listeners etc). So if Jetty delegates >>>>>>> handling of some/all processing of @Resource, how do we ensure that >>>>>>> Weld will be able to find the right JNDI entry? >>>>>> >>>>>> This might be a bug in weld-servlet's ResourceInjectionServices >>>>>> implementation. Can you file an issue at >>>>>> https://issues.jboss.org/browse/WELD ? >>>>>> >>>>>>> thanks for your time, >>>>>>> Jan >>>>>> >>>>>> >>>>> >>> >>> >>> -- >>> Jan Bartel >>> www.webtide.com >>> 'Expert Jetty/CometD developer,production,operations advice' >> >> >> > -- Jan Bartel www.webtide.com 'Expert assistance from the creators of Jetty and CometD' From emijiang6 at googlemail.com Mon Jul 20 05:12:01 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 20 Jul 2015 10:12:01 +0100 Subject: [weld-dev] Weld Performance improvement In-Reply-To: <5594E9CB.3090501@redhat.com> References: <5594E9CB.3090501@redhat.com> Message-ID: Hi Jozef, Martin, Sorry for the delay! I have the performance figure collected eventually. With this Jira's changes, it shows 1% performance improvement. This is a step in the right direction but there is still a performance hit (23% worse) when turning on CDI. Would you like to commit this change so that I can reconsume this release? It will be great if a further performance improvement can be done. I am happy to collect the performance benchmark if needed. Thanks Emily On Thu, Jul 2, 2015 at 8:35 AM, Jozef Hartinger wrote: > Hi Emily, > > that should not be a problem. Would it be possible for you to test the > performance improvement before we actually do the release? I can prepare a > separate branch or send you a binary. I would like to see how much > improvement this makes in your benchmark. > > Jozef > > > On 07/01/2015 06:19 PM, Emily Jiang wrote: > > Is it possible to get the following jira fix committed to 2.2.15.Final? > > https://issues.jboss.org/browse/WELD-1931 > > I would like to consume this and see how much improvement has been made. > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150720/192b882f/attachment.html From mkouba at redhat.com Mon Jul 20 06:15:52 2015 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 20 Jul 2015 12:15:52 +0200 Subject: [weld-dev] Weld Performance improvement In-Reply-To: References: <5594E9CB.3090501@redhat.com> Message-ID: <55ACCA58.1040804@redhat.com> Hi Emily, it's great to hear there is a performance improvement (although 1% is not that much). We're working on further performance improvements in this area [1]. However, 23% additional overhead seems to me too much. Would it be possible to share your performance test case / test application? We could run similar tests in our environment and verify that there's no integration problem. Martin [1] https://issues.jboss.org/browse/WELD-1970 Dne 20.7.2015 v 11:12 Emily Jiang napsal(a): > Hi Jozef, Martin, > > Sorry for the delay! I have the performance figure collected eventually. > With this Jira's changes, it shows 1% performance improvement. This is a > step in the right direction but there is still a performance hit (23% > worse) when turning on CDI. Would you like to commit this change so that > I can reconsume this release? It will be great if a further performance > improvement can be done. I am happy to collect the performance benchmark > if needed. > > Thanks > Emily > > On Thu, Jul 2, 2015 at 8:35 AM, Jozef Hartinger > wrote: > > Hi Emily, > > that should not be a problem. Would it be possible for you to test > the performance improvement before we actually do the release? I can > prepare a separate branch or send you a binary. I would like to see > how much improvement this makes in your benchmark. > > Jozef > > > On 07/01/2015 06:19 PM, Emily Jiang wrote: >> Is it possible to get the following jira fix committed to >> 2.2.15.Final? >> >> https://issues.jboss.org/browse/WELD-1931 >> >> I would like to consume this and see how much improvement has been >> made. >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org From emijiang6 at googlemail.com Mon Jul 20 08:43:24 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 20 Jul 2015 13:43:24 +0100 Subject: [weld-dev] Weld Performance improvement In-Reply-To: <55ACCA58.1040804@redhat.com> References: <5594E9CB.3090501@redhat.com> <55ACCA58.1040804@redhat.com> Message-ID: The test applications we used were attached to the jira https://developer.jboss.org/message/926035#926035. You can compare the responding time between two servlet requests. Can you commit the current changes in the release 2.2.15.Final because I plan to consume this release for other jira fixes as well? Thanks Emily On Mon, Jul 20, 2015 at 11:15 AM, Martin Kouba wrote: > Hi Emily, > > it's great to hear there is a performance improvement (although 1% is not > that much). We're working on further performance improvements in this area > [1]. > > However, 23% additional overhead seems to me too much. Would it be > possible to share your performance test case / test application? We could > run similar tests in our environment and verify that there's no integration > problem. > > Martin > > [1] > https://issues.jboss.org/browse/WELD-1970 > > > Dne 20.7.2015 v 11:12 Emily Jiang napsal(a): > >> Hi Jozef, Martin, >> >> Sorry for the delay! I have the performance figure collected eventually. >> With this Jira's changes, it shows 1% performance improvement. This is a >> step in the right direction but there is still a performance hit (23% >> worse) when turning on CDI. Would you like to commit this change so that >> I can reconsume this release? It will be great if a further performance >> improvement can be done. I am happy to collect the performance benchmark >> if needed. >> >> Thanks >> Emily >> >> On Thu, Jul 2, 2015 at 8:35 AM, Jozef Hartinger > > wrote: >> >> Hi Emily, >> >> that should not be a problem. Would it be possible for you to test >> the performance improvement before we actually do the release? I can >> prepare a separate branch or send you a binary. I would like to see >> how much improvement this makes in your benchmark. >> >> Jozef >> >> >> On 07/01/2015 06:19 PM, Emily Jiang wrote: >> >>> Is it possible to get the following jira fix committed to >>> 2.2.15.Final? >>> >>> https://issues.jboss.org/browse/WELD-1931 >>> >>> I would like to consume this and see how much improvement has been >>> made. >>> >>> -- >>> Thanks >>> Emily >>> ================= >>> Emily Jiang >>> ejiang at apache.org >>> >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150720/4bc981c3/attachment.html From jharting at redhat.com Mon Jul 20 09:18:31 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Mon, 20 Jul 2015 15:18:31 +0200 Subject: [weld-dev] Weld Performance improvement In-Reply-To: References: <5594E9CB.3090501@redhat.com> <55ACCA58.1040804@redhat.com> Message-ID: <55ACF527.4000104@redhat.com> Hi Emily, thanks for the feedback. We're currently busy with other releases but I'll try to get 2.2.15.Final released soon. Jozef On 20.7.2015 14:43, Emily Jiang wrote: > The test applications we used were attached to the jira > https://developer.jboss.org/message/926035#926035. > > You can compare the responding time between two servlet requests. > > Can you commit the current changes in the release 2.2.15.Final because > I plan to consume this release for other jira fixes as well? > Thanks > Emily > > On Mon, Jul 20, 2015 at 11:15 AM, Martin Kouba > wrote: > > Hi Emily, > > it's great to hear there is a performance improvement (although 1% > is not that much). We're working on further performance improvements > in this area [1]. > > However, 23% additional overhead seems to me too much. Would it be > possible to share your performance test case / test application? We > could run similar tests in our environment and verify that there's > no integration problem. > > Martin > > [1] > https://issues.jboss.org/browse/WELD-1970 > > > Dne 20.7.2015 v 11:12 Emily Jiang napsal(a): > > Hi Jozef, Martin, > > Sorry for the delay! I have the performance figure collected > eventually. > With this Jira's changes, it shows 1% performance improvement. > This is a > step in the right direction but there is still a performance hit > (23% > worse) when turning on CDI. Would you like to commit this change > so that > I can reconsume this release? It will be great if a further > performance > improvement can be done. I am happy to collect the performance > benchmark > if needed. > > Thanks > Emily > > On Thu, Jul 2, 2015 at 8:35 AM, Jozef Hartinger > > >> wrote: > > Hi Emily, > > that should not be a problem. Would it be possible for you > to test > the performance improvement before we actually do the > release? I can > prepare a separate branch or send you a binary. I would > like to see > how much improvement this makes in your benchmark. > > Jozef > > > On 07/01/2015 06:19 PM, Emily Jiang wrote: > > Is it possible to get the following jira fix committed to > 2.2.15.Final? > > https://issues.jboss.org/browse/WELD-1931 > > I would like to consume this and see how much > improvement has been > made. > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org From emijiang6 at googlemail.com Tue Jul 21 07:31:09 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Tue, 21 Jul 2015 12:31:09 +0100 Subject: [weld-dev] Weld Performance improvement In-Reply-To: <55ACF527.4000104@redhat.com> References: <5594E9CB.3090501@redhat.com> <55ACCA58.1040804@redhat.com> <55ACF527.4000104@redhat.com> Message-ID: Thank you Jozef and Martin! I am looking forward to consume 2.2.15.Final. On Mon, Jul 20, 2015 at 2:18 PM, Jozef Hartinger wrote: > Hi Emily, > > thanks for the feedback. We're currently busy with other releases but I'll > try to get 2.2.15.Final released soon. > > Jozef > > On 20.7.2015 14:43, Emily Jiang wrote: > >> The test applications we used were attached to the jira >> https://developer.jboss.org/message/926035#926035. >> >> You can compare the responding time between two servlet requests. >> >> Can you commit the current changes in the release 2.2.15.Final because >> I plan to consume this release for other jira fixes as well? >> Thanks >> Emily >> >> On Mon, Jul 20, 2015 at 11:15 AM, Martin Kouba > > wrote: >> >> Hi Emily, >> >> it's great to hear there is a performance improvement (although 1% >> is not that much). We're working on further performance improvements >> in this area [1]. >> >> However, 23% additional overhead seems to me too much. Would it be >> possible to share your performance test case / test application? We >> could run similar tests in our environment and verify that there's >> no integration problem. >> >> Martin >> >> [1] >> https://issues.jboss.org/browse/WELD-1970 >> >> >> Dne 20.7.2015 v 11:12 Emily Jiang napsal(a): >> >> Hi Jozef, Martin, >> >> Sorry for the delay! I have the performance figure collected >> eventually. >> With this Jira's changes, it shows 1% performance improvement. >> This is a >> step in the right direction but there is still a performance hit >> (23% >> worse) when turning on CDI. Would you like to commit this change >> so that >> I can reconsume this release? It will be great if a further >> performance >> improvement can be done. I am happy to collect the performance >> benchmark >> if needed. >> >> Thanks >> Emily >> >> On Thu, Jul 2, 2015 at 8:35 AM, Jozef Hartinger >> >> >> wrote: >> >> Hi Emily, >> >> that should not be a problem. Would it be possible for you >> to test >> the performance improvement before we actually do the >> release? I can >> prepare a separate branch or send you a binary. I would >> like to see >> how much improvement this makes in your benchmark. >> >> Jozef >> >> >> On 07/01/2015 06:19 PM, Emily Jiang wrote: >> >> Is it possible to get the following jira fix committed to >> 2.2.15.Final? >> >> https://issues.jboss.org/browse/WELD-1931 >> >> I would like to consume this and see how much >> improvement has been >> made. >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > >> >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > >> >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150721/e414fb30/attachment.html From emijiang6 at googlemail.com Tue Jul 21 16:35:19 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Tue, 21 Jul 2015 21:35:19 +0100 Subject: [weld-dev] cdi extension - unique bean name Message-ID: I have a question on the CDI extension. I would like to define an extension which is shared among the modules such as multiple war modules and be able to access all war modules. However, I got the following error WELD-001414: Bean name is ambiguous. Name echo resolves to beans: as there are same bean names in multiple wars. Is it possible to switch off the unique bean name checks for some extensions? Do you have any suggestions on how to resolve the problem. -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150721/de8ea31c/attachment-0001.html From jharting at redhat.com Wed Jul 22 03:08:35 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Wed, 22 Jul 2015 09:08:35 +0200 Subject: [weld-dev] cdi extension - unique bean name In-Reply-To: References: Message-ID: <55AF4173.6090505@redhat.com> Hi Emily, can you elaborate a bit more how your extension looks like? If the bean registered by an extension is really shared across wars there should be no ambiguous resolutions. Jozef On 21.7.2015 22:35, Emily Jiang wrote: > > I have a question on the CDI extension. I would like to define an > extension which is shared among the modules such as multiple war modules > and be able to access all war modules. However, I got the following > error WELD-001414: Bean name is ambiguous. Name echo resolves to beans: > as there are same bean names in multiple wars. Is it possible to switch > off the unique bean name checks for some extensions? Do you have any > suggestions on how to resolve the problem. > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > From emijiang6 at googlemail.com Wed Jul 22 04:14:01 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 22 Jul 2015 09:14:01 +0100 Subject: [weld-dev] cdi extension - unique bean name In-Reply-To: <55AF4173.6090505@redhat.com> References: <55AF4173.6090505@redhat.com> Message-ID: Hi Jozef, The extension I am referred to is jsf extension, FlowBuilderCDIExtension, which registers the bean FlowBuilderFactoryBean. This FlowBuilderFactoryBean tries to get all instances of Flows: @Inject @Any private Instance flowDefinitions; On Wed, Jul 22, 2015 at 8:08 AM, Jozef Hartinger wrote: > Hi Emily, > > can you elaborate a bit more how your extension looks like? If the bean > registered by an extension is really shared across wars there should be no > ambiguous resolutions. > > Jozef > > > On 21.7.2015 22:35, Emily Jiang wrote: > >> >> I have a question on the CDI extension. I would like to define an >> extension which is shared among the modules such as multiple war modules >> and be able to access all war modules. However, I got the following >> error WELD-001414: Bean name is ambiguous. Name echo resolves to beans: >> as there are same bean names in multiple wars. Is it possible to switch >> off the unique bean name checks for some extensions? Do you have any >> suggestions on how to resolve the problem. >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150722/b227a47a/attachment.html From emijiang6 at googlemail.com Wed Jul 22 04:19:50 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Wed, 22 Jul 2015 09:19:50 +0100 Subject: [weld-dev] cdi extension - unique bean name In-Reply-To: References: <55AF4173.6090505@redhat.com> Message-ID: continued: The issue is that when it comes to do the validation, Weld insists all bean names must be unique among all the beans which this extension can see. This extension does not need to use el. What is the point to do the upfront validation? Is it possible to switch off this unique bean name validation for some bdas or only throw an exception when it cannot resolve el successfully? On Wed, Jul 22, 2015 at 9:14 AM, Emily Jiang wrote: > Hi Jozef, > > The extension I am referred to is jsf extension, FlowBuilderCDIExtension, > which registers the bean FlowBuilderFactoryBean. This > FlowBuilderFactoryBean tries to get all instances of Flows: > @Inject > @Any > private Instance flowDefinitions; > > On Wed, Jul 22, 2015 at 8:08 AM, Jozef Hartinger > wrote: > >> Hi Emily, >> >> can you elaborate a bit more how your extension looks like? If the bean >> registered by an extension is really shared across wars there should be no >> ambiguous resolutions. >> >> Jozef >> >> >> On 21.7.2015 22:35, Emily Jiang wrote: >> >>> >>> I have a question on the CDI extension. I would like to define an >>> extension which is shared among the modules such as multiple war modules >>> and be able to access all war modules. However, I got the following >>> error WELD-001414: Bean name is ambiguous. Name echo resolves to beans: >>> as there are same bean names in multiple wars. Is it possible to switch >>> off the unique bean name checks for some extensions? Do you have any >>> suggestions on how to resolve the problem. >>> -- >>> Thanks >>> Emily >>> ================= >>> Emily Jiang >>> ejiang at apache.org >>> >>> >>> _______________________________________________ >>> weld-dev mailing list >>> weld-dev at lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/weld-dev >>> >>> > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150722/94f00f4b/attachment.html From jharting at redhat.com Thu Jul 23 03:59:51 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 23 Jul 2015 09:59:51 +0200 Subject: [weld-dev] cdi extension - unique bean name In-Reply-To: References: <55AF4173.6090505@redhat.com> Message-ID: <55B09EF7.5030301@redhat.com> Hi Emily, is the bean supposed to see all the flows in all the wars in the ear? Won't this then break isolation of web apps (e.g. war1 seeing flow defined in war2)? Jozef On 22.7.2015 10:19, Emily Jiang wrote: > continued: > The issue is that when it comes to do the validation, Weld insists all > bean names must be unique among all the beans which this extension can > see. This extension does not need to use el. What is the point to do the > upfront validation? Is it possible to switch off this unique bean name > validation for some bdas or only throw an exception when it cannot > resolve el successfully? > > On Wed, Jul 22, 2015 at 9:14 AM, Emily Jiang > wrote: > > Hi Jozef, > > The extension I am referred to is jsf extension, > FlowBuilderCDIExtension, which registers the bean > FlowBuilderFactoryBean. This FlowBuilderFactoryBean tries to get all > instances of Flows: > @Inject > @Any > private Instance flowDefinitions; > > On Wed, Jul 22, 2015 at 8:08 AM, Jozef Hartinger > > wrote: > > Hi Emily, > > can you elaborate a bit more how your extension looks like? If > the bean registered by an extension is really shared across wars > there should be no ambiguous resolutions. > > Jozef > > > On 21.7.2015 22:35, Emily Jiang wrote: > > > I have a question on the CDI extension. I would like to > define an > extension which is shared among the modules such as multiple > war modules > and be able to access all war modules. However, I got the > following > error WELD-001414: Bean name is ambiguous. Name echo > resolves to beans: > as there are same bean names in multiple wars. Is it > possible to switch > off the unique bean name checks for some extensions? Do you > have any > suggestions on how to resolve the problem. > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org > > > > > -- > Thanks > Emily > ================= > Emily Jiang > ejiang at apache.org From jharting at redhat.com Thu Jul 23 07:27:30 2015 From: jharting at redhat.com (Jozef Hartinger) Date: Thu, 23 Jul 2015 13:27:30 +0200 Subject: [weld-dev] Weld 2.3.0.Beta3 Message-ID: <55B0CFA2.1020303@redhat.com> Weld 2.3.0.Beta3 has been released. Release notes: https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310891&version=12327574 Download: http://download.jboss.org/weld/2.3.0.Beta3/weld-2.3.0.Beta3.zip Patch for WildFly 10: http://download.jboss.org/weld/2.3.0.Beta3/wildfly-10.0.0.Alpha5-weld-2.3.0.Beta3-patch.zip From emijiang6 at googlemail.com Mon Jul 27 05:03:04 2015 From: emijiang6 at googlemail.com (Emily Jiang) Date: Mon, 27 Jul 2015 10:03:04 +0100 Subject: [weld-dev] cdi extension - unique bean name In-Reply-To: <55B09EF7.5030301@redhat.com> References: <55AF4173.6090505@redhat.com> <55B09EF7.5030301@redhat.com> Message-ID: Thank you Jozef! You have the valid point. On Thu, Jul 23, 2015 at 8:59 AM, Jozef Hartinger wrote: > Hi Emily, > > is the bean supposed to see all the flows in all the wars in the ear? > Won't this then break isolation of web apps (e.g. war1 seeing flow defined > in war2)? > > Jozef > > On 22.7.2015 10:19, Emily Jiang wrote: > >> continued: >> The issue is that when it comes to do the validation, Weld insists all >> bean names must be unique among all the beans which this extension can >> see. This extension does not need to use el. What is the point to do the >> upfront validation? Is it possible to switch off this unique bean name >> validation for some bdas or only throw an exception when it cannot >> resolve el successfully? >> >> On Wed, Jul 22, 2015 at 9:14 AM, Emily Jiang > > wrote: >> >> Hi Jozef, >> >> The extension I am referred to is jsf extension, >> FlowBuilderCDIExtension, which registers the bean >> FlowBuilderFactoryBean. This FlowBuilderFactoryBean tries to get all >> instances of Flows: >> @Inject >> @Any >> private Instance flowDefinitions; >> >> On Wed, Jul 22, 2015 at 8:08 AM, Jozef Hartinger >> > wrote: >> >> Hi Emily, >> >> can you elaborate a bit more how your extension looks like? If >> the bean registered by an extension is really shared across wars >> there should be no ambiguous resolutions. >> >> Jozef >> >> >> On 21.7.2015 22:35, Emily Jiang wrote: >> >> >> I have a question on the CDI extension. I would like to >> define an >> extension which is shared among the modules such as multiple >> war modules >> and be able to access all war modules. However, I got the >> following >> error WELD-001414: Bean name is ambiguous. Name echo >> resolves to beans: >> as there are same bean names in multiple wars. Is it >> possible to switch >> off the unique bean name checks for some extensions? Do you >> have any >> suggestions on how to resolve the problem. >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > >> >> >> _______________________________________________ >> weld-dev mailing list >> weld-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/weld-dev >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> >> >> >> >> -- >> Thanks >> Emily >> ================= >> Emily Jiang >> ejiang at apache.org >> > -- Thanks Emily ================= Emily Jiang ejiang at apache.org -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150727/fffb3771/attachment-0001.html