From cmoulliard at redhat.com  Mon Jun  1 02:48:43 2015
From: cmoulliard at redhat.com (Charles Moulliard)
Date: Mon, 01 Jun 2015 08:48:43 +0200
Subject: [weld-dev] CDI+OSGI: bundle packages scope
In-Reply-To: <1432990387.12789305@f378.i.mail.ru>
References: <1432990387.12789305@f378.i.mail.ru>
Message-ID: <556C004B.9000802@redhat.com>

Hi,

Why don't you import the package ("com.example.thirdpackage") within 
your bundle Bundle A too ?

Regards,

Charles M.

On 30/05/15 14:53, ????????? ???????? wrote:
>
> I use javase and solution osgi (felix)+cdi(weld)+paxcdi. I have two 
> bundles A and B. Bundle B is a lib bundle.
>
> In bundle A I have one class and one package.
>
> |package  com.example.firstpackage;import  com.example.secondpackage.Class2;publicclassClass1{@InjectprivateClass2  class2;}|
>
> In bundle B I have two classes and two packages
>
> |package  com.example.secondpackage;import  com.example.thirdpackage.Class3;publicclassClass2{@InjectprivateClass3  class3;}|
>
> and
>
> |package  com.example.thirdpackage;publicclassClass3{....}|
>
> I install and start both bundles.
>
> The problem - pax (or weld) for injecting in classes of bundle A scans 
> only those packages which are imported for classes IN bundle A. In my 
> example - CDI for injecting in Class1 Class2 will scan 
> com.example.secondpackage of bundle B. However, it will throw 
> exception as Class2 needs Class3 but com.example.thirdpackage is not 
> scanned for bundle A (as it's not imported!!!). 
> com.example.thirdpackage is only scanned for bundle B but, as I 
> understand every bundles for cdi has its own scope. How to fix it?
>
>
>
>
> -- 
> ????????? ????????
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

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

From emijiang6 at googlemail.com  Tue Jun  2 12:01:17 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Tue, 2 Jun 2015 17:01:17 +0100
Subject: [weld-dev] JavaEE component class vs. Weld managed classes
In-Reply-To: <55680772.6030205@redhat.com>
References: <CAECq3A-gVKGmbGq4D_iiBbADFk=PPg37WZU_rYW+M4eDypJaJA@mail.gmail.com>
	<55680772.6030205@redhat.com>
Message-ID: <CAECq3A995RH9zJ0g11MOo8Li3aQxbFca=95MC16O1mQy1nj0BA@mail.gmail.com>

yes. This is another solution I have in mind, which is better to discover
these components in CDI integration code. I had hoped there is a nice API
in Weld allowing me to differentiate the JavaEE component classes.

On Fri, May 29, 2015 at 7:30 AM, Jozef Hartinger <jharting at redhat.com>
wrote:

>  I suppose you already must have code capable of identifying those
> components - i.e. the Servlet container must be able to discover Servlets
> in a web application. Therefore, the best way probably is to hook into
> these "Java EE component supporting" pieces of code instead of discovering
> the EE components yourself in the CDI integration code.
>
> We do exactly this in WildFly where we let the other subsystems identify
> EE components and then override the factories for these components to
> actually use InjectionTargets (and fire PIT, PIP in the process).
>
> HTH,
>
> Jozef
>
>
> On 05/28/2015 11:42 AM, Emily Jiang wrote:
>
> I need to fire events for each JavaEE component class (e.g. process
> injectionTarget, injectionPoint etc) during Weld bootstrap phase. At the
> moment, I am think to go through all bdas per deployment and process all
> classes in the bda and fire events for each JavaEE component classes as
> Weld leaves it to be handled by the integrator. What is the best way to
> find out which class is JavaEE component class? I don't like to idea of
> building a long hardcoded list from the EE.5-1 table of the JavaEE7 spec.
>
> --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org
>
>
> _______________________________________________
> weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150602/f6b387ee/attachment-0001.html 

From emijiang6 at googlemail.com  Tue Jun  2 12:15:50 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Tue, 2 Jun 2015 17:15:50 +0100
Subject: [weld-dev] ManagedBean and Weld integration
Message-ID: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>

For managed beans (@ManagedBean classes), they are java EE component
classes. They support both cdi and non-cdi interceptors. When I create a
instance using injectionTarget.produce(), I got hold of the instance with
both cdi and non-cdi interceptors associated. However, the @Resource
injection point on the non-cdi interceptors are not injected when Weld
creates the interceptor instances.

Is there anything I have missed or this is a bug?
-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150602/92f9271f/attachment.html 

From jharting at redhat.com  Wed Jun  3 01:49:57 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 03 Jun 2015 07:49:57 +0200
Subject: [weld-dev] ManagedBean and Weld integration
In-Reply-To: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>
References: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>
Message-ID: <556E9585.6010100@redhat.com>

That's expected. The non-cdi interceptors are expected to be partially 
managed by the EE container (resource injection). If you need resource 
injection in the non-CDI interceptors you can use InjectionTargetBuilder 
to customize this behavior, e.g:

beanManager.createInjectionTargetBuilder(type)
     .setDecorationEnabled(false)
     .setInterceptionEnabled(false)
     .setTargetClassLifecycleCallbacksEnabled(false)
     .setResourceInjectionEnabled(true)
     .build()

On 06/02/2015 06:15 PM, Emily Jiang wrote:
>
> For managed beans (@ManagedBean classes), they are java EE component 
> classes. They support both cdi and non-cdi interceptors. When I create 
> a instance using injectionTarget.produce(), I got hold of the instance 
> with both cdi and non-cdi interceptors associated. However, the 
> @Resource injection point on the non-cdi interceptors are not injected 
> when Weld creates the interceptor instances.
>
> Is there anything I have missed or this is a bug?
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org <mailto:ejiang at apache.org>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

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

From emijiang6 at googlemail.com  Wed Jun  3 05:25:21 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Wed, 3 Jun 2015 10:25:21 +0100
Subject: [weld-dev] ManagedBean and Weld integration
In-Reply-To: <556E9585.6010100@redhat.com>
References: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>
	<556E9585.6010100@redhat.com>
Message-ID: <CAECq3A-rH97HY6D3U5wePpGiGF4dT0nyyiY6i+7_L-2jKp58GA@mail.gmail.com>

Thank you Jozef for your quick reply!

The point is that Weld creates the non-cdi interceptors, so we don't have
control over. We can only control how to create the managed beans, which I
think the defult setting for the injectionTarget are correct (interceptor,
decorator, lifecycle call and resource injection enabled).

After further debugging, below is the calling stack for creating non-cdi
interceptors

BasicInjectionTarget<T>.createNonCdiInterceptor(EnhancedAnnotatedType<T>,
BeanManagerImpl) line: 69
InjectionTargetFactoryImpl<T>.chooseInjectionTarget(EnhancedAnnotatedType<T>,
Bean<T>, boolean) line: 126
InjectionTargetFactoryImpl<T>.createInjectionTarget(EnhancedAnnotatedType<T>,
Bean<T>, boolean) line: 87
InjectionTargetFactoryImpl<T>.createInjectionTarget(Bean<T>, boolean) line:
80
InjectionTargetFactoryImpl<T>.createInterceptorInjectionTarget() line: 75
PlainInterceptorFactory<T>.of(Class<T>, BeanManagerImpl) line: 41
InterceptorMetadataReader$1.load(Class<?>) line: 44
InterceptorMetadataReader$1.load(Object) line: 39
LocalCache$LoadingValueReference<K,V>.loadFuture(K, CacheLoader<? super
K,V>) line: 3599
LocalCache$Segment<K,V>.loadSync(K, int, LoadingValueReference<K,V>,
CacheLoader<? super K,V>) line: 2379
LocalCache$Segment<K,V>.lockedGetOrLoad(K, int, CacheLoader<? super K,V>)
line: 2342
LocalCache$Segment<K,V>.get(K, int, CacheLoader<? super K,V>) line: 2257
LocalCache<K,V>.get(K, CacheLoader<? super K,V>) line: 4000
LocalCache<K,V>.getOrLoad(K) line: 4004
LocalCache$LocalLoadingCache<K,V>.get(K) line: 4874
LoadingCacheUtils.getCacheValue(LoadingCache<K,V>, K) line: 49
LoadingCacheUtils.getCastCacheValue(LoadingCache<K,V>, Object) line: 74
InterceptorMetadataReader.getPlainInterceptorMetadata(Class<T>) line: 64
InterceptionModelInitializer<T>.initClassDeclaredEjbInterceptors() line:
233
InterceptionModelInitializer<T>.initEjbInterceptors() line: 217
InterceptionModelInitializer<T>.init() line: 103
BeanInjectionTarget<T>.buildInterceptionModel(EnhancedAnnotatedType<T>,
AbstractInstantiator<T>) line: 93
BeanInjectionTarget<T>.initializeInterceptionModel(EnhancedAnnotatedType<T>)
line: 88
BeanInjectionTarget<T>.initializeAfterBeanDiscovery(EnhancedAnnotatedType<T>)
line: 98
InjectionTargetInitializationContext<T>.initialize() line: 42
InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetInitializationContext<?>)
line: 55
InjectionTargetService.addInjectionTargetToBeInitialized(EnhancedAnnotatedType<T>,
BasicInjectionTarget<T>) line: 49
InjectionTargetFactoryImpl<T>.initialize(BasicInjectionTarget<T>) line: 145
InjectionTargetFactoryImpl<T>.createInjectionTarget(EnhancedAnnotatedType<T>,
Bean<T>, boolean) line: 92
InjectionTargetFactoryImpl<T>.createInjectionTarget(Bean<T>, boolean) line:
80
InjectionTargetFactoryImpl<T>.createInjectionTarget(Bean<T>) line: 70
InjectionTargetFactoryImpl<T>.createInjectionTarget(Bean) line: 54

