From jan-willem at youngmediaexperts.nl  Mon Aug  8 11:36:40 2016
From: jan-willem at youngmediaexperts.nl (Jan-Willem Gmelig Meyling)
Date: Mon, 8 Aug 2016 17:36:40 +0200
Subject: [weld-dev] Proper way to get to EnhancedAnnotatedConstructor (CDI
 autofactories implementation)
Message-ID: <28200472-1B27-423D-9698-9D8D9AD8483B@youngmediaexperts.nl>

Hello everyone,


I am in the process of patching the softwaremill-common CDI extensions [1] from Weld 1.1 to Weld 2.x. I am currently working on their extension for autofactories. I stumbled upon the following piece of code I would like to migrate:

            CurrentInjectionPoint currentInjectionPoint = Container.instance().services().get(CurrentInjectionPoint.class);
            currentInjectionPoint.push(ConstructorInjectionPoint.of(bean, (WeldConstructor<T>) createdTypeData.getCreatedTypeConstructor()));
            instance = newInstance(parameters);
            currentInjectionPoint.pop();

Source: [2]

I see how the pop should now be invoked on the `ThreadLocalStackReference` returned by the push method. I have also found the InjectionPointFactory#createConstructorInjectionPoint(Bean, Class, EnhancedAnnotatedConstructor, BeanManagerImpl) method [3]. Now I am wondering how I can get to the `EnhancedAnnotatedConstructor`, as the approach I am currently using feels plain wrong.

My code:

            CurrentInjectionPoint currentInjectionPoint = Container.instance().services().get(CurrentInjectionPoint.class);
            Class<?> declaringComponentClass = (Class<T>) createdTypeData.getCreatedTypeConstructor().getBaseType();


            BeanManagerImpl manager = ((BeanManagerProxy) beanManager).delegate();
            EnhancedAnnotatedConstructor<T> constructor = (EnhancedAnnotatedConstructor<T>) manager
                .createEnhancedAnnotatedType(declaringComponentClass)
                .getEnhancedConstructors()
                .stream().findAny().get();

            ConstructorInjectionPoint<T> actualInjectionPoint = InjectionPointFactory.instance()
                .createConstructorInjectionPoint(bean, declaringComponentClass, constructor, manager);
            ThreadLocalStackReference<InjectionPoint> ref = currentInjectionPoint.push(actualInjectionPoint);
            instance = newInstance(parameters);


My code is also available on Github at [4]. My question is also posted on Stackoverflow [5], so points will be awarded for the answer.

Thanks in advance!

Jan-Willem Gmelig Meyling




[1] https://github.com/softwaremill/softwaremill-common/tree/master/softwaremill-cdi <https://github.com/softwaremill/softwaremill-common/tree/master/softwaremill-cdi>
[2] https://github.com/softwaremill/softwaremill-common/blob/master/softwaremill-cdi/src/main/java/com/softwaremill/common/cdi/autofactory/extension/FactoryInvocationHandler.java#L35-L48 <https://github.com/softwaremill/softwaremill-common/blob/master/softwaremill-cdi/src/main/java/com/softwaremill/common/cdi/autofactory/extension/FactoryInvocationHandler.java#L35-L48>
[3] http://javadox.com/org.jboss.weld.servlet/weld-servlet/2.3.1.Final/org/jboss/weld/injection/InjectionPointFactory.html#createConstructorInjectionPoint-javax.enterprise.inject.spi.Bean-java.lang.Class-org.jboss.weld.annotated.enhanced.EnhancedAnnotatedConstructor-org.jboss.weld.manager.BeanManagerImpl- <http://javadox.com/org.jboss.weld.servlet/weld-servlet/2.3.1.Final/org/jboss/weld/injection/InjectionPointFactory.html#createConstructorInjectionPoint-javax.enterprise.inject.spi.Bean-java.lang.Class-org.jboss.weld.annotated.enhanced.EnhancedAnnotatedConstructor-org.jboss.weld.manager.BeanManagerImpl->
[4] https://github.com/JWGmeligMeyling/cdi-autofactories/blob/8346cf269d73a8bd455c12c4d467df7bcb8f3920/src/main/java/com/softwaremill/common/cdi/autofactory/extension/FactoryInvocationHandler.java#L50-L60 <https://github.com/JWGmeligMeyling/cdi-autofactories/blob/8346cf269d73a8bd455c12c4d467df7bcb8f3920/src/main/java/com/softwaremill/common/cdi/autofactory/extension/FactoryInvocationHandler.java#L50-L60>
[5] http://stackoverflow.com/questions/38436110/proper-way-to-get-enhancedannotatedconstructor <http://stackoverflow.com/questions/38436110/proper-way-to-get-enhancedannotatedconstructor>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20160808/33658934/attachment.html 

From mkouba at redhat.com  Tue Aug  9 08:05:12 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Tue, 9 Aug 2016 14:05:12 +0200
Subject: [weld-dev] Proper way to get to EnhancedAnnotatedConstructor
 (CDI autofactories implementation)
In-Reply-To: <28200472-1B27-423D-9698-9D8D9AD8483B@youngmediaexperts.nl>
References: <28200472-1B27-423D-9698-9D8D9AD8483B@youngmediaexperts.nl>
Message-ID: <58392ad1-c9ae-a6f6-919f-826b9ac24325@redhat.com>

Hi Jan-Willem,

first of all it's not a good idea to depend on Weld internals - the 
implementation can change any time without any warning. On the other 
hand, I understand that you're just "patching" an existing extension.

WRT the way to get to the EnhancedAnnotatedConstructor - there is 
org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(Bean<T>, 
EnhancedAnnotatedType<T>, BeanManagerImpl) which itself performs the 
lookup (and attempts to find a bean constructor as defined in 3.9. Bean 
constructors).

Moreover, you should probably use a "silent" instance of 
InjectionPointFactory, otherwise ProcessInjectionPoint event will be 
fired for each injection point created.

