[JBoss JIRA] (WFLY-9371) Fix failing RemoteEJBTwoClusterTestCase
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9371?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-9371 at 9/26/17 10:49 AM:
----------------------------------------------------------------
The problem according to logs is clear:
{noformat}
2017-09-26 15:58:11,689 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5)
ISPN000094: Received new cluster view for channel web: [clusterA-node0|2] (3) [clusterA-node0, clusterA-node1, clusterB-node0]
{noformat}
because {{jboss.default.multicast.address}} is provided with the same value on the system boot, which is a regression caused by https://github.com/wildfly/wildfly/commit/dcfe0af91444768ef87e4d131039bfb...
was (Author: rhusar):
The problem according to logs is clear:
{noformat}
2017-09-26 15:58:11,689 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5)
ISPN000094: Received new cluster view for channel web: [clusterA-node0|2] (3) [clusterA-node0, clusterA-node1, clusterB-node0]
{noformat}
because {{jboss.default.multicast.address}} is provided with the same value on the system boot.
> Fix failing RemoteEJBTwoClusterTestCase
> ---------------------------------------
>
> Key: WFLY-9371
> URL: https://issues.jboss.org/browse/WFLY-9371
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be run as part of regular CI set of tests; if intermittently failing then it should be @Ignore-d in the way intermittently failing tests are.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFCORE-3210) Wildfly module isolation not working consistently
by Nuno Godinho de Matos (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3210?page=com.atlassian.jira.plugi... ]
Nuno Godinho de Matos commented on WFCORE-3210:
-----------------------------------------------
Hi,
Just a short update.
I have been able to configure the set of most relevant appenders from within the wildfly logging subsytem configuration directly, as recommended by you above.
So far as I have been able to test this seems to be working perfectly and I have not experience any issues even while changing mode of startup of the app server.
I was afraid that the native JUL to Log4j support on the subsystem logging would perhaps not be routing along MDC context information, but even the MDC context seems to be handed over to the log4j appenders added to the subsystem logging configuration.
I have therefore completely dropped the original approach of writing a Jul to Log4j1 handler.
>From my side, this issue can be considered as closed.
Although I believe that if you get the opportunity to test the sample domain provided, it might be worth while to try to reproduce the issue as it might indeed lead you find out a relevant bug on module isolation - or my module was simply incorrectly written.
One additional question:
- What is the recommended approach to dynamically change logger levels (e.g. an existing logger change its log level from FINE -> INFO)
Is it via Jboss CLI or admin console application?
Are the loggers under the subsystem logging managed as java managed beans? E.g. can a web application do a logging system configuration reload via some managed bean API?
Thanks for all the help.
Kindest regards.
> Wildfly module isolation not working consistently
> -------------------------------------------------
>
> Key: WFCORE-3210
> URL: https://issues.jboss.org/browse/WFCORE-3210
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging, Modules
> Affects Versions: 2.2.0.Final
> Reporter: Nuno Godinho de Matos
>
> There is an underministic bug on the module layer of wildfly, whereby the boot logic of the application server is not ensured to give the appropriate module isolation - which can lead to unexpected boot classpath problems.
> An example of this phenomena is given on the wildfly forum thread:
> https://developer.jboss.org/thread/275839
> In this example, we have the logging subsystem setup to use a custome handler.
> The custom handler wishes to have acces to the JUL extension classes on the org.jboss.logmanger module, but wishes to do have no relationship with the org.apache.log4j packages associated to the wildfly org.jboss.log4j module.
> What we see in this example is that an application gets from wildfly mixed behavior.
> Most of the time, during boot, the processes works without problem, where the custom handler runs isolated from the undersired log4j libraries within wildfly.
> But other times the application boot procedure will not go smoothly with the custom handler having processes routing JUL LogRecords events into the bundled log4j because the application server has loaded some of the classes that exist the org.jboss.log4j module.
> And as we know when the same class is loaded by different class loaders, then that class that orinates from class loader A cannot be assigned to the corresponding class of class loader B, even if the classes are exactly the same.
> This is not an isolated issue.
> There are also open issues on the wildfly forum reporting on startup problems on the logging subsystme where sometimes the LogManager class had not yet been loaded, and sometimes this issue goes away.
> This is an indication of some deep issue engrained into the module loading, where the module isolation behavior is not ensured to work all the time and that the boot procedure is not deterministically reliable.
> It should not be that the application server some time starts successfully and others not.
> Booting wildfly should always result in the same outcode.
> Problems of this nature with class loading problems should either always happen if the configuration is not done properly or never happen if the configuration is proper.
> In the case of thread:
> https://developer.jboss.org/thread/275839
> Our belief is that the configuration is doing all it possible can to request the necessary module isolation from base packages and the outcome where log4j class load problems take place should never be allowed to happen.
> Many thanks.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9388) There should be replaced stacktrace loggings to stderr with usage of logging.
by Romain Pelisse (JIRA)
[ https://issues.jboss.org/browse/WFLY-9388?page=com.atlassian.jira.plugin.... ]
Romain Pelisse updated WFLY-9388:
---------------------------------
Description:
On many places both in server and in components there is called on exception printStackTrace, this results in having the stacktrace printed to stderr. This results in each line of the stacktrace to be considered a new error message in logs.
Using stderr is
1) is inefficient from performance point of view and
2) it doesn't have such nice control of what and when should be printed (length of stacktrace,log level) as logging does.
I believe occurrences of using the printStackTrace in the code should be reviewed and either removed or replaced with logging where appropriate.
This one is reported for the server itself. If you agree that it is worth doing as I believe it is, then there should be created separate tasks for individual components.
> There should be replaced stacktrace loggings to stderr with usage of logging.
> -----------------------------------------------------------------------------
>
> Key: WFLY-9388
> URL: https://issues.jboss.org/browse/WFLY-9388
> Project: WildFly
> Issue Type: Enhancement
> Components: Server
> Reporter: Romain Pelisse
> Assignee: Romain Pelisse
> Priority: Critical
>
> On many places both in server and in components there is called on exception printStackTrace, this results in having the stacktrace printed to stderr. This results in each line of the stacktrace to be considered a new error message in logs.
> Using stderr is
> 1) is inefficient from performance point of view and
> 2) it doesn't have such nice control of what and when should be printed (length of stacktrace,log level) as logging does.
> I believe occurrences of using the printStackTrace in the code should be reviewed and either removed or replaced with logging where appropriate.
> This one is reported for the server itself. If you agree that it is worth doing as I believe it is, then there should be created separate tasks for individual components.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9371) Fix failing RemoteEJBTwoClusterTestCase
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9371?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-9371:
--------------------------------------
The problem according to logs is clear
{noformat}
2017-09-26 15:58:11,689 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000094: Received new cluster view for channel web: [clusterA-node0|2] (3) [clusterA-node0, clusterA-node1, clusterB-node0]
{noformat}
because {{jboss.default.multicast.address}} is provided with the same value on the system boot.
> Fix failing RemoteEJBTwoClusterTestCase
> ---------------------------------------
>
> Key: WFLY-9371
> URL: https://issues.jboss.org/browse/WFLY-9371
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be run as part of regular CI set of tests; if intermittently failing then it should be @Ignore-d in the way intermittently failing tests are.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9371) Fix failing RemoteEJBTwoClusterTestCase
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9371?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-9371 at 9/26/17 10:41 AM:
----------------------------------------------------------------
The problem according to logs is clear
{noformat}
2017-09-26 15:58:11,689 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5)
ISPN000094: Received new cluster view for channel web: [clusterA-node0|2] (3) [clusterA-node0, clusterA-node1, clusterB-node0]
{noformat}
because {{jboss.default.multicast.address}} is provided with the same value on the system boot.
was (Author: rhusar):
The problem according to logs is clear
{noformat}
2017-09-26 15:58:11,689 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5) ISPN000094: Received new cluster view for channel web: [clusterA-node0|2] (3) [clusterA-node0, clusterA-node1, clusterB-node0]
{noformat}
because {{jboss.default.multicast.address}} is provided with the same value on the system boot.
> Fix failing RemoteEJBTwoClusterTestCase
> ---------------------------------------
>
> Key: WFLY-9371
> URL: https://issues.jboss.org/browse/WFLY-9371
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be run as part of regular CI set of tests; if intermittently failing then it should be @Ignore-d in the way intermittently failing tests are.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9371) Fix failing RemoteEJBTwoClusterTestCase
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-9371?page=com.atlassian.jira.plugin.... ]
Radoslav Husar edited comment on WFLY-9371 at 9/26/17 10:41 AM:
----------------------------------------------------------------
The problem according to logs is clear:
{noformat}
2017-09-26 15:58:11,689 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5)
ISPN000094: Received new cluster view for channel web: [clusterA-node0|2] (3) [clusterA-node0, clusterA-node1, clusterB-node0]
{noformat}
because {{jboss.default.multicast.address}} is provided with the same value on the system boot.
was (Author: rhusar):
The problem according to logs is clear
{noformat}
2017-09-26 15:58:11,689 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (MSC service thread 1-5)
ISPN000094: Received new cluster view for channel web: [clusterA-node0|2] (3) [clusterA-node0, clusterA-node1, clusterB-node0]
{noformat}
because {{jboss.default.multicast.address}} is provided with the same value on the system boot.
> Fix failing RemoteEJBTwoClusterTestCase
> ---------------------------------------
>
> Key: WFLY-9371
> URL: https://issues.jboss.org/browse/WFLY-9371
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 10.1.0.Final
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
>
> The problem is that this test is not run as part of regular CI execution thus is destined to be broken. The test should be run as part of regular CI set of tests; if intermittently failing then it should be @Ignore-d in the way intermittently failing tests are.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months
[JBoss JIRA] (WFLY-9389) BootstrapBeanDeploymentArchiveTestCase fails with security manager
by Ondrej Kotek (JIRA)
[ https://issues.jboss.org/browse/WFLY-9389?page=com.atlassian.jira.plugin.... ]
Ondrej Kotek moved JBEAP-13270 to WFLY-9389:
--------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-9389 (was: JBEAP-13270)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Test Suite
(was: Test Suite)
Affects Version/s: 11.0.0.Final
(was: 7.1.0.CR2)
> BootstrapBeanDeploymentArchiveTestCase fails with security manager
> ------------------------------------------------------------------
>
> Key: WFLY-9389
> URL: https://issues.jboss.org/browse/WFLY-9389
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 11.0.0.Final
> Reporter: Ondrej Kotek
> Labels: security-manager
>
> BootstrapBeanDeploymentArchiveTestCase fails with security manager because of missing permission "("java.lang.RuntimePermission" "accessDeclaredMembers")":
> {noformat}
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy 3f485239-85b6-4893-82a8-c8317b24d0d6.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.\"3f485239-85b6-4893-82a8-c8317b24d0d6.war\".WeldStartService" => "Failed to start service
> Caused by: org.jboss.weld.exceptions.DefinitionException: Exception List with 1 exceptions:
> Exception 0 :
> javax.enterprise.event.ObserverException
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at java.lang.Class.newInstance(Class.java:442)
> at org.jboss.weld.security.NewInstanceAction.run(NewInstanceAction.java:33)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:40)
> at org.jboss.weld.injection.Exceptions.rethrowException(Exceptions.java:78)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:96)
> at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129)
> 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.AbstractDefinitionContainerEvent.fire(AbstractDefinitionContainerEvent.java:44)
> at org.jboss.weld.bootstrap.events.AfterBeanDiscoveryImpl.fire(AfterBeanDiscoveryImpl.java:62)
> at org.jboss.weld.bootstrap.WeldStartup.deployBeans(WeldStartup.java:451)
> at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:83)
> at org.jboss.as.weld.WeldStartService.start(WeldStartService.java:95)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
> 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: java.lang.ExceptionInInitializerError
> at org.wildfly.test.integration.weld.beanarchives.TestExtension.beforeBeanDiscovery(TestExtension.java:49)
> 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)
> ... 21 more
> Caused by: java.security.AccessControlException: WFSM000001: Permission check failed (permission \"(\"java.lang.RuntimePermission\" \"accessDeclaredMembers\")\" in code source \"(vfs:/content/3f485239-85b6-4893-82a8-c8317b24d0d6.war/WEB-INF/classes <no signer certificates>)\" of \"ModuleClassLoader for Module \"deployment.3f485239-85b6-4893-82a8-c8317b24d0d6.war\" from Service Module Loader\")
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:278)
> at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> at java.lang.Class.checkMemberAccess(Class.java:2348)
> at java.lang.Class.getDeclaredMethods(Class.java:1974)
> at javax.enterprise.util.AnnotationLiteral.getMembers(AnnotationLiteral.java:78)
> at javax.enterprise.util.AnnotationLiteral.<init>(AnnotationLiteral.java:69)
> at org.wildfly.test.integration.weld.beanarchives.Alpha$Literal.<init>(Alpha.java:39)
> at org.wildfly.test.integration.weld.beanarchives.Alpha$Literal.<clinit>(Alpha.java:42)
> ... 27 more
> "}}}}
> at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:184)
> at org.jboss.as.arquillian.container.ArchiveDeployer.deployInternal(ArchiveDeployer.java:162)
> at org.jboss.as.arquillian.container.ArchiveDeployer.deploy(ArchiveDeployer.java:91)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.deploy(CommonDeployableContainer.java:244)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:161)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$3.call(ContainerDeployController.java:128)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.executeOperation(ContainerDeployController.java:271)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deploy(ContainerDeployController.java:127)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.container.impl.client.container.DeploymentExceptionHandler.verifyExpectedExceptionDuringDeploy(DeploymentExceptionHandler.java:50)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createDeploymentContext(ContainerDeploymentContextHandler.java:78)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.container.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:95)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController$1.perform(ContainerDeployController.java:80)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachDeployment(ContainerDeployController.java:263)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.forEachManagedDeployment(ContainerDeployController.java:239)
> at org.jboss.arquillian.container.impl.client.container.ContainerDeployController.deployManaged(ContainerDeployController.java:79)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:101)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:85)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> 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.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:96)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:92)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:143)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:114)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeClass(EventTestRunnerAdaptor.java:87)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:202)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:431)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:55)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:219)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:167)
> at org.junit.runners.Suite.runChild(Suite.java:128)
> at org.junit.runners.Suite.runChild(Suite.java:27)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:137)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:115)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:108)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:78)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:144)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:203)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:155)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> Adding the permission helps.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 7 months