This following line on BasicInjectionTarget uses the DefaultInjector, which
does not support resource injection.
 return new BasicInjectionTarget<T>(type, null, beanManager,
DefaultInjector.of(type, null, beanManager),
NoopLifecycleCallbackInvoker.<T>getInstance());

I might have missed your point. Please elaborate a bit more.

On Wed, Jun 3, 2015 at 6:49 AM, Jozef Hartinger <jharting at redhat.com> wrote:

>  That's expected. The non-cdi interceptors are expected to be partially
> managed by the EE container (resource injection). If you need resource
> injection in the non-CDI interceptors you can use InjectionTargetBuilder to
> customize this behavior, e.g:
>
> beanManager.createInjectionTargetBuilder(type)
>     .setDecorationEnabled(false)
>     .setInterceptionEnabled(false)
>     .setTargetClassLifecycleCallbacksEnabled(false)
>     .setResourceInjectionEnabled(true)
>     .build()
>
>
> On 06/02/2015 06:15 PM, Emily Jiang wrote:
>
>
>  For managed beans (@ManagedBean classes), they are java EE component
> classes. They support both cdi and non-cdi interceptors. When I create a
> instance using injectionTarget.produce(), I got hold of the instance with
> both cdi and non-cdi interceptors associated. However, the @Resource
> injection point on the non-cdi interceptors are not injected when Weld
> creates the interceptor instances.
>
>  Is there anything I have missed or this is a bug?
>   --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org
>
>
> _______________________________________________
> weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150603/0cb723d3/attachment.html 

From jharting at redhat.com  Wed Jun  3 05:50:47 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 03 Jun 2015 11:50:47 +0200
Subject: [weld-dev] ManagedBean and Weld integration
In-Reply-To: <CAECq3A-rH97HY6D3U5wePpGiGF4dT0nyyiY6i+7_L-2jKp58GA@mail.gmail.com>
References: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>	<556E9585.6010100@redhat.com>
	<CAECq3A-rH97HY6D3U5wePpGiGF4dT0nyyiY6i+7_L-2jKp58GA@mail.gmail.com>
Message-ID: <556ECDF7.7010708@redhat.com>

What I meant was that your PlainInterceptorFactory should in this case, 
instead of calling createInterceptorInjectionTarget(), call

beanManager.createInjectionTargetBuilder(type)
     .setDecorationEnabled(false)
     .setInterceptionEnabled(false)
     .setTargetClassLifecycleCallbacksEnabled(false)
     .setResourceInjectionEnabled(true)
     .build()

The InjectionTarget you get should be the same except for resource 
injection which will be provided by Weld.

Jozef

On 06/03/2015 11:25 AM, Emily Jiang wrote:
> I might have missed your point. Please elaborate a bit more.


From emijiang6 at googlemail.com  Wed Jun  3 06:52:38 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Wed, 3 Jun 2015 11:52:38 +0100
Subject: [weld-dev] ManagedBean and Weld integration
In-Reply-To: <556ECDF7.7010708@redhat.com>
References: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>
	<556E9585.6010100@redhat.com>
	<CAECq3A-rH97HY6D3U5wePpGiGF4dT0nyyiY6i+7_L-2jKp58GA@mail.gmail.com>
	<556ECDF7.7010708@redhat.com>
Message-ID: <CAECq3A8BfpO-XW8xwhbKX91e6pg+q7L82v0JbK2u6W+d9tsuzQ@mail.gmail.com>

Jozef,
The PlainInterceptorFactory is weld class. Here is the stack when we
created an instance for a managed bean class (@ManagedBean) by calling
injectionTarget.produce(); You are not asking me to override
PlainInterceptorFactory, right?


Caused by: java.lang.Exception
at
org.jboss.weld.injection.producer.BasicInjectionTarget.createNonCdiInterceptor(BasicInjectionTarget.java:69)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:126)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInterceptorInjectionTarget(InjectionTargetFactoryImpl.java:75)
at
org.jboss.weld.interceptor.reader.PlainInterceptorFactory.of(PlainInterceptorFactory.java:41)
at
org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:44)
at
org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:39)
at
com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
at com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
at
com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
at
com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
at
org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
at
org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
at
org.jboss.weld.interceptor.reader.InterceptorMetadataReader.getPlainInterceptorMetadata(InterceptorMetadataReader.java:64)
at
org.jboss.weld.injection.producer.InterceptionModelInitializer.initClassDeclaredEjbInterceptors(InterceptionModelInitializer.java:233)
at
org.jboss.weld.injection.producer.InterceptionModelInitializer.initEjbInterceptors(InterceptionModelInitializer.java:217)
at
org.jboss.weld.injection.producer.InterceptionModelInitializer.init(InterceptionModelInitializer.java:103)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.buildInterceptionModel(BeanInjectionTarget.java:93)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.initializeInterceptionModel(BeanInjectionTarget.java:88)
at
org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:98)
at
org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
at
org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:55)
at
org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:49)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.initialize(InjectionTargetFactoryImpl.java:145)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:92)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:70)
at
org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:54)


On Wed, Jun 3, 2015 at 10:50 AM, Jozef Hartinger <jharting at redhat.com>
wrote:

> What I meant was that your PlainInterceptorFactory should in this case,
> instead of calling createInterceptorInjectionTarget(), call
>
> beanManager.createInjectionTargetBuilder(type)
>     .setDecorationEnabled(false)
>     .setInterceptionEnabled(false)
>     .setTargetClassLifecycleCallbacksEnabled(false)
>     .setResourceInjectionEnabled(true)
>     .build()
>
> The InjectionTarget you get should be the same except for resource
> injection which will be provided by Weld.
>
> Jozef
>
>
> On 06/03/2015 11:25 AM, Emily Jiang wrote:
>
>> I might have missed your point. Please elaborate a bit more.
>>
>
>


-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150603/dce363d7/attachment-0001.html 

From jharting at redhat.com  Wed Jun  3 09:02:19 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Wed, 03 Jun 2015 15:02:19 +0200
Subject: [weld-dev] ManagedBean and Weld integration
In-Reply-To: <CAECq3A8BfpO-XW8xwhbKX91e6pg+q7L82v0JbK2u6W+d9tsuzQ@mail.gmail.com>
References: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>	<556E9585.6010100@redhat.com>	<CAECq3A-rH97HY6D3U5wePpGiGF4dT0nyyiY6i+7_L-2jKp58GA@mail.gmail.com>	<556ECDF7.7010708@redhat.com>
	<CAECq3A8BfpO-XW8xwhbKX91e6pg+q7L82v0JbK2u6W+d9tsuzQ@mail.gmail.com>
Message-ID: <556EFADB.2000506@redhat.com>

Oops, sorry. Ignore my last e-mail. How do you obtain the 
InjectionTarget for the non-CDI interceptor?

On 06/03/2015 12:52 PM, Emily Jiang wrote:
> Jozef,
> The PlainInterceptorFactory is weld class. Here is the stack when we 
> created an instance for a managed bean class (@ManagedBean) by calling 
> injectionTarget.produce(); You are not asking me to override 
> PlainInterceptorFactory, right?
>
>
> Caused by: java.lang.Exception
> at 
> org.jboss.weld.injection.producer.BasicInjectionTarget.createNonCdiInterceptor(BasicInjectionTarget.java:69)
> at 
> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:126)
> at 
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
> at 
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
> at 
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInterceptorInjectionTarget(InjectionTargetFactoryImpl.java:75)
> at 
> org.jboss.weld.interceptor.reader.PlainInterceptorFactory.of(PlainInterceptorFactory.java:41)
> at 
> org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:44)
> at 
> org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:39)
> at 
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
> at 
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
> at 
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
> at 
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
> at 
> org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
> at 
> org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
> at 
> org.jboss.weld.interceptor.reader.InterceptorMetadataReader.getPlainInterceptorMetadata(InterceptorMetadataReader.java:64)
> at 
> org.jboss.weld.injection.producer.InterceptionModelInitializer.initClassDeclaredEjbInterceptors(InterceptionModelInitializer.java:233)
> at 
> org.jboss.weld.injection.producer.InterceptionModelInitializer.initEjbInterceptors(InterceptionModelInitializer.java:217)
> at 
> org.jboss.weld.injection.producer.InterceptionModelInitializer.init(InterceptionModelInitializer.java:103)
> at 
> org.jboss.weld.injection.producer.BeanInjectionTarget.buildInterceptionModel(BeanInjectionTarget.java:93)
> at 
> org.jboss.weld.injection.producer.BeanInjectionTarget.initializeInterceptionModel(BeanInjectionTarget.java:88)
> at 
> org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:98)
> at 
> org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
> at 
> org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:55)
> at 
> org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:49)
> at 
> org.jboss.weld.manager.InjectionTargetFactoryImpl.initialize(InjectionTargetFactoryImpl.java:145)
> at 
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:92)
> at 
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
> at 
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:70)
> at 
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:54)
>
> On Wed, Jun 3, 2015 at 10:50 AM, Jozef Hartinger <jharting at redhat.com 
> <mailto:jharting at redhat.com>> wrote:
>
>     What I meant was that your PlainInterceptorFactory should in this
>     case, instead of calling createInterceptorInjectionTarget(), call
>
>     beanManager.createInjectionTargetBuilder(type)
>         .setDecorationEnabled(false)
>         .setInterceptionEnabled(false)
>         .setTargetClassLifecycleCallbacksEnabled(false)
>         .setResourceInjectionEnabled(true)
>         .build()
>
>     The InjectionTarget you get should be the same except for resource
>     injection which will be provided by Weld.
>
>     Jozef
>
>
>     On 06/03/2015 11:25 AM, Emily Jiang wrote:
>
>         I might have missed your point. Please elaborate a bit more.
>
>
>
>
>
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org <mailto:ejiang at apache.org>

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

