[weld-dev] Re: When are objects removed from CreationalContextImpl's lists of ContextualInstance?

[Martin Kouba]

In general, the dependent objects are destroyed when the 
CreationalContext.release() method is called, i.e. when a bean is 
destroyed. However, the implementation is a bit convoluted in order to 
handle various corner cases.


I'd recommend to track down the beans that reference the problematic CC 
instances and verify they're used correctly. A common source of similar 
memory leaks is the incorrect usage of javax.enterprise.inject.Instance, 
including CDI.current(), i.e. each Instance.get() for a @Dependent bean 
results in a new dependent instance that is stored in the relevant 
CreationalContext. See also http://weld.cdi-spec.org/documentation/#6.


HTH

Martin

On 21. 04. 21 17:57, Benjamin Confino wrote:

Hello

I have a customer who is experiencing out of memory errors. A memory 
analysis has found a CreationalContextImpl object containing a 
Collections$SynchronizedRandomAccessList that in turn contains a lot of 
SerializableContextualInstanceImpl objects. While the Memory Analysis 
cannot provide field names there are only two lists it could be: 
parentDependentInstances and dependentInstances


Given this I was hoping someone could tell me when objects are supposed 
to be removed from those two lists, and what/who is responsible for 
triggering removal from those two lists? I do not see any code to remove 
an object from parentDependentInstances and while objects are removed 
from dependentInstances they are done so in the method 
destroyDependentInstance, which is not part of either of the public 
interfaces implemented by this class: 
javax.enterprise.context.spi.CreationalContext and 
org.jboss.weld.construction.api.WeldCreationalContext


Thank you for your help
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@lists.jboss.org
To unsubscribe send an email to weld-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s



--
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list -- weld-dev@lists.jboss.org
To unsubscribe send an email to weld-dev-le...@lists.jboss.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

Re: [weld-dev] Odd type assignability test

[Martin Kouba]

Dne 27. 04. 20 v 14:26 Matej Novotny napsal(a):
> Forwarding this email to weld-dev to make it public
> 
> 
> So, the Foo is the required parameterized type here and Foo is 
> parameterized bean type.
> 
> And from CDI spec[1]:
>> A parameterized bean type is considered assignable to a parameterized 
>> required type if they have identical raw type and for each parameter:
>> * the required type parameter is an actual type, the bean type parameter is 
>> a type variable and the actual type is assignable to the upper bound, if 
>> any, of the type variable, or
> 
> Isn't that the same case? Or am I just running low on caffeine? :)

I think that you're right. Foo is basically Foo and 
according to the rules String is assignable to Object.

> 
> Matej
> 
> _
> [1] https://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#assignable_parameters
> 
> - Original Message -
>> From: "Laird Nelson" 
>> To: "Matej Novotny" 
>> Sent: Sunday, April 26, 2020 10:52:57 PM
>> Subject: Odd type assignability test
>>
>> Hello; I ran across this test during some code reading to better understand
>> type assignability.  It's in BeanTypeAssignabilityTest.java:
>>
>> @Test
>> public  void testStringFooMatchesVariableFoo() throws Exception {
>>  Type stringFooType = new TypeLiteral>() {
>>  }.getType();
>>  Type variableFooType = new TypeLiteral>() {
>>  }.getType();
>>  Assert.assertTrue("Foo should match Foo",
>> getRules().matches(stringFooType, variableFooType));
>> }
>>
>> Am I reading this right?  Is this saying that a reference of type
>> Foo should be able to receive a Foo, where E doesn't extend
>> String?
>>
>> I understand that any method that declares a type variable E and returns a
>> Foo will happen to produce a compatible reference.  That is:
>>
>> public  Foo blatz() { /* ... */ }
>>
>> can be called like this:
>>
>> final Foo foo = blatz(); // should work; E's upper bounds will be
>> String here
>>
>> But in this test, E has no upper bounds, so how does it work?
>>
>> Thanks,
>> Laird
>>
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

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

___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Validating for fields that are annotated with both EJB and Inject

[Martin Kouba]

Dne 15. 04. 20 v 12:42 Emily Jiang napsal(a):
> Matej,
> 
> Since @Inject can only work with a qualifier annotation not anything 
> other annotations, 

That's not correct. You can add any annotation to an injection point. 
I've seen it several times where a framework inspected the 
InjectionPoint to find certain annotations that have no meaning in CDI.


> do you think adding a validation criteria to assert 
> that is acceptable?
> For IDE validation, it is quite limited because a lot of work needs to 
> be done via runtime to figure out whether the 2nd annotation is a CDI 
> qualifier or not.
> 
> Thanks
> Emily
> 
> On Tue, Apr 14, 2020 at 3:28 PM Benjamin Confino  <mailto:benja...@uk.ibm.com>> wrote:
> 
> Hello weld
> 
> I had a customer with an issue that I believe occurred because they
> annotated a field with both @Inject and @EJB. This has given me two
> questions:
> 
> 1) Should weld throw an error when a field is annotated with both
> annotations?
> 
> 2) If so is the correct way to add something like
> 
>   if (ij.getAnnotated().isAnnotationPresent(Inject.class) &&
> ij.getAnnotated().isAnnotationPresent(EJB.class)) {
>      throw ...
> }
> 
> to Validator.validateInjectionPointForDefinitionErrors()
> 
> If so I'm willing to create a pull request, all I'd need is for you
> to tell me what the error message should say and please point me to
> which test I should expand to cover this case.
> 
> 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@lists.jboss.org <mailto:weld-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 
> 
> 
> -- 
> Thanks
> Emily
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

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


___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] PROBE-000014 - Caused by ClassNotFoundException: int

[Martin Kouba]

Thanks Benjamin.

Dne 20. 11. 18 v 14:37 Benjamin Confino napsal(a):
> Hi Martin
> 
> Unfortunately it looks like it doesn't recreate locally, and it looks 
> like our constantly running test environment has only seen this error 
> once so I don't have high hopes of getting a recreate. If I do manage to 
> reproduce it I'll be sure to debug ProbeDynamicMBean#classForName. It 
> does look like the primitive map should have caught prevented this issue.
> 
> Anyway, just wanted to keep you in the loop.
> 
> Regards
> Benjamin
> 
> 
> 
> From: Martin Kouba 
> To: Benjamin Confino , weld-dev@lists.jboss.org
> Date: 20/11/2018 09:25
> Subject: Re: [weld-dev] PROBE-14 - Caused by ClassNotFoundException: 
> int
> 
> 
> 
> 
> Hi Benjamin,
> 
> I've never seen this before. Could you try to debug the
> org.jboss.weld.probe.ProbeDynamicMBean#classForName(String) method and
> dump the parameter and the content of PRIMITIVES_MAP?
> 
> Martin
> 
> Dne 20. 11. 18 v 9:42 Benjamin Confino napsal(a):
>  > Hello
>  >
>  > I found a PROBE-14 error in my fat test suite which was Caused by:
>  > java.lang.ClassNotFoundException: int cannot be found by
>  > com.ibm.ws.org.jboss.weld.2.4.8_1.0.23.201811031441. Looking at the
>  > stack, I think weld is the code deciding to do a class lookup on int,
>  > have you ever seen this before? Any idea what might be triggering weld
>  > do lookup int? I had a quick look at the application code and couldn't
>  > see anything weird involving ints.
>  >
>  > Here is the full stack:
>  >
>  > org.jboss.weld.exceptions.DeploymentException: PROBE-14: Cannot
>  > register a Probe MBean interface org.jboss.weld.probe.JsonDataProvider
>  > for: cdi12helloworldtest
>  >          at
>  > 
> org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:38)
>  
> 
>  >
>  >          at
>  > 
> org.jboss.weld.bootstrap.events.AfterDeploymentValidationImpl.fire(AfterDeploymentValidationImpl.java:28)
>  
> 
>  >
>  >          at
>  > org.jboss.weld.bootstrap.WeldStartup.validateBeans(WeldStartup.java:487)
>  >          at
>  > 
> org.jboss.weld.bootstrap.WeldBootstrap.validateBeans(WeldBootstrap.java:90)
>  >          at
>  > 
> com.ibm.ws.cdi.impl.CDIContainerImpl.startInitialization(CDIContainerImpl.java:152)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:438)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:28)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:50)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:383)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.deployApp(DeployedAppInfoBase.java:412)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.app.manager.ear.internal.EARApplicationHandlerImpl.install(EARApplicationHandlerImpl.java:76)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.app.manager.internal.statemachine.StartAction.execute(StartAction.java:140)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.enterState(ApplicationStateMachineImpl.java:1258)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.app.manager.internal.statemachine.ApplicationStateMachineImpl.run(ApplicationStateMachineImpl.java:873)
>  
> 
>  >
>  >          at
>  > 
> com.ibm.ws.threading.internal.ExecutorServiceImpl$RunnableWrapper.run(ExecutorServiceImpl.java:232)
>  
> 
>  >
>  >          at
>  > 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
>  
> 
>  >
>  >          at
>  > 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
>  
> 
>  >
>  >          at java.lang.Thread.run(Thread.java:748)
>  > Caused by: org.jboss.weld.exceptions.IllegalStateException:
>  > PROBE-14: Cannot register a Probe MBean interface
>  > org.jboss.weld.probe.JsonDataProvider 

Re: [weld-dev] PROBE-000014 - Caused by ClassNotFoundException: int

[Martin Kouba]

at 
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:154)
>          at 
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:148)
>          at 
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
>  
> 
>          at 
> org.jboss.weld.bootstrap.events.AbstractDeploymentContainerEvent.fire(AbstractDeploymentContainerEvent.java:35)
>  
> 
>          ... 17 more
> Caused by: javax.management.NotCompliantMBeanException: Bad getMBeanInfo()
>          at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:336)
>  
> 
>          at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:319)
>  
> 
>          at 
> com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:522) 
> 
>          at 
> com.ibm.ws.kernel.boot.jmx.service.MBeanServerForwarderDelegate.registerMBean(MBeanServerForwarderDelegate.java:221)
>  
> 
>          at 
> com.ibm.ws.jmx.internal.DelayedMBeanActivator.registerMBean(DelayedMBeanActivator.java:663)
>  
> 
>          at 
> com.ibm.ws.kernel.boot.jmx.internal.PlatformMBeanServer.registerMBean(PlatformMBeanServer.java:435)
>  
> 
>          at 
> org.jboss.weld.probe.ProbeExtension.afterDeploymentValidation(ProbeExtension.java:174)
>  
> 
>          ... 33 more
> Caused by: org.jboss.weld.resources.spi.ResourceLoadingException: Error 
> loading class int
>          at 
> org.jboss.weld.resources.AbstractClassLoaderResourceLoader.classForName(AbstractClassLoaderResourceLoader.java:42)
>  
> 
>          at 
> org.jboss.weld.probe.ProbeDynamicMBean.classForName(ProbeDynamicMBean.java:139)
>  
> 
>          at 
> org.jboss.weld.probe.ProbeDynamicMBean.toParamTypes(ProbeDynamicMBean.java:131)
>  
> 
>          at 
> org.jboss.weld.probe.ProbeDynamicMBean.findMethod(ProbeDynamicMBean.java:122) 
> 
>          at 
> org.jboss.weld.probe.ProbeDynamicMBean.getParameterName(ProbeDynamicMBean.java:94)
>  
> 
>          at 
> javax.management.StandardMBean.getOperations(StandardMBean.java:1001)
>          at 
> javax.management.StandardMBean.getMBeanInfo(StandardMBean.java:459)
>          at 
> com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:333)
>  
> 
>          ... 39 more
> Caused by: java.lang.ClassNotFoundException: int cannot be found by 
> com.ibm.ws.org.jboss.weld.2.4.8_1.0.23.201811031441
>          at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:484)
>  
> 
>          at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:395)
>  
> 
>          at 
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:387)
>  
> 
>          at 
> org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:150)
>  
> 
>          at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
>          at 
> org.jboss.weld.resources.AbstractClassLoaderResourceLoader.classForName(AbstractClassLoaderResourceLoader.java:40)
>  
> 
>          ... 46 more
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why?

[Martin Kouba]

Hi Laird,

The reason why it is possible to register multiple context objects for a 
scope is that a particular context implementation may be intended for a 
specific use case/technology. Take for example the request context - it 
should be active during HTTP requests, async EJB invocation, MDB, etc. 
It wouldn't be practical to only have one Context implementation for all 
use cases.

The spec is very clear that this should be possible. See for example 
6.5.1. The active context object for a scope:
"The container must search for an active instance of Context associated 
with the scope type."

And even 6.2. The Context interface:
"A context object may be defined for any of the built-in scopes and 
registered with the container using the AfterBeanDiscovery event as 
described in AfterBeanDiscovery event."

HTH

Martin

Dne 01. 11. 18 v 22:46 Laird Nelson napsal(a):
> I noticed that BeanManagerImpl permits many Contexts to be indexed under 
> a given scope type 
> <https://github.com/weld/core/blob/d8a8cb64f3a9751dcac07c8d9eda0dd3a0e682b8/impl/src/main/java/org/jboss/weld/manager/BeanManagerImpl.java#L663>.
>   
> Why is that?
> 
> The CDI 2.0 specification says 
> <http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#contexts>:
> 
> "Associated with every scope type is a context object."
> 
> I took "a context object" to mean "exactly one context object" but maybe 
> I'm mistaken?  Obviously Weld can do things outside of the specification 
> but I was curious what the use case might be here.
> 
> I do understand that certainly only one Context of a given scope type 
> may be active.  I was just curious why the container even permits many 
> to be registered.
> 
> Best,
> Laird
> 
> _______
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] [cdi-dev] Question about the spec for BeanManager.getBeans

[Martin Kouba]

>  >
>  > ___
>  > weld-dev mailing list
>  > weld-dev@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
> 
> 
> ___
> cdi-dev mailing list
> cdi-...@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/cdi-dev
> 
> Note that for all code provided on this list, the provider licenses the code 
> under the Apache License, Version 2 
> (http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
> provided on this list, the provider waives all patent and other intellectual 
> property rights inherent in such information.
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Should EventImpl.fireAsync use ExecutorServices from the ServiceRegistry

[Martin Kouba]

Hi Benjamin,

If no Executor is provided - either fireAsync(U event) or no executor 
set to the notification options - Weld uses the Executor returned from 
org.jboss.weld.manager.api.ExecutorServices#getTaskExecutor() or 
ForkJoinPool#commonPool() if no ExecutorServices is registered. In other 
words, it's up to the integrator which Executor is used.

And yes, Event#fireAsync(U, NotificationOptions) javadoc is outdated - 
in the first versions it was only possible to pass an Executor.

What does the NPE look like?

Thanks,

Martin

Dne 17.7.2018 v 18:30 Benjamin Confino napsal(a):
> Hello
> 
> I have a customer with the following
> 
>         @Inject
>          Event event;
> 
>          @Resource
>          ManagedExecutorService threadPool;
> 
>         public void fireAsyncEvent() {
>        System.out.println("Sending Async-Message via CDI");
>        event.fireAsync(new Message("Hello"));
>          }
> 
>          public void fireAsyncEvent_2() {
>        event.fireAsync(new Message("Hello"), 
> NotificationOptions.ofExecutor(threadPool));
>          }
> 
> fireAsyncEvent() eventually results in an NPE when a JSF class attempts 
> tries to call CDI.current() fireAsyncEvent_2() works correctly. I was 
> hoping that it would be possible to fix fireAsyncEvent to remove the 
> dependency on passing in an executor service every time it is used.
> 
> We currently set an executor service into the weld service registry, and 
> I was wondering if org.jboss.weld.event.EventImpl fetch the  executor 
> service from the service registry. Either only when fireAsync is called 
> without any NotificationOptions, or perhaps more aggressively and set 
> the default executor service if NotificationOptions are provided but do 
> not explicitly contain an executor service (The javadoc is unclear, but 
> I believe calling ofExecutor() provides this functionality).
> 
> Before going further with this I wanted to ask for a quick sanity check. 
> Is this fix plausible?
> 
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] RquestScoped not active inside WeldInitialListener.requestDestroyed

[Martin Kouba]

thodAccessorImpl.java:90)
>  > at
>  > 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
>  > at java.lang.reflect.Method.invoke(Method.java:508)
>  > at
>  > 
> org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.invokeMethods(DefaultLifecycleCallbackInvoker.java:97)
>  > at
>  > 
> org.jboss.weld.injection.producer.DefaultLifecycleCallbackInvoker.preDestroy(DefaultLifecycleCallbackInvoker.java:90)
>  > at
>  > 
> org.jboss.weld.injection.producer.BasicInjectionTarget.preDestroy(BasicInjectionTarget.java:127)
>  > at org.jboss.weld.bean.ManagedBean.destroy(ManagedBean.java:191)
>  > at
>  > 
> org.jboss.weld.util.bean.IsolatedForwardingBean.destroy(IsolatedForwardingBean.java:50)
>  > at
>  > 
> org.jboss.weld.context.AbstractContext.destroyContextualInstance(AbstractContext.java:139)
>  > at 
> org.jboss.weld.context.AbstractContext.destroy(AbstractContext.java:153)
>  > at
>  > 
> org.jboss.weld.context.AbstractManagedContext.deactivate(AbstractManagedContext.java:58)
>  > at
>  > 
> org.jboss.weld.context.AbstractBoundContext.deactivate(AbstractBoundContext.java:72)
>  > at
>  > 
> org.jboss.weld.servlet.HttpContextLifecycle.safelyDeactivate(HttpContextLifecycle.java:378)
>  > at
>  > 
> org.jboss.weld.servlet.HttpContextLifecycle.requestDestroyed(HttpContextLifecycle.java:311)
>  > at
>  > 
> org.jboss.weld.servlet.WeldInitialListener.requestDestroyed(WeldInitialListener.java:135)
>  > at
>  > 
> com.ibm.ws.webcontainer.managedobject.ManagedObjectListenerWrapper.requestDestroyed(ManagedObjectListenerWrapper.java:98)
>  > at
>  > 
> com.ibm.ws.webcontainer.webapp.WebApp.notifyServletRequestDestroyed(WebApp.java:2042)
>  > at
>  > 
> com.ibm.wsspi.webcontainer.collaborator.CollaboratorHelper.postInvokeCollaborators(CollaboratorHelper.java:532)
>  > at
>  > 
> com.ibm.ws.webcontainer.filter.WebAppFilterManager.invokeFilters(WebAppFilterManager.java:1282)
>  > at
>  > 
> com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:82)
>  > at 
> com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:963)
>  > at
>  > 
> com.ibm.ws.webcontainer.WSWebContainer.handleRequest(WSWebContainer.java:1817)
>  > at
>  > 
> com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:382)
>  > at
>  > 
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:465)
>  > at
>  > 
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewRequest(HttpInboundLink.java:532)
>  > at
>  > 
> com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.processRequest(HttpInboundLink.java:318)
>  > at
>  > 
> com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:88)
>  > at
>  > 
> com.ibm.ws.tcp.channel.impl.AioReadCompletionListener.futureCompleted(AioReadCompletionListener.java:175)
>  > at
>  > 
> com.ibm.io.async.AbstractAsyncFuture.invokeCallback(AbstractAsyncFuture.java:217)
>  > at
>  > 
> com.ibm.io.async.AsyncChannelFuture.fireCompletionActions(AsyncChannelFuture.java:161)
>  > at com.ibm.io.async.AsyncFuture.completed(AsyncFuture.java:138)
>  > at com.ibm.io.async.ResultHandler.complete(ResultHandler.java:204)
>  > at
>  > 
> com.ibm.io.async.ResultHandler.runEventProcessingLoop(ResultHandler.java:775)
>  > at com.ibm.io.async.ResultHandler$2.run(ResultHandler.java:905)
>  > at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java:1909)
>  >
>  > 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@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
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Staring weld container for SE environment makes me load java ee classes.

[Martin Kouba]

Dne 17.5.2018 v 12:50 Alex Sviridov napsal(a):
> Hi Martin,
> 
> Could you or someone else explain what is the difference between 
> getResource(String name) and getResources(String name) in 
> ResourceLoader? 

It's similar to java.lang.ClassLoader.getResource(String) and 
java.lang.ClassLoader.getResources(String).

> And, could anyone explain how Weld detects what archives 
> it must scan? For examlpe, if from getResource I return 
> `jar:file:///home/user/../jar/my-archive-0.1.0-SNAPSHOT.jar!/META-INF/beans.xml`
>  
> , does it mean that Weld will scan my-archive-0.1.0-SNAPSHOT.jar as it 
> will get the path to archive from this URL?

Yes, Weld will attempt to process the referenced bean archive (using all 
registered 
org.jboss.weld.environment.deployment.discovery.BeanArchiveHandler 
instances).

> 
> Best regards, Alex
> 
> Четверг, 17 мая 2018, 10:12 +03:00 от Martin Kouba <mko...@redhat.com>:
> 
> Dne 16.5.2018 v 20:02 Alex Sviridov napsal(a):
>  > Hi Matej
>  >
>  > I followed your answer and run Weld (SE) as auto module in my JPMS
>  > layer. In this layer I have an arhive with beans.xml
>  > This is my code:
>  >    Weld weld = new Weld();
>  >     WeldContainer container = weld.initialize();
>  >
>  > This is what I get:
>  >
>  > INFO: WELD-000900: 3.0.4 (Final)
>  > May 16, 2018 7:00:39 PM
>  >
> 
> org.jboss.weld.environment.deployment.discovery.ReflectionDiscoveryStrategy
> 
>  > processAnnotatedDiscovery
>  > INFO: WELD-ENV-14: Falling back to Java Reflection for
>  > bean-discovery-mode="annotated" discovery. Add org.jboss:jandex
> to the
>  > classpath to speed-up startup.
>  > 2018-05-16 19:00:39:187 [main] ERROR
>  > com.techsenger.webserver.core.internal.Activator - Error starting
> server
>  > java.lang.IllegalStateException: WELD-ENV-002009: Weld SE container
>  > cannot be initialized - no bean archives found
>  >     at
>  >
> 
> weld.se.core@3.0.4.Final/org.jboss.weld.environment.se.Weld.createDeployment(Weld.java:962)
>  >     at
>  >
> 
> weld.se.core@3.0.4.Final/org.jboss.weld.environment.se.Weld.initialize(Weld.java:773)
>  >
>  > Are there any ways to control what modules Weld should scan if we
>  > initialize via Weld class?
> 
> Weld SE does not support JPMS modules atm. By default, the
> TCCL#getResources() is used to find all beans.xml (if set) or the
> ClassLoader which loaded the WeldResourceLoader.class. However, you can
> provide a custom ClassLoader or
> org.jboss.weld.resources.spi.ResourceLoader respectively (see
> Weld#setClassLoader() and Weld#setResourceLoader()).
> 
>  >
>  > By the way: STOP creating packages with the same name in
> different JAR
>  > arhives! JPMS doesn't allow it! I had to merge core-impl, spi and
> api in
>  > one file.
> 
> Which packages are you talking about? We do know about this limitation
> and AFAIK this was fixed in 3.0.0. If there is a duplicit package pls
> create a JIRA issue.
> 
>  >
>  > Best regards, Alex
>  >
>  > Среда, 16 мая 2018, 16:47 +03:00 от Matej Novotny
>  > <manov...@redhat.com <mailto:manov...@redhat.com>
> <mailto:manov...@redhat.com>>:
>  >
>  > Weld 2.x is NOT to be executed with Java 9+.
>  > Use Weld 3, please. Best use latest release of course (3.0.4.Final).
>  >
>  > If you can share the test project on GH, that would be neat as well.
>  > Then we could see how you use weld as auto module (as well as many
>  > other configurations) and go from there.
>  >
>  > As for starting SE container, you shouldn't manually call
>  > `bootstrap.startContainer(Environments.SE, deployment);`
>  > Please see the docs on how to bootstrap Weld in SE, you shouldn't
>  > need to deal with any of the methods you listed below.
>  > Here is a doc link -
>  >
> 
> http://docs.jboss.org/weld/reference/latest-master/en-US/html_single/#_bootstrapping_cdi_se
>  >
>  > Regards
>  > Matej
>  >
>  > - Original Message -
>  > > From: "Alex Sviridov" <ooo_satu...@mail.ru
> <mailto:ooo_satu...@mail.ru>
>  > >
>  > > To: "weld-dev" <weld-dev@lists.jboss.org
> <mailto:weld-dev@lists.jboss.org>
>  

Re: [weld-dev] @WithAnnotations filtering not picking up annotations from implemented interfaces

[Martin Kouba]

Hi Marko,

comments inline...

Dne 2.5.2018 v 16:57 Marko Bekhta napsal(a):
> Hi all,
> 
> In Hibernate Validator CDI extension we are using @WithAnnotations to filter
> beans that potentially need to be validated (for actual usage see [1]):
> 
> public  void processAnnotatedType(@Observes @WithAnnotations({
> Constraint.class,
> Valid.class,
> ValidateOnExecution.class
> }) ProcessAnnotatedType processAnnotatedTypeEvent) {
> // doing something ...
> }
> 
> The problem that we've stumbled upon is that it looks like this 
> filtering does
> not take into account the information from implemented interfaces. For 
> example
> let's assume we have an interface:
> 
> @ValidateOnExecution(type = ExecutableType.ALL)
> public interface ShipmentService {
> public void findShipment(@NotNull String id);
> }
> 
> which is implemented by ShipmentServiceImpl:
> 
> public class ShipmentServiceImpl implements ShipmentService {
> 
> @Override
> public void findShipment(String id) {
> }
> }
> 
> Our expectation would be that as interface is marked with one of the 
> annotations
> listed among values of @WithAnnotations filter, the corresponding bean
> (ShipmentServiceImpl) would be pushed to processAnnotatedType(..) 
> method. But it
> is not. As a result we don't create a validation proxy and corresponding 
> service
> bean never performs any validation operations.  In case when any of the 
> filtered
> annotations is added to the impl bean things start to work (impl bean is 
> processed).
> 
> The above case shows placement of annotation on a type level, but similar
> behavior is observed in cases when annotation is on a method level.
> 
> As forcing presence of one of the annotations from the filter list on a impl
> beans is not really an option, an alternative could be to drop the
> @WithAnnotations filtering completely. Which is also not that great, as
> dropping the filtering would mean that:
> 
> - Validation extension would need to process all possible beans that are 
> available
> - Such processing requires calls to Hibernate Validatior which must 
> create the metadata
> for each bean hierarchy and store it, even if nobody actually needs to 
> validate those
> beans.
> - This would lead to much greater memory consumption as well as longer 
> bootstrap
> time. Which is not good.
> 
> Hence we would like to ask if there is any particular reasons why 
> @WithAnnotations

Well, the reason is that the spec requires this:

"If the annotation is applied, the container must only deliver 
ProcessAnnotatedType events for types which contain at least one of the 
annotations specified. The annotation can appear on the annotated type, 
or on any member, or any parameter of any member of the annotated type, 
as defined in Alternative metadata sources."

See also 
http://docs.jboss.org/cdi/spec/2.0/cdi-spec.html#process_annotated_type

Annotations should be inherited (and PAT fired) if @Inherited 
meta-annotation is used. But I'm not quite sure this works. Also note 
that annotations are never inherited from interfaces (see also 
java.lang.annotation.Inherited javadoc)!

> filter does not consider looking at super classes and implemented 
> interfaces to check
> for annotations listed in @WithAnnotations?

> 
> Have a nice day,
> Marko
> 
> [1] 
> https://github.com/hibernate/hibernate-validator/blob/master/cdi/src/main/java/org/hibernate/validator/cdi/ValidationExtension.java#L222
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] WIP fix for https://issues.jboss.org/browse/WELD-1130

