From ljnelson at gmail.com Thu Nov 1 17:46:58 2018 From: ljnelson at gmail.com (Laird Nelson) Date: Thu, 1 Nov 2018 14:46:58 -0700 Subject: [weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why? Message-ID: I noticed that BeanManagerImpl permits many Contexts to be indexed under a given scope type . Why is that? The CDI 2.0 specification says : "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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20181101/ea4c6a22/attachment.html From mkouba at redhat.com Fri Nov 2 04:25:57 2018 From: mkouba at redhat.com (Martin Kouba) Date: Fri, 2 Nov 2018 09:25:57 +0100 Subject: [weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why? In-Reply-To: References: Message-ID: 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 > . > Why is that? > > The CDI 2.0 specification says > : > > "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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From ljnelson at gmail.com Fri Nov 2 17:07:07 2018 From: ljnelson at gmail.com (Laird Nelson) Date: Fri, 2 Nov 2018 14:07:07 -0700 Subject: [weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why? In-Reply-To: References: Message-ID: On Fri, Nov 2, 2018 at 1:25 AM Martin Kouba wrote: > 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." > Not so sure about the "very clear" part :-) but yes, you can read it this way and clearly that's the intent so that's good enough for me! Follow-up question: a Context's "activeness" is defined per-thread (section 6.2 ): "At a particular point in the execution of the program a context object may be active with respect to the current thread." So when I ask the BeanManager for the (singular) Context-that-is-active-with-respect-to-the-current-thread by giving it a scope annotation, I get back a Context whose isActive() method returned true at some point during the implementation of the BeanManager#getContext(Class) method . And certainly I'd hope that once I receive this Context its isActive() method would return true. But this is just a "best effort" area of the specification, right? Consider a (hypothetical, thought-experiment) stupid Context that tracks whether it's active or not for a given Thread (using a Map of Threads-to- booleans or something similar). Then pretend solely for discussion purposes that it has a daemon Thread in it that randomly and periodically sets its activeness to true or false for a given Thread. So sometimes a caller of its isActive() method gets true back, and sometimes it gets false based on the random activeness-toggling actions of the internal daemon thread. Again, this is a thought experiment, not proposed or useful code. :-) All the BeanManager can do in this (stupid but legal?) case is make a *best effort*: at the time it selects the Context for returning from its getContext(Class) method, the Context must have returned true from its isActive() method (otherwise it would not be a candidate for returning), but the caller of BeanManager#getContext(Class) receiving this stupid Context may invoke isActive() and discover that suddenly it is returning false because of the actions of its stupid embedded daemon thread. Is this thought-experiment scenario correct and permitted by the laws of the specification? Another way to ask this: is the following statement true or false? I believe it is true: There is no requirement that the activeness of a BeanManager-vended Context be immutable with respect to the calling thread. (It seems this statement must be true or the fact that a Context can throw ContextNotActiveException from its methods would seemingly make no sense.) I'm just trying to understand this area very deeply, particularly with respect to threading. Thanks as always for your time. Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20181102/d794849a/attachment.html From mkouba at redhat.com Mon Nov 5 03:28:56 2018 From: mkouba at redhat.com (Martin Kouba) Date: Mon, 5 Nov 2018 09:28:56 +0100 Subject: [weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why? In-Reply-To: References: Message-ID: Dne 02. 11. 18 v 22:07 Laird Nelson napsal(a): > On Fri, Nov 2, 2018 at 1:25 AM Martin Kouba > wrote: > > 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." > > > Not so sure about the "very clear" part :-) but yes, you can read it > this way and clearly that's the intent so that's good enough for me! > > Follow-up question: a Context's "activeness" is defined per-thread > (section 6.2 ): > > "At a particular point in the execution of the program a context object > may be active with respect to the current thread." > > So when I ask the BeanManager for the (singular) > Context-that-is-active-with-respect-to-the-current-thread by giving it a > scope annotation, I get back a Context whose isActive() method returned > true at some point during the implementation of the > BeanManager#getContext(Class) method > . > And certainly I'd hope that once I receive this Context its isActive() > method would return true. > > But this is just a "best effort" area of the specification, right? Yes. It cannot be guaranteed, ie. it always depends on the context implementation. > > Consider a (hypothetical, thought-experiment) stupid Context that tracks > whether it's active or not for a given Thread (using a Map of > Threads-to-booleans or something similar).? Then pretend solely for > discussion purposes that it has a daemon Thread in it that randomly and > periodically sets its activeness to true or false for a given Thread. > So sometimes a caller of its isActive() method gets true back, and > sometimes it gets false?based on the random activeness-toggling actions > of the internal daemon thread.? Again, this is a thought experiment, not > proposed or useful code.? :-) > > All the BeanManager can do in this (stupid but legal?) case is make a > /best effort/: at the time it selects the Context for returning from its > getContext(Class) method, the Context?must have returned true from its > isActive() method (otherwise it would not be a candidate for returning), > but the caller of BeanManager#getContext(Class) receiving this stupid > Context may?invoke isActive() and discover that suddenly it is returning > false?because of the actions of its stupid embedded daemon thread.? Is > this thought-experiment scenario correct and permitted by the laws of > the specification? > > Another way to ask this: is the following statement true or false?? I > believe it is true: > > ? ? There is no requirement that the activeness of a BeanManager-vended > Context be immutable with respect to the calling thread. True. The state of the context can change at any time. > > (It seems this statement must be true or the fact that a Context can > throw ContextNotActiveException from its methods would seemingly make no > sense.) > > I'm just trying to understand this area very deeply, particularly with > respect to threading.? Thanks as always for your time. > > Best, > Laird -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From manovotn at redhat.com Mon Nov 5 04:15:12 2018 From: manovotn at redhat.com (Matej Novotny) Date: Mon, 5 Nov 2018 04:15:12 -0500 (EST) Subject: [weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why? In-Reply-To: References: Message-ID: <1063779038.30327399.1541409312481.JavaMail.zimbra@redhat.com> Hi Laird, I just wonder, what is it you are ultimately trying to achieve with contexts since you are diving this deep? That is, if it's not classified ;) Comments inline... M ----- Original Message ----- > From: "Laird Nelson" > To: "Martin Kouba" > Cc: weld-dev at lists.jboss.org > Sent: Friday, November 2, 2018 10:07:07 PM > Subject: Re: [weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why? > > On Fri, Nov 2, 2018 at 1:25 AM Martin Kouba < mkouba at redhat.com > wrote: > > > 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." > > Not so sure about the "very clear" part :-) but yes, you can read it this way > and clearly that's the intent so that's good enough for me! > > Follow-up question: a Context 's "activeness" is defined per-thread ( section > 6.2 ): > > "At a particular point in the execution of the program a context object may > be active with respect to the current thread." > > So when I ask the BeanManager for the (singular) Context > -that-is-active-with-respect-to-the-current-thread by giving it a scope > annotation, I get back a Context whose isActive() method returned true at > some point during the implementation of the BeanManager#getContext(Class) > method . And certainly I'd hope that once I receive this Context its > isActive() method would return true . > > But this is just a "best effort" area of the specification, right? I would say it is defined well, but yes, it behaves pretty much like you say. Take for instance session scope (and its context). While you query the context, it may well be active, but right after that, there could be session timeout and that obviously kills the context as well. It is not something you can control, but you need to account for that. Contexts have quite well defined lifecycle in a way that you know when they are supposed to be active and what ends them (request, session, conversation, your custom scope...). > > Consider a (hypothetical, thought-experiment) stupid Context that tracks > whether it's active or not for a given Thread (using a Map of Thread s-to- > boolean s or something similar). Then pretend solely for discussion purposes > that it has a daemon Thread in it that randomly and periodically sets its > activeness to true or false for a given Thread . So sometimes a caller of > its isActive() method gets true back, and sometimes it gets false based on > the random activeness-toggling actions of the internal daemon thread. Again, > this is a thought experiment, not proposed or useful code. :-) > > All the BeanManager can do in this (stupid but legal?) case is make a best > effort : at the time it selects the Context for returning from its > getContext(Class) method, the Context must have returned true from its > isActive() method (otherwise it would not be a candidate for returning), but > the caller of BeanManager#getContext(Class) receiving this stupid Context > may invoke isActive() and discover that suddenly it is returning false > because of the actions of its stupid embedded daemon thread. Is this > thought-experiment scenario correct and permitted by the laws of the > specification? > > Another way to ask this: is the following statement true or false? I believe > it is true: > > There is no requirement that the activeness of a BeanManager -vended Context > be immutable with respect to the calling thread. If I understand you correctly, then yes, this is true. If you retrieve an active context and store it for later use, by the time you reach for it, it may no longer be active. For instance request context in SE can be activated on a per-method scope by annotation (interceptor in fact). In such case you may get to activate/deactivate request context many time over in a single thread. Hence retrieving the context within the method which activates it will work, but using it right after you exit that method will fail. The immutability of context activeness wouldn't make sense at all. > > (It seems this statement must be true or the fact that a Context can throw > ContextNotActiveException from its methods would seemingly make no sense.) > > I'm just trying to understand this area very deeply, particularly with > respect to threading. Thanks as always for your time. > > Best, > Laird > > _______________________________________________ > weld-dev mailing list > weld-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev From ljnelson at gmail.com Mon Nov 5 11:52:20 2018 From: ljnelson at gmail.com (Laird Nelson) Date: Mon, 5 Nov 2018 08:52:20 -0800 Subject: [weld-dev] BeanManagerImpl permits multiple Contexts per scope type: why? In-Reply-To: <1063779038.30327399.1541409312481.JavaMail.zimbra@redhat.com> References: <1063779038.30327399.1541409312481.JavaMail.zimbra@redhat.com> Message-ID: On Mon, Nov 5, 2018 at 1:15 AM Matej Novotny wrote: > I just wonder, what is it you are ultimately trying to achieve with > contexts since you are diving this deep? > That is, if it's not classified ;) > Ha! No, not classified. I am a big proponent of CDI and I like to fully understand everything I work with. I was just suddenly struck by the slight awkwardness of this particular API, that's all. :-) > If you retrieve an active context and store it for later use, by the time > you reach for it, it may no longer be active. > Yes, or even by the time you receive the Context "back" from the BeanManager#getContext(Class) call itself! In other words, the API can't really guarantee that it can honor its own contract! Thanks for your time as always. Best, Laird -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20181105/81a8f9f2/attachment.html From BENJAMIC at uk.ibm.com Tue Nov 20 03:42:14 2018 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Tue, 20 Nov 2018 08:42:14 +0000 Subject: [weld-dev] PROBE-000014 - Caused by ClassNotFoundException: int Message-ID: Hello I found a PROBE-000014 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-000014: 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-000014: Cannot register a Probe MBean interface org.jboss.weld.probe.JsonDataProvider for: cdi12helloworldtest at org.jboss.weld.probe.ProbeExtension.afterDeploymentValidation(ProbeExtension.java:176) 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:498) at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) at org.jboss.weld.injection.MethodInvocationStrategy$SpecialTheParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) at org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:277) at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:255) at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:269) at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:258) 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20181120/68a29ebc/attachment.html From mkouba at redhat.com Tue Nov 20 04:23:58 2018 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 20 Nov 2018 10:23:58 +0100 Subject: [weld-dev] PROBE-000014 - Caused by ClassNotFoundException: int In-Reply-To: References: Message-ID: <29c58e73-390d-f681-1775-1c9d9277909f@redhat.com> 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-000014 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-000014: 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-000014: Cannot register a Probe MBean interface > org.jboss.weld.probe.JsonDataProvider for: cdi12helloworldtest > ? ? ? ? at > org.jboss.weld.probe.ProbeExtension.afterDeploymentValidation(ProbeExtension.java:176) > > ? ? ? ? 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:498) > ? ? ? ? at > org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > > ? ? ? ? at > org.jboss.weld.injection.MethodInvocationStrategy$SpecialTheParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) > > ? ? ? ? at > org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > > ? ? ? ? at > org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) > > ? ? ? ? at > org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:277) > > ? ? ? ? at > org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:255) > ? ? ? ? at > org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:269) > > ? ? ? ? at > org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:258) > ? ? ? ? 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic From BENJAMIC at uk.ibm.com Tue Nov 20 05:33:56 2018 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Tue, 20 Nov 2018 10:33:56 +0000 Subject: [weld-dev] PROBE-000014 - Caused by ClassNotFoundException: int In-Reply-To: <29c58e73-390d-f681-1775-1c9d9277909f@redhat.com> References: <29c58e73-390d-f681-1775-1c9d9277909f@redhat.com> Message-ID: Hello Martin. I'll see if I can recreate the failure outside of our automated test environment. Regards Benjamin From: Martin Kouba To: Benjamin Confino , weld-dev at lists.jboss.org Date: 20/11/2018 09:25 Subject: Re: [weld-dev] PROBE-000014 - 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-000014 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-000014: 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-000014: Cannot register a Probe MBean interface > org.jboss.weld.probe.JsonDataProvider for: cdi12helloworldtest > at > org.jboss.weld.probe.ProbeExtension.afterDeploymentValidation(ProbeExtension.java:176) > > 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:498) > at > org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > > at > org.jboss.weld.injection.MethodInvocationStrategy$SpecialTheParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) > > at > org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > > at > org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) > > at > org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:277) > > at > org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:255) > at > org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:269) > > at > org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:258) > 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20181120/430b112c/attachment.html From BENJAMIC at uk.ibm.com Tue Nov 20 08:37:48 2018 From: BENJAMIC at uk.ibm.com (Benjamin Confino) Date: Tue, 20 Nov 2018 13:37:48 +0000 Subject: [weld-dev] PROBE-000014 - Caused by ClassNotFoundException: int In-Reply-To: <29c58e73-390d-f681-1775-1c9d9277909f@redhat.com> References: <29c58e73-390d-f681-1775-1c9d9277909f@redhat.com> Message-ID: 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 at lists.jboss.org Date: 20/11/2018 09:25 Subject: Re: [weld-dev] PROBE-000014 - 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-000014 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-000014: 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-000014: Cannot register a Probe MBean interface > org.jboss.weld.probe.JsonDataProvider for: cdi12helloworldtest > at > org.jboss.weld.probe.ProbeExtension.afterDeploymentValidation(ProbeExtension.java:176) > > 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:498) > at > org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > > at > org.jboss.weld.injection.MethodInvocationStrategy$SpecialTheParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) > > at > org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > > at > org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) > > at > org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:277) > > at > org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:255) > at > org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:269) > > at > org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:258) > 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 at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/weld-dev > -- Martin Kouba Senior Software Engineer Red Hat, Czech Republic Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/weld-dev/attachments/20181120/01548732/attachment-0001.html From mkouba at redhat.com Tue Nov 20 08:38:50 2018 From: mkouba at redhat.com (Martin Kouba) Date: Tue, 20 Nov 2018 14:38:50 +0100 Subject: [weld-dev] PROBE-000014 - Caused by ClassNotFoundException: int In-Reply-To: References: <29c58e73-390d-f681-1775-1c9d9277909f@redhat.com> Message-ID: <36c88315-a5d9-d8c6-03f9-c01e826de5b9@redhat.com> 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 at lists.jboss.org > Date: 20/11/2018 09:25 > Subject: Re: [weld-dev] PROBE-000014 - 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-000014 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-000014: 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-000014: Cannot register a Probe MBean interface > > org.jboss.weld.probe.JsonDataProvider for: cdi12helloworldtest > > ?? ? ? ? at > > > org.jboss.weld.probe.ProbeExtension.afterDeploymentValidation(ProbeExtension.java:176) > > > > > ?? ? ? ? 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:498) > > ?? ? ? ? at > > > org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88) > > > > > ?? ? ? ? at > > > org.jboss.weld.injection.MethodInvocationStrategy$SpecialTheParamPlusBeanManagerStrategy.invoke(MethodInvocationStrategy.java:144) > > > > > ?? ? ? ? at > > > org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:299) > > > > > ?? ? ? ? at > > > org.jboss.weld.event.ExtensionObserverMethodImpl.sendEvent(ExtensionObserverMethodImpl.java:124) > > > > > ?? ? ? ? at > > > org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:277) > > > > > ?? ? ? ? at > > > org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:255) > > ?? ? ? ? at > > > org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:269) > > > > > ?? ? ? ? at > > org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:258) > > ?? ? ? ? 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 at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/weld-dev > > > > -- > Martin Kouba > Senior Software Engineer > Red Hat, Czech Republic > > > > > 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 From manovotn at redhat.com Wed Nov 28 02:24:12 2018 From: manovotn at redhat.com (Matej Novotny) Date: Wed, 28 Nov 2018 02:24:12 -0500 (EST) Subject: [weld-dev] CDI context propagation? Weld 3.1.0.Beta1 has something to say about that In-Reply-To: <831153131.36889745.1543389203505.JavaMail.zimbra@redhat.com> Message-ID: <1136924546.36891629.1543389852223.JavaMail.zimbra@redhat.com> Hello, Weld 3.1.0.Beta1 was released yesterday. Along with bunch of other fixes[1] and/or features, this release contains first API for CDI context propagation. Weld docs[2] contain more information on how to do that along with an example. If you have a use case for this, please give it a spin. The API is a first draft which was done with MP Concurrency needs in mind and probably won't cover all the cases. Which is precisely why we appreciate any feedback in this regard, we cannot cover use cases we don't know about :-) Regards Matej _____________________________________________________________________________________________ [1] https://issues.jboss.org/projects/WELD/versions/12338801 [2] http://docs.jboss.org/weld/reference/latest/en-US/html_single/#_propagating_built_in_contexts