From emijiang6 at googlemail.com  Wed Jun  3 09:41:29 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Wed, 3 Jun 2015 14:41:29 +0100
Subject: [weld-dev] ManagedBean and Weld integration
In-Reply-To: <556EFADB.2000506@redhat.com>
References: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>
	<556E9585.6010100@redhat.com>
	<CAECq3A-rH97HY6D3U5wePpGiGF4dT0nyyiY6i+7_L-2jKp58GA@mail.gmail.com>
	<556ECDF7.7010708@redhat.com>
	<CAECq3A8BfpO-XW8xwhbKX91e6pg+q7L82v0JbK2u6W+d9tsuzQ@mail.gmail.com>
	<556EFADB.2000506@redhat.com>
Message-ID: <CAECq3A-Cgkg8uTiqDmDXd0V=guJVT5ytmv2rDMdAUbe82njy3Q@mail.gmail.com>

Hi Jozef,
The non-CDI interceptor was created by Weld when I called
injectionTarget.produce() on a ManagedBean class. I have no control of it.
Please see above for the stack. The stack shows the creation sequence
(managed bean creation -> non-cdi interceptor creation). I used the
following snippet to create injection Target for the ManagedBean.

            Bean<T> bean = getBean(); // returns null for managed bean with
dependent scope

            AnnotatedType<T> annotatedType =
beanManager.createAnnotatedType(clazz);
            InjectionTargetFactory<T> itf=
beanManager.getInjectionTargetFactory(annotatedType);
            injectionTarget = itf.createInjectionTarget(bean);
            injectionTarget.produce(context); //produce an instance with
all non-cdi and cdi interceptors... but the non-cdi interceptors without
any ee injection

Thanks
Emily

On Wed, Jun 3, 2015 at 2:02 PM, Jozef Hartinger <jharting at redhat.com> wrote:

>  Oops, sorry. Ignore my last e-mail. How do you obtain the InjectionTarget
> for the non-CDI interceptor?
>
>
> On 06/03/2015 12:52 PM, Emily Jiang wrote:
>
>  Jozef,
>  The PlainInterceptorFactory is weld class. Here is the stack when we
> created an instance for a managed bean class (@ManagedBean) by calling
> injectionTarget.produce(); You are not asking me to override
> PlainInterceptorFactory, right?
>
>
>  Caused by: java.lang.Exception
> at
> org.jboss.weld.injection.producer.BasicInjectionTarget.createNonCdiInterceptor(BasicInjectionTarget.java:69)
> at
> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:126)
> at
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
> at
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
> at
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInterceptorInjectionTarget(InjectionTargetFactoryImpl.java:75)
> at
> org.jboss.weld.interceptor.reader.PlainInterceptorFactory.of(PlainInterceptorFactory.java:41)
> at
> org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:44)
> at
> org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:39)
> at
> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
> at
> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
> at
> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
> at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
> at
> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
> at
> org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
> at
> org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
> at
> org.jboss.weld.interceptor.reader.InterceptorMetadataReader.getPlainInterceptorMetadata(InterceptorMetadataReader.java:64)
> at
> org.jboss.weld.injection.producer.InterceptionModelInitializer.initClassDeclaredEjbInterceptors(InterceptionModelInitializer.java:233)
> at
> org.jboss.weld.injection.producer.InterceptionModelInitializer.initEjbInterceptors(InterceptionModelInitializer.java:217)
> at
> org.jboss.weld.injection.producer.InterceptionModelInitializer.init(InterceptionModelInitializer.java:103)
> at
> org.jboss.weld.injection.producer.BeanInjectionTarget.buildInterceptionModel(BeanInjectionTarget.java:93)
> at
> org.jboss.weld.injection.producer.BeanInjectionTarget.initializeInterceptionModel(BeanInjectionTarget.java:88)
> at
> org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:98)
> at
> org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
> at
> org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:55)
> at
> org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:49)
> at
> org.jboss.weld.manager.InjectionTargetFactoryImpl.initialize(InjectionTargetFactoryImpl.java:145)
> at
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:92)
> at
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
> at
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:70)
> at
> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:54)
>
> On Wed, Jun 3, 2015 at 10:50 AM, Jozef Hartinger <jharting at redhat.com>
> wrote:
>
>> What I meant was that your PlainInterceptorFactory should in this case,
>> instead of calling createInterceptorInjectionTarget(), call
>>
>> beanManager.createInjectionTargetBuilder(type)
>>     .setDecorationEnabled(false)
>>     .setInterceptionEnabled(false)
>>     .setTargetClassLifecycleCallbacksEnabled(false)
>>     .setResourceInjectionEnabled(true)
>>     .build()
>>
>>  The InjectionTarget you get should be the same except for resource
>> injection which will be provided by Weld.
>>
>> Jozef
>>
>>
>> On 06/03/2015 11:25 AM, Emily Jiang wrote:
>>
>>> I might have missed your point. Please elaborate a bit more.
>>>
>>
>>
>
>
> --
> 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/20150603/47ffb1fc/attachment-0001.html 

From jharting at redhat.com  Thu Jun  4 03:03:00 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 04 Jun 2015 09:03:00 +0200
Subject: [weld-dev] ManagedBean and Weld integration
In-Reply-To: <CAECq3A-Cgkg8uTiqDmDXd0V=guJVT5ytmv2rDMdAUbe82njy3Q@mail.gmail.com>
References: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>	<556E9585.6010100@redhat.com>	<CAECq3A-rH97HY6D3U5wePpGiGF4dT0nyyiY6i+7_L-2jKp58GA@mail.gmail.com>	<556ECDF7.7010708@redhat.com>	<CAECq3A8BfpO-XW8xwhbKX91e6pg+q7L82v0JbK2u6W+d9tsuzQ@mail.gmail.com>	<556EFADB.2000506@redhat.com>
	<CAECq3A-Cgkg8uTiqDmDXd0V=guJVT5ytmv2rDMdAUbe82njy3Q@mail.gmail.com>
Message-ID: <556FF824.9090002@redhat.com>

Hi Emily,

thanks for your patience :-) You are right that this is a bug in Weld. I 
filed https://issues.jboss.org/browse/WELD-1963 to track this issue.

Jozef