[Martin Kouba]

Hi Benjamin,

I'm sorry but the Weld team is burried under some high priority issues. 
I've quickly went through your proposal and have few comments.

1. I think it would be more convenient to modify 
org.jboss.weld.module.web.context.beanstore.http.AbstractSessionBeanStore.getAttribute(String)
 
which is used for both the HTTP session and the conversation contexts

2. +1 for config property, we probably need a better name though ;-)

3. You're probably aware that this would not solve the problem 
completely. It should trigger the replication when a @SessionScoped bean 
instance is obtained from the context, e.g. when a client proxy method 
is invoked. However, there are some optimizations in Weld which prevent 
the context lookup (see also 
org.jboss.weld.bean.ContextualInstanceStrategy). Also the replication 
may happen before the state is actually changed - it really depends on 
replication impl details. Still, I agree that this would improve the 
usability.

4. +10 for tests. But I guess it would be tricky to write an automated 
test for this.

Martin

Dne 13.4.2018 v 21:33 Benjamin Confino napsal(a):
> Hello
> 
> I posed 
> https://github.com/benjamin-confino/core/commit/35d055cd9a841cfbdf2bcb2aaa3e0d8d6116ec1cto
>  
> this lift list month but have not heard any feedback. When can I expect 
> to hear if this concept is good in principal? If the concept is good I 
> can begin investigating how to extend the idea to conversation scopes 
> and write a test.
> 
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Integrating with Weld Probe

[Martin Kouba]

rInjectionPoint.newInstance(ConstructorInjectionPoint.java:78)
> at 
> org.jboss.weld.injection.producer.AbstractInstantiator.newInstance(AbstractInstantiator.java:28)
> at 
> org.jboss.weld.injection.producer.InterceptorApplyingInstantiator.newInstance(InterceptorApplyingInstantiator.java:62)
> at 
> org.jboss.weld.injection.producer.ConstructorInterceptionInstantiator.newInstance(ConstructorInterceptionInstantiator.java:66)
> at 
> org.jboss.weld.injection.producer.BasicInjectionTarget.produce(BasicInjectionTarget.java:112)
> at 
> org.jboss.weld.injection.producer.BeanInjectionTarget.produce(BeanInjectionTarget.java:186)
> at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:158)
> at org.jboss.weld.contexts.AbstractContext.get(AbstractContext.java:96)
> at 
> org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:100)
> at 
> org.jboss.weld.bean.ContextualInstanceStrategy$ApplicationScopedContextualInstanceStrategy.get(ContextualInstanceStrategy.java:140)
> at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> at 
> org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:102)
> at 
> org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:131)
> 
> 
> Even though based on the docs that should be all that's needed.  Is 
> there something else required to get Probe running in SE?
> 
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] https://issues.jboss.org/browse/WELD-1130

[Martin Kouba]

Hi Emily,

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

Martin

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

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Potential bug with Typed not affecting if a ProducerMethod is proxiable.

[Martin Kouba]

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

Martin

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

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Class#getGenericInterfaces() on a CDI proxy

[Martin Kouba]

Hi Marko,

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

Martin

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

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] https://issues.jboss.org/browse/WELD-1130

[Martin Kouba]

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

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

Martin

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

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 3.0.3.Final released

[Martin Kouba]

http://weld.cdi-spec.org/news/2018/02/09/weld-303Final/

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Jandex

[Martin Kouba]

Hi Emily,

AFAIK WildFly makes use of existing Jandex indexes and if not present a 
new one is build on the fly (for deployment and external modules) but 
the generated indexes are not persisted.

But in WildFly not only Weld leverages the indexes - all other 
annotation-based technologies should use them too.

Martin

Dne 15.11.2017 v 14:47 Emily Jiang napsal(a):
> Hi Martin/Matej,
> For using Jandex to improve bootstrap performance of CDI application, do 
> you know any application server (e.g. Wildfly) normally requires the 
> index files to be generated before hand or it can generate on the fly 
> and then persist it? Do you know whether there is much performance gain 
> to generate the index files on the fly and then persist it when compared 
> with not doing it at all (by passing jandex)?
> Thanks
> Emily
> 
> Emily Jiang
> 
> WebSphere Application Server, MicroProfile Development Lead
> Phone: 44-1962-816278
> E-mail: emiji...@uk.ibm.com 
> Twitter: @emilyfhjiang
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] illegal access exception on org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler

[Martin Kouba]

I see no stack trace in SWARM-772 description?

Dne 2.11.2017 v 11:36 Emily Jiang napsal(a):
> Just curious. What is the wildfly issue then? It seems reporting the 
> same stack.
> Thanks
> Emily
> 
> Emily Jiang
> 
> WebSphere Application Server, MicroProfile Development Lead
> Phone: 44-1962-816278
> E-mail: emiji...@uk.ibm.com <mailto:emiji...@uk.ibm.com>
> Twitter: @emilyfhjiang
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> 
> - Original message -
> From: Martin Kouba <mko...@redhat.com>
> Sent by: weld-dev-boun...@lists.jboss.org
> To: Emily Jiang <emiji...@uk.ibm.com>
> Cc: weld-dev@lists.jboss.org
> Subject: Re: [weld-dev] illegal access exception on
> org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler
> Date: Wed, Nov 1, 2017 6:11 PM
> Dne 1.11.2017 v 18:41 Emily Jiang napsal(a):
>  > Thank you Martin! We did more experiment. It seems the JDK
> 8.0.4.6 and
>  > newer has this issue. We will follow up with IBM JDK team to find
> out why.
>  > It seems someone reported the same issue on
>  >
> 
> wildfly(https://urldefense.proofpoint.com/v2/url?u=https-3A__issues.jboss.org_browse_SWARM-2D772=DwIGaQ=jf_iaSHvJObTbx-siA1ZOg=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U=U6DM4X-mvUo7Nxy1fa9jUPIWXsBof6oGvsFw75PvhxM=q7HQuvdXQ7qfvYUzFtuyMbD_yb8Xf3fcU4KRzGiGkqY=)
> 
> Hm, this Swarm issue does not seem to be related...
> 
>  > Thanks
>  > Emily
>  > 
>  > Emily Jiang
>  >
>  > WebSphere Application Server, MicroProfile Development Lead
>  > Phone: 44-1962-816278
>  > E-mail: emiji...@uk.ibm.com <mailto:emiji...@uk.ibm.com>
>  > Twitter: @emilyfhjiang
>  > IBM United Kingdom Limited
>  > Registered in England and Wales with number 741598
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hants.
> PO6 3AU
>  >
>  >     - Original message -
>  >     From: Martin Kouba <mko...@redhat.com>
>  >     Sent by: weld-dev-boun...@lists.jboss.org
>  >     To: Emily Jiang <emiji...@uk.ibm.com>
>  >     Cc: weld-dev@lists.jboss.org
>  >     Subject: Re: [weld-dev] illegal access exception on
>  >     org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler
>  >     Date: Wed, Nov 1, 2017 7:23 AM
>  >     Hi Emily,
>  >
>  >     the exception message looks odd. Do you have some more info?
> E.g. do
>  >     also you hit the problem with older versions of jdk8?
>  >
>  >     Martin
>  >
>  >     Dne 1.11.2017 v 00:32 Emily Jiang napsal(a):
>  >      > Hi Martin/Matej,
>  >      > We hit the following problem with Jdk 8.
>  >      > Caused by: java.lang.BootstrapMethodError:
>  >      > java.lang.IllegalAccessException:
>  >      >
> 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no
>  >      > access to:
>  >     'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>  >      >      at
>  >      >
>  >
> 
> org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.(ObserverNotifier.java:480)
>  >      >      at
>  >      >
>  >
> org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
>  >      >      at
>  >      >
>  >
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
>  >      >      at
>  >      >
>  >
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
>  >      >      at
>  >      >
>  >
> 
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
>  >      >      at
>  >      >
>  >
> 
> org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
>  >      >      at
>  >      >
>  >
> 
> org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
>  >      >      at
>  >      >
>  >
> 
> org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
>  >      >

Re: [weld-dev] illegal access exception on org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler

[Martin Kouba]

Dne 1.11.2017 v 18:41 Emily Jiang napsal(a):
> Thank you Martin! We did more experiment. It seems the JDK 8.0.4.6 and 
> newer has this issue. We will follow up with IBM JDK team to find out why.
> It seems someone reported the same issue on 
> wildfly(https://issues.jboss.org/browse/SWARM-772)

Hm, this Swarm issue does not seem to be related...

> Thanks
> Emily
> 
> Emily Jiang
> 
> WebSphere Application Server, MicroProfile Development Lead
> Phone: 44-1962-816278
> E-mail: emiji...@uk.ibm.com <mailto:emiji...@uk.ibm.com>
> Twitter: @emilyfhjiang
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. PO6 3AU
> 
> - Original message -
> From: Martin Kouba <mko...@redhat.com>
> Sent by: weld-dev-boun...@lists.jboss.org
> To: Emily Jiang <emiji...@uk.ibm.com>
> Cc: weld-dev@lists.jboss.org
> Subject: Re: [weld-dev] illegal access exception on
> org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler
> Date: Wed, Nov 1, 2017 7:23 AM
> Hi Emily,
> 
> the exception message looks odd. Do you have some more info? E.g. do
> also you hit the problem with older versions of jdk8?
> 
> Martin
> 
> Dne 1.11.2017 v 00:32 Emily Jiang napsal(a):
>  > Hi Martin/Matej,
>  > We hit the following problem with Jdk 8.
>  > Caused by: java.lang.BootstrapMethodError:
>  > java.lang.IllegalAccessException:
>  > 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no
>  > access to:
> 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>  >      at
>  >
> 
> org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.(ObserverNotifier.java:480)
>  >      at
>  >
> org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
>  >      at
>  >
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
>  >      at
>  >
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
>  >      at
>  >
> 
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
>  >      at
>  >
> 
> org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
>  >      at
>  >
> 
> org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
>  >      at
>  >
> 
> org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
>  >      at
>  >
> 
> org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
>  >      at
>  > com.ibm.ws.cdi.impl.CDIContainerImpl$2.run(CDIContainerImpl.java:141)
>  >      at
>  > com.ibm.ws.cdi.impl.CDIContainerImpl$2.run(CDIContainerImpl.java:138)
>  >      at
>  >
> java.security.AccessController.doPrivileged(AccessController.java:594)
>  >      at
>  >
> 
> com.ibm.ws.cdi.impl.CDIContainerImpl.applicationStarting(CDIContainerImpl.java:138)
>  >      at
>  >
> 
> com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:379)
>  >      at
>  >
> 
> com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:28)
>  >      at
>  >
> 
> com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:50)
>  >      at
>  >
> 
> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:375)
>  >      ... 8 more
>  > Caused by: java.lang.IllegalAccessException:
>  > 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no
>  > access to:
> 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>  >      at
>  >
> 
> java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
>  >      at
>  >
> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
>  >      at
>  >
> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
>  >      at
>  >
> java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
>  >      at
>  >
> 
> java.lang.invo

Re: [weld-dev] illegal access exception on org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler

[Martin Kouba]

Hi Emily,

the exception message looks odd. Do you have some more info? E.g. do 
also you hit the problem with older versions of jdk8?

Martin

Dne 1.11.2017 v 00:32 Emily Jiang napsal(a):
> Hi Martin/Matej,
> We hit the following problem with Jdk 8.
> Caused by: java.lang.BootstrapMethodError: 
> java.lang.IllegalAccessException: 
> 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no 
> access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>      at 
> org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler.(ObserverNotifier.java:480)
>      at 
> org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:273)
>      at 
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:177)
>      at 
> org.jboss.weld.event.ObserverNotifier.fireEvent(ObserverNotifier.java:171)
>      at 
> org.jboss.weld.bootstrap.events.AbstractContainerEvent.fire(AbstractContainerEvent.java:53)
>      at 
> org.jboss.weld.bootstrap.events.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
>      at 
> org.jboss.weld.bootstrap.events.BeforeBeanDiscoveryImpl.fire(BeforeBeanDiscoveryImpl.java:54)
>      at 
> org.jboss.weld.bootstrap.WeldStartup.startInitialization(WeldStartup.java:391)
>      at 
> org.jboss.weld.bootstrap.WeldBootstrap.startInitialization(WeldBootstrap.java:76)
>      at 
> com.ibm.ws.cdi.impl.CDIContainerImpl$2.run(CDIContainerImpl.java:141)
>      at 
> com.ibm.ws.cdi.impl.CDIContainerImpl$2.run(CDIContainerImpl.java:138)
>      at 
> java.security.AccessController.doPrivileged(AccessController.java:594)
>      at 
> com.ibm.ws.cdi.impl.CDIContainerImpl.applicationStarting(CDIContainerImpl.java:138)
>      at 
> com.ibm.ws.cdi.liberty.CDIRuntimeImpl.applicationStarting(CDIRuntimeImpl.java:379)
>      at 
> com.ibm.ws.container.service.state.internal.ApplicationStateManager.fireStarting(ApplicationStateManager.java:28)
>      at 
> com.ibm.ws.container.service.state.internal.StateChangeServiceImpl.fireApplicationStarting(StateChangeServiceImpl.java:50)
>      at 
> com.ibm.ws.app.manager.module.internal.DeployedAppInfoBase.preDeployApp(DeployedAppInfoBase.java:375)
>      ... 8 more
> Caused by: java.lang.IllegalAccessException: 
> 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler' no 
> access to: 'org.jboss.weld.event.ObserverNotifier$ObserverExceptionHandler'
>      at 
> java.lang.invoke.MethodHandles$Lookup.checkClassAccess(MethodHandles.java:371)
>      at 
> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:281)
>      at 
> java.lang.invoke.MethodHandles$Lookup.checkAccess(MethodHandles.java:264)
>      at 
> java.lang.invoke.MethodHandles$Lookup.findStatic(MethodHandles.java:468)
>      at 
> java.lang.invoke.MethodHandle.sendResolveMethodHandle(MethodHandle.java:966)
>      at java.lang.invoke.MethodHandle.getCPMethodHandleAt(Native Method)
>      at 
> java.lang.invoke.MethodHandle.resolveInvokeDynamic(MethodHandle.java:856)
>      ... 25 more
> java version "1.8.0_144"
> Java(TM) SE Runtime Environment (build 8.0.5.0 - 
> pwi3280sr5-20170905_01(SR5))
> IBM J9 VM (build 2.9, JRE 1.8.0 Windows 7 x86-32 20170901_363591 (JIT 
> enabled, A
> OT enabled)
> J9VM - d56eb84
> JIT  - tr.open_20170901_140853_d56eb84
> OMR  - b033a01)
> JCL - 20170823_01 based on Oracle jdk8u144-b01
> Do you know what is wrong here?
> Thanks
> Emily
> 
> Emily Jiang
> 
> WebSphere Application Server, MicroProfile Development Lead
> Phone: 44-1962-816278
> E-mail: emiji...@uk.ibm.com 
> Twitter: @emilyfhjiang
> IBM United Kingdom Limited
> Registered in England and Wales with number 741598
> Registered office: PO Box 41, North Harbour, Portsmouth, Hants. 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] CDI JavaSE tck

[Martin Kouba]

Dne 17.10.2017 v 16:01 Emily Jiang napsal(a):
> Back to my original question, TestGroups.SE is not supposed to be run by 
> an application server such as Wildfly, Glassfish, Liberty, right?

Yes.

> For certifying EE8, these tests are supposed to be excluded by JavaEE 
> runtimes?

Yes. A Java EE runtime TCK runner should not include the tests from this 
group.

> Are these tests only for JavaSE runtime such as Hammock?

TestGroups.SE is supposed to be run by a CDI implementation itself.

> 
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI & MicroProfile Development Lead
> 
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
> 
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> 
> 
> 
> 
> From: Matej Novotny <manov...@redhat.com>
> To: Martin Kouba <mko...@redhat.com>
> Cc: "John D. Ament" <john.d.am...@gmail.com>, Emily Jiang 
> <emiji...@uk.ibm.com>, Weld <weld-dev@lists.jboss.org>
> Date: 17/10/2017 14:17
> Subject: Re: [weld-dev] CDI JavaSE tck
> 
> 
> 
> 
> Sorry for later answer, yea the only TCK test is the one which Martin 
> pointed to.
> However, I don't see much need to cover this particular case on EE part.
> The section of the spec which defines throwing ISE with multiple 
> providers belongs to SE part of the spec, so it feel natural that it's 
> tested there.
> 
> Though if you feel like we should have even EE test then by all means 
> feel free to create JIRA ticket for this and I'll eventually get to it.
> 
> Matej
> 
> - Original Message -
>  > From: "Martin Kouba" <mko...@redhat.com>
>  > To: "John D. Ament" <john.d.am...@gmail.com>, "Emily Jiang" 
> <emiji...@uk.ibm.com>, "Weld" <weld-dev@lists.jboss.org>
>  > Sent: Tuesday, October 17, 2017 8:53:26 AM
>  > Subject: Re: [weld-dev] CDI JavaSE tck
>  >
>  > Dne 16.10.2017 v 20:30 John D. Ament napsal(a):
>  > >
>  > >
>  > > On Mon, Oct 16, 2017 at 2:07 PM Martin Kouba <mko...@redhat.com
>  > > <mailto:mko...@redhat.com>> wrote:
>  > >
>  > >     Hi Emily,
>  > >
>  > >     tests from TestGroups.SE should NOT be run in a Java EE 
> environment.
>  > >     Note that CDI Bootstrap API should not even work in a Java EE 
> container
>  > >     (SeContainerInitializer.newInstance() should throw
>  > >     IllegalStateException).
>  > >
>  > >
>  > > Isn't there a TCK test for that?
>  >
>  > I think not. There is a test in CDI API which verifies that
>  > IllegalStateException is thrown if none or multiple service providers
>  > are found [1]. But it's actually a good idea to create a new TCK test
>  > with TestGroups.INTEGRATION group to verify ISE is thrown in a Java EE
>  > container.
>  >
>  > M
>  >
>  > [1]
>  > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_cdi-2Dspec_cdi_blob_master_api_src_test_java_org_jboss_cdi_api_test_se_SeContainerInitializerTest.java=DwIFaQ=jf_iaSHvJObTbx-siA1ZOg=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U=I-wCdin9dELdurPsIgviW7msB3rHLauyQkEtuCi92lY=a27X8Pl3e9WrQ7pr8wED7YuL4Jst6Px1uEBdmCUhxGg=
>  >
>  > >
>  > >
>  > >     Martin
>  > >
>  > >     Dne 16.10.2017 v 14:33 Emily Jiang napsal(a):
>  > >      > Hi Matej/Martin,
>  > >      >
>  > >      > I am looking at the CDI 2.0 tck on JavaSE. I saw they are 
> under the
>  > >      > groups of "SE". Should the tcks be exercised by JavaEE 
> runtime, e.g.
>  > >      > wildfly, glassfish, Liberty etc? Which profile did you 
> package the
>  > >      > JavaSE tck?
>  > >      >
>  > >      >
>  > >      > Many thanks,
>  > >      > Emily
>  > >      > ===
>  > >      > Emily Jiang
>  > >      > WebSphere Application Server, CDI & MicroProfile Development 
> Lead
>  > >      >
>  > >      > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>  > >      > Phone: +44 (0)1962 816278 <tel:+44%201962%20816278>  Internal:
>  > >      > 246278
>  > >      >
>  > >      > Email: emiji...@uk.ibm.com <mailto:emiji...@uk.ibm.com>
>  > >      > Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>  > >      >
&

Re: [weld-dev] CDI JavaSE tck

[Martin Kouba]

Dne 16.10.2017 v 20:30 John D. Ament napsal(a):
> 
> 
> On Mon, Oct 16, 2017 at 2:07 PM Martin Kouba <mko...@redhat.com 
> <mailto:mko...@redhat.com>> wrote:
> 
> Hi Emily,
> 
> tests from TestGroups.SE should NOT be run in a Java EE environment.
> Note that CDI Bootstrap API should not even work in a Java EE container
> (SeContainerInitializer.newInstance() should throw
> IllegalStateException).
> 
> 
> Isn't there a TCK test for that?

I think not. There is a test in CDI API which verifies that 
IllegalStateException is thrown if none or multiple service providers 
are found [1]. But it's actually a good idea to create a new TCK test 
with TestGroups.INTEGRATION group to verify ISE is thrown in a Java EE 
container.

M

[1]
https://github.com/cdi-spec/cdi/blob/master/api/src/test/java/org/jboss/cdi/api/test/se/SeContainerInitializerTest.java

> 
> 
> Martin
> 
> Dne 16.10.2017 v 14:33 Emily Jiang napsal(a):
>  > Hi Matej/Martin,
>  >
>  > I am looking at the CDI 2.0 tck on JavaSE. I saw they are under the
>  > groups of "SE". Should the tcks be exercised by JavaEE runtime, e.g.
>  > wildfly, glassfish, Liberty etc? Which profile did you package the
>  > JavaSE tck?
>  >
>  >
>  > Many thanks,
>  > Emily
>  > ===
>  > Emily Jiang
>  > WebSphere Application Server, CDI & MicroProfile Development Lead
>  >
>  > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>  > Phone: +44 (0)1962 816278 <tel:+44%201962%20816278>  Internal: 246278
>  >
>  > Email: emiji...@uk.ibm.com <mailto:emiji...@uk.ibm.com>
>  > Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>  >
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth,
> Hampshire PO6 3AU
>  >
>  >
>  > ___
>  > weld-dev mailing list
>  > weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>
>  > https://lists.jboss.org/mailman/listinfo/weld-dev
>  >
> 
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Principal built-in bean

[Martin Kouba]

Well, it works similar to how @Dependent stateless session beans work. 
Unlike @RequestScoped there is no real CDI context just a special proxy 
that delegates to SPI.

Martin

Dne 4.9.2017 v 11:09 Emily Jiang napsal(a):
> Does this mean it functions as a Request scoped bean even though it is a 
> Dependent bean?
> 
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI & MicroProfile Development Lead
> 
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
> 
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> 
> 
> 
> 
> From: Martin Kouba <mko...@redhat.com>
> To: Emily Jiang <emijia...@googlemail.com>, Weld-Dev List 
> <weld-dev@lists.jboss.org>
> Date: 04/09/2017 09:24
> Subject: Re: [weld-dev] Principal built-in bean
> Sent by: weld-dev-boun...@lists.jboss.org
> 
> 
> 
> 
> It's @Dependent. But a special proxy is injected and SPI
> org.jboss.weld.security.spi.SecurityServices.getPrincipal() is invoked
> to obtain the current caller identity for every invocation of an
> injected reference.
> 
> Martin
> 
> Dne 1.9.2017 v 16:57 Emily Jiang napsal(a):
>  > A Java EE or embeddable EJB container must provide the following
>  > built-in beans, all of which
>  > have qualifier @Default:
>  >
>  > a bean with bean type javax.security.Principal, allowing injection of a
>  > Principal
>  > representing the current caller identity.
>  >
>  > The spec does not say the scope of this bean. In Weld, what is the scope
>  > for the Principal bean?
>  >
>  > --
>  > Thanks
>  > Emily
>  > =
>  > Emily Jiang
>  > eji...@apache.org <mailto:eji...@apache.org>
>  >
>  >
>  > ___
>  > weld-dev mailing list
>  > weld-dev@lists.jboss.org
>  > 
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U=jIKn0UxNi92JGBmOv2ycs3JoHrlVZC6ARxh7qsqJzE8=7SXNuw9nF99r1RrRF97m4EBatYRmA9igLcjOExFx6ak=
>  >
> 
> -- 
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.jboss.org_mailman_listinfo_weld-2Ddev=DwICAg=jf_iaSHvJObTbx-siA1ZOg=jt2y5_gH2oPaja8Vt6NzAZV-iEo6D2jiWeuVYs0H-1U=jIKn0UxNi92JGBmOv2ycs3JoHrlVZC6ARxh7qsqJzE8=7SXNuw9nF99r1RrRF97m4EBatYRmA9igLcjOExFx6ak=
> 
> 
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Principal built-in bean