Also I would recommend to analyze the extension code so that it's clear 
what exactly is missing in the CDI 1.2 extension SPI (a lot of stuff was 
added since CDI 1.0/Weld 1). This will help improve the CDI 2.0 SPI 
(under development).

Martin

Dne 8.8.2016 v 17:36 Jan-Willem Gmelig Meyling napsal(a):
> Hello everyone,
>
>
> I am in the process of patching the softwaremill-common CDI extensions
> [1] from Weld 1.1 to Weld 2.x. I am currently working on their extension
> for autofactories. I stumbled upon the following piece of code I would
> like to migrate:
>
>             CurrentInjectionPoint currentInjectionPoint =
> Container.instance().services().get(CurrentInjectionPoint.class);
>
> currentInjectionPoint.push(ConstructorInjectionPoint.of(bean,
> (WeldConstructor<T>) createdTypeData.getCreatedTypeConstructor()));
>             instance = newInstance(parameters);
>             currentInjectionPoint.pop();
>
> Source: [2]
>
> I see how the pop should now be invoked on the
> `ThreadLocalStackReference` returned by the push method. I have also
> found the InjectionPointFactory#createConstructorInjectionPoint(Bean,
> Class, EnhancedAnnotatedConstructor, BeanManagerImpl) method [3]. Now I
> am wondering how I can get to the `EnhancedAnnotatedConstructor`, as the
> approach I am currently using feels plain wrong.
>
> My code:
>
>             CurrentInjectionPoint currentInjectionPoint =
> Container.instance().services().get(CurrentInjectionPoint.class);
>             Class<?> declaringComponentClass = (Class<T>)
> createdTypeData.getCreatedTypeConstructor().getBaseType();
>
>
>             BeanManagerImpl manager = ((BeanManagerProxy)
> beanManager).delegate();
>             EnhancedAnnotatedConstructor<T> constructor =
> (EnhancedAnnotatedConstructor<T>) manager
>                 .createEnhancedAnnotatedType(declaringComponentClass)
>                 .getEnhancedConstructors()
>                 .stream().findAny().get();
>
>             ConstructorInjectionPoint<T> actualInjectionPoint =
> InjectionPointFactory.instance()
>                 .createConstructorInjectionPoint(bean,
> declaringComponentClass, constructor, manager);
>             ThreadLocalStackReference<InjectionPoint> ref =
> currentInjectionPoint.push(actualInjectionPoint);
>             instance = newInstance(parameters);
>
>
> My code is also available on Github at [4]. My question is also posted
> on Stackoverflow [5], so points will be awarded for the answer.
>
> Thanks in advance!
>
> Jan-Willem Gmelig Meyling
>
>
>
>
> [1]
> https://github.com/softwaremill/softwaremill-common/tree/master/softwaremill-cdi
> [2] https://github.com/softwaremill/softwaremill-common/blob/master/softwaremill-cdi/src/main/java/com/softwaremill/common/cdi/autofactory/extension/FactoryInvocationHandler.java#L35-L48
> [3]
> http://javadox.com/org.jboss.weld.servlet/weld-servlet/2.3.1.Final/org/jboss/weld/injection/InjectionPointFactory.html#createConstructorInjectionPoint-javax.enterprise.inject.spi.Bean-java.lang.Class-org.jboss.weld.annotated.enhanced.EnhancedAnnotatedConstructor-org.jboss.weld.manager.BeanManagerImpl-
> [4] https://github.com/JWGmeligMeyling/cdi-autofactories/blob/8346cf269d73a8bd455c12c4d467df7bcb8f3920/src/main/java/com/softwaremill/common/cdi/autofactory/extension/FactoryInvocationHandler.java#L50-L60
> [5] http://stackoverflow.com/questions/38436110/proper-way-to-get-enhancedannotatedconstructor
>
>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From john.d.ament at gmail.com  Sun Aug 14 19:03:41 2016
From: john.d.ament at gmail.com (John D. Ament)
Date: Sun, 14 Aug 2016 23:03:41 +0000
Subject: [weld-dev] How to avoid this warning message?
Message-ID: <CAOqetn81=sxA3pJmruuF51KPVPQmJSqaH0XNqN6qjE91hQQmng@mail.gmail.com>

https://lists.apache.org/thread.html/8edcc676c2dbede50f7e75cc56c4d78d260357df527347a1ff155402@%3Cusers.deltaspike.apache.org%3E
for
some reference

Somewhere between 1.6 and 1.7 this started popping up on DS.  Even though
these methods are defined in the class hierarchy, they are transitively
inherited.  Is DS not picking them up because AbstractEntityRepository
doesn't directly implement the other interfaces?

John
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20160814/8af8ef7d/attachment-0001.html 

From john.d.ament at gmail.com  Sun Aug 14 19:24:17 2016
From: john.d.ament at gmail.com (John D. Ament)
Date: Sun, 14 Aug 2016 23:24:17 +0000
Subject: [weld-dev] How to avoid this warning message?
In-Reply-To: <CAOqetn81=sxA3pJmruuF51KPVPQmJSqaH0XNqN6qjE91hQQmng@mail.gmail.com>
References: <CAOqetn81=sxA3pJmruuF51KPVPQmJSqaH0XNqN6qjE91hQQmng@mail.gmail.com>
Message-ID: <CAOqetn-jK0yGjyz7oFZ1Yf28N9xzZFrkxxan59-YoULHzoUebg@mail.gmail.com>

Yep, it was the inheritance.  Any idea why though?

https://git1-us-west.apache.org/repos/asf?p=deltaspike.git;a=blobdiff;f=deltaspike/modules/data/api/src/main/java/org/apache/deltaspike/data/api/AbstractEntityRepository.java;h=529c474d8a84837ccfb2fb6693ec651f65ff8b3e;hp=933c136abf58efde4bba7dc5cf8944d711d92d40;hb=bb9abfcc;hpb=6d4fbd8e6a50555ed70c06b4a10669e7e6f403d1