On 06/03/2015 03:41 PM, Emily Jiang wrote:
> Hi Jozef,
> The non-CDI interceptor was created by Weld when I called 
> injectionTarget.produce() on a ManagedBean class. I have no control of 
> it. Please see above for the stack. The stack shows the creation 
> sequence (managed bean creation -> non-cdi interceptor creation). I 
> used the following snippet to create injection Target for the ManagedBean.
>
>             Bean<T> bean = getBean(); // returns null for managed bean 
> with dependent scope
>
>             AnnotatedType<T> annotatedType = 
> beanManager.createAnnotatedType(clazz);
>             InjectionTargetFactory<T> itf= 
> beanManager.getInjectionTargetFactory(annotatedType);
>             injectionTarget = itf.createInjectionTarget(bean);
>             injectionTarget.produce(context); //produce an instance 
> with all non-cdi and cdi interceptors... but the non-cdi interceptors 
> without any ee injection
>
> Thanks
> Emily
>
> On Wed, Jun 3, 2015 at 2:02 PM, Jozef Hartinger <jharting at redhat.com 
> <mailto:jharting at redhat.com>> wrote:
>
>     Oops, sorry. Ignore my last e-mail. How do you obtain the
>     InjectionTarget for the non-CDI interceptor?
>
>
>     On 06/03/2015 12:52 PM, Emily Jiang wrote:
>>     Jozef,
>>     The PlainInterceptorFactory is weld class. Here is the stack when
>>     we created an instance for a managed bean class (@ManagedBean) by
>>     calling injectionTarget.produce(); You are not asking me to
>>     override PlainInterceptorFactory, right?
>>
>>
>>     Caused by: java.lang.Exception
>>     at
>>     org.jboss.weld.injection.producer.BasicInjectionTarget.createNonCdiInterceptor(BasicInjectionTarget.java:69)
>>     at
>>     org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:126)
>>     at
>>     org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
>>     at
>>     org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
>>     at
>>     org.jboss.weld.manager.InjectionTargetFactoryImpl.createInterceptorInjectionTarget(InjectionTargetFactoryImpl.java:75)
>>     at
>>     org.jboss.weld.interceptor.reader.PlainInterceptorFactory.of(PlainInterceptorFactory.java:41)
>>     at
>>     org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:44)
>>     at
>>     org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:39)
>>     at
>>     com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
>>     at
>>     com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
>>     at
>>     com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
>>     at
>>     com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
>>     at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
>>     at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
>>     at
>>     com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
>>     at
>>     org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
>>     at
>>     org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
>>     at
>>     org.jboss.weld.interceptor.reader.InterceptorMetadataReader.getPlainInterceptorMetadata(InterceptorMetadataReader.java:64)
>>     at
>>     org.jboss.weld.injection.producer.InterceptionModelInitializer.initClassDeclaredEjbInterceptors(InterceptionModelInitializer.java:233)
>>     at
>>     org.jboss.weld.injection.producer.InterceptionModelInitializer.initEjbInterceptors(InterceptionModelInitializer.java:217)
>>     at
>>     org.jboss.weld.injection.producer.InterceptionModelInitializer.init(InterceptionModelInitializer.java:103)
>>     at
>>     org.jboss.weld.injection.producer.BeanInjectionTarget.buildInterceptionModel(BeanInjectionTarget.java:93)
>>     at
>>     org.jboss.weld.injection.producer.BeanInjectionTarget.initializeInterceptionModel(BeanInjectionTarget.java:88)
>>     at
>>     org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:98)
>>     at
>>     org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
>>     at
>>     org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:55)
>>     at
>>     org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:49)
>>     at
>>     org.jboss.weld.manager.InjectionTargetFactoryImpl.initialize(InjectionTargetFactoryImpl.java:145)
>>     at
>>     org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:92)
>>     at
>>     org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
>>     at
>>     org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:70)
>>     at
>>     org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:54)
>>
>>     On Wed, Jun 3, 2015 at 10:50 AM, Jozef Hartinger
>>     <jharting at redhat.com <mailto:jharting at redhat.com>> wrote:
>>
>>         What I meant was that your PlainInterceptorFactory should in
>>         this case, instead of calling
>>         createInterceptorInjectionTarget(), call
>>
>>         beanManager.createInjectionTargetBuilder(type)
>>             .setDecorationEnabled(false)
>>             .setInterceptionEnabled(false)
>>         .setTargetClassLifecycleCallbacksEnabled(false)
>>             .setResourceInjectionEnabled(true)
>>             .build()
>>
>>         The InjectionTarget you get should be the same except for
>>         resource injection which will be provided by Weld.
>>
>>         Jozef
>>
>>
>>         On 06/03/2015 11:25 AM, Emily Jiang wrote:
>>
>>             I might have missed your point. Please elaborate a bit more.
>>
>>
>>
>>
>>
>>     -- 
>>     Thanks
>>     Emily
>>     =================
>>     Emily Jiang
>>     ejiang at apache.org <mailto:ejiang at apache.org>
>
>
>
>
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org <mailto:ejiang at apache.org>

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

From emijiang6 at googlemail.com  Thu Jun  4 04:36:19 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Thu, 4 Jun 2015 09:36:19 +0100
Subject: [weld-dev] ManagedBean and Weld integration
In-Reply-To: <556FF824.9090002@redhat.com>
References: <CAECq3A-3Ukv4nuTvAy1UvTvvsdFxUZMUKVGU3s_KcsQFCvjfuQ@mail.gmail.com>
	<556E9585.6010100@redhat.com>
	<CAECq3A-rH97HY6D3U5wePpGiGF4dT0nyyiY6i+7_L-2jKp58GA@mail.gmail.com>
	<556ECDF7.7010708@redhat.com>
	<CAECq3A8BfpO-XW8xwhbKX91e6pg+q7L82v0JbK2u6W+d9tsuzQ@mail.gmail.com>
	<556EFADB.2000506@redhat.com>
	<CAECq3A-Cgkg8uTiqDmDXd0V=guJVT5ytmv2rDMdAUbe82njy3Q@mail.gmail.com>
	<556FF824.9090002@redhat.com>
Message-ID: <CAECq3A9O_PeECtWkTEvJURQWz9DQJJSbZUT+AMawLCu_bEhG=Q@mail.gmail.com>

Thank you Jozef! Glad to know that we eventually synced up. It will be
great if this bug is fixed soon.

On Thu, Jun 4, 2015 at 8:03 AM, Jozef Hartinger <jharting at redhat.com> wrote:

>  Hi Emily,
>
> thanks for your patience :-) You are right that this is a bug in Weld. I
> filed https://issues.jboss.org/browse/WELD-1963 to track this issue.
>
> Jozef
>
>
> On 06/03/2015 03:41 PM, Emily Jiang wrote:
>
>   Hi Jozef,
>  The non-CDI interceptor was created by Weld when I called
> injectionTarget.produce() on a ManagedBean class. I have no control of it.
> Please see above for the stack. The stack shows the creation sequence
> (managed bean creation -> non-cdi interceptor creation). I used the
> following snippet to create injection Target for the ManagedBean.
>
>             Bean<T> bean = getBean(); // returns null for managed bean
> with dependent scope
>
>             AnnotatedType<T> annotatedType =
> beanManager.createAnnotatedType(clazz);
>             InjectionTargetFactory<T> itf=
> beanManager.getInjectionTargetFactory(annotatedType);
>             injectionTarget = itf.createInjectionTarget(bean);
>              injectionTarget.produce(context); //produce an instance with
> all non-cdi and cdi interceptors... but the non-cdi interceptors without
> any ee injection
>
>  Thanks
>  Emily
>
> On Wed, Jun 3, 2015 at 2:02 PM, Jozef Hartinger <jharting at redhat.com>
> wrote:
>
>>  Oops, sorry. Ignore my last e-mail. How do you obtain the
>> InjectionTarget for the non-CDI interceptor?
>>
>>
>> On 06/03/2015 12:52 PM, Emily Jiang wrote:
>>
>>  Jozef,
>>  The PlainInterceptorFactory is weld class. Here is the stack when we
>> created an instance for a managed bean class (@ManagedBean) by calling
>> injectionTarget.produce(); You are not asking me to override
>> PlainInterceptorFactory, right?
>>
>>
>>  Caused by: java.lang.Exception
>> at
>> org.jboss.weld.injection.producer.BasicInjectionTarget.createNonCdiInterceptor(BasicInjectionTarget.java:69)
>> at
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.chooseInjectionTarget(InjectionTargetFactoryImpl.java:126)
>> at
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:87)
>> at
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
>> at
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInterceptorInjectionTarget(InjectionTargetFactoryImpl.java:75)
>> at
>> org.jboss.weld.interceptor.reader.PlainInterceptorFactory.of(PlainInterceptorFactory.java:41)
>> at
>> org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:44)
>> at
>> org.jboss.weld.interceptor.reader.InterceptorMetadataReader$1.load(InterceptorMetadataReader.java:39)
>> at
>> com.google.common.cache.LocalCache$LoadingValueReference.loadFuture(LocalCache.java:3599)
>> at
>> com.google.common.cache.LocalCache$Segment.loadSync(LocalCache.java:2379)
>> at
>> com.google.common.cache.LocalCache$Segment.lockedGetOrLoad(LocalCache.java:2342)
>> at com.google.common.cache.LocalCache$Segment.get(LocalCache.java:2257)
>> at com.google.common.cache.LocalCache.get(LocalCache.java:4000)
>> at com.google.common.cache.LocalCache.getOrLoad(LocalCache.java:4004)
>> at
>> com.google.common.cache.LocalCache$LocalLoadingCache.get(LocalCache.java:4874)
>> at
>> org.jboss.weld.util.cache.LoadingCacheUtils.getCacheValue(LoadingCacheUtils.java:49)
>> at
>> org.jboss.weld.util.cache.LoadingCacheUtils.getCastCacheValue(LoadingCacheUtils.java:74)
>> at
>> org.jboss.weld.interceptor.reader.InterceptorMetadataReader.getPlainInterceptorMetadata(InterceptorMetadataReader.java:64)
>> at
>> org.jboss.weld.injection.producer.InterceptionModelInitializer.initClassDeclaredEjbInterceptors(InterceptionModelInitializer.java:233)
>> at
>> org.jboss.weld.injection.producer.InterceptionModelInitializer.initEjbInterceptors(InterceptionModelInitializer.java:217)
>> at
>> org.jboss.weld.injection.producer.InterceptionModelInitializer.init(InterceptionModelInitializer.java:103)
>> at
>> org.jboss.weld.injection.producer.BeanInjectionTarget.buildInterceptionModel(BeanInjectionTarget.java:93)
>> at
>> org.jboss.weld.injection.producer.BeanInjectionTarget.initializeInterceptionModel(BeanInjectionTarget.java:88)
>> at
>> org.jboss.weld.injection.producer.BeanInjectionTarget.initializeAfterBeanDiscovery(BeanInjectionTarget.java:98)
>> at
>> org.jboss.weld.injection.producer.InjectionTargetInitializationContext.initialize(InjectionTargetInitializationContext.java:42)
>> at
>> org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:55)
>> at
>> org.jboss.weld.injection.producer.InjectionTargetService.addInjectionTargetToBeInitialized(InjectionTargetService.java:49)
>> at
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.initialize(InjectionTargetFactoryImpl.java:145)
>> at
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:92)
>> at
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:80)
>> at
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:70)
>> at
>> org.jboss.weld.manager.InjectionTargetFactoryImpl.createInjectionTarget(InjectionTargetFactoryImpl.java:54)
>>
>> On Wed, Jun 3, 2015 at 10:50 AM, Jozef Hartinger <jharting at redhat.com>
>> wrote:
>>
>>> What I meant was that your PlainInterceptorFactory should in this case,
>>> instead of calling createInterceptorInjectionTarget(), call
>>>
>>> beanManager.createInjectionTargetBuilder(type)
>>>     .setDecorationEnabled(false)
>>>     .setInterceptionEnabled(false)
>>>     .setTargetClassLifecycleCallbacksEnabled(false)
>>>     .setResourceInjectionEnabled(true)
>>>     .build()
>>>
>>>  The InjectionTarget you get should be the same except for resource
>>> injection which will be provided by Weld.
>>>
>>> Jozef
>>>
>>>
>>> On 06/03/2015 11:25 AM, Emily Jiang wrote:
>>>
>>>> I might have missed your point. Please elaborate a bit more.
>>>>
>>>
>>>
>>
>>
>> --
>> 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/20150604/9cbe621f/attachment-0001.html 