[Martin Kouba]

It's @Dependent. But a special proxy is injected and SPI 
org.jboss.weld.security.spi.SecurityServices.getPrincipal() is invoked 
to obtain the current caller identity for every invocation of an 
injected reference.

Martin

Dne 1.9.2017 v 16:57 Emily Jiang napsal(a):
> A Java EE or embeddable EJB container must provide the following 
> built-in beans, all of which
> have qualifier @Default:
> 
> a bean with bean type javax.security.Principal, allowing injection of a 
> Principal
> representing the current caller identity.
> 
> The spec does not say the scope of this bean. In Weld, what is the scope 
> for the Principal bean?
> 
> -- 
> Thanks
> Emily
> =
> Emily Jiang
> eji...@apache.org <mailto:eji...@apache.org>
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] How to make method injection when bean subclass is required in Weld?

[Martin Kouba]

Hi Alex,

that's an interesting question. Indeed, qualifiers are the way to go if 
you need to keep the method signature.

Another way could be to override the setFoo() method so that the Child 
initializer is ignored and add a new method to inject AdvancedFoo:

@Override
protected void setFoo(SimpleFoo foo) { // Do nothing }

@Inject
void setAdvancedFoo(AdvancedFoo foo) {
   super.setFoo(foo);
}

However, note that right now there are the following beans:

SimpleFoo with bean types Object, SimpleFoo
AdvancedFoo -> Object, SimpleFoo, AdvancedFoo

So if you do @Inject SimpleFoo you get ambiguous dependency exception 
because both SimpleFoo and AdvancedFoo are eligible for injection.

To resolve this you need to use qualifiers or restrict the bean types of 
AdvancedFoo:

@Typed(AdvancedFoo.class)
class AdvancedFoo extends SimpleFoo {}

HTH

Martin


Dne 29.8.2017 v 15:09 Matej Novotny napsal(a):
> Hi Alex,
> 
> no need to be sorry, you have come to the right place :)
> As for your question, the simplest thing is probably to use qualifiers.
> 
> Create your own like this:
> 
> @Qualifier
> @Retention(RetentionPolicy.RUNTIME)
> @Target({ ElementType.TYPE, ElementType.PARAMETER, ElementType.FIELD, 
> ElementType.METHOD })
> public @interface MyQualifier {}
> 
> 
> And then change your AdvancedFoo class to use the qualifier:
> 
> @Dependent
> @MyQualifier
> public class AdvancedFoo extends SimpleFoo {
> }
> 
> And accordingly, the init method which uses injection should then look like 
> this:
> 
> @Dependent
> public class Parent extends Child {
> 
>@Inject
>@Override
>protected void setFoo(@MyQualifier SimpleFoo foo) {
>  super.setFoo(foo);
>}
> }
> 
> Does this answer your question?
> 
> Matej
> 
> - Original Message -
>> From: "Alex Sviridov" <ooo_satu...@mail.ru>
>> To: "weld-dev" <weld-dev@lists.jboss.org>
>> Sent: Tuesday, August 29, 2017 1:46:23 PM
>> Subject: [weld-dev] How to make method injection when bean subclass is 
>> required in Weld?
>>
>> Hi all,
>>
>> I am really sorry for writing to this mailing list, but I checked all user
>> forums and chats and saw that they are very old.
>>
>> I would be very thankful if someone gives suggestion for solving the
>> following problem.
>> I have a child and parent class. Child has SimpleFoo, Parent needs Advaced
>> foo. So,
>>
>> @Dependent
>> public class SimpleFoo {
>> }
>>
>> @Dependent
>> public class AdvancedFoo extends SimpleFoo {
>> }
>>
>> @Dependent
>> public class Child {
>>
>> private SimpleFoo foo;
>>
>> @Inject
>> protected void setFoo(SimpleFoo foo) {
>> this.foo = foo;
>> }
>> }
>>
>> @Dependent
>> public class Parent extends Child {
>>
>> @Inject
>> @Override
>> protected void setFoo(SimpleFoo foo) { //How to inject here AdvancedFoo?
>> super.setFoo(foo);
>> }
>> }
>>
>> How to inject in Parent AdvancedFoo? I know that I can do it via constructor
>> injection
>> but I need method injection. How to do it? Can it be done without using names
>> (like MyBean1)
>> but only using classes (AdvancedFoo)?
>>
>> Best regards, Alex
>>
>>
>>
>>
>>
>> --
>> Alex Sviridov
>>
>> ___
>> weld-dev mailing list
>> weld-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Dependent Scoped bean aquired by CDI.current() is not destroyed

[Martin Kouba]

FYI I've created https://issues.jboss.org/browse/WELD-2413

Martin

Dne 9.8.2017 v 12:41 Martin Kouba napsal(a):
> Hi Benjamin,
> 
> the lifecycle of @Dependent instances created through 
> javax.enterprise.inject.spi.CDI is not well defined. So it's always 
> better to destroy such instances when not needed. However, it would make 
> sense to destroy such instances during shutdown.
> 
> I believe this works in Weld SE. What environment/runtime do you use?
> 
> Martin
> 
> Dne 9.8.2017 v 11:52 Benjamin Confino napsal(a):
>> Hello
>>
>> I have a servlet that acquires two instances of a dependent scoped 
>> bean. The first is aquired by @Inject Instance the second is 
>> acquired via CDI.current().select(CdiBean.class).get().
>>
>> I can see that the first instance's @PreDestroy is called when I shut 
>> down the application. However @PreDestroy is not called on the 
>> instance acquired CDI.current. Here is the source:
>>
>>
>>
>> My question is, is this behaviour intentional? And if it is, can you 
>> please link me to the appropriate part of the spec that says when we 
>> should expect a @Dependent bean created by CDI.current to be 
>> destroyed? I have a customer concerned about this causing a potential 
>> memory leak.
>>
>> 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Dependent Scoped bean aquired by CDI.current() is not destroyed

[Martin Kouba]

Hi Benjamin,

the lifecycle of @Dependent instances created through 
javax.enterprise.inject.spi.CDI is not well defined. So it's always 
better to destroy such instances when not needed. However, it would make 
sense to destroy such instances during shutdown.

I believe this works in Weld SE. What environment/runtime do you use?

Martin

Dne 9.8.2017 v 11:52 Benjamin Confino napsal(a):
> Hello
> 
> I have a servlet that acquires two instances of a dependent scoped bean. 
> The first is aquired by @Inject Instance the second is acquired 
> via CDI.current().select(CdiBean.class).get().
> 
> I can see that the first instance's @PreDestroy is called when I shut 
> down the application. However @PreDestroy is not called on the instance 
> acquired CDI.current. Here is the source:
> 
> 
> 
> My question is, is this behaviour intentional? And if it is, can you 
> please link me to the appropriate part of the spec that says when we 
> should expect a @Dependent bean created by CDI.current to be destroyed? 
> I have a customer concerned about this causing a potential memory leak.
> 
> 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Do Custom implementations of Bean need to provide injection points?

[Martin Kouba]

Something like this should do the trick:

new InjectionPoint() {

 @Override
 public boolean isTransient() {
 return false;
 }

 @Override
 public boolean isDelegate() {
 return false;
 }

 @Override
 public Type getType() {
 return InjectionPoint.class;
 }

 @Override
 public Set getQualifiers() {
return Collections. singleton(new 
AnnotationLiteral() {});
 }

 @Override
 public Member getMember() {
 return null;
 }

 @Override
 public Bean getBean() {
 return this;
 }

 @Override
 public Annotated getAnnotated() {
 return null;
 }
 };

Martin

Dne 4.8.2017 v 14:35 John D. Ament napsal(a):
> Martin,
> 
> Knowing that I don't have any reference to an injection point, what 
> would you recommend I pass in as a dummy injection point?
> 
> John
> 
> On Fri, Aug 4, 2017 at 8:07 AM Martin Kouba <mko...@redhat.com 
> <mailto:mko...@redhat.com>> wrote:
> 
> Hm, I think BeanManager.getReference() should not be used here, see also
> 6.5.3. Contextual reference for a bean [1]:
> 
> "The container must ensure that every injection point of type
> InjectionPoint and qualifier @Default of any dependent object
> instantiated during this process receives a null value if it is not
> being injected into any injection point."
> 
> However, in Weld you could use
> BeanManager.getInjectableReference(InjectionPoint, CreationalContext)
> and provide some dummy IP. See for example
> 
> https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/injectionPoint/custom/BarBean.java#L50.
> 
> FYI there is a TCK test that verifies the InjectionPoint is null if
> using getReference() outside custom bean's create:
> 
> org.jboss.cdi.tck.tests.lookup.injectionpoint.InjectionPointTest#testNullInjectionPointInjectedIntoNonInjectedObject()
> 
> Martin
> 
>     [1]
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#contextual_reference
> 
> Dne 4.8.2017 v 13:05 Martin Kouba napsal(a):
>  > Hi John,
>  >
>  > Bean.getInjectionPoints() is only used during validation - returned
>  > injection points are validated at initialization time, so for a
> custom
>  > bean it makes sense to return an empty set as there are no real
>  > injection points.
>  >
>  > WRT lookup - what exactly do you try to accomplish? Do you try to
> obtain
>  > InjectionPoint metadata from inside a custom dependent bean's
> create()
>  > method? This should be possible although not clearly specified. I
> think
>  > we have a test with
> BeanManager.getInjectableReference(InjectionPoint,
>  > CreationalContext) but I will need to double check.
>  >
>  > I will also look at the geronimo-config repo.
>  >
>  > Martin
>  >
>  > Dne 4.8.2017 v 11:42 John D. Ament napsal(a):
>  >> Hi
>  >>
>  >> As the subject says.  I have a library that registers a custom
>  >> implementation of Bean, which has a method
>  >>
>  >>  @Override
>  >>  public Set getInjectionPoints() {
>  >>  return Collections.emptySet();
>  >>  }
>  >>
>  >> When testing this on Weld3, I have code that looks up the injection
>  >> point, to find the annotations present.  However, the following
>  >> injection point lookup fails:
>  >>
>  >>  private static InjectionPoint findInjectionPoint(final
>  >> BeanManager bm, final CreationalContext ctx) {
>  >>  return InjectionPoint.class.cast(
>  >> bm.getReference(bm.resolve(bm.getBeans(InjectionPoint.class)),
>  >> InjectionPoint.class, ctx));
>  >>  }
>  >>
>  >> so based on a CreationalContext I'm looking for InjectionPoint. 
> Maybe
>  >> there's a different way that this is supposed to work?  If you're
>  >> interested in giving it a shot, take a look at
>  >> https://github.com/apache/geronimo-config and run the Weld3
> profile to
>  >> replicate the issue.
>  >>
>  >> John
>  >>
>  >>
>  >> ___
>  >> weld-dev mailing list
>  >> weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>
>  >> https://lists.jboss.org/mailman/listinfo/weld-dev
>  >>
>  >
> 
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Do Custom implementations of Bean need to provide injection points?

[Martin Kouba]

Hm, I think BeanManager.getReference() should not be used here, see also 
6.5.3. Contextual reference for a bean [1]:

"The container must ensure that every injection point of type 
InjectionPoint and qualifier @Default of any dependent object 
instantiated during this process receives a null value if it is not 
being injected into any injection point."

However, in Weld you could use 
BeanManager.getInjectableReference(InjectionPoint, CreationalContext) 
and provide some dummy IP. See for example 
https://github.com/weld/core/blob/master/tests-arquillian/src/test/java/org/jboss/weld/tests/injectionPoint/custom/BarBean.java#L50.

FYI there is a TCK test that verifies the InjectionPoint is null if 
using getReference() outside custom bean's create: 
org.jboss.cdi.tck.tests.lookup.injectionpoint.InjectionPointTest#testNullInjectionPointInjectedIntoNonInjectedObject()

Martin

[1]
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#contextual_reference

Dne 4.8.2017 v 13:05 Martin Kouba napsal(a):
> Hi John,
> 
> Bean.getInjectionPoints() is only used during validation - returned 
> injection points are validated at initialization time, so for a custom 
> bean it makes sense to return an empty set as there are no real 
> injection points.
> 
> WRT lookup - what exactly do you try to accomplish? Do you try to obtain 
> InjectionPoint metadata from inside a custom dependent bean's create() 
> method? This should be possible although not clearly specified. I think 
> we have a test with BeanManager.getInjectableReference(InjectionPoint, 
> CreationalContext) but I will need to double check.
> 
> I will also look at the geronimo-config repo.
> 
> Martin
> 
> Dne 4.8.2017 v 11:42 John D. Ament napsal(a):
>> Hi
>>
>> As the subject says.  I have a library that registers a custom 
>> implementation of Bean, which has a method
>>
>>  @Override
>>  public Set getInjectionPoints() {
>>  return Collections.emptySet();
>>  }
>>
>> When testing this on Weld3, I have code that looks up the injection 
>> point, to find the annotations present.  However, the following 
>> injection point lookup fails:
>>
>>  private static InjectionPoint findInjectionPoint(final 
>> BeanManager bm, final CreationalContext ctx) {
>>  return InjectionPoint.class.cast(
>> bm.getReference(bm.resolve(bm.getBeans(InjectionPoint.class)), 
>> InjectionPoint.class, ctx));
>>  }
>>
>> so based on a CreationalContext I'm looking for InjectionPoint.  Maybe 
>> there's a different way that this is supposed to work?  If you're 
>> interested in giving it a shot, take a look at 
>> https://github.com/apache/geronimo-config and run the Weld3 profile to 
>> replicate the issue.
>>
>> John
>>
>>
>> ___
>> weld-dev mailing list
>> weld-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Do Custom implementations of Bean need to provide injection points?

[Martin Kouba]

Hi John,

Bean.getInjectionPoints() is only used during validation - returned 
injection points are validated at initialization time, so for a custom 
bean it makes sense to return an empty set as there are no real 
injection points.

WRT lookup - what exactly do you try to accomplish? Do you try to obtain 
InjectionPoint metadata from inside a custom dependent bean's create() 
method? This should be possible although not clearly specified. I think 
we have a test with BeanManager.getInjectableReference(InjectionPoint, 
CreationalContext) but I will need to double check.

I will also look at the geronimo-config repo.

Martin

Dne 4.8.2017 v 11:42 John D. Ament napsal(a):
> Hi
> 
> As the subject says.  I have a library that registers a custom 
> implementation of Bean, which has a method
> 
>  @Override
>  public Set getInjectionPoints() {
>  return Collections.emptySet();
>  }
> 
> When testing this on Weld3, I have code that looks up the injection 
> point, to find the annotations present.  However, the following 
> injection point lookup fails:
> 
>  private static InjectionPoint findInjectionPoint(final BeanManager 
> bm, final CreationalContext ctx) {
>  return InjectionPoint.class.cast(
>  
> bm.getReference(bm.resolve(bm.getBeans(InjectionPoint.class)), 
> InjectionPoint.class, ctx));
>  }
> 
> so based on a CreationalContext I'm looking for InjectionPoint.  Maybe 
> there's a different way that this is supposed to work?  If you're 
> interested in giving it a shot, take a look at 
> https://github.com/apache/geronimo-config and run the Weld3 profile to 
> replicate the issue.
> 
> John
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] WELD-001417 while enabling interceptors in JBoss Forge addons

[Martin Kouba]

   > I appreciate any help!
>  >
>  > Best Regards,
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  > George Gastaldi
>  >
>  > Principal Software Engineer
>  >
>  > Red Hat
>  >
>  > Remote
>  >
>  > Joinville - Santa Catarina
>  >
>  > ggast...@redhat.com <mailto:ggast...@redhat.com> M:
> +55-47-99711-1000 <tel:+55%2047%2099711-1000>
>  > TRIED. TESTED. TRUSTED.
>  > @redhatnews Red Hat Red Hat
>  >
>  >
>  > ___
>  > weld-dev mailing list
>  > weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>
>  > https://lists.jboss.org/mailman/listinfo/weld-dev
> <https://lists.jboss.org/mailman/listinfo/weld-dev>
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/weld-dev
> <https://lists.jboss.org/mailman/listinfo/weld-dev>
> 
> 
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] PAX-WEB + PAX-CDI + WELD = Problem scavenging sessions' java.lang.IllegalStateException

[Martin Kouba]

Hi Alex,

what does Bundle.update actually do? Is the HTTP session destroyed? Are 
the HttpSessionListener instances thrown away?

It looks like the Weld container is restarted but the Weld listener is 
reused and thus is referencing the previous container which is cleaned 
up and shutdown.

Martin

Dne 1.6.2017 v 09:01 Alex Sviridov napsal(a):
> Hi all
> 
> The question is about using Pax-Web (osgi servlet container) + Pax-Cdi + 
> Weld.
> There is a bug in pax-web https://ops4j1.jira.com/browse/PAXWEB-760 than 
> can't
> be fixed about 2.5 year. And it seems that it is linked with weld. So I post
> my question here - maybe someone of weld developers can give any hints, 
> ideas
> etc that can help us. So, the situation.
> 
> Configuration: jetty 9.3.11.v20160721, weld 2.2.12.Final, pax-cdi 
> 0.13.0-SNAPSHOT,
> pax-swissbox 1.8.0 , pax-web 6.0.0-SNAPSHOT.We must have a war bundle with
> servlet + cdi bean. In servlet we do
> 
> private  void processRequest(HttpServletRequest request, HttpServletResponse 
> response){
>  HttpSession session = request.getSession();
>  session.setMaxInactiveInterval(60);//Note, these are seconds.
> call some cdi bean method
> }
> 
> The problem appears when we update war bundle on osgi when there is a 
> live session.
> So, timing is very important here. What we do by steps and time:
> hr:min:sec
> 1) at 00:00:00 we start our war bundle
> 2) at 00:00:10 we make the first http request to our servlet with cdi 
> bean call
> 3) at 00:00:30 we update our war bundle on osgi (Bundle.update)
> 4) at 00:00:40 we make the second http request to our servlet with cdi 
> bean call
> 5) at 00:01:40 we get the following exception:
> 
> 2016-08-28 16:40:53,385 | WARN  | er@57af3ea4Timer | 39 - 
> org.ops4j.pax.web.pax-web-jetty - 6.0.0.SNAPSHOT | 
> org.ops4j.pax.web.service.jetty.internal.LateInvalidatingHashSessionManager | 
> Problem scavenging sessions
> java.lang.RuntimeException: Error accessing invisible AbstractSession method 
> via reflection
>   at 
> org.ops4j.pax.web.service.jetty.internal.LateInvalidatingHashSessionManager.sessionTimeout(LateInvalidatingHashSessionManager.java:169)
>   at 
> org.ops4j.pax.web.service.jetty.internal.LateInvalidatingHashSessionManager.scavenge(LateInvalidatingHashSessionManager.java:82)
>   at 
> org.eclipse.jetty.server.session.HashSessionManager$Scavenger.run(HashSessionManager.java:84)
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>   at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.reflect.InvocationTargetException
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at 
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>   at java.lang.reflect.Method.invoke(Method.java:497)
>   at 
> org.ops4j.pax.web.service.jetty.internal.LateInvalidatingHashSessionManager.sessionTimeout(LateInvalidatingHashSessionManager.java:166)
>   ... 9 more
> Caused by: org.jboss.weld.exceptions.UnsatisfiedResolutionException: 
> WELD-001308: Unable to resolve any beansfor  Type:class 
> org.jboss.weld.context.http.HttpSessionDestructionContext; Qualifiers: []
>   at org.jboss.weld.bean.builtin.InstanceImpl.get(InstanceImpl.java:101)
>   at 
> org.jboss.weld.servlet.HttpContextLifecycle.getSessionDestructionContext(HttpContextLifecycle.java:112)
>   at 
> org.jboss.weld.servlet.HttpContextLifecycle.deactivateSessionDestructionContext(HttpContextLifecycle.java:172)
>   at 
> org.jboss.weld.servlet.HttpContextLifecycle.sessionDestroyed(HttpContextLifecycle.java:153)
>   at 
> org.jboss.weld.servlet.WeldInitialListener.sessionDestroyed(WeldInitialListener.java:144)
>   at 
> org.jboss.weld.servlet.api.helpers.ForwardingServletListener.sessionDestroyed(ForwardingServletListener.java:50)
>   at 
> org.eclipse.jetty.server.session.AbstractSessionManager.removeSession(AbstractSessionManager.java:794)
>   at 
> org.eclipse.jetty.server.session.AbstractSession.timeout(AbstractSession.java:310)
>   ... 14 mor

Re: [weld-dev] Interceptor & Interceptors

[Martin Kouba]

Tomas Remes pointed out that the new/upcoming version contains the new 
sentence which also mentions @Interceptor.

I think it's related to:
https://github.com/javaee/interceptors-spec/issues/27

But it's hard to guess as it's not possible to track the changes - 
sources are binary files.

Martin


Dne 1.6.2017 v 08:07 Martin Kouba napsal(a):
> Hi Emily,
> 
> I suppose you're talking about section 5.3 Ordering Interceptors using 
> the Priority Annotation:
> "The Priority annotation is ignored on interceptors bound to a component 
> using the Interceptors annotation."
> 
> There is a very old clarification issue for the interceptor spec:
> https://github.com/javaee/interceptors-spec/issues/23
> (originally INTERCEPTORS_SPEC-23)
> 
> Martin
> 
> Dne 31.5.2017 v 14:53 Emily Jiang napsal(a):
>> Hi Martin,
>>
>> In the updated Interceptor spec, it has the following statement:
>>
>> "The Interceptor annotation is ignored on interceptor classes bound 
>> using the Interceptorsannotation."
>>
>> I assume this already the case in Weld 2.x, CDI 1.2 implementation. 
>> Right?
>>
>> Many thanks,
>> Emily
>> ===
>> Emily Jiang
>> WebSphere Application Server, CDI & MicroProfile Development Lead
>>
>> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>> Phone:  +44 (0)1962 816278  Internal: 246278
>>
>> Email: emiji...@uk.ibm.com
>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with 
>> number 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 
>> 3AU
>>
>>
>> ___
>> weld-dev mailing list
>> weld-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>>
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Interceptor & Interceptors

[Martin Kouba]

Hi Emily,

I suppose you're talking about section 5.3 Ordering Interceptors using 
the Priority Annotation:
"The Priority annotation is ignored on interceptors bound to a component 
using the Interceptors annotation."

There is a very old clarification issue for the interceptor spec:
https://github.com/javaee/interceptors-spec/issues/23
(originally INTERCEPTORS_SPEC-23)

Martin

Dne 31.5.2017 v 14:53 Emily Jiang napsal(a):
> Hi Martin,
> 
> In the updated Interceptor spec, it has the following statement:
> 
> "The Interceptor annotation is ignored on interceptor classes bound 
> using the Interceptorsannotation."
> 
> I assume this already the case in Weld 2.x, CDI 1.2 implementation. Right?
> 
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI & MicroProfile Development Lead
> 
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
> 
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> 
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number 
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Application scoped bean and its lifecycle

[Martin Kouba]

I don't recommend downgrading Weld. A more important issues could be 
fixed in newer versions.

In your case, I would modify the Test bean to count with multiple 
@Initialized events and replace @Destroyed with @PreDestroy callback:

class Test {

void appContextInit(@Observes @Initialized(ApplicationScoped.class) init) {
  // Empty body - force eager instantiation
}

@PostConstruct
void onInit() {
  // logic... will only be called once
}

@PreDestroy
void onDestroy() {
  // logic will be called once before 
@Destroyed(ApplicationScoped.class)
}

}



