[jira] [Commented] (DELTASPIKE-1348) Deltaspike is unusable with junit's @category
[
https://issues.apache.org/jira/browse/DELTASPIKE-1348?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16682042#comment-16682042
]
Falko Modler commented on DELTASPIKE-1348:
--
I guess this only happens with {{maven-failsafe-plugin}} in phase
{{integration-test}}, right?
I am asking this because I have been using {{CdiTestRunner}} with {{@Category}}
without any issues in phase {{test}} via {{maven-surefire-plugin}} for at least
3 years now.
> Deltaspike is unusable with junit's @category
> -
>
> Key: DELTASPIKE-1348
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1348
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.7.2
>Reporter: Lonzak
>Priority: Major
> Labels: category, cdi, junit, test
> Fix For: 1.9.1
>
>
> A while ago we separated our tests in standard junit- and integration tests
> using junit's category mechanism:
> ([https://dzone.com/articles/unit-and-integration-tests)|https://www.javaworld.com/article/2074569/core-java/unit-and-integration-tests-with-maven-and-junit-categories.html)]
>
> The goal: When maven 'package' is used, then all tests annotated with
> @category are skipped. When using 'install' they are executed. If in either
> build a junit test fails, the build fails.
> So now we switched to Deltaspike's CdiTestRunner. And now the above mechanism
> doesn't work anymore:
> # The integration tests are always executed ignoring the build phase
> (package, install...)
> # If the integration fails the build doesn't fail.
> We were using the "RunWith" before so I think it is not a junit problem. I
> did some research but only gradle seemed to had a similar problem
> ([https://github.com/gradle/gradle/issues/3189|https://github.com/gradle/gradle/pull/4321])
> Any ideas how to get it to work again?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (DELTASPIKE-1207) Incorrect exception handling in DynamicMBeanWrapper.invoke()
[
https://issues.apache.org/jira/browse/DELTASPIKE-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15591898#comment-15591898
]
Falko Modler commented on DELTASPIKE-1207:
--
I *successfully* tested my changes and here is a comparison before/after with
[Twiddle|https://github.com/swesource/twiddle-standalone] (Client) and JBoss
EAP 6.4.10:
{noformat:title=before, TestMBean throws IllegalStateException or
MBeanException (doesn't matter)}
10:16:49,676 INFO [xnio] XNIO Version 3.0.15.GA-redhat-1
10:16:49,698 INFO [nio] XNIO NIO Implementation Version 3.0.15.GA-redhat-1
10:16:50,309 INFO [remoting] JBoss Remoting version 3.3.8.Final-redhat-1
10:16:52,141 ERROR [Twiddle] Exec failed
java.io.IOException: Internal server error.
at
org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:164)
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)
{noformat}
{noformat:title=after, TestMBean throws IllegalStateException}
09:52:51,562 INFO [xnio] XNIO Version 3.0.15.GA-redhat-1
09:52:51,578 INFO [nio] XNIO NIO Implementation Version 3.0.15.GA-redhat-1
09:52:52,087 INFO [remoting] JBoss Remoting version 3.3.8.Final-redhat-1
09:52:56,107 ERROR [Twiddle] Exec failed
javax.management.MBeanException: throwIllegalStateException failed with
exception
at
org.apache.deltaspike.core.impl.jmx.DynamicMBeanWrapper.invoke(DynamicMBeanWrapper.java:409)
at
com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819)
at
com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801)
at
org.jboss.as.jmx.PluggableMBeanServerImpl$TcclMBeanServer.invoke(PluggableMBeanServerImpl.java:1417)
at
org.jboss.as.jmx.PluggableMBeanServerImpl.invoke(PluggableMBeanServerImpl.java:692)
at
org.jboss.as.jmx.BlockingNotificationMBeanServer.invoke(BlockingNotificationMBeanServer.java:168)
at
org.jboss.remotingjmx.protocol.v2.ServerProxy$InvokeHandler.handle(ServerProxy.java:952)
at
org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1$1.run(ServerCommon.java:153)
at
org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:75)
at
org.jboss.as.jmx.ServerInterceptorFactory$Interceptor$1.run(ServerInterceptorFactory.java:70)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:422)
at
org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:94)
at
org.jboss.as.jmx.ServerInterceptorFactory$Interceptor.handleEvent(ServerInterceptorFactory.java:70)
at
org.jboss.remotingjmx.protocol.v2.ServerCommon$MessageReciever$1.run(ServerCommon.java:149)
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.IllegalStateException: test throwIllegalStateException
at
some.project.middleware.service.common.TestMBean.throwIllegalStateException(TestMBean.java:43)
at
some.project.middleware.service.common.TestMBean$Proxy$_$$_WeldSubclass.throwIllegalStateException(TestMBean$Proxy$_$$_WeldSubclass.java)
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.interceptor.proxy.SimpleInterceptionChain.invokeNextInterceptor(SimpleInterceptionChain.java:85)
at
org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:127)
at
some.project.common.support.cdi.CDIRequestScopeInterceptor.intercept(CDIRequestScopeInterceptor.java:42)
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.interceptor.proxy.SimpleMethodInvocation.invoke(SimpleMethodInvocation.java:30)
at
org.jboss.weld.interceptor.proxy.SimpleInterceptionChain.invokeNextInterceptor(SimpleInterceptionChain.java:69)
at
org.jboss.weld.interceptor.proxy.InterceptorInvocationContext.proceed(InterceptorInvocationContext.java:127)
at
[jira] [Commented] (DELTASPIKE-1207) Incorrect exception handling in DynamicMBeanWrapper.invoke()
[
https://issues.apache.org/jira/browse/DELTASPIKE-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15580537#comment-15580537
]
Falko Modler commented on DELTASPIKE-1207:
--
Thanks, I resolved the issues you mentioned.
https://github.com/apache/deltaspike/compare/master...famod:DELTASPIKE-1207
> Incorrect exception handling in DynamicMBeanWrapper.invoke()
>
>
> Key: DELTASPIKE-1207
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1207
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.7.1
>Reporter: Falko Modler
>
> {{DynamicMBeanWrapper.invoke(String, Object[], String[])}} just re-throws any
> exception as a {{RuntimeException}}.
> This makes it impossible for a client to determine the specific exception
> which might have been thrown on purpose by the MBean method. See also:
> {code:java|title=JavaDoc of javax.management.DynamicMBean.invoke(String,
> Object[], String[])}
> ...
> * @exception MBeanException Wraps a java.lang.Exception
> thrown by the MBean's invoked method.
> * @exception ReflectionException Wraps a
> java.lang.Exception thrown while trying to invoke the method
> */
> public Object invoke(String actionName, Object params[], String
> signature[])
> throws MBeanException, ReflectionException ;
> {code}
> So the correct approach is to handle {{InvocationTargetException}}
> specifically by wrapping it's *cause* in a {{MBeanException}} and throwing
> that {{MBeanException}}.
> All other exceptions should be wrapped in a {{ReflectionException}}.
> PS: I filed DELTASPIKE-984 some time ago which led to a slight improvement of
> the very same {{invoke}} method but obviously my suggestions regarding
> {{MBeanException}} haven't been considered (I don't know why).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1207) Incorrect exception handling in DynamicMBeanWrapper.invoke()
[
https://issues.apache.org/jira/browse/DELTASPIKE-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15578892#comment-15578892
]
Falko Modler commented on DELTASPIKE-1207:
--
I'll try to come up with a pull request next week.
> Incorrect exception handling in DynamicMBeanWrapper.invoke()
>
>
> Key: DELTASPIKE-1207
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1207
> Project: DeltaSpike
> Issue Type: Bug
> Components: Core
>Affects Versions: 1.7.1
>Reporter: Falko Modler
>
> {{DynamicMBeanWrapper.invoke(String, Object[], String[])}} just re-throws any
> exception as a {{RuntimeException}}.
> This makes it impossible for a client to determine the specific exception
> which might have been thrown on purpose by the MBean method. See also:
> {code:java|title=JavaDoc of javax.management.DynamicMBean.invoke(String,
> Object[], String[])}
> ...
> * @exception MBeanException Wraps a java.lang.Exception
> thrown by the MBean's invoked method.
> * @exception ReflectionException Wraps a
> java.lang.Exception thrown while trying to invoke the method
> */
> public Object invoke(String actionName, Object params[], String
> signature[])
> throws MBeanException, ReflectionException ;
> {code}
> So the correct approach is to handle {{InvocationTargetException}}
> specifically by wrapping it's *cause* in a {{MBeanException}} and throwing
> that {{MBeanException}}.
> All other exceptions should be wrapped in a {{ReflectionException}}.
> PS: I filed DELTASPIKE-984 some time ago which led to a slight improvement of
> the very same {{invoke}} method but obviously my suggestions regarding
> {{MBeanException}} haven't been considered (I don't know why).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1207) Incorrect exception handling in DynamicMBeanWrapper.invoke()
Falko Modler created DELTASPIKE-1207:
Summary: Incorrect exception handling in
DynamicMBeanWrapper.invoke()
Key: DELTASPIKE-1207
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1207
Project: DeltaSpike
Issue Type: Bug
Components: Core
Affects Versions: 1.7.1
Reporter: Falko Modler
{{DynamicMBeanWrapper.invoke(String, Object[], String[])}} just re-throws any
exception as a {{RuntimeException}}.
This makes it impossible for a client to determine the specific exception which
might have been thrown on purpose by the MBean method. See also:
{code:java|title=JavaDoc of javax.management.DynamicMBean.invoke(String,
Object[], String[])}
...
* @exception MBeanException Wraps a java.lang.Exception
thrown by the MBean's invoked method.
* @exception ReflectionException Wraps a java.lang.Exception
thrown while trying to invoke the method
*/
public Object invoke(String actionName, Object params[], String signature[])
throws MBeanException, ReflectionException ;
{code}
So the correct approach is to handle {{InvocationTargetException}} specifically
by wrapping it's *cause* in a {{MBeanException}} and throwing that
{{MBeanException}}.
All other exceptions should be wrapped in a {{ReflectionException}}.
PS: I filed DELTASPIKE-984 some time ago which led to a slight improvement of
the very same {{invoke}} method but obviously my suggestions regarding
{{MBeanException}} haven't been considered (I don't know why).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1116) allow conditional injection-point customization in test-classes
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15306322#comment-15306322
]
Falko Modler commented on DELTASPIKE-1116:
--
[~gpetracek]: Works as expected, thanks!
> allow conditional injection-point customization in test-classes
> ---
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Improvement
> Components: TestControl
>Affects Versions: 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Fix For: 1.6.1
>
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-707) AbstractMockManager does not support interfaces mocked by mockito
[
https://issues.apache.org/jira/browse/DELTASPIKE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228063#comment-15228063
]
Falko Modler commented on DELTASPIKE-707:
-
I have a suggestion for an alternative/extended {{AbstractMockManager}}
implementation that fixes this problem.
Do I have to start a discussion in the mailing list and push a discussion
branch first or can I just put it here?
> AbstractMockManager does not support interfaces mocked by mockito
> -
>
> Key: DELTASPIKE-707
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-707
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2
> Environment: Mockito 1.9.5
> JDK 1.7u51
>Reporter: Falko Modler
>
> Following the
> [manual|https://deltaspike.apache.org/test-control.html#mock-frameworks], I
> tried to mock {{EntitityManager}} in my test class:
> {noformat}
> @RunWith(CdiTestRunner.class)
> public class SomeTest {
> @Inject
> private DynamicMockManager mockManager;
> @Test
> public void mockitoMockAsCdiBean() {
> mockManager.addMock(Mockito.mock(EntityManager.class));
> [...]
> }
> }
> {noformat}
> Unfortunately this doesn't work as {{AbstractMockManager}} fails with:
> {noformat}
> java.lang.IllegalArgumentException:
> $javax.persistence.EntityManager$$EnhancerByMockitoWithCGLIB$$b065dd9c isn't
> a supported approach for mocking -> please extend from the original class.
> at
> org.apache.deltaspike.testcontrol.impl.mock.AbstractMockManager.addMock(AbstractMockManager.java:45)
> {noformat}
> Following (rather ugly) workaound fixes the problem:
> {noformat}
> @Typed(EntityManager.class)
> public static abstract class EntityManagerMockBase implements
> EntityManager {
> }
> {noformat}
> {noformat}
> mockManager.addMock(Mockito.mock(EntityManagerMockBase.class));
> {noformat}
> If this problem cannot be solved then the documentation should at least
> mention that mocking does not work for interfaces and how to work around that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228055#comment-15228055
]
Falko Modler commented on DELTASPIKE-1116:
--
{quote}
those fields shouldn't get changed manually
{quote}
Why not? While I understand that this isn't the default use case, shouldn't the
test to be able to decide what to do with it's fields after the frameworks did
their job?
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15228046#comment-15228046
]
Falko Modler commented on DELTASPIKE-1116:
--
Only @Inject fields are changed.
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
>Assignee: Gerhard Petracek
>Priority: Minor
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated DELTASPIKE-1116:
-
Attachment: DELTASPIKE-1116.zip
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated DELTASPIKE-1116:
-
Attachment: (was: DELTASPIKE-1116.zip)
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
[
https://issues.apache.org/jira/browse/DELTASPIKE-1116?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated DELTASPIKE-1116:
-
Attachment: DELTASPIKE-1116.zip
Please see attached maven project which contains a showcase test for this
problem:
A bean is injected and is wrapped into a mockito spy via {{@Spy}} and
{{MockitoJUnitRule}}.
The {{@Before}} method "sees" the spy as expected, but in the actual test
method it's gone (overwritten with the Weld proxy by the second injection).
> CdiTestRunner injects test class fields twice
> -
>
> Key: DELTASPIKE-1116
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
> Project: DeltaSpike
> Issue Type: Bug
> Components: TestControl
>Affects Versions: 1.0.2, 1.5.4, 1.6.0
> Environment: Apache Maven 3.2.5
> (12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
> Maven home: C:\Program Files\apache-maven-3.2.5
> Java version: 1.7.0_80, vendor: Oracle Corporation
> Java home: C:\Develop\jdk1.7.0_80\jre
> Default locale: de_DE, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
>Reporter: Falko Modler
> Attachments: DELTASPIKE-1116.zip
>
>
> {{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
> {{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes
> it possible to use injected beans in a {{@Before}} method or even in a JUnit
> {{TestRule}}.
> But shortly before executing the actual test method,
> {{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
> overwriting any changes that have been made to the fields in a JUnit
> {{TestRule}} or a {{@Before}} method in the test.
> The second injection was introduced by DELTASPIKE-342:
> https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
> I don't know why there needs to be a second injection at all.
> All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
> PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
> is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1116) CdiTestRunner injects test class fields twice
Falko Modler created DELTASPIKE-1116:
Summary: CdiTestRunner injects test class fields twice
Key: DELTASPIKE-1116
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1116
Project: DeltaSpike
Issue Type: Bug
Components: TestControl
Affects Versions: 1.6.0, 1.5.4, 1.0.2
Environment: Apache Maven 3.2.5
(12a6b3acb947671f09b81f49094c53f426d8cea1; 2014-12-14T18:29:23+01:00)
Maven home: C:\Program Files\apache-maven-3.2.5
Java version: 1.7.0_80, vendor: Oracle Corporation
Java home: C:\Develop\jdk1.7.0_80\jre
Default locale: de_DE, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"
Reporter: Falko Modler
{{CdiTestRunner}} first injects into {{@Inject}} fields of the test class in
{{CdiTestRunner.createTest()}}. I'm absolutely fine with that as this makes it
possible to use injected beans in a {{@Before}} method or even in a JUnit
{{TestRule}}.
But shortly before executing the actual test method,
{{CdiTestRunner.ContainerAwareMethodInvoker.evaluate()}} *injects again*,
overwriting any changes that have been made to the fields in a JUnit
{{TestRule}} or a {{@Before}} method in the test.
The second injection was introduced by DELTASPIKE-342:
https://git-wip-us.apache.org/repos/asf?p=deltaspike.git;a=commitdiff;h=2d44e7d2980f8ab0b0a2a388255c0f0944c85098
I don't know why there needs to be a second injection at all.
All tests pass when I remove the second {{BeanProvider.injectFields(...)}}.
PS: {{deltaspike.testcontrol.use_test_class_as_cdi_bean}} is {{false}}, which
is the default value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1018) Automatic RequestScope activation for @MBean invocations
[
https://issues.apache.org/jira/browse/DELTASPIKE-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991566#comment-14991566
]
Falko Modler commented on DELTASPIKE-1018:
--
One problem here is that the JMX stuff is located in the
{{deltaspike-core-impl}} module which does not have/must not have an dependency
on {{deltaspike-cdictrl-api}}.
This could be solved by moving the JMX stuff to a new module (e.g.
{{deltaspike-jmx}}) which then would have an (optional?) dependency on
{{deltaspike-cdictrl-api}}.
> Automatic RequestScope activation for @MBean invocations
> -
>
> Key: DELTASPIKE-1018
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1018
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0.2
>Reporter: Falko Modler
>Priority: Minor
>
> When a {{@JmxManaged}} method is called (via jconsole for instance) on a
> CDI-Bean which has been registered as a MBean via {{@MBean}} annotation, the
> RequestScope is not active.
> It would be handy if RequestScope could be actived automatically, perhaps
> configurable via a new {{@MBean}} attribute and/or
> {{apache-deltaspike.properties}}.
> Workaround: Implement and register an Interceptor which actives/deactivates
> the scope via {{ContextControl}} around the method invocation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1018) Automatic RequestScope activation for @MBean invocations
Falko Modler created DELTASPIKE-1018:
Summary: Automatic RequestScope activation for @MBean invocations
Key: DELTASPIKE-1018
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1018
Project: DeltaSpike
Issue Type: Improvement
Components: Core
Affects Versions: 1.0.2
Reporter: Falko Modler
Priority: Minor
When a {{@JmxManaged}} method is called (via jconsole for instance) on a
CDI-Bean which has been registered as a MBean via {{@MBean}} annotation, the
RequestScope is not active.
It would be handy if RequestScope could be actived automatically, perhaps
configurable via a new {{@MBean}} attribute and/or
{{apache-deltaspike.properties}}.
Workaround: Implement and register an Interceptor which actives/deactivates the
scope via {{ContextControl}} around the method invocation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1019) Enterprise container friendlier deltaspike-cdictrl-weld
Falko Modler created DELTASPIKE-1019:
Summary: Enterprise container friendlier deltaspike-cdictrl-weld
Key: DELTASPIKE-1019
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1019
Project: DeltaSpike
Issue Type: Improvement
Components: CdiControl
Affects Versions: 1.0.2
Reporter: Falko Modler
Priority: Minor
h5. Preface
Although {{deltaspike-cdictrl}} was designed for "SE setups",
{{ContextControl}} can be used in an enterprise CDI container like WELD on
JBoss/Wildfly just fine. {{CdiControl}} cannot be used.
h5. Problem
Even when you do not use {{CdiControl}}, enterprise WELD will at least log
{{ClassNotFoundException}} regarding {{org.jboss.weld.environment.se.Weld}}
when {{deltaspike-cdictrl-weld}} is deployed.
In WAR-deployments you might be able to exclude {{WeldContainerControl}} via
{{beans.xml}} but with EAR-deployments you are out of luck.
h5. Solution
- *Either* exclude {{WeldContainerControl}} (is created via {{ServiceLoader}}):
{code:xml|title=deltaspike-cdictrl-weld/META-INF/beans.xml}
{code}
PS: Not sure whether {{@Typed()}} would work as well?
- *Or* provide a second assembly of {{deltaspike-cdictrl-weld}} with some
classifer like "ctxctrl-only" which does not include the {{CdiControl}} stuff
I think the {{beans.xml}}-approach is the better solution.
h5. Workaround
Custom re-packing/shading of {{deltaspike-cdictrl-weld}} and possibly also
{{deltaspike-cdictrl-api}}. Very cumbersome...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1018) Automatic RequestScope activation for @MBean invocations
[
https://issues.apache.org/jira/browse/DELTASPIKE-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991772#comment-14991772
]
Falko Modler commented on DELTASPIKE-1018:
--
We already use such an interceptor. I can also understand that you won't fix
it. At least people can now find this ticket clearly pointing out the "issue.
Thanks for the quick feedback
> Automatic RequestScope activation for @MBean invocations
> -
>
> Key: DELTASPIKE-1018
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1018
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0.2
>Reporter: Falko Modler
>Priority: Minor
>
> When a {{@JmxManaged}} method is called (via jconsole for instance) on a
> CDI-Bean which has been registered as a MBean via {{@MBean}} annotation, the
> RequestScope is not active.
> It would be handy if RequestScope could be actived automatically, perhaps
> configurable via a new {{@MBean}} attribute and/or
> {{apache-deltaspike.properties}}.
> Workaround: Implement and register an Interceptor which actives/deactivates
> the scope via {{ContextControl}} around the method invocation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1019) Enterprise container friendlier deltaspike-cdictrl-weld
[
https://issues.apache.org/jira/browse/DELTASPIKE-1019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated DELTASPIKE-1019:
-
Description:
h5. Preface
Although {{deltaspike-cdictrl}} was designed for "SE setups",
{{ContextControl}} can be used in an enterprise CDI container like WELD on
JBoss/Wildfly just fine. {{CdiControl}} cannot be used.
h5. Problem
Even when you do not use {{CdiControl}}, enterprise WELD will at least log
{{ClassNotFoundException}} regarding {{org.jboss.weld.environment.se.Weld}}
when {{deltaspike-cdictrl-weld}} is deployed.
In WAR-deployments you might be able to exclude {{WeldContainerControl}} via
{{beans.xml}} but with EAR-deployments you are out of luck.
h5. Solution
- *Either* exclude {{WeldContainerControl}} (is created via {{ServiceLoader}}
anyway):
{code:xml|title=deltaspike-cdictrl-weld/META-INF/beans.xml}
{code}
PS: Not sure whether {{@Typed()}} would work as well?
- *Or* provide a second assembly of {{deltaspike-cdictrl-weld}} with some
classifer like "ctxctrl-only" which does not include the {{CdiControl}} stuff
I think the {{beans.xml}}-approach is the better solution.
h5. Workaround
Custom re-packing/shading of {{deltaspike-cdictrl-weld}} and possibly also
{{deltaspike-cdictrl-api}}. Very cumbersome...
was:
h5. Preface
Although {{deltaspike-cdictrl}} was designed for "SE setups",
{{ContextControl}} can be used in an enterprise CDI container like WELD on
JBoss/Wildfly just fine. {{CdiControl}} cannot be used.
h5. Problem
Even when you do not use {{CdiControl}}, enterprise WELD will at least log
{{ClassNotFoundException}} regarding {{org.jboss.weld.environment.se.Weld}}
when {{deltaspike-cdictrl-weld}} is deployed.
In WAR-deployments you might be able to exclude {{WeldContainerControl}} via
{{beans.xml}} but with EAR-deployments you are out of luck.
h5. Solution
- *Either* exclude {{WeldContainerControl}} (is created via {{ServiceLoader}}):
{code:xml|title=deltaspike-cdictrl-weld/META-INF/beans.xml}
{code}
PS: Not sure whether {{@Typed()}} would work as well?
- *Or* provide a second assembly of {{deltaspike-cdictrl-weld}} with some
classifer like "ctxctrl-only" which does not include the {{CdiControl}} stuff
I think the {{beans.xml}}-approach is the better solution.
h5. Workaround
Custom re-packing/shading of {{deltaspike-cdictrl-weld}} and possibly also
{{deltaspike-cdictrl-api}}. Very cumbersome...
> Enterprise container friendlier deltaspike-cdictrl-weld
> ---
>
> Key: DELTASPIKE-1019
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1019
> Project: DeltaSpike
> Issue Type: Improvement
> Components: CdiControl
>Affects Versions: 1.0.2
>Reporter: Falko Modler
>Priority: Minor
>
> h5. Preface
> Although {{deltaspike-cdictrl}} was designed for "SE setups",
> {{ContextControl}} can be used in an enterprise CDI container like WELD on
> JBoss/Wildfly just fine. {{CdiControl}} cannot be used.
> h5. Problem
> Even when you do not use {{CdiControl}}, enterprise WELD will at least log
> {{ClassNotFoundException}} regarding {{org.jboss.weld.environment.se.Weld}}
> when {{deltaspike-cdictrl-weld}} is deployed.
> In WAR-deployments you might be able to exclude {{WeldContainerControl}} via
> {{beans.xml}} but with EAR-deployments you are out of luck.
> h5. Solution
> - *Either* exclude {{WeldContainerControl}} (is created via {{ServiceLoader}}
> anyway):
> {code:xml|title=deltaspike-cdictrl-weld/META-INF/beans.xml}
>
> {code}
> PS: Not sure whether {{@Typed()}} would work as well?
> - *Or* provide a second assembly of {{deltaspike-cdictrl-weld}} with some
> classifer like "ctxctrl-only" which does not include the {{CdiControl}} stuff
> I think the {{beans.xml}}-approach is the better solution.
> h5. Workaround
> Custom re-packing/shading of {{deltaspike-cdictrl-weld}} and possibly also
> {{deltaspike-cdictrl-api}}. Very cumbersome...
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DELTASPIKE-1018) Automatic RequestScope activation for @MBean invocations
[
https://issues.apache.org/jira/browse/DELTASPIKE-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14991772#comment-14991772
]
Falko Modler edited comment on DELTASPIKE-1018 at 11/5/15 3:12 PM:
---
We already use such an interceptor. I can also understand that you won't fix
it. At least people can now find this ticket clearly pointing out the "issue".
Thanks for the quick feedback
was (Author: famod):
We already use such an interceptor. I can also understand that you won't fix
it. At least people can now find this ticket clearly pointing out the "issue.
Thanks for the quick feedback
> Automatic RequestScope activation for @MBean invocations
> -
>
> Key: DELTASPIKE-1018
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1018
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0.2
>Reporter: Falko Modler
>Priority: Minor
>
> When a {{@JmxManaged}} method is called (via jconsole for instance) on a
> CDI-Bean which has been registered as a MBean via {{@MBean}} annotation, the
> RequestScope is not active.
> It would be handy if RequestScope could be actived automatically, perhaps
> configurable via a new {{@MBean}} attribute and/or
> {{apache-deltaspike.properties}}.
> Workaround: Implement and register an Interceptor which actives/deactivates
> the scope via {{ContextControl}} around the method invocation.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Comment Edited] (DELTASPIKE-1008) Introduce @MBean.type() to customize type in JMX bean objectName
[
https://issues.apache.org/jira/browse/DELTASPIKE-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971057#comment-14971057
]
Falko Modler edited comment on DELTASPIKE-1008 at 10/23/15 2:19 PM:
It's all about convenience then. I just don't want to fiddle around with the
objectName syntax in my CDI-Bean's MBean annotation.
I just want to define the type and deltaspike {{MBeanExtension}} shall take
care of the details.
was (Author: famod):
It's all about convenience then. I just don't want to fiddle around with the
syntax in my CDI-Bean's MBean annotation.
I just want to define the type and deltaspike {{MBeanExtension}} shall take
care of the details.
> Introduce @MBean.type() to customize type in JMX bean objectName
>
>
> Key: DELTASPIKE-1008
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1008
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.5.0
>Reporter: Falko Modler
>Assignee: Romain Manni-Bucau
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: MBean_type_configurable.patch
>
>
> The {{type}} part in a JMX bean's {{objectName}} is the only thing that is
> not yet configurable. The attached patch changes that by introducing
> {{@MBean.type()}} similar to {{@MBean.category()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (DELTASPIKE-1008) Introduce @MBean.type() to customize type in JMX bean objectName
[
https://issues.apache.org/jira/browse/DELTASPIKE-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=14971057#comment-14971057
]
Falko Modler commented on DELTASPIKE-1008:
--
It's all about convenience then. I just don't want to fiddle around with the
syntax in my CDI-Bean's MBean annotation.
I just want to define the type and deltaspike {{MBeanExtension}} shall take
care of the details.
> Introduce @MBean.type() to customize type in JMX bean objectName
>
>
> Key: DELTASPIKE-1008
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1008
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.5.0
>Reporter: Falko Modler
>Assignee: Romain Manni-Bucau
>Priority: Minor
> Fix For: 1.6.0
>
> Attachments: MBean_type_configurable.patch
>
>
> The {{type}} part in a JMX bean's {{objectName}} is the only thing that is
> not yet configurable. The attached patch changes that by introducing
> {{@MBean.type()}} similar to {{@MBean.category()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-1008) Introduce @MBean.type() to customize type in JMX bean objectName
[
https://issues.apache.org/jira/browse/DELTASPIKE-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated DELTASPIKE-1008:
-
Attachment: MBean_type_configurable.patch
> Introduce @MBean.type() to customize type in JMX bean objectName
>
>
> Key: DELTASPIKE-1008
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1008
> Project: DeltaSpike
> Issue Type: Improvement
> Components: Core
>Affects Versions: 1.0.2, 1.5.0
>Reporter: Falko Modler
>Priority: Minor
> Labels: jmx
> Attachments: MBean_type_configurable.patch
>
>
> The {{type}} part in a JMX bean's {{objectName}} is the only thing that is
> not yet configurable. The attached patch changes that by introducing
> {{@MBean.type()}} similar to {{@MBean.category()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-1008) Introduce @MBean.type() to customize type in JMX bean objectName
Falko Modler created DELTASPIKE-1008:
Summary: Introduce @MBean.type() to customize type in JMX bean
objectName
Key: DELTASPIKE-1008
URL: https://issues.apache.org/jira/browse/DELTASPIKE-1008
Project: DeltaSpike
Issue Type: Improvement
Components: Core
Affects Versions: 1.5.0, 1.0.2
Reporter: Falko Modler
Priority: Minor
Attachments: MBean_type_configurable.patch
The {{type}} part in a JMX bean's {{objectName}} is the only thing that is not
yet configurable. The attached patch changes that by introducing
{{@MBean.type()}} similar to {{@MBean.category()}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-984) DynamicMBeanWrapper throws misleading MBeanException saying that the required action does not exist when MBean method (deliberately) throws an exception
Falko Modler created DELTASPIKE-984:
---
Summary: DynamicMBeanWrapper throws misleading MBeanException
saying that the required action does not exist when MBean method (deliberately)
throws an exception
Key: DELTASPIKE-984
URL: https://issues.apache.org/jira/browse/DELTASPIKE-984
Project: DeltaSpike
Issue Type: Bug
Components: Core
Affects Versions: 1.0.2
Reporter: Falko Modler
See {{org.apache.deltaspike.core.impl.jmx.DynamicMBeanWrapper.invoke(String,
Object[], String[])}}:
{code:java}
if (operations.containsKey(actionName))
{
final ClassLoader oldCl =
Thread.currentThread().getContextClassLoader();
Thread.currentThread().setContextClassLoader(classloader);
try
{
return operations.get(actionName).invoke(instance(), params);
}
catch (IllegalArgumentException e)
{
LOGGER.log(Level.SEVERE, actionName + "can't be invoked", e);
}
catch (IllegalAccessException e)
{
LOGGER.log(Level.SEVERE, actionName + "can't be invoked", e);
}
catch (InvocationTargetException e)
{
LOGGER.log(Level.SEVERE, actionName + "can't be invoked", e);
}
finally
{
Thread.currentThread().setContextClassLoader(oldCl);
}
}
throw new MBeanException(new IllegalArgumentException(), actionName + "
doesn't exist");
{code}
When the MBean method throws an exception, the wrapper catches and logs the
{{InvocationTargetException}}. But as the last step a {{MBeanException}} with
cause {{actionName + " doesn't exist"}} is thrown, regardless of what went
wrong actually!
The "doesn't exist" exception should be moved into an else block.
The specificly caught exception should be wrapped into a new {{MBeanException}}
which should be thrown afterwards. If wrapping is not possible due to
classloadings constraints, at least the message of the original exception
should be retained.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (DELTASPIKE-707) AbstractMockManager does not support interfaces mocked by mockito
Falko Modler created DELTASPIKE-707:
---
Summary: AbstractMockManager does not support interfaces mocked by
mockito
Key: DELTASPIKE-707
URL: https://issues.apache.org/jira/browse/DELTASPIKE-707
Project: DeltaSpike
Issue Type: Bug
Components: TestControl
Affects Versions: 1.0.2
Environment: Mockito 1.9.5
JDK 1.7u51
Reporter: Falko Modler
Following the
[manual|https://deltaspike.apache.org/test-control.html#mock-frameworks], I
tried to mock {{EntitityManager}} in my test class:
{noformat}
@RunWith(CdiTestRunner.class)
public class SomeTest {
@Inject
private DynamicMockManager mockManager;
@Test
public void mockitoMockAsCdiBean() {
mockManager.addMock(Mockito.mock(EntityManager.class));
[...]
}
}
{noformat}
Unfortunately this doesn't work as {{AbstractMockManager}} fails with:
{noformat}
java.lang.IllegalArgumentException:
$javax.persistence.EntityManager$$EnhancerByMockitoWithCGLIB$$b065dd9c isn't a
supported approach for mocking - please extend from the original class.
at
org.apache.deltaspike.testcontrol.impl.mock.AbstractMockManager.addMock(AbstractMockManager.java:45)
{noformat}
Following (rather ugly) workaound fixes the problem:
{noformat}
@Typed(EntityManager.class)
public static abstract class EntityManagerMockBase implements EntityManager
{
}
{noformat}
{noformat}
mockManager.addMock(Mockito.mock(EntityManagerMockBase.class));
{noformat}
In case this problem cannot be solved then the documentation should at least
mention that mocking does not work for interfaces and how to work around that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (DELTASPIKE-707) AbstractMockManager does not support interfaces mocked by mockito
[
https://issues.apache.org/jira/browse/DELTASPIKE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Falko Modler updated DELTASPIKE-707:
Description:
Following the
[manual|https://deltaspike.apache.org/test-control.html#mock-frameworks], I
tried to mock {{EntitityManager}} in my test class:
{noformat}
@RunWith(CdiTestRunner.class)
public class SomeTest {
@Inject
private DynamicMockManager mockManager;
@Test
public void mockitoMockAsCdiBean() {
mockManager.addMock(Mockito.mock(EntityManager.class));
[...]
}
}
{noformat}
Unfortunately this doesn't work as {{AbstractMockManager}} fails with:
{noformat}
java.lang.IllegalArgumentException:
$javax.persistence.EntityManager$$EnhancerByMockitoWithCGLIB$$b065dd9c isn't a
supported approach for mocking - please extend from the original class.
at
org.apache.deltaspike.testcontrol.impl.mock.AbstractMockManager.addMock(AbstractMockManager.java:45)
{noformat}
Following (rather ugly) workaound fixes the problem:
{noformat}
@Typed(EntityManager.class)
public static abstract class EntityManagerMockBase implements EntityManager
{
}
{noformat}
{noformat}
mockManager.addMock(Mockito.mock(EntityManagerMockBase.class));
{noformat}
If this problem cannot be solved then the documentation should at least mention
that mocking does not work for interfaces and how to work around that.
was:
Following the
[manual|https://deltaspike.apache.org/test-control.html#mock-frameworks], I
tried to mock {{EntitityManager}} in my test class:
{noformat}
@RunWith(CdiTestRunner.class)
public class SomeTest {
@Inject
private DynamicMockManager mockManager;
@Test
public void mockitoMockAsCdiBean() {
mockManager.addMock(Mockito.mock(EntityManager.class));
[...]
}
}
{noformat}
Unfortunately this doesn't work as {{AbstractMockManager}} fails with:
{noformat}
java.lang.IllegalArgumentException:
$javax.persistence.EntityManager$$EnhancerByMockitoWithCGLIB$$b065dd9c isn't a
supported approach for mocking - please extend from the original class.
at
org.apache.deltaspike.testcontrol.impl.mock.AbstractMockManager.addMock(AbstractMockManager.java:45)
{noformat}
Following (rather ugly) workaound fixes the problem:
{noformat}
@Typed(EntityManager.class)
public static abstract class EntityManagerMockBase implements EntityManager
{
}
{noformat}
{noformat}
mockManager.addMock(Mockito.mock(EntityManagerMockBase.class));
{noformat}
In case this problem cannot be solved then the documentation should at least
mention that mocking does not work for interfaces and how to work around that.
AbstractMockManager does not support interfaces mocked by mockito
-
Key: DELTASPIKE-707
URL: https://issues.apache.org/jira/browse/DELTASPIKE-707
Project: DeltaSpike
Issue Type: Bug
Components: TestControl
Affects Versions: 1.0.2
Environment: Mockito 1.9.5
JDK 1.7u51
Reporter: Falko Modler
Following the
[manual|https://deltaspike.apache.org/test-control.html#mock-frameworks], I
tried to mock {{EntitityManager}} in my test class:
{noformat}
@RunWith(CdiTestRunner.class)
public class SomeTest {
@Inject
private DynamicMockManager mockManager;
@Test
public void mockitoMockAsCdiBean() {
mockManager.addMock(Mockito.mock(EntityManager.class));
[...]
}
}
{noformat}
Unfortunately this doesn't work as {{AbstractMockManager}} fails with:
{noformat}
java.lang.IllegalArgumentException:
$javax.persistence.EntityManager$$EnhancerByMockitoWithCGLIB$$b065dd9c isn't
a supported approach for mocking - please extend from the original class.
at
org.apache.deltaspike.testcontrol.impl.mock.AbstractMockManager.addMock(AbstractMockManager.java:45)
{noformat}
Following (rather ugly) workaound fixes the problem:
{noformat}
@Typed(EntityManager.class)
public static abstract class EntityManagerMockBase implements
EntityManager {
}
{noformat}
{noformat}
mockManager.addMock(Mockito.mock(EntityManagerMockBase.class));
{noformat}
If this problem cannot be solved then the documentation should at least
mention that mocking does not work for interfaces and how to work around that.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