From jharting at redhat.com  Thu Jun 11 03:21:52 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Thu, 11 Jun 2015 09:21:52 +0200
Subject: [weld-dev] Weld 2.2.13.Final & 3.0.0.Alpha10
Message-ID: <55793710.5030506@redhat.com>

These two mostly bug-fixing releases are now available. 
http://weld.cdi-spec.org/download/

From emijiang6 at googlemail.com  Fri Jun 19 06:28:18 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Fri, 19 Jun 2015 11:28:18 +0100
Subject: [weld-dev] JavaEE component classes - JPA entity listener
Message-ID: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>

In CDI 1.2 spec
11.5.7. ProcessInjectionPoint event
The container must fire an event for every injection point of every Java EE
component class
supporting injection that may be instantiated by the container at runtime,
including every managed bean declared using @ManagedBean, EJB session or
message-driven bean, bean, interceptor or decorator.

The JavaEE component classes are mentioned in JavaEE platform EE.5-1, which
includes servlets, servlet filters, entity listeners etc.

My concern is about entity listeners in JPA. Eclipse link has done all the
injection for entity listeners. It does not fire the event, @See
createEntityListenerAndInjectDependancies(...)

JPA spec section 3.5.1 does not mention this event requirement. How can the
eclipse cdi implementation satisfy the CDI spec?

[1]
http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS
]
-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150619/18f16982/attachment.html 

From jharting at redhat.com  Sun Jun 21 15:42:07 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Sun, 21 Jun 2015 21:42:07 +0200
Subject: [weld-dev] JavaEE component classes - JPA entity listener
In-Reply-To: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>
References: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>
Message-ID: <5587138F.2050406@redhat.com>

Hi Emily,

the implementation should call the following method 
http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldManager.html#fireProcessInjectionTarget-javax.enterprise.inject.spi.AnnotatedType-javax.enterprise.inject.spi.InjectionTarget- 
on Weld BeanManager and use the returned value as the InjectionTarget.

HTH,

Jozef

On 06/19/2015 12:28 PM, Emily Jiang wrote:
>
> In CDI 1.2 spec
> 11.5.7. ProcessInjectionPoint event
> The container must fire an event for every injection point of every 
> Java EE component class
> supporting injection that may be instantiated by the container at 
> runtime, including every managed bean declared using @ManagedBean, EJB 
> session or message-driven bean, bean, interceptor or decorator.
>
> The JavaEE component classes are mentioned in JavaEE platform EE.5-1, 
> which includes servlets, servlet filters, entity listeners etc.
>
> My concern is about entity listeners in JPA. Eclipse link has done all 
> the injection for entity listeners. It does not fire the event, @See 
> createEntityListenerAndInjectDependancies(...)
>
> JPA spec section 3.5.1 does not mention this event requirement. How 
> can the eclipse cdi implementation satisfy the CDI spec?
>
> [1] 
> http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS]
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org <mailto:ejiang at apache.org>
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

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

From emijiang6 at googlemail.com  Sun Jun 21 17:58:45 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Sun, 21 Jun 2015 22:58:45 +0100
Subject: [weld-dev] JavaEE component classes - JPA entity listener
In-Reply-To: <5587138F.2050406@redhat.com>
References: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>
	<5587138F.2050406@redhat.com>
Message-ID: <CAECq3A-TJa7spveWr_zgZFo3wyrxkX+vftdbr1+jwHmKuOGPAw@mail.gmail.com>

Jozef,
The implementation is in eclipse link. I guess they don't want to depend on
a specific CDI implementation.
Thanks
Emily

On Sun, Jun 21, 2015 at 8:42 PM, Jozef Hartinger <jharting at redhat.com>
wrote:

>  Hi Emily,
>
> the implementation should call the following method
> http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldManager.html#fireProcessInjectionTarget-javax.enterprise.inject.spi.AnnotatedType-javax.enterprise.inject.spi.InjectionTarget-
> on Weld BeanManager and use the returned value as the InjectionTarget.
>
> HTH,
>
> Jozef
>
>
> On 06/19/2015 12:28 PM, Emily Jiang wrote:
>
>
>  In CDI 1.2 spec
> 11.5.7. ProcessInjectionPoint event
> The container must fire an event for every injection point of every Java
> EE component class
> supporting injection that may be instantiated by the container at runtime,
> including every managed bean declared using @ManagedBean, EJB session or
> message-driven bean, bean, interceptor or decorator.
>
>  The JavaEE component classes are mentioned in JavaEE platform EE.5-1,
> which includes servlets, servlet filters, entity listeners etc.
>
>  My concern is about entity listeners in JPA. Eclipse link has done all
> the injection for entity listeners. It does not fire the event, @See
> createEntityListenerAndInjectDependancies(...)
>
> JPA spec section 3.5.1 does not mention this event requirement. How can
> the eclipse cdi implementation satisfy the CDI spec?
>
> [1]
> http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS
> ]
>  --
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org
>
>
> _______________________________________________
> weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150621/ca4b1b87/attachment.html 

From emijiang6 at googlemail.com  Sun Jun 21 17:59:11 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Sun, 21 Jun 2015 22:59:11 +0100
Subject: [weld-dev] JavaEE component classes - JPA entity listener
In-Reply-To: <CAECq3A-TJa7spveWr_zgZFo3wyrxkX+vftdbr1+jwHmKuOGPAw@mail.gmail.com>
References: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>
	<5587138F.2050406@redhat.com>
	<CAECq3A-TJa7spveWr_zgZFo3wyrxkX+vftdbr1+jwHmKuOGPAw@mail.gmail.com>
Message-ID: <CAECq3A-kh9fwBmfDWOQdEVwuS4m=BvhXrzBVwNQyOp=CS6PCgw@mail.gmail.com>

thanks Jozef!

On Sun, Jun 21, 2015 at 10:58 PM, Emily Jiang <emijiang6 at googlemail.com>
wrote:

> Jozef,
> The implementation is in eclipse link. I guess they don't want to depend
> on a specific CDI implementation.
> Thanks
> Emily
>
> On Sun, Jun 21, 2015 at 8:42 PM, Jozef Hartinger <jharting at redhat.com>
> wrote:
>
>>  Hi Emily,
>>
>> the implementation should call the following method
>> http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldManager.html#fireProcessInjectionTarget-javax.enterprise.inject.spi.AnnotatedType-javax.enterprise.inject.spi.InjectionTarget-
>> on Weld BeanManager and use the returned value as the InjectionTarget.
>>
>> HTH,
>>
>> Jozef
>>
>>
>> On 06/19/2015 12:28 PM, Emily Jiang wrote:
>>
>>
>>  In CDI 1.2 spec
>> 11.5.7. ProcessInjectionPoint event
>> The container must fire an event for every injection point of every Java
>> EE component class
>> supporting injection that may be instantiated by the container at
>> runtime, including every managed bean declared using @ManagedBean, EJB
>> session or message-driven bean, bean, interceptor or decorator.
>>
>>  The JavaEE component classes are mentioned in JavaEE platform EE.5-1,
>> which includes servlets, servlet filters, entity listeners etc.
>>
>>  My concern is about entity listeners in JPA. Eclipse link has done all
>> the injection for entity listeners. It does not fire the event, @See
>> createEntityListenerAndInjectDependancies(...)
>>
>> JPA spec section 3.5.1 does not mention this event requirement. How can
>> the eclipse cdi implementation satisfy the CDI spec?
>>
>> [1]
>> http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS
>> ]
>>  --
>> Thanks
>> Emily
>> =================
>> Emily Jiang
>> ejiang at apache.org
>>
>>
>> _______________________________________________
>> weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150621/bc2e2267/attachment-0001.html 