Dne 22.5.2017 v 12:03 Alex Sviridov napsal(a):
> Martin,
> 
> Thank you for your answer. I replaced 2.3.5.Final with 2.2.16.Final. 
> Besides in 2.2.16
> manifest I had to export package org.jboss.weld.config which is used by 
> pax-cdi.
> 
> Now  on bundle start:
> Test was created.
> java.lang.Object@6bc3928f
> Test was initialized
> 
> Now  on bundle stop:
> java.lang.Object@6bc3928f
> Test was destroyed.
> 
> Понедельник, 22 мая 2017, 12:27 +03:00 от Martin Kouba <mko...@redhat.com>:
> 
> 
> Dne 22.5.2017 v 11:14 Alex Sviridov napsal(a):
>  > Martin,
>  >
>  > In your message you wrote : "Up to version 2.2 Weld did not fire
>  > @Initialized/@Destroyed events for
>  > @ApplicationScoped for non-web modules.".
>  >
>  > In WELD-2389 you wrote : "Right now, this service is registered
> for any
>  > non-SE environment".
>  >
>  > I use OSGi + PAX-CDI + WELD + JAVAFX. As I suppose this is a SE
>  > application (not EE).
>  > Could you explain "Right now, this service is registered for any
> non-SE
>  > environment" ?
> 
> Well, I'm talking about Weld SPI and I'm refering to the environment
> info provided by the integrator. PAX CDI provides a custom
> implementation of org.jboss.weld.bootstrap.api.Environment, which is
> fine. The problem is that Weld currently skips registration only if
> org.jboss.weld.bootstrap.api.Environments.SE is used.
> 
>  >
>  > Best regards, Alex
>  >
>  >
>  > Понедельник, 22 мая 2017, 11:51 +03:00 от Martin Kouba
>  > <mko...@redhat.com <mailto:mko...@redhat.com>>:
>  >
>  > Ok, now I know what's going on.
>  >
>  > The event with payload "Application context initialized." comes
>  > directly
>  > from Weld. Whereas the second one java.lang.Object@48813e62 comes
> from
>  > PAX CDI [1].
>  >
>  > Up to version 2.2 Weld did not fire @Initialized/@Destroyed
> events for
>  > @ApplicationScoped for non-web modules. The behavior changed in 2.3 -
>  > see also WELD-1821 [2].
>  >
>  > This explains the events fired twice.
>  >
>  > WRT Test bean instance created twice - the problem is that
>  > @Destroyed(ApplicationScoped.class) event is fired after the actual
>  > destruction. So if you declare an observer on an @ApplicationScoped
>  > you're entering the "undefined behavior zone". In Weld, the Test
>  > bean is
>  > created again.
>  >
>  > I've created WELD-2389 [3] to track this issue.
>  >
>  > Thanks,
>  >
>  > Martin
>  >
>  > [1]
>  >
> 
> https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L154
>  >
>  > [2]
>  > https://issues.jboss.org/browse/WELD-1821
>  >
>  > [3]
>  > https://issues.jboss.org/browse/WELD-2389
>  >
>  >
>  > Dne 22.5.2017 v 09:57 Alex Sviridov napsal(a):
>  > > Hi Martin
>  > >
>  > > Thank you for your answer.
>  > >
>  > > 1) I don't inject Test class anywhere.
>  > > 2) I modified init and destroy methods:
>  > > public void init(@Observes @Initialized(ApplicationScoped.class)
>  > > Object init) {
>  > > System.out.println(init);
>  > > System.out.println("Test was initialized");
>  > > }
>  > >
>  > > public void destroy(@Observes @Destroyed(ApplicationScoped.class)
>  > > Object init) {
>  > > System.out.println(init);
>  > > System.out.println("Test was destroyed.");
>  > > }
>  > >
>  > > Now on bundle start:
>  > >
>  > > Test was created.
>

Re: [weld-dev] Application scoped bean and its lifecycle

[Martin Kouba]

Ok, now I know what's going on.

The event with payload "Application context initialized." comes directly 
from Weld. Whereas the second one java.lang.Object@48813e62 comes from 
PAX CDI [1].

Up to version 2.2 Weld did not fire @Initialized/@Destroyed events for 
@ApplicationScoped for non-web modules. The behavior changed in 2.3 - 
see also WELD-1821 [2].

This explains the events fired twice.

WRT Test bean instance created twice - the problem is that 
@Destroyed(ApplicationScoped.class) event is fired after the actual 
destruction. So if you declare an observer on an @ApplicationScoped 
you're entering the "undefined behavior zone". In Weld, the Test bean is 
created again.

I've created WELD-2389 [3] to track this issue.

Thanks,

Martin

[1]
https://github.com/ops4j/org.ops4j.pax.cdi/blob/master/pax-cdi-weld/src/main/java/org/ops4j/pax/cdi/weld/impl/WeldCdiContainer.java#L154

[2]
https://issues.jboss.org/browse/WELD-1821

[3]
https://issues.jboss.org/browse/WELD-2389


Dne 22.5.2017 v 09:57 Alex Sviridov napsal(a):
> Hi Martin
> 
> Thank you for your answer.
> 
> 1) I don't inject Test class anywhere.
> 2) I modified init and destroy methods:
>  public void init(@Observes @Initialized(ApplicationScoped.class) 
> Object init) {
>  System.out.println(init);
>  System.out.println("Test was initialized");
>  }
> 
>  public void destroy(@Observes @Destroyed(ApplicationScoped.class) 
> Object init) {
>  System.out.println(init);
>  System.out.println("Test was destroyed.");
>  }
> 
> Now on bundle start:
> 
> Test was created.
> Application context initialized.
> Test was initialized
> java.lang.Object@48813e62
> Test was initialized
> 
> Now on bundle stop:
> 
> java.lang.Object@48813e62
> Test was destroyed.
> Test was created.
> Application context destroyed.
> Test was destroyed.
> 
> 
> Понедельник, 22 мая 2017, 10:48 +03:00 от Martin Kouba
> <mko...@redhat.com>:
> 
> Hi Alex,
> 
> this looks really weird. Could you try to print out the event payload,
> e.g. System.out.println(init)?
> 
> Also you should be always very careful when using code inside the
> no-args constructor of a normal-scoped bean -> it will be also executed
> when creating a client proxy. In your case, if you do @Inject Test and
> invoke any method then you will also see "Test was created" printed
> twice.
> 
> Martin
> 
> Dne 22.5.2017 v 08:50 Alex Sviridov napsal(a):
>  > Hi all
>  >
>  > I use pax-cdi -1.0.0.RC2 and weld 2.3.5.Final and this is my test
> class:
>  >
>  > import javax.enterprise.context.ApplicationScoped;
>  > import javax.enterprise.context.Destroyed;
>  > import javax.enterprise.context.Initialized;
>  > import javax.enterprise.event.Observes;
>  >
>  > @ApplicationScoped
>  > public class Test {
>  >
>  > public Test() {
>  > System.out.println("Test was created.");
>  > }
>  >
>  > public void init(@Observes @Initialized(ApplicationScoped.class)
> Object
>  > init) {
>  > System.out.println("Test was initialized");
>  > }
>  >
>  > public void destroy(@Observes @Destroyed(ApplicationScoped.class)
>  > Object init) {
>  > System.out.println("Test was destroyed.");
>  > }
>  > }
>  >
>  > When I start test-bundle I see the following output:
>  > Test was created.
>  > Test was initialized
>  > Test was initialized
>  > When I stop test-bundle I see the following output:
>  > Test was destroyed.
>  > Test was created.
>  > Test was destroyed.
>  >
>  > So as result this bean was two times created, two times
> initialized and two
>  > times destroyed.
>  >
>  > I expected that this bean must be once created, one initialized
> and once
>      > destroyed.
>  >
>  > Is this a bug that must be reported or my mistake?
>  >
>  > --
>  > Alex Sviridov
>  >
>  >
>  > ___
>  > weld-dev mailing list
>  > weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>
>  > https://lists.jboss.org/mailman/listinfo/weld-dev
>  >
> 
> -- 
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> 
> 
> 
> -- 
> Alex Sviridov

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Application scoped bean and its lifecycle

[Martin Kouba]

Hi Alex,

this looks really weird. Could you try to print out the event payload, 
e.g. System.out.println(init)?

Also you should be always very careful when using code inside the 
no-args constructor of a normal-scoped bean -> it will be also executed 
when creating a client proxy. In your case, if you do @Inject Test and 
invoke any method then you will also see "Test was created" printed twice.

Martin

Dne 22.5.2017 v 08:50 Alex Sviridov napsal(a):
> Hi all
> 
> I use pax-cdi -1.0.0.RC2 and weld 2.3.5.Final and this is my test class:
> 
> import javax.enterprise.context.ApplicationScoped;
> import javax.enterprise.context.Destroyed;
> import javax.enterprise.context.Initialized;
> import javax.enterprise.event.Observes;
> 
> @ApplicationScoped
> public class Test {
> 
>  public Test() {
>  System.out.println("Test was created.");
>  }
> 
>  public void init(@Observes @Initialized(ApplicationScoped.class) Object
> init) {
>  System.out.println("Test was initialized");
>  }
> 
>  public void destroy(@Observes @Destroyed(ApplicationScoped.class)
> Object init) {
>  System.out.println("Test was destroyed.");
>  }
> }
> 
> When I start test-bundle I see the following output:
> Test was created.
> Test was initialized
> Test was initialized
> When I stop test-bundle I see the following output:
> Test was destroyed.
> Test was created.
> Test was destroyed.
> 
> So as result this bean was two times created, two times initialized and two
> times destroyed.
> 
> I expected that this bean must be once created, one initialized and once
> destroyed.
> 
> Is this a bug that must be reported or my mistake?
> 
> -- 
> Alex Sviridov
> 
> 
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
> 

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Weld 3.0.0.Final released

[Martin Kouba]

Dne 15.5.2017 v 20:44 George Gastaldi napsal(a):
> Cool!
>
> Question: What's the reason why Weld-core-impl depends on
> jboss-interceptors-api_1.2_spec and jboss-el-api_3.0_spec given that
> cdi-api:2.0 already brings javax.incerceptor.api:1.2 and
> javax.el-api:3.0.0 as transitive dependencies?

Well, it's always been like this. In EE users don't depend on Weld at 
all. In SE users usually bring in weld-se directly (depends on Weld core 
and Weld API - depends on cdi-api with exclusions 
https://github.com/weld/api/blob/master/pom.xml#L190) and explicit 
cdi-api dependency is not needed.

But the truth is we should probably revisit this since users can now 
depend on cdi-api and use CDI bootstrap API, ie. bring weld only as an 
impl dependency.

>
> PS: Just upgraded Furnace to use Weld 3.0.0.Final and all tests are
> passing. Great job!

That's great ;-)

>
>
> Best Regards,
>
>
>
> George Gastaldi
>
> Principal Software Engineer
>
> Red Hat <https://www.redhat.com>
>
> Remote
>
> Joinville - Santa Catarina
>
> ggast...@redhat.com <mailto:ggast...@redhat.com>M: +55-47-99711-1000
> <tel:+55-47-99711-1000>
>
> <https://red.ht/sig>  
> TRIED. TESTED. TRUSTED. <https://redhat.com/trusted>
>
> @redhatnews <https://twitter.com/redhatnews>   Red Hat
> <https://www.linkedin.com/company/red-hat>   Red Hat
> <https://www.facebook.com/RedHatInc>
>
>
> On Mon, May 15, 2017 at 5:30 AM, Martin Kouba <mko...@redhat.com
> <mailto:mko...@redhat.com>> wrote:
>
> http://weld.cdi-spec.org/news/2017/05/15/weld-300Final/
> <http://weld.cdi-spec.org/news/2017/05/15/weld-300Final/>
>
> --
> Martin Kouba
> Senior Software Engineer
> Red Hat, Czech Republic
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/weld-dev
> <https://lists.jboss.org/mailman/listinfo/weld-dev>
>
>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 3.0.0.Final released

[Martin Kouba]

http://weld.cdi-spec.org/news/2017/05/15/weld-300Final/

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Thread deadlock with osgi refresh

[Martin Kouba]

Well, when looking at Niclas's answer - it is true that Weld's 
ClassFileUtils holds 0xfd03aa50 and also waiting in another 
thread to release this lock. But the weld-worker-1 thread (which holds 
the lock) is in state WAITING (on object monitor) due to 
org.apache.felix.framework.Felix.acquireGlobalLock(Felix.java:5332) 
which calls m_bundleLock.wait().

Martin

Dne 9.5.2017 v 11:45 Alex Sviridov napsal(a):
> Hi Martin
>
> Thank you very much for your answer. Yes, I asked them. Please see
> https://groups.google.com/forum/#!topic/ops4j/msmgHq0B1l8
>
>
> Вторник, 9 мая 2017, 12:22 +03:00 от Martin Kouba <mko...@redhat.com>:
>
> Hi Alex,
>
> I don't know much about Felix and OSGi but it seems the
> org.apache.felix.framework.Felix.acquireGlobalLock() is waiting to wake
> up and the thread holds lock on
> org.jboss.weld.util.bytecode.ClassFileUtils. Have you tried PAX CDI
> guys
> already?
>
> Martin
>
> Dne 9.5.2017 v 09:04 Alex Sviridov napsal(a):
> > Hi all
> >
> > I use pax-cdi 1.0.0.RC2 with weld-osgi-bundle 2.3.5. And I have two
> > bundles: bundleA and bundleB.
> >
> > BundleB has CDI beans and CDI container is created for bundleB.
> Besides
> > bundleB depends on bundleA.
> >
> > Now I update bundleA and do osgi refresh using this code
> >
> > |Bundle systemBundle = bundleContext.getBundle(0);
> > FrameworkWiring frameworkWiring =
> > systemBundle.adapt(FrameworkWiring.class);
> > frameworkWiring.refreshBundles(null);
> >
> > What I see in log of bundle B.
> >
> > |2017-05-08 12:31:42,831 | DEBUG | xFrameworkWiring | ? |
> BundleEvent STOPPING - com.bundleB
> > 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? |
> ServiceEvent UNREGISTERING - [java.lang.Object] - com.bundleB
> > 2017-05-08 12:31:42,832 | DEBUG | xFrameworkWiring | ? |
> BundleEvent STOPPED - com.bundleB
> > 2017-05-08 12:31:42,845 | DEBUG | xFrameworkWiring | ? |
> BundleEvent UNRESOLVED - com.bundleB
> > 2017-05-08 12:31:42,885 | DEBUG | xFrameworkWiring | ? |
> BundleEvent RESOLVED - com.bundleB
> > 2017-05-08 12:31:42,886 | DEBUG | xFrameworkWiring | ? |
> BundleEvent STARTING - com.bundleB
> > 2017-05-08 12:31:43,164 | DEBUG | xFrameworkWiring | ? |
> ServiceEvent REGISTERED - [java.lang.Object] - com.bundleB
> > |
> > Please,note that bundleB didn't change state to STARTED. When I don't
> > use in bundleB CDI
> > beans and CDI container is not created for bundleB then everything
> is ok
> > - after bundleA
> > update and osgi refresh bundleB reaches STARTED state.
> >
> > Is this a bug of weld or something else? This is some thread dump:
> >
> > "weld-worker-3" #146 daemon prio=5 os_prio=0 tid=0x7f3e08044000
> > nid=0x1dc8 waiting for monitor entry [0x7f3dd867a000]
> > java.lang.Thread.State: BLOCKED (on object monitor)
> > at
> >
> 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass2(ClassFileUtils.java:108)
> > - waiting to lock <0xfd03aa50> (a java.lang.Class for
> > org.jboss.weld.util.bytecode.ClassFileUtils)
> > at
> >
> 
> org.jboss.weld.util.bytecode.ClassFileUtils.toClass(ClassFileUtils.java:97)
> > at
> >
> 
> org.jboss.weld.bean.proxy.ProxyFactory.createProxyClass(ProxyFactory.java:491)
> > at
> >
> 
> org.jboss.weld.bean.proxy.ProxyFactory.getProxyClass(ProxyFactory.java:364)
> > at
> >
> 
> org.jboss.weld.bean.builtin.AbstractFacadeBean.initializeAfterBeanDiscovery(AbstractFacadeBean.java:61)
> > at
> >
> 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:136)
> > at
> >
> 
> org.jboss.weld.bootstrap.ConcurrentBeanDeployer$AfterBeanDiscoveryInitializerFactory.doWork(ConcurrentBeanDeployer.java:127)
> > at
> >
> 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:63)
> > at
> >
> 
> org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:56)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > at
> >
> 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> > at
> >
> 
> java.util.concurrent.Thre

Re: [weld-dev] Thread deadlock with osgi refresh

[Martin Kouba]

.util.EventDispatcher.invokeBundleListenerCallback(EventDispatcher.java:916)
> at
> org.apache.felix.framework.util.EventDispatcher.fireEventImmediately(EventDispatcher.java:835)
> at
> org.apache.felix.framework.util.EventDispatcher.fireBundleEvent(EventDispatcher.java:517)
> at org.apache.felix.framework.Felix.fireBundleEvent(Felix.java:4541)
> at org.apache.felix.framework.Felix.startBundle(Felix.java:2172)
> at org.apache.felix.framework.Felix$RefreshHelper.restart(Felix.java:5063)
> at org.apache.felix.framework.Felix.refreshPackages(Felix.java:4253)
> at
> org.apache.felix.framework.FrameworkWiringImpl.run(FrameworkWiringImpl.java:188)
> at java.lang.Thread.run(Thread.java:745)|
>
>
>
>
> --
> Alex Sviridov
>
>
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 2.4.3.Final released!

[Martin Kouba]

http://weld.cdi-spec.org/news/2017/04/07/weld-243Final/

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 3.0.0.CR2 released

[Martin Kouba]

http://weld.cdi-spec.org/news/2017/03/03/weld-300CR2/

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 2.4.2.Final released!

[Martin Kouba]

http://weld.cdi-spec.org/news/2017/02/02/weld-242Final/

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 3.0.0.CR1 released

[Martin Kouba]

http://weld.cdi-spec.org/news/2017/01/23/weld-300CR1/

-- 
Martin Kouba
Senior Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Weld 3.0 Beta 1 & Arquillian Embedded Container

[Martin Kouba]

Hi John,

known issue and fixed in Arquillian Embedded Container Weld 2.0.0.Beta4.

Martin

Dne 21.12.2016 v 12:42 John D. Ament napsal(a):
> Hi,
>
> It seems that Arquillian Embedded Container Weld (2.0 Beta3) is not
> compatible with Weld 3 Beta 1.  Is this a known issue, or do we need to
> bump to Weld container 3.0.x to add CDI 2.0 support?
>
> java.lang.NoClassDefFoundError: org/jboss/weld/literal/InitializedLiteral
> at
> org.jboss.arquillian.container.weld.embedded.mock.TestContainer.startContainer(TestContainer.java:244)
> at
> org.jboss.arquillian.container.weld.embedded.WeldMockContainer.deploy(WeldMockContainer.java:115)
> at
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> at
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> at
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> at
> org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
>
> John
>
>
> ___
> weld-dev mailing list
> weld-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Does WELD-2260 Need to be fixed for StartMain?

[Martin Kouba]

Hi John,

I believe it's not necessary. However, it might make sense for other 
reasons. Hm, let's think about this during holidays ;-)

Martin

Dne 20.12.2016 v 03:00 John D. Ament napsal(a):
> Hi,
>
> So I ran into an issue after manually patching to work around
> WELD-2260.  It didn't work for use cases where StartMain is used to
> boostrap Weld.  I'm just not sure if its actually needed.  E.g. the
> fixes for WELD-2260 may be good enough that this isn't an issue.
>
> https://github.com/weld/core/pull/1535
>
> Let me know what you think.
>
> John
>
>
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Weld & Groovy

[Martin Kouba]

Yep, this issue [1] is fixed in Weld 3.0.0.Beta1 that we're going to 
release early next week.

Martin

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


Dne 17.12.2016 v 15:15 John D. Ament napsal(a):
> Hi
>
> So based on the last issue I saw, I just want to run this by you guys.
>
> I'm starting to run tests with Weld 3.  I saw the following, which made
> me think of the groovy issue
>
> Caused by: java.lang.AbstractMethodError:
> org.apache.cxf.Bus$1366014918$Proxy$_$$_WeldClientProxy.getProperty(Ljava/lang/String;)Ljava/lang/Object;
> at org.apache.cxf.common.util.ClassHelper.getRealClass(ClassHelper.java:81)
>
>
> I just want to confirm that this is fixed on master, and its just
> because Weld is a little out of date.
>
> -Dweld.version=3.0.0.Alpha17 -Dcdi-api.version=2.0-EDR2
>
> John
>
>
> ___
> weld-dev mailing list
> weld-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Specializes bean in war causes unsatisfied resolution exception

[Martin Kouba]

Dne 30.11.2016 v 18:01 Benjamin Confino napsal(a):
> Thank you for the prompt replies.
>
> In answer to your question. It is UiSnapshotData which gets injected
> under OWB.

Ok, thanks. From my point of view this violates the EE class loading rules.

>
> Regards
> Benjamin
>
>
>
> From:Martin Kouba <mko...@redhat.com>
> To:Matej Novotny <manov...@redhat.com>, Benjamin
> Confino/UK/IBM@IBMGB,
> Cc:Emily Jiang/UK/IBM@IBMGB, Tom Evans/UK/IBM@IBMGB,
> weld-dev@lists.jboss.org
> Date:29/11/2016 07:42
> Subject:Re: [weld-dev] Specializes bean in war causes
> unsatisfied resolution exception
> 
>
>
>
> Matej is correct. The specializing bean from the war disables the
> specialized bean from ear/lib. And since the bean from war is not
> visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an
> unsatisfied dependency exists.
>
> By the way, what instance of SnapshotData gets injected into
> KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the
> war/lib?
>
> Martin
>
> Dne 29.11.2016 v 07:06 Matej Novotny napsal(a):
>> Hello Benjamin
>>
>> Thanks for well written question!
>>
>>> (You can see the application at was_bugs/was_bug22 at master ·
>>> thikade/was_bugs · GitHub )
>>
>> Thanks! Took a glance and it looks like the infamous EAR visibility issue.
>>
>>> My first thought was that this application should not work
>>
>> I agree with that. Anything located in EAR/lib cannot really "see"
> into WAR.
>> Hence the bean with @Specializes (in WAR) will disable the original
> bean (in EAR/lib) and the injection cannot be performed as
>> the specialized bean is not visible to the archive in EAR/lib.
>>
>>> I confirmed that this application works fine on OpenWebBeans.
>>
>> The fact that it does NOT work should be in accord with Java EE spec
> and its visibility restrictions.
>> Maybe you should be asking OWB guys why does it work at all?
>>
>> I am no EAR expert but I really think this is Java EE spec (not CDI)
> intended behavior.
>>
>> Matej
>>
>> - Original Message -
>>> From: "Benjamin Confino" <benja...@uk.ibm.com>
>>> To: weld-dev@lists.jboss.org
>>> Cc: "Tom Evans" <tev...@uk.ibm.com>, "Emily Jiang" <emiji...@uk.ibm.com>
>>> Sent: Monday, November 28, 2016 4:56:12 PM
>>> Subject: [weld-dev] Specializes bean in war causes unsatisfied
> resolution exception
>>>
>>> Hello
>>>
>>> A customer of mine sent in a test application with the following
> structure:
>>>
>>> A war file inside ear
>>> Two jar files inside ear/lib
>>> One jar file inside ear/war/WEB-INF/lib
>>>
>>> There is a class inside one of the ear/lib jar files which @Injects a
> bean
>>> from the other ear/lib jar file
>>>
>>> And there is a class inside the ear/war/WEB-INF/lib jar file that
>>> @Specializes the bean inside an ear/lib jar file
>>>
>>> (You can see the application at was_bugs/was_bug22 at master ·
>>> thikade/was_bugs · GitHub )
>>>
>>> Attempting to run this application on Weld results in an Unsatisfied
>>> Resolution Exception. When I remove the jar containing the
> @Specializes bean
>>> the application works correctly.
>>>
>>>
>>> My first thought was that this application should not work, because
> the war
>>> file and it's internal jar would have a second classloader that would be
>>> invisible to the application classloader. However the customer
> attested, and
>>> I confirmed that this application works fine on OpenWebBeans.
>>>
>>> I do not think this is an integration issue, because I tested this on
> Wildfly
>>> and got the same error.
>>>
>>>
>>> So it seems that Weld throws an Unsatisfied Resolution Exception if
>>> @specializes exists in a class that is loaded by a classloader which
> is not
>>> visible .
>>>
>>> What do you think is the correct behaviour is in this instance? From a
>>> classloading perspective a class inside ear/lib should not be able to
> see a
>>> class inside ear/war; but on the other hand the entire purpose of a
>>> @Specializes bean is that you drop it into your application and it
> replaces
>>> the original bean. It feels appropriate that you can drop in a war f

Re: [weld-dev] Specializes bean in war causes unsatisfied resolution exception

[Martin Kouba]

Matej is correct. The specializing bean from the war disables the 
specialized bean from ear/lib. And since the bean from war is not 
visible to the bean from ear/lib (KinderzuschussKinderServiceImpl) an 
unsatisfied dependency exists.

By the way, what instance of SnapshotData gets injected into 
KinderzuschussKinderServiceImpl for OWB? Is it UiSnapshotData from the 
war/lib?

Martin