John

On Sun, Aug 14, 2016 at 7:03 PM John D. Ament <john.d.ament at gmail.com>
wrote:

>
> https://lists.apache.org/thread.html/8edcc676c2dbede50f7e75cc56c4d78d260357df527347a1ff155402@%3Cusers.deltaspike.apache.org%3E for
> some reference
>
> Somewhere between 1.6 and 1.7 this started popping up on DS.  Even though
> these methods are defined in the class hierarchy, they are transitively
> inherited.  Is DS not picking them up because AbstractEntityRepository
> doesn't directly implement the other interfaces?
>
> John
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20160814/f155e1e5/attachment.html 

From mkouba at redhat.com  Mon Aug 15 04:21:31 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 15 Aug 2016 10:21:31 +0200
Subject: [weld-dev] How to avoid this warning message?
In-Reply-To: <CAOqetn-jK0yGjyz7oFZ1Yf28N9xzZFrkxxan59-YoULHzoUebg@mail.gmail.com>
References: <CAOqetn81=sxA3pJmruuF51KPVPQmJSqaH0XNqN6qjE91hQQmng@mail.gmail.com>
	<CAOqetn-jK0yGjyz7oFZ1Yf28N9xzZFrkxxan59-YoULHzoUebg@mail.gmail.com>
Message-ID: <4c3557e6-69ac-67d7-5db2-966d7ee67079@redhat.com>

Hi John,

looks like a bug. Weld does not consider extended interfaces. I've 
created WELD-2221 [1] to track this issue.

Martin

[1]
https://issues.jboss.org/browse/WELD-2221


Dne 15.8.2016 v 01:24 John D. Ament napsal(a):
> Yep, it was the inheritance.  Any idea why though?
>
> https://git1-us-west.apache.org/repos/asf?p=deltaspike.git;a=blobdiff;f=deltaspike/modules/data/api/src/main/java/org/apache/deltaspike/data/api/AbstractEntityRepository.java;h=529c474d8a84837ccfb2fb6693ec651f65ff8b3e;hp=933c136abf58efde4bba7dc5cf8944d711d92d40;hb=bb9abfcc;hpb=6d4fbd8e6a50555ed70c06b4a10669e7e6f403d1
>
> John
>
> On Sun, Aug 14, 2016 at 7:03 PM John D. Ament <john.d.ament at gmail.com
> <mailto:john.d.ament at gmail.com>> wrote:
>
>     https://lists.apache.org/thread.html/8edcc676c2dbede50f7e75cc56c4d78d260357df527347a1ff155402@%3Cusers.deltaspike.apache.org%3E for
>     some reference
>
>     Somewhere between 1.6 and 1.7 this started popping up on DS.  Even
>     though these methods are defined in the class hierarchy, they are
>     transitively inherited.  Is DS not picking them up because
>     AbstractEntityRepository doesn't directly implement the other
>     interfaces?
>
>     John
>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From jan-willem at youngmediaexperts.nl  Mon Aug 15 15:37:09 2016
From: jan-willem at youngmediaexperts.nl (Jan-Willem Gmelig Meyling)
Date: Mon, 15 Aug 2016 21:37:09 +0200
Subject: [weld-dev] Proper way to get to EnhancedAnnotatedConstructor
 (CDI autofactories implementation)
In-Reply-To: <58392ad1-c9ae-a6f6-919f-826b9ac24325@redhat.com>
References: <28200472-1B27-423D-9698-9D8D9AD8483B@youngmediaexperts.nl>
	<58392ad1-c9ae-a6f6-919f-826b9ac24325@redhat.com>
Message-ID: <B818080F-C060-4EED-8F4D-3B148DB000EB@youngmediaexperts.nl>

Hi Martin,


Thanks for your response. These are obviously my first steps with CDI and Weld, so I wasn?t familiar with the extension SPI.  I will first try to improve the logic getting to the construction point and then see how much of the code I can make CDI vendor unspecific.

Jan-Willem