From emijiang6 at googlemail.com  Mon Jun 22 08:25:44 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Mon, 22 Jun 2015 13:25:44 +0100
Subject: [weld-dev] JavaEE component classes - JPA entity listener
In-Reply-To: <CAECq3A-kh9fwBmfDWOQdEVwuS4m=BvhXrzBVwNQyOp=CS6PCgw@mail.gmail.com>
References: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>
	<5587138F.2050406@redhat.com>
	<CAECq3A-TJa7spveWr_zgZFo3wyrxkX+vftdbr1+jwHmKuOGPAw@mail.gmail.com>
	<CAECq3A-kh9fwBmfDWOQdEVwuS4m=BvhXrzBVwNQyOp=CS6PCgw@mail.gmail.com>
Message-ID: <CAECq3A-Jqc7Rqno4vOmsRW9PxCP2uhtpm79ca1DDeu1R7-hTqQ@mail.gmail.com>

Jozef,
Just re-iterate my concern:
The implementation is in eclipse link. I guess they don't want to depend on
a specific CDI implementation. Therefore, what you suggested may not be
accepted by the eclipse link project.

Thanks
Emily


On Sun, Jun 21, 2015 at 10:59 PM, Emily Jiang <emijiang6 at googlemail.com>
wrote:

> thanks Jozef!
>
> On Sun, Jun 21, 2015 at 10:58 PM, Emily Jiang <emijiang6 at googlemail.com>
> wrote:
>
>> Jozef,
>> The implementation is in eclipse link. I guess they don't want to depend
>> on a specific CDI implementation.
>> Thanks
>> Emily
>>
>> On Sun, Jun 21, 2015 at 8:42 PM, Jozef Hartinger <jharting at redhat.com>
>> wrote:
>>
>>>  Hi Emily,
>>>
>>> the implementation should call the following method
>>> http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldManager.html#fireProcessInjectionTarget-javax.enterprise.inject.spi.AnnotatedType-javax.enterprise.inject.spi.InjectionTarget-
>>> on Weld BeanManager and use the returned value as the InjectionTarget.
>>>
>>> HTH,
>>>
>>> Jozef
>>>
>>>
>>> On 06/19/2015 12:28 PM, Emily Jiang wrote:
>>>
>>>
>>>  In CDI 1.2 spec
>>> 11.5.7. ProcessInjectionPoint event
>>> The container must fire an event for every injection point of every Java
>>> EE component class
>>> supporting injection that may be instantiated by the container at
>>> runtime, including every managed bean declared using @ManagedBean, EJB
>>> session or message-driven bean, bean, interceptor or decorator.
>>>
>>>  The JavaEE component classes are mentioned in JavaEE platform EE.5-1,
>>> which includes servlets, servlet filters, entity listeners etc.
>>>
>>>  My concern is about entity listeners in JPA. Eclipse link has done all
>>> the injection for entity listeners. It does not fire the event, @See
>>> createEntityListenerAndInjectDependancies(...)
>>>
>>> JPA spec section 3.5.1 does not mention this event requirement. How can
>>> the eclipse cdi implementation satisfy the CDI spec?
>>>
>>> [1]
>>> http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS
>>> ]
>>>  --
>>> Thanks
>>> Emily
>>> =================
>>> Emily Jiang
>>> ejiang at apache.org
>>>
>>>
>>> _______________________________________________
>>> weld-dev mailing listweld-dev at lists.jboss.orghttps://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/20150622/9eef9638/attachment.html 

From jharting at redhat.com  Tue Jun 23 02:25:32 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Tue, 23 Jun 2015 08:25:32 +0200
Subject: [weld-dev] JavaEE component classes - JPA entity listener
In-Reply-To: <CAECq3A-Jqc7Rqno4vOmsRW9PxCP2uhtpm79ca1DDeu1R7-hTqQ@mail.gmail.com>
References: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>	<5587138F.2050406@redhat.com>	<CAECq3A-TJa7spveWr_zgZFo3wyrxkX+vftdbr1+jwHmKuOGPAw@mail.gmail.com>	<CAECq3A-kh9fwBmfDWOQdEVwuS4m=BvhXrzBVwNQyOp=CS6PCgw@mail.gmail.com>
	<CAECq3A-Jqc7Rqno4vOmsRW9PxCP2uhtpm79ca1DDeu1R7-hTqQ@mail.gmail.com>
Message-ID: <5588FBDC.7080404@redhat.com>

Doing this using purely CDI APIs can be a bit tricky. One option that 
will most likely work is to combine BeanManager.resolveObserverMethods() 
method with a custom implementation of ProcessInjectionTarget interface. 
That way you can resolve the matching observer methods and then call 
their notify() method to deliver the event. Exception handling needs to 
be implemented to match the spec.

We should update the spec to define a more direct route and for the JPA 
spec to mention this requirement.

Jozef

On 06/22/2015 02:25 PM, Emily Jiang wrote:
> Jozef,
> Just re-iterate my concern:
> The implementation is in eclipse link. I guess they don't want to 
> depend on a specific CDI implementation. Therefore, what you suggested 
> may not be accepted by the eclipse link project.
>
> Thanks
> Emily
>
>
> On Sun, Jun 21, 2015 at 10:59 PM, Emily Jiang 
> <emijiang6 at googlemail.com <mailto:emijiang6 at googlemail.com>> wrote:
>
>     thanks Jozef!
>
>     On Sun, Jun 21, 2015 at 10:58 PM, Emily Jiang
>     <emijiang6 at googlemail.com <mailto:emijiang6 at googlemail.com>> wrote:
>
>         Jozef,
>         The implementation is in eclipse link. I guess they don't want
>         to depend on a specific CDI implementation.
>         Thanks
>         Emily
>
>         On Sun, Jun 21, 2015 at 8:42 PM, Jozef Hartinger
>         <jharting at redhat.com <mailto:jharting at redhat.com>> wrote:
>
>             Hi Emily,
>
>             the implementation should call the following method
>             http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldManager.html#fireProcessInjectionTarget-javax.enterprise.inject.spi.AnnotatedType-javax.enterprise.inject.spi.InjectionTarget-
>             on Weld BeanManager and use the returned value as the
>             InjectionTarget.
>
>             HTH,
>
>             Jozef
>
>
>             On 06/19/2015 12:28 PM, Emily Jiang wrote:
>>
>>             In CDI 1.2 spec
>>             11.5.7. ProcessInjectionPoint event
>>             The container must fire an event for every injection
>>             point of every Java EE component class
>>             supporting injection that may be instantiated by the
>>             container at runtime, including every managed bean
>>             declared using @ManagedBean, EJB session or
>>             message-driven bean, bean, interceptor or decorator.
>>
>>             The JavaEE component classes are mentioned in JavaEE
>>             platform EE.5-1, which includes servlets, servlet
>>             filters, entity listeners etc.
>>
>>             My concern is about entity listeners in JPA. Eclipse link
>>             has done all the injection for entity listeners. It does
>>             not fire the event, @See
>>             createEntityListenerAndInjectDependancies(...)
>>
>>             JPA spec section 3.5.1 does not mention this event
>>             requirement. How can the eclipse cdi implementation
>>             satisfy the CDI spec?
>>
>>             [1]
>>             http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS]
>>             -- 
>>             Thanks
>>             Emily
>>             =================
>>             Emily Jiang
>>             ejiang at apache.org <mailto:ejiang at apache.org>
>>
>>
>>             _______________________________________________
>>             weld-dev mailing list
>>             weld-dev at lists.jboss.org  <mailto:weld-dev at lists.jboss.org>
>>             https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
>
>
>         -- 
>         Thanks
>         Emily
>         =================
>         Emily Jiang
>         ejiang at apache.org <mailto:ejiang at apache.org>
>
>
>
>
>     -- 
>     Thanks
>     Emily
>     =================
>     Emily Jiang
>     ejiang at apache.org <mailto:ejiang at apache.org>
>
>
>
>
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org <mailto:ejiang at apache.org>

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

From emijiang6 at googlemail.com  Tue Jun 23 08:56:45 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Tue, 23 Jun 2015 13:56:45 +0100
Subject: [weld-dev] JavaEE component classes - JPA entity listener
In-Reply-To: <5588FBDC.7080404@redhat.com>
References: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>
	<5587138F.2050406@redhat.com>
	<CAECq3A-TJa7spveWr_zgZFo3wyrxkX+vftdbr1+jwHmKuOGPAw@mail.gmail.com>
	<CAECq3A-kh9fwBmfDWOQdEVwuS4m=BvhXrzBVwNQyOp=CS6PCgw@mail.gmail.com>
	<CAECq3A-Jqc7Rqno4vOmsRW9PxCP2uhtpm79ca1DDeu1R7-hTqQ@mail.gmail.com>
	<5588FBDC.7080404@redhat.com>
Message-ID: <CAECq3A-OQEMXqmUdWEdFLjKP=fRuHV=u1xKH3DT5F0QMrDJneg@mail.gmail.com>

+1 on revisiting this on the CDI spec. I think adding an additional method
on the BeanManager api would be good. Effectively, it is to promote this
very method on WeldManager to BeanManager. Shall I raise a CDI jira for
this?

On Tue, Jun 23, 2015 at 7:25 AM, Jozef Hartinger <jharting at redhat.com>
wrote:

>  Doing this using purely CDI APIs can be a bit tricky. One option that
> will most likely work is to combine BeanManager.resolveObserverMethods()
> method with a custom implementation of ProcessInjectionTarget interface.
> That way you can resolve the matching observer methods and then call their
> notify() method to deliver the event. Exception handling needs to be
> implemented to match the spec.
>
> We should update the spec to define a more direct route and for the JPA
> spec to mention this requirement.
>
> Jozef
>
>
> On 06/22/2015 02:25 PM, Emily Jiang wrote:
>
>   Jozef,
>  Just re-iterate my concern:
> The implementation is in eclipse link. I guess they don't want to depend
> on a specific CDI implementation. Therefore, what you suggested may not be
> accepted by the eclipse link project.
>
>  Thanks
>  Emily
>
>
> On Sun, Jun 21, 2015 at 10:59 PM, Emily Jiang <emijiang6 at googlemail.com>
> wrote:
>
>> thanks Jozef!
>>
>> On Sun, Jun 21, 2015 at 10:58 PM, Emily Jiang <emijiang6 at googlemail.com>
>> wrote:
>>
>>>   Jozef,
>>>  The implementation is in eclipse link. I guess they don't want to
>>> depend on a specific CDI implementation.
>>>  Thanks
>>>  Emily
>>>
>>> On Sun, Jun 21, 2015 at 8:42 PM, Jozef Hartinger <jharting at redhat.com>
>>> wrote:
>>>
>>>>  Hi Emily,
>>>>
>>>> the implementation should call the following method
>>>> http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldManager.html#fireProcessInjectionTarget-javax.enterprise.inject.spi.AnnotatedType-javax.enterprise.inject.spi.InjectionTarget-
>>>> on Weld BeanManager and use the returned value as the InjectionTarget.
>>>>
>>>> HTH,
>>>>
>>>> Jozef
>>>>
>>>>
>>>> On 06/19/2015 12:28 PM, Emily Jiang wrote:
>>>>
>>>>
>>>>  In CDI 1.2 spec
>>>> 11.5.7. ProcessInjectionPoint event
>>>> The container must fire an event for every injection point of every
>>>> Java EE component class
>>>> supporting injection that may be instantiated by the container at
>>>> runtime, including every managed bean declared using @ManagedBean, EJB
>>>> session or message-driven bean, bean, interceptor or decorator.
>>>>
>>>>  The JavaEE component classes are mentioned in JavaEE platform EE.5-1,
>>>> which includes servlets, servlet filters, entity listeners etc.
>>>>
>>>>  My concern is about entity listeners in JPA. Eclipse link has done all
>>>> the injection for entity listeners. It does not fire the event, @See
>>>> createEntityListenerAndInjectDependancies(...)
>>>>
>>>> JPA spec section 3.5.1 does not mention this event requirement. How can
>>>> the eclipse cdi implementation satisfy the CDI spec?
>>>>
>>>> [1]
>>>> http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS
>>>> ]
>>>>  --
>>>> Thanks
>>>> Emily
>>>> =================
>>>> Emily Jiang
>>>> ejiang at apache.org
>>>>
>>>>
>>>>  _______________________________________________
>>>> weld-dev mailing listweld-dev at lists.jboss.orghttps://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
>
>
>


-- 
Thanks
Emily
=================
Emily Jiang
ejiang at apache.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150623/1c38e35b/attachment-0001.html 

From jharting at redhat.com  Tue Jun 23 09:00:42 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Tue, 23 Jun 2015 15:00:42 +0200
Subject: [weld-dev] JavaEE component classes - JPA entity listener
In-Reply-To: <CAECq3A-OQEMXqmUdWEdFLjKP=fRuHV=u1xKH3DT5F0QMrDJneg@mail.gmail.com>
References: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>	<5587138F.2050406@redhat.com>	<CAECq3A-TJa7spveWr_zgZFo3wyrxkX+vftdbr1+jwHmKuOGPAw@mail.gmail.com>	<CAECq3A-kh9fwBmfDWOQdEVwuS4m=BvhXrzBVwNQyOp=CS6PCgw@mail.gmail.com>	<CAECq3A-Jqc7Rqno4vOmsRW9PxCP2uhtpm79ca1DDeu1R7-hTqQ@mail.gmail.com>	<5588FBDC.7080404@redhat.com>
	<CAECq3A-OQEMXqmUdWEdFLjKP=fRuHV=u1xKH3DT5F0QMrDJneg@mail.gmail.com>
Message-ID: <5589587A.3020003@redhat.com>

Yes please.

On 06/23/2015 02:56 PM, Emily Jiang wrote:
> +1 on revisiting this on the CDI spec. I think adding an additional 
> method on the BeanManager api would be good. Effectively, it is to 
> promote this very method on WeldManager to BeanManager. Shall I raise 
> a CDI jira for this?
>
> On Tue, Jun 23, 2015 at 7:25 AM, Jozef Hartinger <jharting at redhat.com 
> <mailto:jharting at redhat.com>> wrote:
>
>     Doing this using purely CDI APIs can be a bit tricky. One option
>     that will most likely work is to combine
>     BeanManager.resolveObserverMethods() method with a custom
>     implementation of ProcessInjectionTarget interface. That way you
>     can resolve the matching observer methods and then call their
>     notify() method to deliver the event. Exception handling needs to
>     be implemented to match the spec.
>
>     We should update the spec to define a more direct route and for
>     the JPA spec to mention this requirement.
>
>     Jozef
>
>
>     On 06/22/2015 02:25 PM, Emily Jiang wrote:
>>     Jozef,
>>     Just re-iterate my concern:
>>     The implementation is in eclipse link. I guess they don't want to
>>     depend on a specific CDI implementation. Therefore, what you
>>     suggested may not be accepted by the eclipse link project.
>>
>>     Thanks
>>     Emily
>>
>>
>>     On Sun, Jun 21, 2015 at 10:59 PM, Emily Jiang
>>     <emijiang6 at googlemail.com <mailto:emijiang6 at googlemail.com>> wrote:
>>
>>         thanks Jozef!
>>
>>         On Sun, Jun 21, 2015 at 10:58 PM, Emily Jiang
>>         <emijiang6 at googlemail.com <mailto:emijiang6 at googlemail.com>>
>>         wrote:
>>
>>             Jozef,
>>             The implementation is in eclipse link. I guess they don't
>>             want to depend on a specific CDI implementation.
>>             Thanks
>>             Emily
>>
>>             On Sun, Jun 21, 2015 at 8:42 PM, Jozef Hartinger
>>             <jharting at redhat.com <mailto:jharting at redhat.com>> wrote:
>>
>>                 Hi Emily,
>>
>>                 the implementation should call the following method
>>                 http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldManager.html#fireProcessInjectionTarget-javax.enterprise.inject.spi.AnnotatedType-javax.enterprise.inject.spi.InjectionTarget-
>>                 on Weld BeanManager and use the returned value as the
>>                 InjectionTarget.
>>
>>                 HTH,
>>
>>                 Jozef
>>
>>
>>                 On 06/19/2015 12:28 PM, Emily Jiang wrote:
>>>
>>>                 In CDI 1.2 spec
>>>                 11.5.7. ProcessInjectionPoint event
>>>                 The container must fire an event for every injection
>>>                 point of every Java EE component class
>>>                 supporting injection that may be instantiated by the
>>>                 container at runtime, including every managed bean
>>>                 declared using @ManagedBean, EJB session or
>>>                 message-driven bean, bean, interceptor or decorator.
>>>
>>>                 The JavaEE component classes are mentioned in JavaEE
>>>                 platform EE.5-1, which includes servlets, servlet
>>>                 filters, entity listeners etc.
>>>
>>>                 My concern is about entity listeners in JPA. Eclipse
>>>                 link has done all the injection for entity
>>>                 listeners. It does not fire the event, @See
>>>                 createEntityListenerAndInjectDependancies(...)
>>>
>>>                 JPA spec section 3.5.1 does not mention this event
>>>                 requirement. How can the eclipse cdi implementation
>>>                 satisfy the CDI spec?
>>>
>>>                 [1]
>>>                 http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS]
>>>                 -- 
>>>                 Thanks
>>>                 Emily
>>>                 =================
>>>                 Emily Jiang
>>>                 ejiang at apache.org <mailto:ejiang at apache.org>
>>>
>>>
>>>                 _______________________________________________
>>>                 weld-dev mailing list
>>>                 weld-dev at lists.jboss.org  <mailto:weld-dev at lists.jboss.org>
>>>                 https://lists.jboss.org/mailman/listinfo/weld-dev
>>
>>
>>
>>
>>             -- 
>>             Thanks
>>             Emily
>>             =================
>>             Emily Jiang
>>             ejiang at apache.org <mailto:ejiang at apache.org>
>>
>>
>>
>>
>>         -- 
>>         Thanks
>>         Emily
>>         =================
>>         Emily Jiang
>>         ejiang at apache.org <mailto:ejiang at apache.org>
>>
>>
>>
>>
>>     -- 
>>     Thanks
>>     Emily
>>     =================
>>     Emily Jiang
>>     ejiang at apache.org <mailto:ejiang at apache.org>
>
>
>
>
> -- 
> Thanks
> Emily
> =================
> Emily Jiang
> ejiang at apache.org <mailto:ejiang at apache.org>

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