Dne 29.11.2016 v 07:06 Matej Novotny napsal(a):
> Hello Benjamin
>
> Thanks for well written question!
>
>> (You can see the application at was_bugs/was_bug22 at master ·
>> thikade/was_bugs · GitHub )
>
> Thanks! Took a glance and it looks like the infamous EAR visibility issue.
>
>> My first thought was that this application should not work
>
> I agree with that. Anything located in EAR/lib cannot really "see" into WAR.
> Hence the bean with @Specializes (in WAR) will disable the original bean (in 
> EAR/lib) and the injection cannot be performed as
> the specialized bean is not visible to the archive in EAR/lib.
>
>> I confirmed that this application works fine on OpenWebBeans.
>
> The fact that it does NOT work should be in accord with Java EE spec and its 
> visibility restrictions.
> Maybe you should be asking OWB guys why does it work at all?
>
> I am no EAR expert but I really think this is Java EE spec (not CDI) intended 
> behavior.
>
> Matej
>
> - Original Message -
>> From: "Benjamin Confino" 
>> To: weld-dev@lists.jboss.org
>> Cc: "Tom Evans" , "Emily Jiang" 
>> Sent: Monday, November 28, 2016 4:56:12 PM
>> Subject: [weld-dev] Specializes bean in war causes unsatisfied resolution
>> exception
>>
>> Hello
>>
>> A customer of mine sent in a test application with the following structure:
>>
>> A war file inside ear
>> Two jar files inside ear/lib
>> One jar file inside ear/war/WEB-INF/lib
>>
>> There is a class inside one of the ear/lib jar files which @Injects a bean
>> from the other ear/lib jar file
>>
>> And there is a class inside the ear/war/WEB-INF/lib jar file that
>> @Specializes the bean inside an ear/lib jar file
>>
>> (You can see the application at was_bugs/was_bug22 at master ·
>> thikade/was_bugs · GitHub )
>>
>> Attempting to run this application on Weld results in an Unsatisfied
>> Resolution Exception. When I remove the jar containing the @Specializes bean
>> the application works correctly.
>>
>>
>> My first thought was that this application should not work, because the war
>> file and it's internal jar would have a second classloader that would be
>> invisible to the application classloader. However the customer attested, and
>> I confirmed that this application works fine on OpenWebBeans.
>>
>> I do not think this is an integration issue, because I tested this on Wildfly
>> and got the same error.
>>
>>
>> So it seems that Weld throws an Unsatisfied Resolution Exception if
>> @specializes exists in a class that is loaded by a classloader which is not
>> visible .
>>
>> What do you think is the correct behaviour is in this instance? From a
>> classloading perspective a class inside ear/lib should not be able to see a
>> class inside ear/war; but on the other hand the entire purpose of a
>> @Specializes bean is that you drop it into your application and it replaces
>> the original bean. It feels appropriate that you can drop in a war file
>> containing the @Specializes bean and it just works without you having to do
>> anything extra.
>>
>> Best regards
>> Benjamin
>>
>> Unless stated otherwise above:
>> IBM United Kingdom Limited - Registered in England and Wales with number
>> 741598.
>> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>>
>> ___
>> weld-dev mailing list
>> weld-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/weld-dev
>
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 2.4.1.Final released

[Martin Kouba]

http://weld.cdi-spec.org/news/2016/11/18/weld-241Final/

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Unique BeanIdentifierIndex every time I restart a server

[Martin Kouba]

Hi Benjamin,

it looks like an integration issue. The index hash should be the same 
unless an ID of a session/conversation scoped bean changes.

Its value is computed using java.util.Arrays.hashCode(BeanIdentifier[]). 
Note that BeanIdentifier.hashCode() is always based on the String 
representation of the ID.

In you case, I can see the difference in:
org.eclipse.osgi.internal.loader.EquinoxClassLoader@d6318459
org.eclipse.osgi.internal.loader.EquinoxClassLoader@b3a3f568

It seems the BeanDeploymentArchive.getId() is different between 
deployments which violates the Weld SPI contract:
"The identifier must be consistent between multiple occurrences of this 
deployment." [1]

It's also possible to disable this optimization:
http://docs.jboss.org/weld/reference/latest/en-US/html/configure.html#_bean_identifier_index_optimization

Martin

[1]
https://github.com/weld/api/blob/master/weld-spi/src/main/java/org/jboss/weld/bootstrap/spi/BeanDeploymentArchive.java

Dne 20.10.2016 v 18:22 Benjamin Confino napsal(a):
> Hello.
>
> I've been investigating a bug relating to session failover and I've
> noticed that my BeanIdentifierIndexhas a different hash every time I
> start and stop the server. This is consistent across every app I tried.
>
> For example:
>
> Upon starting the server I see my debug output
>
> GREPBeanIdentifierIndex [hash=591986009, indexed=3]
>  0:
> WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession
>
>  1:
> WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession
>  2:
> WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader@d6318459[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession
>
>
> I stop the server, and start it again
>
> GREPBeanIdentifierIndex [hash=-375657379, indexed=3]
>  0:
> WELD%AbstractBuiltInBean%invalidBeansXml#com.ibm.ws.transaction.cdi_1.0.15.20161018-1920.additionalClasses%HttpSession
>
>  1:
> WELD%AbstractBuiltInBean%invalidBeansXml#invalidBeansXml.war%HttpSession
>  2:
> WELD%AbstractBuiltInBean%invalidBeansXml#org.eclipse.osgi.internal.loader.EquinoxClassLoader@b3a3f568[com.ibm.ws.org.jboss.weld.2.4.0:1.0.15.20161018-1920(id=108)].additionalClasses%HttpSession
>
>
> Same three classes but the hash is completely different.
>
> My question is simple. Is this the expected behaviour or is this a sign
> that something's gone wrong?
>
> 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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Race condition in HttpContextLifecycle requestInitialized

[Martin Kouba]

Hi Benjamin,

Dne 2.10.2016 v 11:36 Benjamin Confino napsal(a):
> Hello.
>
> We have a problem from a race condition in
> HttpContextLifecycle.requestInitialized()
>
> The condition is as follows:
>
> Thread one calls nestedInvocationGuard.set(*new*Counter());
> Thread two calls Counter counter = nestedInvocationGuard.get();  Object
> marker = request.getAttribute(GUARD_PARAMETER_NAME);
> Thread one has not yet called request.setAttribute(GUARD_PARAMETER_NAME,
> GUARD_PARAMETER_VALUE);

I don't understand how this could be a race condition? Are you saying 
that both these threads are processing a single request at the same time?

>
> This will result in thread two having a counter but no marker, leading
> to ServletLogger.LOG.guardLeak(counter.value);
>
> I believe this issue is known because of the following comment.
>
> * This request has not been processed yet but the guard is set already.
> That indicates, that the guard leaked from a previous request
> * processing - most likely the Servlet container did not invoke listener
> methods symmetrically. Log a warning and recover by
> * re-initializing the guard
>
> I am assuming that "symmetrically" is supposed to say "synchronised".

No it's not. It is really supposed to say symmetrically, it means that 
ServletRequestListener.requestInitialized(ServletRequestEvent) should be 
always followed by 
ServletRequestListener.requestDestroyed(ServletRequestEvent)?

>
> I have checked with the relevant team and there is no way we can call
> that method from inside a synchronised block. So I was hoping that you
> might have some alternatives?
>
> I noticed that the file at
> https://github.com/doctau/weld-core/blob/master/impl/src/main/java/org/jboss/weld/servlet/HttpContextLifecycle.javahas
> been updated and no longer has that race condition? Do you think
> including that update resolve this issue? And if so which release will
> include that update.

What version of Weld are you using?
What "update" do you have in mind?

>
> 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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Not possible to destroy normal scoped beans returned by producer method

[Martin Kouba]

I see. Well, this is a bit problematic. The main problem is that Weld 
session context does not always synchronize with the underlying 
HttpSession. There is a thread local bean store which is 
"write-through", i.e. if attached any modifications are written to the 
HttpSession immediately. But in your case, the destroy operation is not 
recognized as a modification (bean instance is not found in the thread 
local bean store).

I think we can fix this particular problem - I've created WELD-2234 to 
track this issue.

I think this is undefined from spec point of view. And I'm not quite 
sure it would be possible to specify it in a clear way.

Martin

Dne 15.9.2016 v 11:58 arjan tijms napsal(a):
> Hi,
>
> Just a quick follow up, it seems that if the bean is touched in 1
> request (so it's actually constructed and in the "global" bean store for
> the session), then destroyed in another request within the same session
> that hasn't touched the bean it fails.
>
> But like you said, if the bean is touched within the same request (e.g.
> @Inject Foo foo; ... foo.toString();) then destroying it works.
>
> I'm not sure, do you think this is a bug, a spec issue, or "just the way
> things are"?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
> On Thu, Sep 15, 2016 at 8:59 AM, arjan tijms <arjan.ti...@gmail.com
> <mailto:arjan.ti...@gmail.com>> wrote:
>
> Hi,
>
> The produced Foo should have been used before it's destroyed, but
> I'll double check it's also used right before the destroy method is
> called in the same thread. I'll try to make a simple reproducer as
> well if it still doesn't work correctly then.
>
> Kind regards,
> Arjan Tijms
>
> On Thu, Sep 15, 2016 at 8:48 AM, Martin Kouba <mko...@redhat.com
> <mailto:mko...@redhat.com>> wrote:
>
> Hi Arjan,
>
> a simple reproducer would be helpful. There are few edge cases
> around session context and HTTP session which are problematic
> (e.g. HttpSession.invalidate()).
>
> Do you call some method on the produced Foo before you call
> destroy? Because in Weld, normal scoped instances are created
> lazily and so does the HTTP session in case of @SessionScoped.
>
> Thanks,
>
> Martin
>
> Dne 14.9.2016 v 19:14 arjan tijms napsal(a):
>
> Hi,
>
> I have a simple producer:
>
> @Produced
> @SessionScoped
> public void Foo getFoo() { return new Foo());
>
> If I subsequently want to destroy the Bean using:
>
> Set<Bean> beans = beanManager.getBeans(Foo.class);
>
> Bean bean = (Bean) beanManager.resolve(beans);
> Context context = beanManager.getContext(bean.ge
> <http://bean.ge>tScope());
>
> ((AlterableContext) context).destroy(bean);
>
> Then in Weld 2.3.2 the destroy method of the super class
> of org.jboss.weld.context.http.Ht
> <http://org.jboss.weld.context.http.Ht>tpSessionContextImpl
> is called:
>
> org.jboss.weld.context.AbstractContext
>
> Containing this code:
>
> @Override
> public void destroy(Contextual contextual) {
> if (!isActive()) {
> throw new ContextNotActiveException();
> }
> checkContextInitialized();
> if (contextual == null) {
> throw ContextLogger.LOG.contextualIsNull();
> }
> final BeanStore beanStore = getBeanStore();
> if (beanStore == null) {
> throw ContextLogger.LOG.noBeanStoreAvailable(this);
> }
> BeanIdentifier id = getId(contextual);
> ContextualInstance beanInstance =
> beanStore.remove(id);
> if (beanInstance != null) {
> RequestScopedCache.invalidate();
> destroyContextualInstance(beanInstance);
> }
> }
>
> Now the getBeanStore() method
> (from org.jboss.weld.context.AbstractBoundContext) returns an
> org.jboss.weld.context.beanstore.http.LazySessionBeanStore
> and this bean
> store does *not* contain the Foo bean (no key for its
> BeanIdentifier).
> There are other session scoped beans there that have been
> 

Re: [weld-dev] Not possible to destroy normal scoped beans returned by producer method

[Martin Kouba]

Hi Arjan,

a simple reproducer would be helpful. There are few edge cases around 
session context and HTTP session which are problematic (e.g. 
HttpSession.invalidate()).

Do you call some method on the produced Foo before you call destroy? 
Because in Weld, normal scoped instances are created lazily and so does 
the HTTP session in case of @SessionScoped.

Thanks,

Martin

Dne 14.9.2016 v 19:14 arjan tijms napsal(a):
> Hi,
>
> I have a simple producer:
>
> @Produced
> @SessionScoped
> public void Foo getFoo() { return new Foo());
>
> If I subsequently want to destroy the Bean using:
>
> Set beans = beanManager.getBeans(Foo.class);
>
> Bean bean = (Bean) beanManager.resolve(beans);
> Context context = beanManager.getContext(bean.getScope());
>
> ((AlterableContext) context).destroy(bean);
>
> Then in Weld 2.3.2 the destroy method of the super class
> of org.jboss.weld.context.http.HttpSessionContextImpl is called:
>
> org.jboss.weld.context.AbstractContext
>
> Containing this code:
>
> @Override
> public void destroy(Contextual contextual) {
> if (!isActive()) {
> throw new ContextNotActiveException();
> }
> checkContextInitialized();
> if (contextual == null) {
> throw ContextLogger.LOG.contextualIsNull();
> }
> final BeanStore beanStore = getBeanStore();
> if (beanStore == null) {
> throw ContextLogger.LOG.noBeanStoreAvailable(this);
> }
> BeanIdentifier id = getId(contextual);
> ContextualInstance beanInstance = beanStore.remove(id);
> if (beanInstance != null) {
> RequestScopedCache.invalidate();
> destroyContextualInstance(beanInstance);
> }
> }
>
> Now the getBeanStore() method
> (from org.jboss.weld.context.AbstractBoundContext) returns an
> org.jboss.weld.context.beanstore.http.LazySessionBeanStore and this bean
> store does *not* contain the Foo bean (no key for its BeanIdentifier).
> There are other session scoped beans there that have been instantiated
> for the test, but Foo is missing.
>
> If subsequently the session is destroyed, the same destroy method is
> called on the
> org.jboss.weld.context.http.HttpSessionContextImpl eventually, but now
> the getBeanStore() method returns
> an org.jboss.weld.context.beanstore.http.EagerSessionBeanStore, and this
> one *does* contain the Foo bean.
>
> The other beans that the EagerSessionBeanStore contain are equal to the
> ones in the LazySessionBeanStore, the only difference is the Foo bean.
>
> Is this a bug in Weld or am I doing something wrong?
>
> Kind regards,
> Arjan Tijms
>
>
>
>
>
>
>
>
>
>
>
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 2.4.0.Final released

[Martin Kouba]

http://weld.cdi-spec.org/news/2016/09/13/weld-240Final/

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] ApplicationScoped event fires on service invocation

[Martin Kouba]

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 <mko...@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
>>>  lim

Re: [weld-dev] ApplicationScoped event fires on service invocation

[Martin Kouba]

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 w

Re: [weld-dev] How to avoid this warning message?

[Martin Kouba]

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.am...@gmail.com
> <mailto:john.d.am...@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Proper way to get to EnhancedAnnotatedConstructor (CDI autofactories implementation)

[Martin Kouba]

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,
 
EnhancedAnnotatedType, 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) 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)
> createdTypeData.getCreatedTypeConstructor().getBaseType();
>
>
> BeanManagerImpl manager = ((BeanManagerProxy)
> beanManager).delegate();
> EnhancedAnnotatedConstructor constructor =
> (EnhancedAnnotatedConstructor) manager
> .createEnhancedAnnotatedType(declaringComponentClass)
> .getEnhancedConstructors()
> .stream().findAny().get();
>
> ConstructorInjectionPoint actualInjectionPoint =
> InjectionPointFactory.instance()
> .createConstructorInjectionPoint(bean,
> declaringComponentClass, constructor, manager);
> ThreadLocalStackReference 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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Next stable version is 2.4.0

[Martin Kouba]

So far I don't expect any other major changes from the migration point 
of view. But the list of issues is not definitive yet.

Martin

Dne 21.7.2016 v 17:09 Emily Jiang napsal(a):
> Thanks Martin for the detailed list! From the migration point of view,
> are there any other items except the guava dependency changes?
>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From:Martin Kouba <mko...@redhat.com>
> To:weld-dev@lists.jboss.org,
> Date:21/07/2016 14:44
> Subject:Re: [weld-dev] Next stable version is 2.4.0
> Sent by:weld-dev-boun...@lists.jboss.org
> 
>
>
>
> Not quite. There are others. E.g. reflect the output of CDI-494
> (WELD-2137), add enhanced version of javax.enterprise.inject.Instance to
> Weld API (WELD-2151) or better support for rolling upgrades on Payara
> (WELD-2064). And if possible, we would like to add support for JDK8
> default method interception (WELD-2093) as well.
>
> Not to mention all the cleanup work ;-)
>
> Martin
>
> Dne 21.7.2016 v 15:25 Emily Jiang napsal(a):
>> Thanks Matej for the info! From the issue list as per Martin's notes,
>> sounds like the major change is to remove the dependency on Guava.
>>
>> Many thanks,
>> Emily
>> ===
>> Emily Jiang
>> WebSphere Application Server, CDI Development Lead
>>
>> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>> Phone:  +44 (0)1962 816278  Internal: 246278
>>
>> Email: emiji...@uk.ibm.com
>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>
>>
>>
>>
>> From:Matej Novotny <manov...@redhat.com>
>> To:Emily Jiang/UK/IBM@IBMGB,
>> Cc:weld-dev@lists.jboss.org
>> Date:21/07/2016 11:49
>> Subject:Re: [weld-dev] Next stable version is 2.4.0
>> Sent by:weld-dev-boun...@lists.jboss.org
>> 
>>
>>
>>
>> Hi Emily,
>>
>> the 2.4 release is a continuation of 2.3.x releases.
>> And you will be able to smoothly upgrade Weld from 2.3 to 2.4.
>>
>> We simply felt that there will be some more changes included and so
>> it would be fitting to increase the minor version of project (instead of
>> micro one).
>>
>>
>> As for WELD-1574, we shall evaluate the efforts needed for backporting
>> this from Weld 3.x to 2.4x and make a desicion based on that.
>> As 2.4 is a continuation of 2.3 branch, you have your answer there - no
>> need to backport it to 2.3.x.
>>
>> Regards
>> Matej
>>
>> - Original Message -
>>> From: "Emily Jiang" <emiji...@uk.ibm.com>
>>> To: "Martin Kouba" <mko...@redhat.com>
>>> Cc: weld-dev@lists.jboss.org
>>> Sent: Thursday, July 21, 2016 12:24:25 PM
>>> Subject: Re: [weld-dev] Next stable version is 2.4.0
>>>
>>> Hi Martin,
>>>
>>> Why not carrying on releasing these jira fixes on 2.3.x branches?
>> Weld-1574
>>> is useful. Do you plan to
>>> WELD-1574 [3] - remove the dependency on Google Guava and reduce the
>>> footprint to Weld 2.3.x?
>>>
>>> Many thanks,
>>> Emily
>>> ===
>>> Emily Jiang
>>> WebSphere Application Server, CDI Development Lead
>>>
>>> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>>> Phone: +44 (0)1962 816278 Internal: 246278
>>>
>>> Email: emiji...@uk.ibm.com
>>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>>
>>>
>>>
>>>
>>> From: Martin Kouba <mko...@redhat.com>
>>> To: Antoine Sabot-Durand <anto...@sabot-durand.net>,
>>> "weld-dev@lists.jboss.org" <weld-dev@lists.jboss.org>,
>>> Date: 21/07/2016 10:22
>>> Subject: Re: [weld-dev] Next stable version is 2.4.0
>>> Sent by: weld-dev-boun...@lists.jboss.org
>>>
>>>
>>>
>>>
>>> Dne 21.7.2016 v 11:18 Antoine Sabot-Durand napsal(a):
>>> > Hi Martin,
>>> >
>>> > I find all this interesting , especially the back porting of WELD-1574.
>>> > For this last point, 

Re: [weld-dev] Next stable version is 2.4.0

[Martin Kouba]

Not quite. There are others. E.g. reflect the output of CDI-494 
(WELD-2137), add enhanced version of javax.enterprise.inject.Instance to 
Weld API (WELD-2151) or better support for rolling upgrades on Payara 
(WELD-2064). And if possible, we would like to add support for JDK8 
default method interception (WELD-2093) as well.

Not to mention all the cleanup work ;-)

Martin

Dne 21.7.2016 v 15:25 Emily Jiang napsal(a):
> Thanks Matej for the info! From the issue list as per Martin's notes,
> sounds like the major change is to remove the dependency on Guava.
>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From:Matej Novotny <manov...@redhat.com>
> To:Emily Jiang/UK/IBM@IBMGB,
> Cc:weld-dev@lists.jboss.org
> Date:21/07/2016 11:49
> Subject:Re: [weld-dev] Next stable version is 2.4.0
> Sent by:weld-dev-boun...@lists.jboss.org
> 
>
>
>
> Hi Emily,
>
> the 2.4 release is a continuation of 2.3.x releases.
> And you will be able to smoothly upgrade Weld from 2.3 to 2.4.
>
> We simply felt that there will be some more changes included and so
> it would be fitting to increase the minor version of project (instead of
> micro one).
>
>
> As for WELD-1574, we shall evaluate the efforts needed for backporting
> this from Weld 3.x to 2.4x and make a desicion based on that.
> As 2.4 is a continuation of 2.3 branch, you have your answer there - no
> need to backport it to 2.3.x.
>
> Regards
> Matej
>
> - Original Message -
>> From: "Emily Jiang" <emiji...@uk.ibm.com>
>> To: "Martin Kouba" <mko...@redhat.com>
>> Cc: weld-dev@lists.jboss.org
>> Sent: Thursday, July 21, 2016 12:24:25 PM
>> Subject: Re: [weld-dev] Next stable version is 2.4.0
>>
>> Hi Martin,
>>
>> Why not carrying on releasing these jira fixes on 2.3.x branches?
> Weld-1574
>> is useful. Do you plan to
>> WELD-1574 [3] - remove the dependency on Google Guava and reduce the
>> footprint to Weld 2.3.x?
>>
>> Many thanks,
>> Emily
>> ===
>> Emily Jiang
>> WebSphere Application Server, CDI Development Lead
>>
>> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>> Phone: +44 (0)1962 816278 Internal: 246278
>>
>> Email: emiji...@uk.ibm.com
>> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>>
>>
>>
>>
>> From: Martin Kouba <mko...@redhat.com>
>> To: Antoine Sabot-Durand <anto...@sabot-durand.net>,
>> "weld-dev@lists.jboss.org" <weld-dev@lists.jboss.org>,
>> Date: 21/07/2016 10:22
>> Subject: Re: [weld-dev] Next stable version is 2.4.0
>> Sent by: weld-dev-boun...@lists.jboss.org
>>
>>
>>
>>
>> Dne 21.7.2016 v 11:18 Antoine Sabot-Durand napsal(a):
>> > Hi Martin,
>> >
>> > I find all this interesting , especially the back porting of WELD-1574.
>> > For this last point, does that means that Weld 2.4 will require Java 8?
>>
>> No, 2.4 will still require Java 7.
>>
>> >
>> > Antoine
>> >
>> >
>> > Le jeu. 21 juil. 2016 à 09:58, Martin Kouba <mko...@redhat.com
>> > < mailto:mko...@redhat.com>> a écrit :
>> >
>> > Hi all,
>> >
>> > we've just created the 2.4 branch on github [1].
>> >
>> > Weld 2.4 will remain a CDI 1.2 implementation. We would like to do some
>> > cleanup (e.g. remove deprecated classes from Weld SE), enhance the API
>> > and also add some new features. See also the list of issues for
>> > 2.4.0.CR1 [2].
>> >
>> > Weld team is also considering backporting WELD-1574 [3] - remove the
>> > dependency on Google Guava and reduce the footprint. Let us know what
>> > you think about this idea.
>> >
>> > Martin
>> >
>> > [1]
>> > https://github.com/weld/core/tree/2.4
>> >
>> > [2]
>> > https://issues.jboss.org/projects/WELD/versions/12330683
>> >
>> > [3]
>> > https://issues.jboss.org/browse/WELD-1574
>> >
>> > --
>> > Martin Kouba
>> > Software Engineer
>> > Red Hat, Czech Republic
>> > 

Re: [weld-dev] Next stable version is 2.4.0

[Martin Kouba]

Dne 21.7.2016 v 11:18 Antoine Sabot-Durand napsal(a):
> Hi Martin,
>
> I find all this interesting , especially the back porting of WELD-1574.
> For this last point, does that means that Weld 2.4 will require Java 8?

No, 2.4 will still require Java 7.

>
> Antoine
>
>
> Le jeu. 21 juil. 2016 à 09:58, Martin Kouba <mko...@redhat.com
> <mailto:mko...@redhat.com>> a écrit :
>
> Hi all,
>
> we've just created the 2.4 branch on github [1].
>
> Weld 2.4 will remain a CDI 1.2 implementation. We would like to do some
> cleanup (e.g. remove deprecated classes from Weld SE), enhance the API
> and also add some new features. See also the list of issues for
> 2.4.0.CR1 [2].
>
> Weld team is also considering backporting WELD-1574 [3] - remove the
> dependency on Google Guava and reduce the footprint. Let us know what
> you think about this idea.
>
> Martin
>
> [1]
> https://github.com/weld/core/tree/2.4
>
> [2]
> https://issues.jboss.org/projects/WELD/versions/12330683
>
> [3]
> https://issues.jboss.org/browse/WELD-1574
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org <mailto:weld-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Next stable version is 2.4.0

[Martin Kouba]

Hi all,

we've just created the 2.4 branch on github [1].

Weld 2.4 will remain a CDI 1.2 implementation. We would like to do some 
cleanup (e.g. remove deprecated classes from Weld SE), enhance the API 
and also add some new features. See also the list of issues for 
2.4.0.CR1 [2].

Weld team is also considering backporting WELD-1574 [3] - remove the 
dependency on Google Guava and reduce the footprint. Let us know what 
you think about this idea.

Martin

[1]
https://github.com/weld/core/tree/2.4

[2]
https://issues.jboss.org/projects/WELD/versions/12330683

[3]
https://issues.jboss.org/browse/WELD-1574

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 2.3.5.Final released

[Martin Kouba]

http://weld.cdi-spec.org/news/2016/07/01/weld-235Final/

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Fwd: [cdi-dev] test weld 3.0.0-SNAPSHOT with wildfly 9.0

[Martin Kouba]

Forwarding from cdi-dev...

 Přeposlaná zpráva 
Předmět: [cdi-dev] test weld 3.0.0-SNAPSHOT with wildfly 9.0
Datum: Thu, 11 Feb 2016 07:46:56 -0700 (MST)
Od: baochen su 
Komu: cdi-...@lists.jboss.org

hi all,

I want to test weld-core 3.0.0-SNAPSHOT with wildfly-9.0.2.Final, but
because  no probe directory exists in
modules/system/layers/base/org/jboss/weld, so mvn package -Pupdate-jboss-as
... failed.

I have modify jboss-as/pom.xml and add those lines just before :

 
 
 
 

this works fine, but one problem remain: file "module.xml" for probe not
provided by wildfly, so how can I find or create suitable module.xml for
probe? Or, any patch needed for the missing module.xml file to pom.xml?