> On 09 Aug 2016, at 14:05, Martin Kouba <mkouba at redhat.com> wrote:
> 
> Hi Jan-Willem,
> 
> first of all it's not a good idea to depend on Weld internals - the 
> implementation can change any time without any warning. On the other 
> hand, I understand that you're just "patching" an existing extension.
> 
> WRT the way to get to the EnhancedAnnotatedConstructor - there is 
> org.jboss.weld.injection.InjectionPointFactory.createConstructorInjectionPoint(Bean<T>, 
> EnhancedAnnotatedType<T>, BeanManagerImpl) which itself performs the 
> lookup (and attempts to find a bean constructor as defined in 3.9. Bean 
> constructors).
> 
> Moreover, you should probably use a "silent" instance of 
> InjectionPointFactory, otherwise ProcessInjectionPoint event will be 
> fired for each injection point created.
> 
> Also I would recommend to analyze the extension code so that it's clear 
> what exactly is missing in the CDI 1.2 extension SPI (a lot of stuff was 
> added since CDI 1.0/Weld 1). This will help improve the CDI 2.0 SPI 
> (under development).
> 
> Martin
> 
> Dne 8.8.2016 v 17:36 Jan-Willem Gmelig Meyling napsal(a):
>> Hello everyone,
>> 
>> 
>> I am in the process of patching the softwaremill-common CDI extensions
>> [1] from Weld 1.1 to Weld 2.x. I am currently working on their extension
>> for autofactories. I stumbled upon the following piece of code I would
>> like to migrate:
>> 
>>            CurrentInjectionPoint currentInjectionPoint =
>> Container.instance().services().get(CurrentInjectionPoint.class);
>> 
>> currentInjectionPoint.push(ConstructorInjectionPoint.of(bean,
>> (WeldConstructor<T>) createdTypeData.getCreatedTypeConstructor()));
>>            instance = newInstance(parameters);
>>            currentInjectionPoint.pop();
>> 
>> Source: [2]
>> 
>> I see how the pop should now be invoked on the
>> `ThreadLocalStackReference` returned by the push method. I have also
>> found the InjectionPointFactory#createConstructorInjectionPoint(Bean,
>> Class, EnhancedAnnotatedConstructor, BeanManagerImpl) method [3]. Now I
>> am wondering how I can get to the `EnhancedAnnotatedConstructor`, as the
>> approach I am currently using feels plain wrong.
>> 
>> My code:
>> 
>>            CurrentInjectionPoint currentInjectionPoint =
>> Container.instance().services().get(CurrentInjectionPoint.class);
>>            Class<?> declaringComponentClass = (Class<T>)
>> createdTypeData.getCreatedTypeConstructor().getBaseType();
>> 
>> 
>>            BeanManagerImpl manager = ((BeanManagerProxy)
>> beanManager).delegate();
>>            EnhancedAnnotatedConstructor<T> constructor =
>> (EnhancedAnnotatedConstructor<T>) manager
>>                .createEnhancedAnnotatedType(declaringComponentClass)
>>                .getEnhancedConstructors()
>>                .stream().findAny().get();
>> 
>>            ConstructorInjectionPoint<T> actualInjectionPoint =
>> InjectionPointFactory.instance()
>>                .createConstructorInjectionPoint(bean,
>> declaringComponentClass, constructor, manager);
>>            ThreadLocalStackReference<InjectionPoint> ref =
>> currentInjectionPoint.push(actualInjectionPoint);
>>            instance = newInstance(parameters);
>> 
>> 
>> My code is also available on Github at [4]. My question is also posted
>> on Stackoverflow [5], so points will be awarded for the answer.
>> 
>> Thanks in advance!
>> 
>> Jan-Willem Gmelig Meyling
>> 
>> 
>> 
>> 
>> [1]
>> https://github.com/softwaremill/softwaremill-common/tree/master/softwaremill-cdi
>> [2] https://github.com/softwaremill/softwaremill-common/blob/master/softwaremill-cdi/src/main/java/com/softwaremill/common/cdi/autofactory/extension/FactoryInvocationHandler.java#L35-L48
>> [3]
>> http://javadox.com/org.jboss.weld.servlet/weld-servlet/2.3.1.Final/org/jboss/weld/injection/InjectionPointFactory.html#createConstructorInjectionPoint-javax.enterprise.inject.spi.Bean-java.lang.Class-org.jboss.weld.annotated.enhanced.EnhancedAnnotatedConstructor-org.jboss.weld.manager.BeanManagerImpl-
>> [4] https://github.com/JWGmeligMeyling/cdi-autofactories/blob/8346cf269d73a8bd455c12c4d467df7bcb8f3920/src/main/java/com/softwaremill/common/cdi/autofactory/extension/FactoryInvocationHandler.java#L50-L60
>> [5] http://stackoverflow.com/questions/38436110/proper-way-to-get-enhancedannotatedconstructor
>> 
>> 
>> 
>> 
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>> 
> 
> -- 
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev


From BENJAMIC at uk.ibm.com  Fri Aug 19 08:17:26 2016
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Fri, 19 Aug 2016 12:17:26 +0000
Subject: [weld-dev] ApplicationScoped event fires on service invocation
Message-ID: <OFD807ACA1.BFD0F6C2-ON00258014.0043646F-80258014.00438369@notes.na.collabserv.com>

We have a user scenario where we wishes to replace @Singleton @Startup EJB 
beans with CDI beans. This was attempted by observing the 
ApplicationScoped initialization event to trigger the replacement code.

However, the event was fired only after the service invocation, which was 
too late. Apparently OWB fires this event much earlier. 
The CDI spec states:

The application context is provided by a built-in context object for the 
built-in scope type
@ApplicationScoped. The application scope is active:
? during the service() method of any servlet in the web application, 
during the doFilter()
method of any servlet filter and when the container calls any 
ServletContextListener,
HttpSessionListener, AsyncListener or ServletRequestListener,
? during any Java EE web service invocation,
? during any remote method invocation of any EJB, during any asynchronous 
method invocation
of any EJB, during any call to an EJB timeout method and during message 
delivery to any EJB
message-driven bean,
? when the disposer method or @PreDestroy callback of any bean with any 
normal scope other
than @ApplicationScoped is called, and
? during @PostConstruct callback of any bean.

The application context is shared between all servlet requests, web 
service invocations, EJB
remote method invocations, EJB asynchronous method invocations, EJB 
timeouts and message
deliveries to message-driven beans that execute within the same 
application. The application
context is destroyed when the application is shut down.

An event with qualifier @Initialized(ApplicationScoped.class) is fired 
when the application
context is initialized and an event with qualifier 
@Destroyed(ApplicationScoped.class) is fired
when the application is destroyed. The event payload is:
? the ServletContext if the application is a web application deployed to a 
Servlet container, or
? any java.lang.Object for other types of application.

How do you interpret "initialized"? Does it mean the event is fired only 
after the context is active?

Is it possible to make the event firing a bit earlier, say around 
AfterDeploymentValidation?

Below is the app to demonstrate the timing along with the server.xml:




And here is the results of running it


[AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
[AUDIT   ] CWWKE0100I: This product is licensed for development, and 
limited production use. The full license terms can be viewed here: 
https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/16.0.0.2/lafiles/en.html
[AUDIT   ] CWWKZ0058I: Monitoring dropins for applications. 
---> ApplicationScopedExtension, AfterDeploymentValidation event received, 
before looking up and touching @ApplicationScoped dummy bean
---> ApplicationScopedDummyBean, @PostConstruct init method called
---> ApplicationScopedExtension, after looking up and touching 
@ApplicationScoped dummy bean
[AUDIT   ] CWWKT0016I: Web application available (default_host): 
http://localhost:9080/70383.180.846.test-application/
---> ApplicationScopedObserverBean, observed 
@Initialized(ApplicationScoped.class) event.
[AUDIT   ] CWWKZ0001I: Application 70383.180.846.test-application started 
in 1.165 seconds.
[AUDIT   ] CWWKF0012I: The server installed the following features: 
[jsp-2.3, ejbLite-3.2, managedBeans-1.0, jsf-2.2, beanValidation-1.1, 
servlet-3.1, ssl-1.0, jndi-1.0, jsonp-1.0, appSecurity-2.0, jdbc-4.1, 
jaxrs-2.0, jaxrsClient-2.0, el-3.0, json-1.0, cdi-1.2, distributedMap-1.0, 
webProfile-7.0, websocket-1.1, jpa-2.1].
[AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a smarter 
planet.

As you can see, the ApplicationScopedDummyBean, @PostConstruct init method 
called proves that the applicationContext was active before the event was 
fired. Why is this applicationscoped initialization event not fired 
earlier?


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

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/20160819/daa0b632/attachment-0001.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-application.war
Type: application/octet-stream
Size: 5489 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/weld-dev/attachments/20160819/daa0b632/attachment-0002.obj 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test-application-source.zip
Type: application/zip
Size: 4092 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/weld-dev/attachments/20160819/daa0b632/attachment-0001.zip 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: server.xml
Type: application/octet-stream
Size: 599 bytes
Desc: not available
Url : http://lists.jboss.org/pipermail/weld-dev/attachments/20160819/daa0b632/attachment-0003.obj 

From mkouba at redhat.com  Fri Aug 19 09:35:16 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Fri, 19 Aug 2016 15:35:16 +0200
Subject: [weld-dev] ApplicationScoped event fires on service invocation
In-Reply-To: <OFD807ACA1.BFD0F6C2-ON00258014.0043646F-80258014.00438369@notes.na.collabserv.com>
References: <OFD807ACA1.BFD0F6C2-ON00258014.0043646F-80258014.00438369@notes.na.collabserv.com>
Message-ID: <4ed8e7c0-2a26-b9d8-5cbb-995baa73b7c4@redhat.com>

Hi Benjanmin,

for a web application the payload of 
@Initialized(ApplicationScoped.class) must be the relevant 
ServletContext. That's why Weld is waiting for a webapp to be ready 
(implemented as 
javax.servlet.ServletContextListener.contextInitialized(ServletContextEvent)).

Martin

Dne 19.8.2016 v 14:17 Benjamin Confino napsal(a):
> We have a user scenario where we wishes to replace @Singleton @Startup
> EJB beans with CDI beans. This was attempted by observing the
> ApplicationScoped initialization event to trigger the replacement code.
>
> However, the event was fired only after the service invocation, which
> was too late. Apparently OWB fires this event much earlier.
> The CDI spec states:
>
> The /application context /is provided by a built-in context object for
> the built-in scope type
> @ApplicationScoped. The application scope is active:
> ? during the service() method of any servlet in the web application,
> during the doFilter()
> method of any servlet filter and when the container calls any
> ServletContextListener,
> HttpSessionListener, AsyncListener or ServletRequestListener,
> ? during any Java EE web service invocation,
> ? during any remote method invocation of any EJB, during any
> asynchronous method invocation
> of any EJB, during any call to an EJB timeout method and during message
> delivery to any EJB
> message-driven bean,
> ? when the disposer method or @PreDestroy callback of any bean with any
> normal scope other
> than @ApplicationScoped is called, and
> *? during **@PostConstruct **callback of any bean.*
>
> The application context is shared between all servlet requests, web
> service invocations, EJB
> remote method invocations, EJB asynchronous method invocations, EJB
> timeouts and message
> deliveries to message-driven beans that execute within the same
> application. The application
> context is destroyed when the application is shut down.
>
> An event with qualifier @Initialized(ApplicationScoped.class) is fired
> when the application
> context is initialized and an event with qualifier
> @Destroyed(ApplicationScoped.class) is fired
> when the application is destroyed. The event payload is:
> ? the ServletContext if the application is a web application deployed to
> a Servlet container, or
> ? any java.lang.Object for other types of application.
>
> How do you interpret "initialized"? Does it mean the event is fired only
> after the context is *active?*
>
> Is it possible to make the event firing a bit earlier, say around
> AfterDeploymentValidation?
>
> Below is the app to demonstrate the timing along with the server.xml:
>
>
>
>
> And here is the results of running it
>
>
> [AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
> [AUDIT   ] CWWKE0100I: This product is licensed for development, and
> limited production use. The full license terms can be viewed here:
> https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/16.0.0.2/lafiles/en.html
>
> [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
> *---> ApplicationScopedExtension, AfterDeploymentValidation event
> received, before looking up and touching @ApplicationScoped dummy bean*
> *---> ApplicationScopedDummyBean, @PostConstruct init method called*
> *---> ApplicationScopedExtension, after looking up and touching
> @ApplicationScoped dummy bean*
> [AUDIT   ] CWWKT0016I: Web application available (default_host):
> http://localhost:9080/70383.180.846.test-application/
> *---> ApplicationScopedObserverBean, observed
> @Initialized(ApplicationScoped.class) event.*
> [AUDIT   ] CWWKZ0001I: Application 70383.180.846.test-application
> started in 1.165 seconds.
> [AUDIT   ] CWWKF0012I: The server installed the following features:
> [jsp-2.3, ejbLite-3.2, managedBeans-1.0, jsf-2.2, beanValidation-1.1,
> servlet-3.1, ssl-1.0, jndi-1.0, jsonp-1.0, appSecurity-2.0, jdbc-4.1,
> jaxrs-2.0, jaxrsClient-2.0, el-3.0, json-1.0, cdi-1.2,
> distributedMap-1.0, webProfile-7.0, websocket-1.1, jpa-2.1].
> [AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a
> smarter planet.
>
> As you can see, the *ApplicationScopedDummyBean, @PostConstruct init
> method called*proves that the applicationContext was active before the
> event was fired. Why is this applicationscoped initialization event not
> fired earlier?
>
>
> 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
>
> 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
Software Engineer
Red Hat, Czech Republic

From struberg at yahoo.de  Sun Aug 21 06:32:12 2016
From: struberg at yahoo.de (Mark Struberg)
Date: Sun, 21 Aug 2016 10:32:12 +0000 (UTC)
Subject: [weld-dev] ApplicationScoped event fires on service invocation
In-Reply-To: <4ed8e7c0-2a26-b9d8-5cbb-995baa73b7c4@redhat.com>
References: <OFD807ACA1.BFD0F6C2-ON00258014.0043646F-80258014.00438369@notes.na.collabserv.com>
	<4ed8e7c0-2a26-b9d8-5cbb-995baa73b7c4@redhat.com>
Message-ID: <444910677.472144.1471775532833@mail.yahoo.com>

But the ServletContextEvent is available much earlier.
I think this might rather be an integration issue. 


In OWB we don't fire the @Intialized for the ApplicationContext inside the ApplicationContext implementation but as part of the integration code, means TomEE, Geronimo, SAP, etc.

The interplay and boot order between EJB @Startup @Singleton and the CDI container is imo not really well defined. We just did what we think is best. Afair that means that in TomEE we fire the @Initialized _before_ we do @Startup but _after_ all the metadata parsing and EJB and CDI Extension handling was done. 


LieGrue,
strub





> On Friday, 19 August 2016, 15:37, Martin Kouba <mkouba at redhat.com> wrote:
> > Hi Benjanmin,
> 
> for a web application the payload of 
> @Initialized(ApplicationScoped.class) must be the relevant 
> ServletContext. That's why Weld is waiting for a webapp to be ready 
> (implemented as 
> javax.servlet.ServletContextListener.contextInitialized(ServletContextEvent)).
> 
> Martin
> 
> Dne 19.8.2016 v 14:17 Benjamin Confino napsal(a):
>>  We have a user scenario where we wishes to replace @Singleton @Startup
>>  EJB beans with CDI beans. This was attempted by observing the
>>  ApplicationScoped initialization event to trigger the replacement code.
>> 
>>  However, the event was fired only after the service invocation, which
>>  was too late. Apparently OWB fires this event much earlier.
>>  The CDI spec states:
>> 
>>  The /application context /is provided by a built-in context object for
>>  the built-in scope type
>>  @ApplicationScoped. The application scope is active:
>>  ? during the service() method of any servlet in the web application,
>>  during the doFilter()
>>  method of any servlet filter and when the container calls any
>>  ServletContextListener,
>>  HttpSessionListener, AsyncListener or ServletRequestListener,
>>  ? during any Java EE web service invocation,
>>  ? during any remote method invocation of any EJB, during any
>>  asynchronous method invocation
>>  of any EJB, during any call to an EJB timeout method and during message
>>  delivery to any EJB
>>  message-driven bean,
>>  ? when the disposer method or @PreDestroy callback of any bean with any
>>  normal scope other
>>  than @ApplicationScoped is called, and
>>  *? during **@PostConstruct **callback of any bean.*
>> 
>>  The application context is shared between all servlet requests, web
>>  service invocations, EJB
>>  remote method invocations, EJB asynchronous method invocations, EJB
>>  timeouts and message
>>  deliveries to message-driven beans that execute within the same
>>  application. The application
>>  context is destroyed when the application is shut down.
>> 
>>  An event with qualifier @Initialized(ApplicationScoped.class) is fired
>>  when the application
>>  context is initialized and an event with qualifier
>>  @Destroyed(ApplicationScoped.class) is fired
>>  when the application is destroyed. The event payload is:
>>  ? the ServletContext if the application is a web application deployed to
>>  a Servlet container, or
>>  ? any java.lang.Object for other types of application.
>> 
>>  How do you interpret "initialized"? Does it mean the event is 
> fired only
>>  after the context is *active?*
>> 
>>  Is it possible to make the event firing a bit earlier, say around
>>  AfterDeploymentValidation?
>> 
>>  Below is the app to demonstrate the timing along with the server.xml:
>> 
>> 
>> 
>> 
>>  And here is the results of running it
>> 
>> 
>>  [AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
>>  [AUDIT   ] CWWKE0100I: This product is licensed for development, and
>>  limited production use. The full license terms can be viewed here:
>> 
> https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/16.0.0.2/lafiles/en.html
>> 
>>  [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
>>  *---> ApplicationScopedExtension, AfterDeploymentValidation event
>>  received, before looking up and touching @ApplicationScoped dummy bean*
>>  *---> ApplicationScopedDummyBean, @PostConstruct init method called*
>>  *---> ApplicationScopedExtension, after looking up and touching
>>  @ApplicationScoped dummy bean*
>>  [AUDIT   ] CWWKT0016I: Web application available (default_host):
>>  http://localhost:9080/70383.180.846.test-application/
>>  *---> ApplicationScopedObserverBean, observed
>>  @Initialized(ApplicationScoped.class) event.*
>>  [AUDIT   ] CWWKZ0001I: Application 70383.180.846.test-application
>>  started in 1.165 seconds.
>>  [AUDIT   ] CWWKF0012I: The server installed the following features:
>>  [jsp-2.3, ejbLite-3.2, managedBeans-1.0, jsf-2.2, beanValidation-1.1,
>>  servlet-3.1, ssl-1.0, jndi-1.0, jsonp-1.0, appSecurity-2.0, jdbc-4.1,
>>  jaxrs-2.0, jaxrsClient-2.0, el-3.0, json-1.0, cdi-1.2,
>>  distributedMap-1.0, webProfile-7.0, websocket-1.1, jpa-2.1].
>>  [AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a
>>  smarter planet.
>> 
>>  As you can see, the *ApplicationScopedDummyBean, @PostConstruct init
>>  method called*proves that the applicationContext was active before the
>>  event was fired. Why is this applicationscoped initialization event not
>>  fired earlier?
>> 
>> 
>>  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
>> 
>>  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
> Software Engineer
> Red Hat, Czech Republic
> 
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 


From mkouba at redhat.com  Mon Aug 22 04:22:52 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Mon, 22 Aug 2016 10:22:52 +0200
Subject: [weld-dev] ApplicationScoped event fires on service invocation
In-Reply-To: <444910677.472144.1471775532833@mail.yahoo.com>
References: <OFD807ACA1.BFD0F6C2-ON00258014.0043646F-80258014.00438369@notes.na.collabserv.com>
	<4ed8e7c0-2a26-b9d8-5cbb-995baa73b7c4@redhat.com>
	<444910677.472144.1471775532833@mail.yahoo.com>
Message-ID: <3f5c67d8-f2b2-18d2-9ade-6dff7037cb0d@redhat.com>

Dne 21.8.2016 v 12:32 Mark Struberg napsal(a):
> But the ServletContextEvent is available much earlier.
> I think this might rather be an integration issue.

ServletContext might be available earlier but Weld is using standard 
portable ServletContextListener API to be notified. In any case, the 
client code should not rely on the timing here as it's not exactly defined.

>
>
> In OWB we don't fire the @Intialized for the ApplicationContext inside the ApplicationContext implementation but as part of the integration code, means TomEE, Geronimo, SAP, etc.
>
> The interplay and boot order between EJB @Startup @Singleton and the CDI container is imo not really well defined. We just did what we think is best. Afair that means that in TomEE we fire the @Initialized _before_ we do @Startup but _after_ all the metadata parsing and EJB and CDI Extension handling was done.

I would rather say this is completely undefined. Java EE spec does not 
say anything about cooperation and startup order of various 
technologies. That's why for example injection into JPA entity listeners 
is problematic (and impossible to implement 100% correctly).

>
>
> LieGrue,
> strub
>
>
>
>
>
>> On Friday, 19 August 2016, 15:37, Martin Kouba <mkouba at redhat.com> wrote:
>>> Hi Benjanmin,
>>
>> for a web application the payload of
>> @Initialized(ApplicationScoped.class) must be the relevant
>> ServletContext. That's why Weld is waiting for a webapp to be ready
>> (implemented as
>> javax.servlet.ServletContextListener.contextInitialized(ServletContextEvent)).
>>
>> Martin
>>
>> Dne 19.8.2016 v 14:17 Benjamin Confino napsal(a):
>>>  We have a user scenario where we wishes to replace @Singleton @Startup
>>>  EJB beans with CDI beans. This was attempted by observing the
>>>  ApplicationScoped initialization event to trigger the replacement code.
>>>
>>>  However, the event was fired only after the service invocation, which
>>>  was too late. Apparently OWB fires this event much earlier.
>>>  The CDI spec states:
>>>
>>>  The /application context /is provided by a built-in context object for
>>>  the built-in scope type
>>>  @ApplicationScoped. The application scope is active:
>>>  ? during the service() method of any servlet in the web application,
>>>  during the doFilter()
>>>  method of any servlet filter and when the container calls any
>>>  ServletContextListener,
>>>  HttpSessionListener, AsyncListener or ServletRequestListener,
>>>  ? during any Java EE web service invocation,
>>>  ? during any remote method invocation of any EJB, during any
>>>  asynchronous method invocation
>>>  of any EJB, during any call to an EJB timeout method and during message
>>>  delivery to any EJB
>>>  message-driven bean,
>>>  ? when the disposer method or @PreDestroy callback of any bean with any
>>>  normal scope other
>>>  than @ApplicationScoped is called, and
>>>  *? during **@PostConstruct **callback of any bean.*
>>>
>>>  The application context is shared between all servlet requests, web
>>>  service invocations, EJB
>>>  remote method invocations, EJB asynchronous method invocations, EJB
>>>  timeouts and message
>>>  deliveries to message-driven beans that execute within the same
>>>  application. The application
>>>  context is destroyed when the application is shut down.
>>>
>>>  An event with qualifier @Initialized(ApplicationScoped.class) is fired
>>>  when the application
>>>  context is initialized and an event with qualifier
>>>  @Destroyed(ApplicationScoped.class) is fired
>>>  when the application is destroyed. The event payload is:
>>>  ? the ServletContext if the application is a web application deployed to
>>>  a Servlet container, or
>>>  ? any java.lang.Object for other types of application.
>>>
>>>  How do you interpret "initialized"? Does it mean the event is
>> fired only
>>>  after the context is *active?*
>>>
>>>  Is it possible to make the event firing a bit earlier, say around
>>>  AfterDeploymentValidation?
>>>
>>>  Below is the app to demonstrate the timing along with the server.xml:
>>>
>>>
>>>
>>>
>>>  And here is the results of running it
>>>
>>>
>>>  [AUDIT   ] CWWKE0001I: The server defaultServer has been launched.
>>>  [AUDIT   ] CWWKE0100I: This product is licensed for development, and
>>>  limited production use. The full license terms can be viewed here:
>>>
>> https://public.dhe.ibm.com/ibmdl/export/pub/software/websphere/wasdev/license/base_ilan/ilan/16.0.0.2/lafiles/en.html
>>>
>>>  [AUDIT   ] CWWKZ0058I: Monitoring dropins for applications.
>>>  *---> ApplicationScopedExtension, AfterDeploymentValidation event
>>>  received, before looking up and touching @ApplicationScoped dummy bean*
>>>  *---> ApplicationScopedDummyBean, @PostConstruct init method called*
>>>  *---> ApplicationScopedExtension, after looking up and touching
>>>  @ApplicationScoped dummy bean*
>>>  [AUDIT   ] CWWKT0016I: Web application available (default_host):
>>>  http://localhost:9080/70383.180.846.test-application/
>>>  *---> ApplicationScopedObserverBean, observed
>>>  @Initialized(ApplicationScoped.class) event.*
>>>  [AUDIT   ] CWWKZ0001I: Application 70383.180.846.test-application
>>>  started in 1.165 seconds.
>>>  [AUDIT   ] CWWKF0012I: The server installed the following features:
>>>  [jsp-2.3, ejbLite-3.2, managedBeans-1.0, jsf-2.2, beanValidation-1.1,
>>>  servlet-3.1, ssl-1.0, jndi-1.0, jsonp-1.0, appSecurity-2.0, jdbc-4.1,
>>>  jaxrs-2.0, jaxrsClient-2.0, el-3.0, json-1.0, cdi-1.2,
>>>  distributedMap-1.0, webProfile-7.0, websocket-1.1, jpa-2.1].
>>>  [AUDIT   ] CWWKF0011I: The server defaultServer is ready to run a
>>>  smarter planet.
>>>
>>>  As you can see, the *ApplicationScopedDummyBean, @PostConstruct init
>>>  method called*proves that the applicationContext was active before the
>>>  event was fired. Why is this applicationscoped initialization event not
>>>  fired earlier?
>>>
>>>
>>>  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
>>>
>>>  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
>> Software Engineer
>> Red Hat, Czech Republic
>>
>> _______________________________________________
>> weld-dev mailing list
>> weld-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic

From BENJAMIC at uk.ibm.com  Thu Aug 25 09:42:01 2016
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Thu, 25 Aug 2016 14:42:01 +0100
Subject: [weld-dev] Requesting comment on WELD-2062
Message-ID: <OF20852869.9DFA7A9F-ON0025801A.004ACA9A-8025801A.004B41B3@notes.na.collabserv.com>

Hello

A while back this issue was raised: 
https://issues.jboss.org/browse/WELD-2062

I have recently encountered a similar issue in which an update to a 
servlet does not take effect. 

I have verified the solution proposed in WELD-2062 manually. By using my 
eclipse debugger I was able to modify a variable and force 
AnnotatedTypeIdentifier.equals() to return false, this resolved the issue. 


My questions is, does AnnotatedTypeIdentifier.equals() need to be modified 
to use the class instead of the className as suggested in WELD-2062 or is 
this an integration issue where websphere has failed to provide the 
required information? 


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/20160825/27736c26/attachment-0001.html 

From mkouba at redhat.com  Thu Aug 25 10:51:55 2016
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 25 Aug 2016 16:51:55 +0200
Subject: [weld-dev] Requesting comment on WELD-2062
In-Reply-To: <OF20852869.9DFA7A9F-ON0025801A.004ACA9A-8025801A.004B41B3@notes.na.collabserv.com>
References: <OF20852869.9DFA7A9F-ON0025801A.004ACA9A-8025801A.004B41B3@notes.na.collabserv.com>
Message-ID: <1a1ca939-dd4a-2df0-61b9-7bef53a72285@redhat.com>

Hi Benjamin,

I've added a comment to the issue.

Thanks,

Martin

Dne 25.8.2016 v 15:42 Benjamin Confino napsal(a):
> Hello
>
> A while back this issue was raised:
> https://issues.jboss.org/browse/WELD-2062
>
> I have recently encountered a similar issue in which an update to a
> servlet does not take effect.
>
> I have verified the solution proposed in WELD-2062 manually. By using my
> eclipse debugger I was able to modify a variable and force
> AnnotatedTypeIdentifier.equals() to return false, this resolved the issue.
>
> My questions is, does AnnotatedTypeIdentifier.equals() need to be
> modified to use the class instead of the className as suggested in
> WELD-2062 or is this an integration issue where websphere has failed to
> provide the required information?
>
>
> 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  Thu Aug 25 11:47:45 2016
From: BENJAMIC at uk.ibm.com (Benjamin Confino)
Date: Thu, 25 Aug 2016 16:47:45 +0100
Subject: [weld-dev] Requesting comment on WELD-2062
In-Reply-To: <1a1ca939-dd4a-2df0-61b9-7bef53a72285@redhat.com>
References: <OF20852869.9DFA7A9F-ON0025801A.004ACA9A-8025801A.004B41B3@notes.na.collabserv.com>
	<1a1ca939-dd4a-2df0-61b9-7bef53a72285@redhat.com>
Message-ID: <OFBBB712F0.9846A31D-ON0025801A.0056B700-8025801A.0056C4C8@notes.na.collabserv.com>

Thanks Martin 

I hope your prototype works well.

Regards
Benjamin



From:   Martin Kouba <mkouba at redhat.com>
To:     Benjamin Confino/UK/IBM at IBMGB, weld-dev at lists.jboss.org, 
Cc:     Tom Evans/UK/IBM at IBMGB
Date:   25/08/2016 15:52
Subject:        Re: [weld-dev] Requesting comment on WELD-2062



Hi Benjamin,

I've added a comment to the issue.

Thanks,

Martin

Dne 25.8.2016 v 15:42 Benjamin Confino napsal(a):
> Hello
>
> A while back this issue was raised:
> https://issues.jboss.org/browse/WELD-2062
>
> I have recently encountered a similar issue in which an update to a
> servlet does not take effect.
>
> I have verified the solution proposed in WELD-2062 manually. By using my
> eclipse debugger I was able to modify a variable and force
> AnnotatedTypeIdentifier.equals() to return false, this resolved the 
issue.
>
> My questions is, does AnnotatedTypeIdentifier.equals() need to be
> modified to use the class instead of the className as suggested in
> WELD-2062 or is this an integration issue where websphere has failed to
> provide the required information?
>
>
> 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
>



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/20160825/a4789a05/attachment.html