From emijiang6 at googlemail.com  Tue Jun 23 09:31:27 2015
From: emijiang6 at googlemail.com (Emily Jiang)
Date: Tue, 23 Jun 2015 14:31:27 +0100
Subject: [weld-dev] JavaEE component classes - JPA entity listener
In-Reply-To: <5589587A.3020003@redhat.com>
References: <CAECq3A920cLeR_CQB4B0izj4UDWLQK5Xr3kCxD_9b8aNuOrDKQ@mail.gmail.com>
	<5587138F.2050406@redhat.com>
	<CAECq3A-TJa7spveWr_zgZFo3wyrxkX+vftdbr1+jwHmKuOGPAw@mail.gmail.com>
	<CAECq3A-kh9fwBmfDWOQdEVwuS4m=BvhXrzBVwNQyOp=CS6PCgw@mail.gmail.com>
	<CAECq3A-Jqc7Rqno4vOmsRW9PxCP2uhtpm79ca1DDeu1R7-hTqQ@mail.gmail.com>
	<5588FBDC.7080404@redhat.com>
	<CAECq3A-OQEMXqmUdWEdFLjKP=fRuHV=u1xKH3DT5F0QMrDJneg@mail.gmail.com>
	<5589587A.3020003@redhat.com>
Message-ID: <CAECq3A8fe7BmrQ2+6xhyqFm9jwfo=ieb=Qyy0nmCNEyZf0JYww@mail.gmail.com>

Raised https://issues.jboss.org/browse/CDI-537.

On Tue, Jun 23, 2015 at 2:00 PM, Jozef Hartinger <jharting at redhat.com>
wrote:

>  Yes please.
>
>
> On 06/23/2015 02:56 PM, Emily Jiang wrote:
>
> +1 on revisiting this on the CDI spec. I think adding an additional method
> on the BeanManager api would be good. Effectively, it is to promote this
> very method on WeldManager to BeanManager. Shall I raise a CDI jira for
> this?
>
> On Tue, Jun 23, 2015 at 7:25 AM, Jozef Hartinger <jharting at redhat.com>
> wrote:
>
>>  Doing this using purely CDI APIs can be a bit tricky. One option that
>> will most likely work is to combine BeanManager.resolveObserverMethods()
>> method with a custom implementation of ProcessInjectionTarget interface.
>> That way you can resolve the matching observer methods and then call their
>> notify() method to deliver the event. Exception handling needs to be
>> implemented to match the spec.
>>
>> We should update the spec to define a more direct route and for the JPA
>> spec to mention this requirement.
>>
>> Jozef
>>
>>
>> On 06/22/2015 02:25 PM, Emily Jiang wrote:
>>
>>   Jozef,
>>  Just re-iterate my concern:
>> The implementation is in eclipse link. I guess they don't want to depend
>> on a specific CDI implementation. Therefore, what you suggested may not be
>> accepted by the eclipse link project.
>>
>>  Thanks
>>  Emily
>>
>>
>> On Sun, Jun 21, 2015 at 10:59 PM, Emily Jiang <emijiang6 at googlemail.com>
>> wrote:
>>
>>> thanks Jozef!
>>>
>>> On Sun, Jun 21, 2015 at 10:58 PM, Emily Jiang <emijiang6 at googlemail.com>
>>> wrote:
>>>
>>>>   Jozef,
>>>>  The implementation is in eclipse link. I guess they don't want to
>>>> depend on a specific CDI implementation.
>>>>  Thanks
>>>>  Emily
>>>>
>>>> On Sun, Jun 21, 2015 at 8:42 PM, Jozef Hartinger <jharting at redhat.com>
>>>> wrote:
>>>>
>>>>>  Hi Emily,
>>>>>
>>>>> the implementation should call the following method
>>>>> http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldManager.html#fireProcessInjectionTarget-javax.enterprise.inject.spi.AnnotatedType-javax.enterprise.inject.spi.InjectionTarget-
>>>>> on Weld BeanManager and use the returned value as the InjectionTarget.
>>>>>
>>>>> HTH,
>>>>>
>>>>> Jozef
>>>>>
>>>>>
>>>>> On 06/19/2015 12:28 PM, Emily Jiang wrote:
>>>>>
>>>>>
>>>>>  In CDI 1.2 spec
>>>>> 11.5.7. ProcessInjectionPoint event
>>>>> The container must fire an event for every injection point of every
>>>>> Java EE component class
>>>>> supporting injection that may be instantiated by the container at
>>>>> runtime, including every managed bean declared using @ManagedBean, EJB
>>>>> session or message-driven bean, bean, interceptor or decorator.
>>>>>
>>>>>  The JavaEE component classes are mentioned in JavaEE platform EE.5-1,
>>>>> which includes servlets, servlet filters, entity listeners etc.
>>>>>
>>>>>  My concern is about entity listeners in JPA. Eclipse link has done
>>>>> all the injection for entity listeners. It does not fire the event, @See
>>>>> createEntityListenerAndInjectDependancies(...)
>>>>>
>>>>> JPA spec section 3.5.1 does not mention this event requirement. How
>>>>> can the eclipse cdi implementation satisfy the CDI spec?
>>>>>
>>>>> [1]
>>>>> http://git.eclipse.org/c/eclipselink/eclipselink.runtime.git/tree/foundation/org.eclipse.persistence.core/src/org/eclipse/persistence/internal/sessions/cdi/EntityListenerInjectionManagerImpl.java?h=2.6_WAS
>>>>> ]
>>>>>  --
>>>>> Thanks
>>>>> Emily
>>>>> =================
>>>>> Emily Jiang
>>>>> ejiang at apache.org
>>>>>
>>>>>
>>>>>  _______________________________________________
>>>>> weld-dev mailing listweld-dev at lists.jboss.orghttps://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
>>
>>
>>
>
>
> --
> 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/20150623/f518d317/attachment-0001.html 

From ooo_saturn7 at mail.ru  Wed Jun 24 11:13:12 2015
From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=)
Date: Wed, 24 Jun 2015 18:13:12 +0300
Subject: [weld-dev] =?utf-8?q?How_to_change_logging_level_for_weld_se?=
Message-ID: <1435158792.672328910@f193.i.mail.ru>

 Please, give the name of java system property which must be used in order to change the logging level for weld se.


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

From mkouba at redhat.com  Thu Jun 25 02:08:51 2015
From: mkouba at redhat.com (Martin Kouba)
Date: Thu, 25 Jun 2015 08:08:51 +0200
Subject: [weld-dev] How to change logging level for weld se
In-Reply-To: <1435158792.672328910@f193.i.mail.ru>
References: <1435158792.672328910@f193.i.mail.ru>
Message-ID: <558B9AF3.4010305@redhat.com>

Hi,

it depends on the logging framework used.

See also http://weld.cdi-spec.org/documentation/#10

Martin

Dne 24.6.2015 v 17:13 ????????? ???????? napsal(a):
> Please, give the name of java system property which must be used in
> order to change the logging level for weld se.
>
>
> --
> ????????? ????????
>
>
> _______________________________________________
> 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 ooo_saturn7 at mail.ru  Thu Jun 25 12:04:57 2015
From: ooo_saturn7 at mail.ru (=?UTF-8?B?0JDQu9C10LrRgdCw0L3QtNGAINCh0LLQuNGA0LjQtNC+0LI=?=)
Date: Thu, 25 Jun 2015 19:04:57 +0300
Subject: [weld-dev] =?utf-8?q?OsgiServiceProvider_and_Singleton?=
Message-ID: <1435248297.729999498@f369.i.mail.ru>

 I use weld se+pax+osgi.

I have 3 bundles. And I want that one instance of one class of one bundle be accessed via CDI to other bundles. I tried different ways but I found no solution. 

Is it possible to do taking into consideration that pax creates one cdi container for every bundle?


-- 
????????? ????????
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20150625/3201b4b0/attachment.html 

From jharting at redhat.com  Fri Jun 26 04:50:37 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Fri, 26 Jun 2015 10:50:37 +0200
Subject: [weld-dev] OsgiServiceProvider and Singleton
In-Reply-To: <1435248297.729999498@f369.i.mail.ru>
References: <1435248297.729999498@f369.i.mail.ru>
Message-ID: <558D125D.8040909@redhat.com>

Hi ?????????,

this is a Pax CDI question. Try asking at 
https://groups.google.com/forum/#!forum/ops4j

Jozef

On 06/25/2015 06:04 PM, ????????? ???????? wrote:
> I use weld se+pax+osgi.
>
> I have 3 bundles. And I want that one instance of one class of one 
> bundle be accessed via CDI to other bundles. I tried different ways 
> but I found no solution.
>
> Is it possible to do taking into consideration that pax creates one 
> cdi container for every bundle?
>
>
> -- 
> ????????? ????????
>
>
> _______________________________________________
> weld-dev mailing list
> weld-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev

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

From jharting at redhat.com  Mon Jun 29 05:31:48 2015
From: jharting at redhat.com (Jozef Hartinger)
Date: Mon, 29 Jun 2015 11:31:48 +0200
Subject: [weld-dev] Weld 2.2.14.Final
Message-ID: <55911084.5070809@redhat.com>

Weld 2.2.14.Final with several bug fixes has been released: 
http://weld.cdi-spec.org/download/