Thanks  in advance!



--
View this message in context: 
http://cdi-development-mailing-list.1064426.n5.nabble.com/test-weld-3-0-0-SNAPSHOT-with-wildfly-9-0-tp5712457.html
Sent from the CDI Development mailing list mailing list archive at 
Nabble.com.
___
cdi-dev mailing list
cdi-...@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/cdi-dev

Note that for all code provided on this list, the provider licenses the 
code under the Apache License, Version 2 
(http://www.apache.org/licenses/LICENSE-2.0.html). For all other ideas 
provided on this list, the provider waives all patent and other 
intellectual property rights inherent in such information.


___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 3.0.0.Alpha15 released

[Martin Kouba]

http://weld.cdi-spec.org/news/2016/02/04/weld-300Alpha15/

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 2.3.2.Final released

[Martin Kouba]

http://weld.cdi-spec.org/news/2015/12/10/weld-232Final/

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 3.0.0.Alpha14 released

[Martin Kouba]

http://weld.cdi-spec.org/news/2015/12/04/weld-300Alpha14/

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Overridden equals() are ignored on client proxy

[Martin Kouba]

Hi Emily,

yes, the spec is clear and for good reasons. This was already discussed 
in EG and weld community - see for example WELD-695 [1]. And the 
consensus is: "it does not make sense to delegate equals/hashcode to 
bean instances for client proxies".

One of the problems is that client proxies may be shared between 
multiple injection points (and in Weld they are).

Also in Weld a client proxy is equal to a client proxy for the same bean.

Anyway, it seems it doesn't work on OWB either - see also OWB-458 [2].

Martin


[1]
https://issues.jboss.org/browse/WELD-695?focusedCommentId=12566720=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-12566720

[2]
https://issues.apache.org/jira/browse/OWB-458

Dne 3.12.2015 v 00:43 Emily Jiang napsal(a):
> Hi Martin,
>
> For some reason, a proxied bean's equals cannot be called. Are you aware
> of this problem? Although the spec says:
>
> The behavior of all methods declared by java.lang.Object, except for
> toString(), is
> undefined for a client proxy. Portable applications should not invoke
> any method declared by
> java.lang.Object, except for toString(), on a client proxy.
>
> I thought the overridden equals is different from the methods defined by
> Object class and it should be invoked.
>
> Please find attached a very simple test case that shows a .equals()
> method not being invoked on a bean proxied by Weld.
>
>
> In a debugger one can see that GenericBean.equals() is not invoked
> within the Servlet:
>
>  protected void doGet(HttpServletRequest request,
> HttpServletResponse response) throws ServletException, IOException {
>PrintWriter pw = response.getWriter();
>pw.println ("Hello");
>if (gb.equals(new GenericBean(10))) {  // GenericBean.equals() is
> not invoked; test prints 'fail'
>pw.println("pass");
>} else {
>pw.println ("fail");
>}
>  }
>
> The .war contains source and object code. As you can see there's only
> two classes.
>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] clean up unused conversations

[Martin Kouba]

Hi Emily,

there is no such way. Of course, if an HTTP session times out all the 
conversations are destroyed as well.

Martin

Dne 25.11.2015 v 15:40 Emily Jiang napsal(a):
> Thank you Martin! Is there any way to destroy the unused conversations
> earlier before ServletRequestListener.requestDestroyed()?
>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Martin Kouba <mko...@redhat.com>
> To: weld-dev@lists.jboss.org,
> Date: 18/11/2015 07:53
> Subject: Re: [weld-dev] clean up unused conversations
> Sent by: weld-dev-boun...@lists.jboss.org
> 
>
>
>
> Hi Emily,
>
> in Weld all expired/timed-out conversations are marked as transient and
> destroyed during every ServletRequestListener.requestDestroyed()
> notification. So there is no such configuration property.
>
> Martin
>
> Dne 17.11.2015 v 23:15 Emily Jiang napsal(a):
>  > In OpenWebBeans, there is a configuration
>  > *org.apache.webbeans.conversation.Conversation.periodicDelay*
>  >
>  > Specifies a delay in milliseconds. Use the conversation periodic delay
>  > custom property to search for and delete unused conversations.
>  >
>  > Is there such configuration in Weld?
>  >
>  > Many thanks,
>  > Emily
>  > ===
>  > Emily Jiang
>  > WebSphere Application Server, CDI Development Lead
>  >
>  > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>  > Phone:  +44 (0)1962 816278  Internal: 246278
>  >
>  > Email: emiji...@uk.ibm.com
>  > Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>  >
>  >
>  > ___
>  > weld-dev mailing list
>  > weld-dev@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] clean up unused conversations

[Martin Kouba]

Dne 26.11.2015 v 10:48 Emily Jiang napsal(a):
> Hi Martin,
>
> Let me clarify with a scenario:
>
> If I set the conversation timeout to be 30s, the unused conversations is
> destroyed after the timeout, e.g. 31s, automatically. No user
> interactions are involved. No ServletRequestListener needs to be
> registered by the customer applications.
>
> In summary, the unused conversations will be cleared either during
> ServletRequestListner.requestDestroyed() notification or HTTPSession
> timeout. Do you have anyone complain about unused conversations not
> cleared up timely?

Yes, the timed out conversations are automatically destroyed after the 
next ServletRequestListner.requestDestroyed() or when the session times 
out or when the session is invalidated. No ServletRequestListener needs 
to be registered by the application.

No complaints so far.

>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Martin Kouba <mko...@redhat.com>
> To: Emily Jiang/UK/IBM@IBMGB,
> Cc: weld-dev@lists.jboss.org
> Date: 26/11/2015 08:04
> Subject: Re: [weld-dev] clean up unused conversations
> Sent by: weld-dev-boun...@lists.jboss.org
> 
>
>
>
> Hi Emily,
>
> there is no such way. Of course, if an HTTP session times out all the
> conversations are destroyed as well.
>
> Martin
>
> Dne 25.11.2015 v 15:40 Emily Jiang napsal(a):
>  > Thank you Martin! Is there any way to destroy the unused conversations
>  > earlier before ServletRequestListener.requestDestroyed()?
>  >
>  > Many thanks,
>  > Emily
>  > ===
>  > Emily Jiang
>  > WebSphere Application Server, CDI Development Lead
>  >
>  > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>  > Phone:  +44 (0)1962 816278  Internal: 246278
>  >
>  > Email: emiji...@uk.ibm.com
>  > Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>  >
>  >
>  >
>  >
>  > From: Martin Kouba <mko...@redhat.com>
>  > To: weld-dev@lists.jboss.org,
>  > Date: 18/11/2015 07:53
>  > Subject: Re: [weld-dev] clean up unused conversations
>  > Sent by: weld-dev-boun...@lists.jboss.org
>  > 
>  >
>  >
>  >
>  > Hi Emily,
>  >
>  > in Weld all expired/timed-out conversations are marked as transient and
>  > destroyed during every ServletRequestListener.requestDestroyed()
>  > notification. So there is no such configuration property.
>  >
>  > Martin
>  >
>  > Dne 17.11.2015 v 23:15 Emily Jiang napsal(a):
>  >  > In OpenWebBeans, there is a configuration
>  >  > *org.apache.webbeans.conversation.Conversation.periodicDelay*
>  >  >
>  >  > Specifies a delay in milliseconds. Use the conversation periodic delay
>  >  > custom property to search for and delete unused conversations.
>  >  >
>  >  > Is there such configuration in Weld?
>  >  >
>  >  > Many thanks,
>  >  > Emily
>  >  > ===
>  >  > Emily Jiang
>  >  > WebSphere Application Server, CDI Development Lead
>  >  >
>  >  > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>  >  > Phone:  +44 (0)1962 816278  Internal: 246278
>  >  >
>  >  > Email: emiji...@uk.ibm.com
>  >  > Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>  >  > Unless stated otherwise above:
>  >  > IBM United Kingdom Limited - Registered in England and Wales with
> number
>  >  > 741598.
>  >  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
>  > PO6 3AU
>  >  >
>  >  >
>  >  >
>  >  > ___
>  >  > weld-dev mailing list
>  >  > weld-dev@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] potential weld jira

[Martin Kouba]

Dne 19.11.2015 v 10:07 Emily Jiang napsal(a):
> Hi Martin,
>
> The issue is that the specialized bean is not enabled for
> beans-xml-modified2.jar.

Yep, but the spec does not state this should be taken into account.

> @Alternative @Specialized annotated beans should not be active if it is
> not enabled. I think the specialized should not be active if the
> alternative is not. Otherwise, we run into the situation where the
> specialized bean disabled a second bean but itself is not active.
>
> ok. I'll post the question on cdi-dev.
>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Martin Kouba <mko...@redhat.com>
> To: Emily Jiang/UK/IBM@IBMGB,
> Cc: Weld <weld-dev@lists.jboss.org>
> Date: 19/11/2015 07:46
> Subject: Re: [weld-dev] potential weld jira
> Sent by: weld-dev-boun...@lists.jboss.org
> 
>
>
>
> The enablement is per bean archive but specialization is not, see also
> 4.3. Specialization:
>
> "When an enabled bean, as defined in Enabled and disabled beans,
> specializes a second bean, we can be certain that the second bean is
> never instantiated or called by the container. Even if the second bean
> defines a producer or observer method, the method will never be called."
>
> In other words, AlternativeCounterProducerModified (which is enabled in
> beans-xml-modified.jar) specializes CounterProducerModified. And so
> CounterProducerModified is not enabled for beans-xml-modified2.jar
> because it is specialized by any other enabled bean.
>
> Feel free to post a question to the cdi-dev ML.
>
> Martin
>
> Dne 18.11.2015 v 18:14 Emily Jiang napsal(a):
>  > Thank you Martin!
>  >
>  > I interpreted this enablement differently.
>  >
>  > The CDI 1.2 spec states:
>  >
>  > A bean is said to be /enabled/ if:
>  >
>  >   * it is deployed in a bean archive, and
>  >   * it is not a producer method or field of a disabled bean, and
>  >   * it is not specialized by any other enabled bean, as defined in
>  > _Specialization_
>  > <http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#specialization>,
>  > and either
>  >   * it is not an alternative, or it is a selected alternative of at
>  > least one bean archive or the application.
>  >
>  > Otherwise, the bean is said to be disabled.
>  >
>  >   In the above app, there are two jars. The jar
>  > beans-xml-modified2.jar.jar  does not enable the alternative and in its
>  > injection, it should only see the CounterProducerModified. While in
>  > another jar, the alternative AlternativeCounterProducerModified
>  > completely disabled the CounterProducerModified. Any injection in that
>  > jar should only see the specialized bean.
>  >
>  >  From what you explained, the beans.xml in one jar enabled the
>  > alternative bean and affect other jars. From my understanding, the
>  > enablement of alternatives/interceptors are specific for that archive
>  > and should not affect other jars.
>  >
>  > Also OpenWebBeans behaves differently from Weld, and OpenWebBeans does
>  > what I have expected (enablement are per jar only).
>  >
>  > Many thanks,
>  > Emily
>  > ===
>  > Emily Jiang
>  > WebSphere Application Server, CDI Development Lead
>  >
>  > MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
>  > Phone:  +44 (0)1962 816278  Internal: 246278
>  >
>  > Email: emiji...@uk.ibm.com
>  > Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>  >
>  >
>  >
>  >
>  > From: Martin Kouba <mko...@redhat.com>
>  > To: Emily Jiang/UK/IBM@IBMGB,
>  > Cc: Weld <weld-dev@lists.jboss.org>
>  > Date: 18/11/2015 15:52
>  > Subject: Re: potential weld jira
>  >
>  > 
>  >
>  >
>  >
>  > Well, it seems the problem is that CounterProducerModified is
>  > specialized by AlternativeCounterProducerModified and so it's not
>  > enabled and therefore it's producer method is also disabled (see also
>  > 5.1.2. Enabled and disabled beans [1]), i.e. it's not available for
>  > injection in beans-xml-modified2.jar. And
>  > AlternativeCounterProducerModified is an alternati

Re: [weld-dev] potential weld jira

[Martin Kouba]

Well, it seems the problem is that CounterProducerModified is 
specialized by AlternativeCounterProducerModified and so it's not 
enabled and therefore it's producer method is also disabled (see also 
5.1.2. Enabled and disabled beans [1]), i.e. it's not available for 
injection in beans-xml-modified2.jar. And 
AlternativeCounterProducerModified is an alternative which is not 
selected for beans-xml-modified2.jar.

It should work if you enable AlternativeCounterProducerModified globally 
or select AlternativeCounterProducerModified for beans-xml-modified2.jar.

Martin

[1]
http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#enablement

Dne 18.11.2015 v 16:14 Emily Jiang napsal(a):
> Hi Martin,
>
> Here's a simplified form of the test case:
>
>
> The application does not start, reporting
>
> [ERROR   ] CWWKZ0004E: An exception occurred while starting the
> application testDiffBDA. The exception message was:
> com.ibm.ws.container.service.state.StateChangeException:
> org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
> dependencies for type String with qualifiers @CounterModifiedQualifier
>at injection point [BackedAnnotatedField] @Inject
> @CounterModifiedQualifier
> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
>at
> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
>
> There are five classes in the .war.
>
> testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
>
> @Inject CounterProducerConsumerModified2 bean;
>
> This class, CounterProducerConsumerModified2.class is packaged in the
> first of two WEB-INF/lib jars, at
> testDiffBDA.war/WEB-INF/lib/beans-xml-modified2.jar.jar/com/ibm/jcdi/test/beans/xml.
> There is a bean that needs another bean injected into it:
>
> @Inject@CounterModifiedQualifierString modifiedProducer;
>
> The remaining three classes are all in the second WEB-INF/lib jar, at
> testDiffBDA.war/WEB-INF/lib/beans-xml-modified.jar.jar/com/ibm/jcdi/test/beansxml/.
> The classes are
>
> CounterModifiedQualifier  (the interface)
> CounterProducerModified (the bean implementing that interface)
> AlternativeCounterProducerModified (an alternative bean)
>
> The AlternativeCounterProducerModified class is declared in
> testDiffBDA.war/WEB-INF/lib/beans-xml-modified.jar.jar/META-INF/beans.xml,
>
> 
> com.ibm.jcdi.test.beansxml.AlternativeCounterProducerModified
> 
>
> The test app starts correctly if the  stanza is commented out.
>
>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Martin Kouba <mko...@redhat.com>
> To: Emily Jiang/UK/IBM@IBMGB, Weld <weld-dev@lists.jboss.org>,
> Date: 18/11/2015 07:58
> Subject: Re: potential weld jira
> 
>
>
>
> Hi Emily,
>
> a brief description would be helpful - it's not a trivial
> deployment/reproducer.
>
> Martin
>
> Dne 16.11.2015 v 23:15 Emily Jiang napsal(a):
>  > I'm trying to deploy the attached war but got Weld alidation error. On
>  > Glassfish 4.1, I got this error:
>  > Error occurred during deployment: Exception while loading the app : CDI
>  > deployment failure:WELD-001408: Unsatisfied dependencies for type String
>  > with qualifiers @DiffBDACounterQualifier at injection point
>  > [BackedAnnotatedField] @Inject @DiffBDACounterQualifier
>  >
> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified.diffBDAProducer
>  > at
>  >
> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified.diffBDAProducer(CounterProducerConsumerModified.java:0)
>  > WELD-001475: The following beans match by type, but none have matching
>  > qualifiers: - Producer Method [String] with qualifiers
>  > [@CounterUnmodifiedQualifier @Any] declared as [[BackedAnnotatedMethod]
>  > @ExcludeClassInterceptors @Produces @CounterUnmodifiedQualifier
>  >
> com.ibm.jcdi.test.beansxml.CounterProducerNoModifiers.getCounterBeanProducer()],
>  > - Producer Method [String] with qualifiers [@BatchProperty @Any]
>  > declared as [[UnbackedAnnotatedMethod] @Produces @Dependent
>  > @BatchProperty public com.ibm.jbatch.container.cdi.BatchProducerBean.p
>  >  msg.seeServerLog
>  >
>  >
>  >
>  >
>  >
>  > The app works fine on OpenWebBeans. Any ideas on what was wrong?
>  >
>  > Many thanks,
&g

Re: [weld-dev] potential weld jira

[Martin Kouba]

The enablement is per bean archive but specialization is not, see also 
4.3. Specialization:

"When an enabled bean, as defined in Enabled and disabled beans, 
specializes a second bean, we can be certain that the second bean is 
never instantiated or called by the container. Even if the second bean 
defines a producer or observer method, the method will never be called."

In other words, AlternativeCounterProducerModified (which is enabled in 
beans-xml-modified.jar) specializes CounterProducerModified. And so 
CounterProducerModified is not enabled for beans-xml-modified2.jar 
because it is specialized by any other enabled bean.

Feel free to post a question to the cdi-dev ML.

Martin

Dne 18.11.2015 v 18:14 Emily Jiang napsal(a):
> Thank you Martin!
>
> I interpreted this enablement differently.
>
> The CDI 1.2 spec states:
>
> A bean is said to be /enabled/ if:
>
>   * it is deployed in a bean archive, and
>   * it is not a producer method or field of a disabled bean, and
>   * it is not specialized by any other enabled bean, as defined in
> _Specialization_
> <http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#specialization>,
> and either
>   * it is not an alternative, or it is a selected alternative of at
> least one bean archive or the application.
>
> Otherwise, the bean is said to be disabled.
>
>   In the above app, there are two jars. The jar
> beans-xml-modified2.jar.jar  does not enable the alternative and in its
> injection, it should only see the CounterProducerModified. While in
> another jar, the alternative AlternativeCounterProducerModified
> completely disabled the CounterProducerModified. Any injection in that
> jar should only see the specialized bean.
>
>  From what you explained, the beans.xml in one jar enabled the
> alternative bean and affect other jars. From my understanding, the
> enablement of alternatives/interceptors are specific for that archive
> and should not affect other jars.
>
> Also OpenWebBeans behaves differently from Weld, and OpenWebBeans does
> what I have expected (enablement are per jar only).
>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>
>
>
>
> From: Martin Kouba <mko...@redhat.com>
> To: Emily Jiang/UK/IBM@IBMGB,
> Cc: Weld <weld-dev@lists.jboss.org>
> Date: 18/11/2015 15:52
> Subject: Re: potential weld jira
>
> 
>
>
>
> Well, it seems the problem is that CounterProducerModified is
> specialized by AlternativeCounterProducerModified and so it's not
> enabled and therefore it's producer method is also disabled (see also
> 5.1.2. Enabled and disabled beans [1]), i.e. it's not available for
> injection in beans-xml-modified2.jar. And
> AlternativeCounterProducerModified is an alternative which is not
> selected for beans-xml-modified2.jar.
>
> It should work if you enable AlternativeCounterProducerModified globally
> or select AlternativeCounterProducerModified for beans-xml-modified2.jar.
>
> Martin
>
> [1]
> http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#enablement
>
> Dne 18.11.2015 v 16:14 Emily Jiang napsal(a):
>  > Hi Martin,
>  >
>  > Here's a simplified form of the test case:
>  >
>  >
>  > The application does not start, reporting
>  >
>  > [ERROR   ] CWWKZ0004E: An exception occurred while starting the
>  > application testDiffBDA. The exception message was:
>  > com.ibm.ws.container.service.state.StateChangeException:
>  > org.jboss.weld.exceptions.DeploymentException: WELD-001408: Unsatisfied
>  > dependencies for type String with qualifiers @CounterModifiedQualifier
>  >at injection point [BackedAnnotatedField] @Inject
>  > @CounterModifiedQualifier
>  >
> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer
>  >at
>  >
> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified2.modifiedProducer(CounterProducerConsumerModified2.java:0)
>  >
>  > There are five classes in the .war.
>  >
>  > testDiffBDA.war/WEB-INF/classes/test/diff/web/FrontEndServlet.class
>  >
>  > @Inject CounterProducerConsumerModified2 bean;
>  >
>  > This class, CounterProducerConsumerModified2.class is packaged in the
>  > first of two WEB-INF/lib jars, at
>  >
> testDiffBDA.war/WEB-INF/lib/beans-xml-modified2.jar.jar/com/ibm/jcdi/test/beans/xml.
>  > Th

Re: [weld-dev] clean up unused conversations

[Martin Kouba]

Hi Emily,

in Weld all expired/timed-out conversations are marked as transient and 
destroyed during every ServletRequestListener.requestDestroyed() 
notification. So there is no such configuration property.

Martin

Dne 17.11.2015 v 23:15 Emily Jiang napsal(a):
> In OpenWebBeans, there is a configuration
> *org.apache.webbeans.conversation.Conversation.periodicDelay*
>
> Specifies a delay in milliseconds. Use the conversation periodic delay
> custom property to search for and delete unused conversations.
>
> Is there such configuration in Weld?
>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
>
>
> ___
> weld-dev mailing list
> weld-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] potential weld jira

[Martin Kouba]

Hi Emily,

a brief description would be helpful - it's not a trivial 
deployment/reproducer.

Martin

Dne 16.11.2015 v 23:15 Emily Jiang napsal(a):
> I'm trying to deploy the attached war but got Weld alidation error. On
> Glassfish 4.1, I got this error:
> Error occurred during deployment: Exception while loading the app : CDI
> deployment failure:WELD-001408: Unsatisfied dependencies for type String
> with qualifiers @DiffBDACounterQualifier at injection point
> [BackedAnnotatedField] @Inject @DiffBDACounterQualifier
> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified.diffBDAProducer
> at
> com.ibm.jcdi.test.beansxml.CounterProducerConsumerModified.diffBDAProducer(CounterProducerConsumerModified.java:0)
> WELD-001475: The following beans match by type, but none have matching
> qualifiers: - Producer Method [String] with qualifiers
> [@CounterUnmodifiedQualifier @Any] declared as [[BackedAnnotatedMethod]
> @ExcludeClassInterceptors @Produces @CounterUnmodifiedQualifier
> com.ibm.jcdi.test.beansxml.CounterProducerNoModifiers.getCounterBeanProducer()],
> - Producer Method [String] with qualifiers [@BatchProperty @Any]
> declared as [[UnbackedAnnotatedMethod] @Produces @Dependent
> @BatchProperty public com.ibm.jbatch.container.cdi.BatchProducerBean.p
>  msg.seeServerLog
>
>
>
>
>
> The app works fine on OpenWebBeans. Any ideas on what was wrong?
>
> Many thanks,
> Emily
> ===
> Emily Jiang
> WebSphere Application Server, CDI Development Lead
>
> MP 211, DE3A20, Winchester, Hampshire, England, SO21 2JN
> Phone:  +44 (0)1962 816278  Internal: 246278
>
> Email: emiji...@uk.ibm.com
> Lotus Notes: Emily Jiang/UK/IBM@IBMGB
>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] New blog post: Weld development mode and JMX support

[Martin Kouba]

http://weld.cdi-spec.org/news/2015/11/10/weld-probe-jmx/

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] javax.el.ExpressionFactory has final methods! CDI doesn't allow that

[Martin Kouba]

Well, might not be nice but we cannot guarantee backward compatibility 
for such cases. CDI defines a contract. If you break the contract then 
the deployment fails. If we allow to break the contract then the 
contract is useless and we could allow anything...

Anyway what's the use case here? Is there a normal-scoped producer?
I believe that having such a producer for a third-party type other than 
interface is not a good practice. Is there a normal-scoped bean class 
extending Hashtable? Not a good practice either. If so, the bean author 
should reduce the bean types by means of @Typed and allow the bean 
clients to only work with interfaces.

Martin

Dne 22.10.2015 v 00:28 Emily Jiang napsal(a):
> What about legacy applications running on new JDK7? The only workaround
> is that the customers have to update the app. Otherwise, their app won't
> start. This is not nice.
>
> On Wed, Oct 21, 2015 at 2:57 PM, Martin Kouba <mko...@redhat.com
> <mailto:mko...@redhat.com>> wrote:
>
> Dne 21.10.2015 v 13:54 Emily Jiang napsal(a):
>
> doh. You were right that the OWB-616 was for a different issue
> rather
> than the one I am interested.
>
> Do you have any suggestions about working around the unproxiable
> Hashtable issue?
>
>
> Well, the spec only requires the injection points to be validated,
> or rather the required bean types to be proxyable. So if you
> inject/use Map interface instead of Hashtable, the validation should
> pass.
>
>
> On Wed, Oct 21, 2015 at 12:38 PM, Martin Kouba
> <mko...@redhat.com <mailto:mko...@redhat.com>
> <mailto:mko...@redhat.com <mailto:mko...@redhat.com>>> wrote:
>
>  Dne 21.10.2015 v 13:20 Emily Jiang napsal(a):
>
>  Thanks Martin!
>  The new final method on the Hashtable is
>
>  final boolean initHashSeedAsNeeded(int capacity)
>
>
>  I see. This package-private method was added in JDK7.
>
>
>  The change went as part of the following bug fix:
>
>  [1]
> http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8006593
>
>  As for the OWB-616 jira, I did not look at the actual
> fix, but I
>  assume
>  the fix by the following comments. I might be wrong here.
>
>  <https://issues.apache.org/jira/browse/OWB-616#>
>  Mark Struberg
>
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg>
>  added a comment - 01/Oct/11 19:12
>
>  I now changed the checks to allow private final and
> public/protected
>  static final methods.
>
>
>  Mark does not talk about non-static package-private
> methods, right?
>  He talks about private final and public/protected static
> final =>
>  should work in Weld too.
>
>  If non-static package-private methods are allowed than the
> spec is
>  violated. Unfortunately, it seems there's no tck test for this.
>
>
>
>  Thanks
>
>  Emily
>
>
>  On Wed, Oct 21, 2015 at 11:50 AM, Martin Kouba
>  <mko...@redhat.com <mailto:mko...@redhat.com>
> <mailto:mko...@redhat.com <mailto:mko...@redhat.com>>
>  <mailto:mko...@redhat.com <mailto:mko...@redhat.com>
> <mailto:mko...@redhat.com <mailto:mko...@redhat.com>>>> wrote:
>
>   Hi Emily,
>
>   commments inline.
>
>   Dne 21.10.2015 v 11:02 Emily Jiang napsal(a):
>
>   CDI specification does not allow proxying a
> class with
>   non-private final
>   methods. The java.util.Hashtable class has a
>   non-private final method added to the class in
> later
>  versions
>   of Java, so a CDI application that previously
> worked
>  may break
>   when updating the Java level.
>
>
>   Just for the record: what's the name of the method?
>
>
>   This issue was logged in CDI-527.
>
>   OpenWebBeans fixed this via the jira
>   (https://issues.apache.org/jira/browse/OWB-616).
>
>
>   OWB-616 does not fix CDI-527

Re: [weld-dev] javax.el.ExpressionFactory has final methods! CDI doesn't allow that

[Martin Kouba]

Dne 21.10.2015 v 13:20 Emily Jiang napsal(a):
> Thanks Martin!
> The new final method on the Hashtable is
>
> final boolean initHashSeedAsNeeded(int capacity)

I see. This package-private method was added in JDK7.

>
> The change went as part of the following bug fix:
>
> [1] http://bugs.java.com/bugdatabase/view_bug.do?bug_id=8006593
>
> As for the OWB-616 jira, I did not look at the actual fix, but I assume
> the fix by the following comments. I might be wrong here.
>
> <https://issues.apache.org/jira/browse/OWB-616#>
> Mark Struberg
> <https://issues.apache.org/jira/secure/ViewProfile.jspa?name=struberg>
> added a comment - 01/Oct/11 19:12
>
> I now changed the checks to allow private final and public/protected
> static final methods.

Mark does not talk about non-static package-private methods, right? He 
talks about private final and public/protected static final => should 
work in Weld too.

If non-static package-private methods are allowed than the spec is 
violated. Unfortunately, it seems there's no tck test for this.

>
>
> Thanks
>
> Emily
>
>
> On Wed, Oct 21, 2015 at 11:50 AM, Martin Kouba <mko...@redhat.com
> <mailto:mko...@redhat.com>> wrote:
>
> Hi Emily,
>
> commments inline.
>
> Dne 21.10.2015 v 11:02 Emily Jiang napsal(a):
>
> CDI specification does not allow proxying a class with
> non-private final
> methods. The java.util.Hashtable class has a
> non-private final method added to the class in later versions
> of Java, so a CDI application that previously worked may break
> when updating the Java level.
>
>
> Just for the record: what's the name of the method?
>
>
> This issue was logged in CDI-527.
>
> OpenWebBeans fixed this via the jira
> (https://issues.apache.org/jira/browse/OWB-616).
>
>
> OWB-616 does not fix CDI-527 but CDI-159, i.e. a private final
> method does not cause a deployment problem. This works in Weld too.
> On the other hand, CDI-527 is still an open issue so we can't simply
> fix it. In theory, we could add a new feature of a non-portable
> mode. But non-portable mode is not intended to be commonly used.
> It's kind of a workaround.
>
>
> Can Weld fix this in the 2.3 or 2.2 trunk?
>
>
> --
> Thanks
> Emily
> =
> Emily Jiang
> eji...@apache.org <mailto:eji...@apache.org>
> <mailto:eji...@apache.org <mailto:eji...@apache.org>>
>
>
> ___
> weld-dev mailing list
> weld-dev@lists.jboss.org <mailto:weld-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/weld-dev
>
>
> --
> Martin Kouba
> Software Engineer
> Red Hat, Czech Republic
>
>
>
>
> --
> Thanks
> Emily
> =
> Emily Jiang
> eji...@apache.org <mailto:eji...@apache.org>

-- 
Martin Kouba
Software Engineer
Red Hat, Czech Republic
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] Weld 3.0.0.Alpha12 - CDI 2.0 EDR1 reference implementation released!

[Martin Kouba]

Hello,

Weld 3.0.0.Alpha12 - a CDI 2.0 EDR1 reference implementation - has been 
released:
http://weld.cdi-spec.org/news/2015/08/05/weld-300Alpha12/

It's available in Maven Central Repository, in a zip bundle [1] and 
there is a patch for WildFly 10.0.0.Alpha6 [2].

Furthermore, we've released the next stable version - 2.2.15.Final. See 
also the changelog [3]. The target platform is WildFly 9.0.1.Final [4].

Martin


[1]
http://download.jboss.org/weld/3.0.0.Alpha12/weld-3.0.0.Alpha12.zip

[2]
http://download.jboss.org/weld/3.0.0.Alpha12/wildfly-10.0.0.Alpha6-weld-3.0.0.Alpha12-patch.zip

[3]
https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310891version=12327593

[4]
http://download.jboss.org/weld/2.2.15.Final/wildfly-9.0.1.Final-weld-2.2.15.Final-patch.zip
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Weld Performance improvement

[Martin Kouba]

Hi Emily,

it's great to hear there is a performance improvement (although 1% is 
not that much). We're working on further performance improvements in 
this area [1].

However, 23% additional overhead seems to me too much. Would it be 
possible to share your performance test case / test application? We 
could run similar tests in our environment and verify that there's no 
integration problem.

Martin

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


Dne 20.7.2015 v 11:12 Emily Jiang napsal(a):
 Hi Jozef, Martin,

 Sorry for the delay! I have the performance figure collected eventually.
 With this Jira's changes, it shows 1% performance improvement. This is a
 step in the right direction but there is still a performance hit (23%
 worse) when turning on CDI. Would you like to commit this change so that
 I can reconsume this release? It will be great if a further performance
 improvement can be done. I am happy to collect the performance benchmark
 if needed.

 Thanks
 Emily

 On Thu, Jul 2, 2015 at 8:35 AM, Jozef Hartinger jhart...@redhat.com
 mailto:jhart...@redhat.com wrote:

 Hi Emily,

 that should not be a problem. Would it be possible for you to test
 the performance improvement before we actually do the release? I can
 prepare a separate branch or send you a binary. I would like to see
 how much improvement this makes in your benchmark.

 Jozef


 On 07/01/2015 06:19 PM, Emily Jiang wrote:
 Is it possible to get the following jira fix committed to
 2.2.15.Final?

 https://issues.jboss.org/browse/WELD-1931

 I would like to consume this and see how much improvement has been
 made.

 --
 Thanks
 Emily
 =
 Emily Jiang
 eji...@apache.org mailto:eji...@apache.org




 --
 Thanks
 Emily
 =
 Emily Jiang
 eji...@apache.org mailto:eji...@apache.org

___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] How to change logging level for weld se

[Martin Kouba]

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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Interceptors

[Martin Kouba]

Dne 17.5.2015 v 00:02 Emily Jiang napsal(a):
 Thank you Martin! I think if I specifiy a class level interceptor,
 service(ServiceRequest, ServletResponse) will be intercepted but not
 doGet(), as doGet will be called by .service(ServletRequest,
 ServletResponse) directly not via a proxy. Did I miss anything?


Yes, the HttpServlet.doGet() invocation itself will not be intercepted, 
but the interceptor will be called for the outer service() method. So 
from the user point of view the result will be similar.

 On Fri, May 15, 2015 at 11:45 AM, Martin Kouba mko...@redhat.com
 mailto:mko...@redhat.com wrote:

 Dne 13.5.2015 v 00:27 Emily Jiang napsal(a):

 Thank you Jozef for the helpful info. I have another question on
 interceptor:
 EE7 spec states the JavaEE component classes, listed in Table
 EE.5-1,
 need to support interceptors. Take servlet for an example, which
 methods
 can be intercepted?

 As the servlet classes are invoked by the container, according
 to CDI1.2
 spec, it seems only service(ServletRequest, ServletResponse) can be
 intercepted. No other methods can be intercepted.

 Normally customer applications override doPost or doGet, but
 they cannot
 be intercepted. I cannot see any value of support interceptors on
 Servlet. Anything I missed?


 The serlet container always invokes Servlet.service(ServletRequest,
 ServletResponse)() which delegates to one of those convenient
 methods (doGet() etc.) in case of javax.servlet.http.HttpServlet. So
 if you extend HttpServlet and only override doGet() it would be
 intercepted if you annotate the servlet class with an interceptor
 binding. If you only annotate the doGet() method an interceptor will
 not be invoked.


 On Tue, May 12, 2015 at 7:50 AM, Jozef Hartinger
 jhart...@redhat.com mailto:jhart...@redhat.com
 mailto:jhart...@redhat.com mailto:jhart...@redhat.com wrote:

  On 05/11/2015 03:47 PM, Emily Jiang wrote:


  I have a few questions on interceptors:

  1. CDI Interceptors on cdi beans
  Will the interceptors share the same creational context
 as the
  bean it is associated with?

  Yes. It is not the very same creational context but a new
 one with a
  parent-child relationship to the one of the associated
 bean. This is
  the same as for @Dependent dependencies

  Will Weld managed the cdi interceptors as well as the
 old-styled
  interceptors?

  Yes, Weld manages interceptor bindings associated using
 interceptor
  bindings as well as those associated using @Interceptors

  @Interceptors don't work on other cdi beans except ejb
 and managed
  beans, right?

  Managed bean is ambiguous. Weld support interceptors on
 all CDI
  managed beans (not on producer fields/methods nor
 extension-provided
  beans).


  2. Interceptors on ejb beans or managed beans
  I think the integrator needs to create these
 @Interceptors and cdi
  interceptors.

  Yes, for EJBs and EE managed beans it is integrator's job
 to handle
  those. Weld can handle @AroundConstruct interceptors if
 needed. I've
  updated the docs on this topic recently:
 
 https://github.com/jharting/core/blob/a1eb6194be36ded86dc9709c6767f5016fb98997/docs/reference/src/main/asciidoc/ri-spi.asciidoc#around-construct-interception

  Will these interceptors use the non-contextual
 creational context
  (scope @Dependent) or use the ejb or managed bean's
 creational
  context?

  ejb or managed bean's creational context


  Will Weld destroy the interceptors when the associated
 beans are
  destroyed or the integrator need to destroy them? This
 logic
  applicable to both cdi interceptors and @Interceptors style
  interceptors, right?

  Any time the parent (bean's) creational context is
 destroyed, the
  children creational contexts (interceptors') are destroyed
 also by Weld.


  3. Interceptors on JavaEE components
  I think this interceptors are created by Weld when the
 JavaEE
  component classes are created, right? By the way, how
 can the
  container make sure to destroy the interceptors?

  This depends on how the component classes are managed.
 Assuming

Re: [weld-dev] Injection Services cannot handler producer on a static field

[Martin Kouba]

Hi Emily,

for a static producer field there is no InjectionTarget (there's no 
instance to inject) and therefore no IT may be registered via 
InjectionServices.

When using InjectionServices the current API does not allow to bypass 
the value of the static field and obtain the EE resource (e.g. do a JNDI 
lookup). So we let the integrator inject the static field, then read 
the value and propagate as the bean instance.

Martin


Dne 14.5.2015 v 23:47 Emily Jiang napsal(a):

 I am trying to run cdi cts and failed on the following test:
 org.jboss.cdi.tck.tests.implementation.simple.resource.ws.staticProducer.WebServiceResourceStaticProducerFieldTest.testResourceProduced(WebServiceResourceStaticProducerFieldTest.java:46)

 The test is to test the following produer:
 @Produces @WebServiceRef private static MyClass wsRef;

 On further investigation,it seems like Weld has a special call that it
 makes when a producer field is static but also annotated with a JavaEE
 resource. Eventually that calls to JaxwsInjectionServices, a weld SPI
 that we don't implement and falls back to just getting the value of the
 static field, which may not be set.

 We followed the Weld integration guide which said that we can handle
 JavaEE resource injection either by implementing the SPI
 InjectionServices where we can hook every injection call and to
 additional injection ourselves, or by implementing EjbInjectionServices,
 JaxwsInjectionServices, JpaInjectionServices and
 ResourceInjectionServices, all of which return a factory which produces
 the instance that weld will then inject.

 We implemented the former because it lets us just call our
 injectionengine, but Weld doesn't seem to use this SPI at all when
 handling static producer fields. Can someone confirm or give me some
 pointers how to fix this problem?

 --
 Thanks
 Emily
 =
 Emily Jiang
 eji...@apache.org mailto:eji...@apache.org


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev

___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] Interceptors

[Martin Kouba]

Dne 13.5.2015 v 00:27 Emily Jiang napsal(a):
 Thank you Jozef for the helpful info. I have another question on
 interceptor:
 EE7 spec states the JavaEE component classes, listed in Table EE.5-1,
 need to support interceptors. Take servlet for an example, which methods
 can be intercepted?

 As the servlet classes are invoked by the container, according to CDI1.2
 spec, it seems only service(ServletRequest, ServletResponse) can be
 intercepted. No other methods can be intercepted.

 Normally customer applications override doPost or doGet, but they cannot
 be intercepted. I cannot see any value of support interceptors on
 Servlet. Anything I missed?

The serlet container always invokes Servlet.service(ServletRequest, 
ServletResponse)() which delegates to one of those convenient methods 
(doGet() etc.) in case of javax.servlet.http.HttpServlet. So if you 
extend HttpServlet and only override doGet() it would be intercepted 
if you annotate the servlet class with an interceptor binding. If you 
only annotate the doGet() method an interceptor will not be invoked.


 On Tue, May 12, 2015 at 7:50 AM, Jozef Hartinger jhart...@redhat.com
 mailto:jhart...@redhat.com wrote:

 On 05/11/2015 03:47 PM, Emily Jiang wrote:

 I have a few questions on interceptors:

 1. CDI Interceptors on cdi beans
 Will the interceptors share the same creational context as the
 bean it is associated with?
 Yes. It is not the very same creational context but a new one with a
 parent-child relationship to the one of the associated bean. This is
 the same as for @Dependent dependencies
 Will Weld managed the cdi interceptors as well as the old-styled
 interceptors?
 Yes, Weld manages interceptor bindings associated using interceptor
 bindings as well as those associated using @Interceptors
 @Interceptors don't work on other cdi beans except ejb and managed
 beans, right?
 Managed bean is ambiguous. Weld support interceptors on all CDI
 managed beans (not on producer fields/methods nor extension-provided
 beans).

 2. Interceptors on ejb beans or managed beans
 I think the integrator needs to create these @Interceptors and cdi
 interceptors.
 Yes, for EJBs and EE managed beans it is integrator's job to handle
 those. Weld can handle @AroundConstruct interceptors if needed. I've
 updated the docs on this topic recently:
 
 https://github.com/jharting/core/blob/a1eb6194be36ded86dc9709c6767f5016fb98997/docs/reference/src/main/asciidoc/ri-spi.asciidoc#around-construct-interception
 Will these interceptors use the non-contextual creational context
 (scope @Dependent) or use the ejb or managed bean's creational
 context?
 ejb or managed bean's creational context

 Will Weld destroy the interceptors when the associated beans are
 destroyed or the integrator need to destroy them? This logic
 applicable to both cdi interceptors and @Interceptors style
 interceptors, right?
 Any time the parent (bean's) creational context is destroyed, the
 children creational contexts (interceptors') are destroyed also by Weld.

 3. Interceptors on JavaEE components
 I think this interceptors are created by Weld when the JavaEE
 component classes are created, right? By the way, how can the
 container make sure to destroy the interceptors?
 This depends on how the component classes are managed. Assuming the
 components are managed using Weld-provided InjectionTarget then it
 is up to the integrator to decide whether it provides interception
 support or whether it should be provided by Weld. This can be
 configured for each InjectionTarget individually using this builder:
 
 http://docs.jboss.org/weld/javadoc/2.2/weld-spi/org/jboss/weld/manager/api/WeldInjectionTargetBuilder.html


 --
 Thanks
 Emily
 =
 Emily Jiang
 eji...@apache.org mailto:eji...@apache.org


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org  mailto:weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev




 --
 Thanks
 Emily
 =
 Emily Jiang
 eji...@apache.org mailto:eji...@apache.org


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev


___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] ECCN for weld

[Martin Kouba]

Hello,

Weld 1.1.x is a part of Red Hat JBoss Enterprise Application Platform 
[1], of which the ECCN can be found in the product and technology matrix.

I'm not sure about the project itself (i.e. if used outside the product).

Martin

[1]
http://www.redhat.com/en/technologies/jboss-middleware/application-platform
[2]
http://www.redhat.com/en/about/export-control-product-matrix


Dne 13.5.2015 v 13:33 Beurer, Maria (Coriant - DE/Munich) napsal(a):
 Hello,

 We use weld in our commercial product and therefore need to know the
 ECCN for it.

 The ECCN is an international Export control and compliance number that
 is necessary for EVERY Export. Most of the european countries specify
 their goods according to the european commerce control list (EG dual-use
 list : http://ec.europa.eu/trade/index_en.htm).
 So for export of a commercial Software using weld  ( or any other open
 source or OEM Software), we need to document the libs, on one side to
 comply with license obligations and on the other side the ECCNs for
 Export restrictions. Please note, as the US regulations also care about
 re-export of US items ( any stuff that contains US Content above a
 certain Limit), we need to specify both; the EU-ECCN and the US-ECCN and
 hopefully the US license exception that applies (e.g. TSU for open source).

 So please specify the ECCN for weld or answer the following questions:
 - Country of origin ( where is weld Software mainly developed)
 - is there US Content in there? ( e.g. other open source libs)
 - Is the SW designed or modified to use cryptography performing any
 cryptographic function other than authentication or digital signature?
 (y/n)

 –if yes,

 -- key length symetric

 -- Bit length asymmetric


 Thanks and kind regards

 Maria Beurer

 Mit freundlichen Grüßen / Kind Regards / Com os melhores cumprimentos!

 Maria Beurer

 cid:image001.png@01D01091.4F1BD1F0

 *Coriant GmbH
 *Maria Beurer
 RD Engineer

 Coriant RD GmbH
 SW OSSTransnet TNTC DE
 St.-Martin-Str. 76
 81541 München
 Tel: +49 89 5402 15138
 maria.beu...@coriant.com mailto:maria.beu...@coriant.com
 http://www.coriant.com
 cid:image004.png@01D08645.87B02DC0Think before you print

 Coriant GmbH
 registered under / registriert unter: HRB 202750 | WEEE-Reg.-No. DE
 77603797
 Local Court of Munich / Amtsgericht München
 Registered Office:  Munich (Germany) / Sitz: München
 Managing Directors / Geschäftsführer: Peter Streit, Mike MacKinnon
 VAT ID / USt-IdNr.: DE288084869



 ___
 weld-dev mailing list
 weld-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] AfterBeanDiscovery and observer resolver cache

[Martin Kouba]

Hi Christian,

in CDI 1.1 you can use the EventMetadata interface [1]. But it's not
possible to inspect metadata in a custom observer notify() method. At
some point, there was a notify(T event, SetAnnotation qualifiers)
method, but it was removed because of backwards compatibility [2].

M

[1]
http://docs.jboss.org/cdi/spec/1.1/cdi-spec.html#event_metadata
[2]
https://issues.jboss.org/browse/CDI-281


Dne 19.3.2014 19:46, Christian Sadilek napsal(a):
 Hi guys,
 
 I have to follow up on this because our proposed solution using a single 
 ObserverMethod for @Any and Object.class won't work. The problem is that the 
 notify() method will only provide the event object but not its actual 
 qualifiers. So, I won't be able to dispatch to the corresponding observers 
 since I don't know which qualifiers the event actually has.
 
 So, taking away the ability to register observer methods on ABD after the 
 bootstrap process will cause a critical problem for us that is not resolvable.
 
 Is it possible to enhance or overload notify() in ObserverMethod to contain 
 the actual set of qualifiers as parameter (I think providing this metadata 
 would be good from an API perspective anyway)?
 
 If that's not possible, can we rethink the options I listed below for 
 clearing the observer caches?
 
 Can you think of other solutions?
 
 Thanks,
 Christian
 
 On 2014-03-06, at 10:11 AM, Martin Kouba mko...@redhat.com wrote:
 
 Dne 6.3.2014 15:51, Christian Sadilek napsal(a):
 Hi guys,

 Fair enough. This is the outcome I expected. I do think, however, that
 the docs for ABD need some clarification here and ideally the ABD
 instance should be deactivated once the bootstrap process finished so
 it can throw an exception when e.g. addObserverMethod is invoked too
 late in the game (better than silently having no effect).

 +1
 I've created https://issues.jboss.org/browse/CDI-425 to address this issue.


 Thanks for your answers!

 Cheers,
 Christian

 On 2014-03-06, at 5:24 AM, Jozef Hartinger jhart...@redhat.com
 mailto:jhart...@redhat.com wrote:

 Yes, I don't think Errai should depend on this behavior as it is not
 even in the undefined category but rather in implicitly not
 allowed or not the intention of the spec category.

 Even from the Weld point of view we use two levels of caching and
 while clearing the main one is easy, dealing with the second layer
 would require adding further complexity just to support this corner case.

 Therefore, I would suggest to use the other approach you proposed
 where you register a general observer method and dispatch to the
 dynamically added observers within there. It is always hard to guess
 performance implications without doing measurements but as long as the
 general observer method implementation is efficient, I would not worry
 about that one additional method invocation much.

 Jozef

 On 03/06/2014 10:04 AM, Mark Struberg wrote:
 Hi Christian!

 While I find it nice that this works with OWB I also have to agree
 that this is not a guaranteed behaviour by the spec intention.
 What you could do in to hack around this issue is to have an
 @Observes@Any  Object method which delivers the events with your own
 dynamic rules.
 But be prepared that this might slow down your app a bit.

 LieGrue,
 strub



 On Wednesday, 5 March 2014, 17:04, Christian Sadilek
 csadi...@redhat.com wrote:

Hi,

Yes, I expected this to not be an officially supported use case.
So, I guess it's just a matter of improving the API
design/documentation.

However, dynamically registering an observer method would really
be useful in the case of Errai where we set up an event bridge
between the server and the client and potentially discover new
observers at runtime.

We could work around this by registering an observer method that
observes all events and then handle the dispatching internally
but that seems less efficient. Right now this works because
OpenWebBeans doesn't cache the observers and allows invocations
to AfterBeanDiscovery.addObserverMethod at runtime and because
Weld has the functionality to clear the observer cache (although
that's not public API).

My questions is: Is there a good reason not to support this going
forward? Can we add alternative functionality to add observer
methods at runtime (not using ABD)?

Cheers,
Christian

On 2014-03-05, at 4:37 AM, Martin Kouba mko...@redhat.com
mailto:mko...@redhat.com wrote:

 FYI I've informed CDI EG and it will be discussed on the next
meeting
 whether to clarify this already in CDI 1.2 MR...

 M

 Dne 5.3.2014 10:19, Jozef Hartinger napsal(a):
 Agreed. It is definitely not the intention of the
specification to allow
 beans/observers/contexts to be added at runtime and
applications should
 not have any expectations of what these methods do when
invoked outside
 of the AfterBeanDiscovery observer.

 We'll add stricter validation to Weld to disallow

Re: [weld-dev] AfterBeanDiscovery and observer resolver cache

[Martin Kouba]

FYI I've informed CDI EG and it will be discussed on the next meeting
whether to clarify this already in CDI 1.2 MR...

M

Dne 5.3.2014 10:19, Jozef Hartinger napsal(a):
 Agreed. It is definitely not the intention of the specification to allow 
 beans/observers/contexts to be added at runtime and applications should 
 not have any expectations of what these methods do when invoked outside 
 of the AfterBeanDiscovery observer.
 
 We'll add stricter validation to Weld to disallow this.
 
 On 03/05/2014 08:53 AM, Martin Kouba wrote:
 Hi Christian,this

 actually invoking any container lifecycle event method after the
 container initialization finished should have no effect. ABD event
 reference can escape but it does not mean you can invoke ABD.addBean()
 after ADV is fired.

 The spec wording is not very explicit here:
 During the application initialization process, the container fires a
 series of events, allowing portable extensions to integrate with
 the container initialization process defined in Section 12.2.

 Maybe we should file a new spec issue to clarify that such invocations
 should result in IllegalStateException...

 Martin


 Dne 4.3.2014 17:42, Christian Sadilek napsal(a):
 Hi Jozef,

 I think clearing the cache at the end of the Weld bootstrap process is not 
 enough to solve that particular problem since a CDI extension can hold on 
 to the ABD reference and invoke addObserverMethod later (multiple times) 
 which causes the same problem I described below. There's no indication to 
 the caller of addObserverMethod that it's in fact too late to call that 
 method.

 Since an ABD event reference can always escape (can be used outside the 
 method that observes it) it seems this issue should be resolved (although 
 it admittedly is an edge case).

 Cheers,
 Christian

 On 2014-03-04, at 11:29 AM, Jozef Hartinger jhart...@redhat.com wrote:

 Hi Christian,

 this sounds like a bug. All the resolution caches should be cleared at the 
 very end of Weld's bootstrap sequence (after ABD observers are called). 
 (see 
 https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldStartup.java#L415)

 Jozef

 On 03/04/2014 04:36 PM, Christian Sadilek wrote:
 Hi everyone,

 CDI extensions can observe the AfterBeanDiscovery event to register 
 observer methods (addObserverMethod). However, when an event is first 
 fired, the observers for that event are resolved and then cached (in 
 TypeSafeResolver). All future calls to addObserverMethod for an already 
 fired event with corresponding qualifiers will have no effect because the 
 observer result is read from cache and not recomputed.

 From an API perspective that's unfortunate because addObserverMethod 
 will only work until an event (with corresponding qualifiers) is fired 
 and there is no indication to the caller of that method that it didn't 
 have any effect when invoked after that.

 Possible solutions:

 - Provide some public API to clear/recompute that part the observer 
 cache. Maybe that exists? I couldn't find it which is why I am using the 
 private API and Reflection :(. Also let 
 AfterBeanDiscovery.addObserverMethod fail in that case with the advice to 
 reset the cache.

 - Recompute the corresponding part of the cache when addObserverMethod is 
 called (seems preferable).

 OpenWebBeans doesn't have this issue as their NotificationManager will 
 simply add the new ObserverMethod to a ConcurrentHashMap that is also 
 accessed when an event is fired.

 What do you think? Can this already be done or is there another solution?

 Cheers,
 Christian







 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev

 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev

 
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] AfterBeanDiscovery and observer resolver cache

[Martin Kouba]

Hi Christian,

the problem is that CDI is static by design. Anyway feel free to create
a feature request in the spec issue tracker
(https://issues.jboss.org/browse/CDI).

Martin

Dne 5.3.2014 17:01, Christian Sadilek napsal(a):
 Hi,
 
 Yes, I expected this to not be an officially supported use case. So, I guess 
 it's just a matter of improving the API design/documentation.
 
 However, dynamically registering an observer method would really be useful in 
 the case of Errai where we set up an event bridge between the server and the 
 client and potentially discover new observers at runtime.
 
 We could work around this by registering an observer method that observes all 
 events and then handle the dispatching internally but that seems less 
 efficient. Right now this works because OpenWebBeans doesn't cache the 
 observers and allows invocations to AfterBeanDiscovery.addObserverMethod at 
 runtime and because Weld has the functionality to clear the observer cache 
 (although that's not public API).
 
 My questions is: Is there a good reason not to support this going forward? 
 Can we add alternative functionality to add observer methods at runtime (not 
 using ABD)?
 
 Cheers,
 Christian
 
 On 2014-03-05, at 4:37 AM, Martin Kouba mko...@redhat.com wrote:
 
 FYI I've informed CDI EG and it will be discussed on the next meeting
 whether to clarify this already in CDI 1.2 MR...

 M

 Dne 5.3.2014 10:19, Jozef Hartinger napsal(a):
 Agreed. It is definitely not the intention of the specification to allow 
 beans/observers/contexts to be added at runtime and applications should 
 not have any expectations of what these methods do when invoked outside 
 of the AfterBeanDiscovery observer.

 We'll add stricter validation to Weld to disallow this.

 On 03/05/2014 08:53 AM, Martin Kouba wrote:
 Hi Christian,this

 actually invoking any container lifecycle event method after the
 container initialization finished should have no effect. ABD event
 reference can escape but it does not mean you can invoke ABD.addBean()
 after ADV is fired.

 The spec wording is not very explicit here:
 During the application initialization process, the container fires a
 series of events, allowing portable extensions to integrate with
 the container initialization process defined in Section 12.2.

 Maybe we should file a new spec issue to clarify that such invocations
 should result in IllegalStateException...

 Martin


 Dne 4.3.2014 17:42, Christian Sadilek napsal(a):
 Hi Jozef,

 I think clearing the cache at the end of the Weld bootstrap process is 
 not enough to solve that particular problem since a CDI extension can 
 hold on to the ABD reference and invoke addObserverMethod later (multiple 
 times) which causes the same problem I described below. There's no 
 indication to the caller of addObserverMethod that it's in fact too late 
 to call that method.

 Since an ABD event reference can always escape (can be used outside the 
 method that observes it) it seems this issue should be resolved (although 
 it admittedly is an edge case).

 Cheers,
 Christian

 On 2014-03-04, at 11:29 AM, Jozef Hartinger jhart...@redhat.com wrote:

 Hi Christian,

 this sounds like a bug. All the resolution caches should be cleared at 
 the very end of Weld's bootstrap sequence (after ABD observers are 
 called). (see 
 https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldStartup.java#L415)

 Jozef

 On 03/04/2014 04:36 PM, Christian Sadilek wrote:
 Hi everyone,

 CDI extensions can observe the AfterBeanDiscovery event to register 
 observer methods (addObserverMethod). However, when an event is first 
 fired, the observers for that event are resolved and then cached (in 
 TypeSafeResolver). All future calls to addObserverMethod for an already 
 fired event with corresponding qualifiers will have no effect because 
 the observer result is read from cache and not recomputed.

 From an API perspective that's unfortunate because addObserverMethod 
 will only work until an event (with corresponding qualifiers) is fired 
 and there is no indication to the caller of that method that it didn't 
 have any effect when invoked after that.

 Possible solutions:

 - Provide some public API to clear/recompute that part the observer 
 cache. Maybe that exists? I couldn't find it which is why I am using 
 the private API and Reflection :(. Also let 
 AfterBeanDiscovery.addObserverMethod fail in that case with the advice 
 to reset the cache.

 - Recompute the corresponding part of the cache when addObserverMethod 
 is called (seems preferable).

 OpenWebBeans doesn't have this issue as their NotificationManager will 
 simply add the new ObserverMethod to a ConcurrentHashMap that is also 
 accessed when an event is fired.

 What do you think? Can this already be done or is there another 
 solution?

 Cheers,
 Christian







 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https

Re: [weld-dev] AfterBeanDiscovery and observer resolver cache

[Martin Kouba]

Hi Christian,

actually invoking any container lifecycle event method after the
container initialization finished should have no effect. ABD event
reference can escape but it does not mean you can invoke ABD.addBean()
after ADV is fired.

The spec wording is not very explicit here:
During the application initialization process, the container fires a
series of events, allowing portable extensions to integrate with
the container initialization process defined in Section 12.2.

Maybe we should file a new spec issue to clarify that such invocations
should result in IllegalStateException...

Martin


Dne 4.3.2014 17:42, Christian Sadilek napsal(a):
 Hi Jozef,
 
 I think clearing the cache at the end of the Weld bootstrap process is not 
 enough to solve that particular problem since a CDI extension can hold on to 
 the ABD reference and invoke addObserverMethod later (multiple times) which 
 causes the same problem I described below. There's no indication to the 
 caller of addObserverMethod that it's in fact too late to call that method.
 
 Since an ABD event reference can always escape (can be used outside the 
 method that observes it) it seems this issue should be resolved (although it 
 admittedly is an edge case).
 
 Cheers,
 Christian
 
 On 2014-03-04, at 11:29 AM, Jozef Hartinger jhart...@redhat.com wrote:
 
 Hi Christian,

 this sounds like a bug. All the resolution caches should be cleared at the 
 very end of Weld's bootstrap sequence (after ABD observers are called). (see 
 https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldStartup.java#L415)

 Jozef

 On 03/04/2014 04:36 PM, Christian Sadilek wrote:
 Hi everyone,

 CDI extensions can observe the AfterBeanDiscovery event to register 
 observer methods (addObserverMethod). However, when an event is first 
 fired, the observers for that event are resolved and then cached (in 
 TypeSafeResolver). All future calls to addObserverMethod for an already 
 fired event with corresponding qualifiers will have no effect because the 
 observer result is read from cache and not recomputed.

 From an API perspective that's unfortunate because addObserverMethod will 
 only work until an event (with corresponding qualifiers) is fired and 
 there is no indication to the caller of that method that it didn't have 
 any effect when invoked after that.

 Possible solutions:

 - Provide some public API to clear/recompute that part the observer cache. 
 Maybe that exists? I couldn't find it which is why I am using the private 
 API and Reflection :(. Also let AfterBeanDiscovery.addObserverMethod fail 
 in that case with the advice to reset the cache.

 - Recompute the corresponding part of the cache when addObserverMethod is 
 called (seems preferable).

 OpenWebBeans doesn't have this issue as their NotificationManager will 
 simply add the new ObserverMethod to a ConcurrentHashMap that is also 
 accessed when an event is fired.

 What do you think? Can this already be done or is there another solution?

 Cheers,
 Christian







 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev

 
 
 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev
 
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] @WithAnnotations bug?

[Martin Kouba]

Hi Kristoffer,

the javadoc is wrong, CDI should follow JSL rules here - i.e. only if
@Inherited meta-annotation is present the annotation is inherited and
the type is observed. @Path has not @Inherited defined. Therefore only
resources with this annotation will be observed.

See also:
https://issues.jboss.org/browse/CDI-318
(will be fixed in CDI 1.2 MR)

Martin

Dne 28.1.2014 11:14, Kristoffer Sjögren napsal(a):
 Hi
 
 Extensions that observe using @WithAnnotations are not notified with
 implementing classes for annotated interfaces. 
 
 Not sure if this is intended - the javadoc seems pretty clear on that
 the following example should work.
 
 @Path(/service)
 public interface Service {
   @POST
   public void execute();
 }
 
 public ServiceEndpoint implements Service {
public void execute() { ... }
 }
 
 public class JaxrsExtension implements Extension {
 
 X void storeJaxrsResourceClasses(@Observes
 @WithAnnotations({Path.class, Provider.class}) ProcessAnnotatedTypeX
 pat) {
 AnnotatedTypeX type = pat.getAnnotatedType();
 if (!type.getJavaClass().isInterface()) {
// want to manage the ServiceEndpoint here
 }
   }
 }
 
 Cheers,
 -Kristoffer
 
 
 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev
 
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] CDI and @Singleton

[Martin Kouba]

Antoine, I think the Weld 2.x behaviour is correct per the spec.
GlobalRepositoryImpl is not a passivation capable dependency (@Singleton
is not a normal scope)...

M

Dne 22.11.2013 11:54, Antoine Sabot-Durand napsal(a):
 In my experience, Weld 1.1.x supported @Singleton,
 Weld 2.x don’t support them (or not in same way).
 
 In Agorava roadmap I plan to provide implementation on other JSR 330 
 framework than CDI, so I have a module containing only JSR 330 compliant 
 code. In this module I defined a Bean « GlobalRespository » with @Singleton 
 scope. In my CDI module this bean is injected in a SessionScoped bean 
 (inCookieProducer). Under Jboss AS 7.1.1, Glassfish 3.1.2 and EAP 6.1 the 
 code works nicely.
 With Wildfly 8 and Glassfish 4.0, I have this exception when my web app start 
 :
 
 Caused by: org.jboss.weld.exceptions.UnserializableDependencyException: 
 WELD-001413: The bean Managed Bean [class org.agorava.cdi.InCookieProducer] 
 with qualifiers [@Any @Default] declares passivating scope but has 
 non-passivation-capable dependency Managed Bean [class 
 org.agorava.oauth.GlobalRepositoryImpl] with qualifiers [@Any @Default]
   at 
 org.jboss.weld.bootstrap.Validator.validateInjectionPointPassivationCapable(Validator.java:461)
   at 
 org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:386)
   at 
 org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)
   at 
 org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)
   at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
   at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)
   at 
 org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
   at 
 org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
   at 
 org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
   at 
 org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
   at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 [rt.jar:1.7.0_45]
   ... 3 more
 As a workaround I had to create a @Specialize bean of my @Singleton only to 
 set it in @ApplicationScope.
 
 Antoine Sabot-Durand /@antoine_sd
 ———
 CDI co-spec lead
 CDI eco-system development
 Agorava tech lead
 
 
 Le 22 nov. 2013 à 09:24, Jozef Hartinger jhart...@redhat.com a écrit :
 
 Weld supports it but because of the reasons stated by Mark I would 
 recommend avoiding it.

 On 11/22/2013 08:19 AM, Mark Struberg wrote:
 Hi Bill!

 This pops up quite often.
 Actually the spec is pretty much silent on this and defines nothing else 
 than CDI being based on JSR-330. But the TCK defines that any JSR-299 
 container also must fully pass the JSR-330 TCK as part of the compatibility 
 check.

 Means CDI containers need to support it, but it is not really defined how 
 it should behave.
 In OWB we just treat it as alias for @ApplicationScoped. I'm not 100% sure 
 if it's the same for Weld, but I think to remember discussing about it with 
 either Jozef or Pete that they do it effectively the same way. Needs ack 
 from them though.

 My personal suggestion is to avoid it.

 There is a slightly broader issue hidden in this topic actually.
 As per explanation above, each CDI container must also support scopes 
 annotated with @Scope (from atinject, not @NormalScope from CDI). But 
 atinject does nowhere define how to register Contexts for those scopes. In 
 CDI we should do pickup contexts for those scopes but it's probably not 
 well tested nor defined how those contexts should behave.
 I'd personally would expect them to just get injected without the 
 Contextual Reference proxies but as direct Contextual Instances and 
 otherwise be pretty much the same like standard CDI scopes. But that needs 
 ack + wordig by my fellow CDI EG members.


 LieGrue,
 strub



 - Original Message -
 From: Bill Burke bbu...@redhat.com
 To: Weld weld-dev@lists.jboss.org
 Cc:
 Sent: Friday, 22 November 2013, 3:17
 Subject: [weld-dev] CDI and @Singleton

 Is Weld or CDI supposed to recognize and support @javax.inject.Singleton
 annotated classes?

 -- 
 Bill Burke
 JBoss, a division of Red Hat
 http://bill.burkecentral.com
 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev

 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev

 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev
 
 
 
 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev
 

Re: [weld-dev] CDI and @Singleton

[Martin Kouba]

Dne 22.11.2013 15:37, Antoine Sabot-Durand napsal(a):
 I don’t totally agree on your point Martin : @Dependent scope is not a normal 
 scope as well but I can inject a dependent scope bean in a normal scope bean.

Yep, but it must be passivation capable - this is explicitly written in
the spec, 6.6.3 in CDI 1.1 and 6.6.2 in CDI 1.0.

 
 I don’t say it’s a bug since the spec seems to be a bit blur on the subject.

Yes, it's complicated.

 
 I wanted just to stress that 
 
 1. Singleton don’t behave like Application Scope as it was evoked in this 
 thread
 2. Weld behavior changed from version 1 to 2

I agree.

 3. Singleton is now, nearly useless since I can’t make it interact with other 
 scope. and if something can’t be used can we say we implemented it ;) ?

IMHO javax.inject.Singleton was never useful (in connection with CDI)
because it's behaviour/lifecycle is not defined...

 
 Antoine
 
 
 Le 22 nov. 2013 à 12:53, Martin Kouba mko...@redhat.com a écrit :
 
 Antoine, I think the Weld 2.x behaviour is correct per the spec.
 GlobalRepositoryImpl is not a passivation capable dependency (@Singleton
 is not a normal scope)...

 M

 Dne 22.11.2013 11:54, Antoine Sabot-Durand napsal(a):
 In my experience, Weld 1.1.x supported @Singleton,
 Weld 2.x don’t support them (or not in same way).

 In Agorava roadmap I plan to provide implementation on other JSR 330 
 framework than CDI, so I have a module containing only JSR 330 compliant 
 code. In this module I defined a Bean « GlobalRespository » with @Singleton 
 scope. In my CDI module this bean is injected in a SessionScoped bean 
 (inCookieProducer). Under Jboss AS 7.1.1, Glassfish 3.1.2 and EAP 6.1 the 
 code works nicely.
 With Wildfly 8 and Glassfish 4.0, I have this exception when my web app 
 start :

 Caused by: org.jboss.weld.exceptions.UnserializableDependencyException: 
 WELD-001413: The bean Managed Bean [class org.agorava.cdi.InCookieProducer] 
 with qualifiers [@Any @Default] declares passivating scope but has 
 non-passivation-capable dependency Managed Bean [class 
 org.agorava.oauth.GlobalRepositoryImpl] with qualifiers [@Any @Default]
 at 
 org.jboss.weld.bootstrap.Validator.validateInjectionPointPassivationCapable(Validator.java:461)
 at 
 org.jboss.weld.bootstrap.Validator.validateInjectionPointForDeploymentProblems(Validator.java:386)
 at 
 org.jboss.weld.bootstrap.Validator.validateInjectionPoint(Validator.java:282)
 at 
 org.jboss.weld.bootstrap.Validator.validateGeneralBean(Validator.java:133)
 at org.jboss.weld.bootstrap.Validator.validateRIBean(Validator.java:164)
 at org.jboss.weld.bootstrap.Validator.validateBean(Validator.java:507)
 at 
 org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:68)
 at 
 org.jboss.weld.bootstrap.ConcurrentValidator$1.doWork(ConcurrentValidator.java:66)
 at 
 org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
 at 
 org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
 at java.util.concurrent.FutureTask.run(FutureTask.java:262) 
 [rt.jar:1.7.0_45]
 ... 3 more
 As a workaround I had to create a @Specialize bean of my @Singleton only to 
 set it in @ApplicationScope.

 Antoine Sabot-Durand /@antoine_sd
 ———
 CDI co-spec lead
 CDI eco-system development
 Agorava tech lead


 Le 22 nov. 2013 à 09:24, Jozef Hartinger jhart...@redhat.com a écrit :

 Weld supports it but because of the reasons stated by Mark I would 
 recommend avoiding it.

 On 11/22/2013 08:19 AM, Mark Struberg wrote:
 Hi Bill!

 This pops up quite often.
 Actually the spec is pretty much silent on this and defines nothing else 
 than CDI being based on JSR-330. But the TCK defines that any JSR-299 
 container also must fully pass the JSR-330 TCK as part of the 
 compatibility check.

 Means CDI containers need to support it, but it is not really defined how 
 it should behave.
 In OWB we just treat it as alias for @ApplicationScoped. I'm not 100% 
 sure if it's the same for Weld, but I think to remember discussing about 
 it with either Jozef or Pete that they do it effectively the same way. 
 Needs ack from them though.

 My personal suggestion is to avoid it.

 There is a slightly broader issue hidden in this topic actually.
 As per explanation above, each CDI container must also support scopes 
 annotated with @Scope (from atinject, not @NormalScope from CDI). But 
 atinject does nowhere define how to register Contexts for those scopes. 
 In CDI we should do pickup contexts for those scopes but it's probably 
 not well tested nor defined how those contexts should behave.
 I'd personally would expect them to just get injected without the 
 Contextual Reference proxies but as direct Contextual Instances and 
 otherwise be pretty much the same like standard CDI scopes. But that 
 needs ack + wordig by my fellow CDI EG members.


 LieGrue,
 strub



 - Original Message

Re: [weld-dev] PostConstruct PreDestroy in Java SE

[Martin Kouba]

FYI:
https://issues.jboss.org/browse/WELD-1504

Martin

Dne 9.9.2013 19:20, Pete Muir napsal(a):
 Agree with Mark entirely. There is no reason for Weld not support this AFAIK. 
 I think we agreed informally in CDI 1.1 that @Singleton is essentially 
 identical to @ApplicationScoped in behaviour.
 
 On 7 Sep 2013, at 18:22, Mark Struberg strub...@yahoo.de wrote:
 
 The wording is not correct.

 Each JSR-299 Container must _fully_ implement the JSR-330 specification and 
 pass the JSR-330 TCK. Thus each CDI Container MUST support 
 javax.inject.Singleton. But it's actually not really defined in detail how 
 this scope should behave. And the atinject and EE specs also define that 
 @PostConstruct and @PreDestroy must work for @Singleton beans. So this is 
 imo a bug. But otoh I personally would suggest to not use 
 javax.inject.Singleton because of the aforementioned underspecified 
 behaviout.

 LieGrue,
 strub




 - Original Message -
 From: Martin Kouba mko...@redhat.com
 To: Kristoffer Sjögren sto...@gmail.com
 Cc: weld-dev@lists.jboss.org
 Sent: Friday, 6 September 2013, 14:31
 Subject: Re: [weld-dev] PostConstruct  PreDestroy in Java SE

 Actually there's no singleton scope and corresponding built-in context
 defined in the CDI spec. Though Weld API contains
 org.jboss.weld.context.SingletonContext. Also the docs are outdated
 (chapter 5.4. The singleton pseudo-scope). I think relevant classes
 should be deprecated and the docs updated.

 With regard to lifecycle callbacks - Weld only invalidates application
 context during shutdown right now [1].

 Martin

 [1]
 https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bootstrap/WeldRuntime.java#L56

 Dne 6.9.2013 14:09, Kristoffer Sjögren napsal(a):
 Hi

 We're running Weld 2.0.3.Final in a Java SE environment and have
 encountered a precarious situation where it seems like Weld is not
 consistent in handling the lifecycle of singleton beans.

 We have singleton beans with @PostConstruct and @PreDestroy methods.
 During Weld.initialize() all @PostConstruct methods are called. But
 during @PreDestroy methods are never called during Weld.shutdown().
 @PreDestroy is only called on beans which are @ApplicationScoped.

 Is this according to specification or a bug?

 Cheers,
 -Kristoffer


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev
 
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

Re: [weld-dev] CDI TCK on GitHub

[Martin Kouba]

I added basic README that points to TCK Reference Guide - check it out.

Martin

Dne 28.7.2011 21:56, Jason Porter napsal(a):

Done https://issues.jboss.org/browse/CDITCK-227

On Thu, Jul 28, 2011 at 13:45, Dan Allen dan.j.al...@gmail.com 
mailto:dan.j.al...@gmail.com wrote:


Right, my intention was to link to them from the readme, nothing
more complicated than that.

- Dan Allen

Sent from my Android-powered phone:
An open platform for carriers, consumers and developers

On Jul 28, 2011 7:59 AM, Pete Muir pm...@redhat.com
mailto:pm...@redhat.com wrote:
 Suggest you file a CDITCK issue in JIRA.

 We already have extensive docs on the TCK, so we can just link
to them.

 On 28 Jul 2011, at 15:50, Jason Porter wrote:

 Right. I knew that. What you suggested Pete would be fine, just
something the person who comes across it on GitHub or wants to add
a test can read and quickly understand what it is and how to
contribute.

 Sent from my iPhone

 On Jul 28, 2011, at 3:39, Pete Muir pm...@redhat.com
mailto:pm...@redhat.com wrote:

 Not quite. What you are looking at here is a development view,
not the released zip, which contains a readme and the license
file. What would be useful would a quick readme pointing people to
do the docs so if they do stumble on this they can get a link.

 On 27 Jul 2011, at 23:04, Jason Porter wrote:

 Shouldn't it include a README (at least) and a LICENSE file
so people know how to use it and can use it?

 On Wed, Jul 27, 2011 at 15:52, Dan Allen
dan.j.al...@gmail.com mailto:dan.j.al...@gmail.com wrote:
 Awesome work, and great timing (since I was just telling
people here at #oscon that it's on github)!

 - Dan Allen

 Sent from my Android-powered phone:
 An open platform for carriers, consumers and developers

 On Jul 27, 2011 5:57 AM, Martin Kouba mko...@redhat.com
mailto:mko...@redhat.com wrote:
 Hi,
 CDI TCK project moved to GitHub - see
https://github.com/jboss/cditck.
 FishEye and JIRA (https://issues.jboss.org/browse/CDITCK)
configurations
 arealready changed. Since this was the last Weld subproject
to migrate
 from svn, Weld svn repo will be made readonly - see ticket

https://engineering.redhat.com/rt3/Ticket/Display.html?id=117363. QA
 Jenkins jobs are not updated yet.

 If anyone encounters problems related to this migration,
please let me know.

 Martin

 --
 Martin Kouba
 JBoss Quality Assurance Engineer
 E-mail: mko...@redhat.com mailto:mko...@redhat.com
 Web: www.cz.redhat.com http://www.cz.redhat.com
 Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech
Republic


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org mailto:weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev



 --
 Jason Porter
 http://lightguard-jp.blogspot.com
 http://twitter.com/lightguardjp

 Software Engineer
 Open Source Advocate
 Author of Seam Catch - Next Generation Java Exception Handling

 PGP key id: 926CCFF5
 PGP key available at: keyserver.net http://keyserver.net,
pgp.mit.edu http://pgp.mit.edu
 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org mailto:weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org mailto:weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev


 ___
 weld-dev mailing list
 weld-dev@lists.jboss.org mailto:weld-dev@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/weld-dev




--
Jason Porter
http://lightguard-jp.blogspot.com
http://twitter.com/lightguardjp

Software Engineer
Open Source Advocate
Author of Seam Catch - Next Generation Java Exception Handling

PGP key id: 926CCFF5
PGP key available at: keyserver.net http://keyserver.net, 
pgp.mit.edu http://pgp.mit.edu



___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev
___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev

[weld-dev] CDI TCK on GitHub

[Martin Kouba]

Hi,
CDI TCK project moved to GitHub - see https://github.com/jboss/cditck. 
FishEye and JIRA (https://issues.jboss.org/browse/CDITCK) configurations 
arealready changed. Since this was the last Weld subproject to migrate 
from svn, Weld svn repo will be made readonly - see ticket 
https://engineering.redhat.com/rt3/Ticket/Display.html?id=117363. QA 
Jenkins jobs are not updated yet.


If anyone encounters problems related to this migration, please let me know.

Martin

--
Martin Kouba
JBoss Quality Assurance Engineer
E-mail: mko...@redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic

___
weld-dev mailing list
weld-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/weld-dev