[JBoss JIRA] (DROOLS-795) Timers are reset during the serialization process
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/DROOLS-795?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on DROOLS-795:
------------------------------------------------
Marek Winkler <mwinkler(a)redhat.com> changed the Status of [bug 1248429|https://bugzilla.redhat.com/show_bug.cgi?id=1248429] from ON_QA to VERIFIED
> Timers are reset during the serialization process
> -------------------------------------------------
>
> Key: DROOLS-795
> URL: https://issues.jboss.org/browse/DROOLS-795
> Project: Drools
> Issue Type: Bug
> Reporter: Mario Fusco
> Assignee: Mario Fusco
> Fix For: 6.3.0.CR1
>
>
> When the marshall serializes a timer it doesn't take count of how much time it is already passed, so when the timer is deserialized it restart from it start time. The following failing test case reproduces the problem.
> {code}
> @Test
> public void testMarshallWithTimedRule() {
> String drl = "rule \"Rule A Timeout\"\n" +
> "when\n" +
> " String( this == \"ATrigger\" )\n" +
> "then\n" +
> " insert (new String( \"A-Timer\") );\n" +
> "System.out.println(\"+++++++Got ATrigger, started A-Timer with 5s timeout\");\n" +
> "end\n" +
> "\n" +
> "rule \"Timer For rule A Timeout\"\n" +
> " timer ( int: 5s )\n" +
> "when\n" +
> " String( this == \"A-Timer\")\n" +
> "then\n" +
> " delete ( \"A-Timer\" );\n" +
> " delete ( \"ATrigger\" );\n" +
> "System.out.println(\"******* reset rule A based on timer\");\n" +
> "end\n";
> KieBase kbase = new KieHelper().addContent( drl, ResourceType.DRL )
> .build( EqualityBehaviorOption.EQUALITY,
> DeclarativeAgendaOption.ENABLED,
> EventProcessingOption.STREAM );
> KieSessionConfiguration sessionConfig = KnowledgeBaseFactory.newKnowledgeSessionConfiguration();
> sessionConfig.setOption( ClockTypeOption.get( "pseudo" ) );
> KieSession ksession = kbase.newKieSession(sessionConfig, null);
> ksession.insert( new String( "ATrigger" ) );
> assertEquals( 1, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> SessionPseudoClock clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 2, ksession.getFactCount() );
> ksession = marshallAndUnmarshall( kbase, ksession, sessionConfig);
> clock = ksession.getSessionClock();
> clock.advanceTime( 4, TimeUnit.SECONDS );
> assertEquals( 2, ksession.getFactCount() );
> ksession.fireAllRules();
> assertEquals( 0, ksession.getFactCount() );
> }
> public static KieSession marshallAndUnmarshall(KieBase kbase, KieSession ksession, KieSessionConfiguration sessionConfig) {
> // Serialize and Deserialize
> try {
> Marshaller marshaller = KieServices.Factory.get().getMarshallers().newMarshaller(kbase);
> ByteArrayOutputStream baos = new ByteArrayOutputStream();
> marshaller.marshall(baos, ksession);
> marshaller = MarshallerFactory.newMarshaller( kbase );
> ByteArrayInputStream bais = new ByteArrayInputStream(baos.toByteArray());
> baos.close();
> ksession = marshaller.unmarshall(bais, sessionConfig, null);
> bais.close();
> } catch (Exception e) {
> e.printStackTrace();
> fail("unexpected exception :" + e.getMessage());
> }
> return ksession;
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-940) CLI gets fooled by early connection
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-940?page=com.atlassian.jira.plugin... ]
Petr Kremensky moved JBEAP-953 to WFCORE-940:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-940 (was: JBEAP-953)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: CLI
Domain Management
(was: CLI)
(was: Domain Management)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.0.Beta4
(was: 7.0.0.DR9)
> CLI gets fooled by early connection
> -----------------------------------
>
> Key: WFCORE-940
> URL: https://issues.jboss.org/browse/WFCORE-940
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Alexey Loubyansky
>
> CLI in confused by early connection to domain which is booting. CLI acts as I was connected to the standalone instance, some high level commands are not executable.
> {noformat}
> [pkremens@dhcp-10-40-5-149 bin]$ ./domain.sh
> ...
> # run while domain is booting
> [pkremens@dhcp-10-40-5-149 bin]$ ./jboss-cli.sh -c
> [standalone@localhost:9999 /]
> # domain has fully booted
> [standalone@localhost:9999 /] ls -l
> ATTRIBUTE VALUE TYPE
> launch-type DOMAIN STRING
> ...
> [standalone@localhost:9999 /] shutdown --host=master
> --host is not allowed in the standalone mode.
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFLY-3971) Jar Services in META-INF/services are not loaded from static modules
by Lucas K (JIRA)
[ https://issues.jboss.org/browse/WFLY-3971?page=com.atlassian.jira.plugin.... ]
Lucas K commented on WFLY-3971:
-------------------------------
Got the same problem with atmospheres [AnnotationScanningServletContainerInitializer|http://atmosphere.github.io/atmosphere/apidocs/org/atmosphere/cpr/AnnotationScanningServletContainerInitializer.html]. It's not called, if atmosphere is a static module.
But i got a workaround for the moment:
I added export="true" to the atmosphere-module and added a new JAR to the WEB-INF/lib folder. The JAR only contains the META-INF folder of atmosphere.jar. Inside it there is the services folder with the "javax.servlet.ServletContainerInitializer" file.
The atmosphere-module gets loaded and exported. So if the new JAR is deployed the ServletContainerInitializer is read and the AnnotationScanningServletContainerInitializer of atmosphere gets called.
I hope it helps someone who has the same problem and is also waiting for the bugfix.
> Jar Services in META-INF/services are not loaded from static modules
> --------------------------------------------------------------------
>
> Key: WFLY-3971
> URL: https://issues.jboss.org/browse/WFLY-3971
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 9.0.0.Final, 10.0.0.Alpha6
> Reporter: Tomas Repel
> Assignee: Stuart Douglas
>
> If the web application (war) uses jar file from static module, the content of META-INF/services has no effect. If the jar is located inside WEB-INF/lib, services are loaded successfully.
> Neither adding `Dependencies: my.module.name.com services` into MANIFEST.MF nor adding `services="import"` to jboss-deployment-structure.xml works.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-939) Embedded host controller should set lunch type attribute to EMBEDDED
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-939?page=com.atlassian.jira.plugin... ]
Petr Kremensky updated WFCORE-939:
----------------------------------
Environment: (was: *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded.
Looking into the LaunchType class, I believe that EMBEDDED value should be used.
{noformat}
/** The manner in which a server can be launched */
public static enum LaunchType {
/** Launched by a Host Controller in a managed domain */
DOMAIN(ProcessType.DOMAIN_SERVER),
/** Launched from the command line */
STANDALONE(ProcessType.STANDALONE_SERVER),
/** Launched by another process in which the server is embedded */
EMBEDDED(ProcessType.EMBEDDED_SERVER),
...
{noformat}
\\
*Additional info:*
{noformat}./standalone.sh
launch-type STANDALONE
{noformat}
{noformat}./domain.sh
launch-type DOMAIN
{noformat}
{noformat}[disconnected /] embed-server
launch-type EMBEDDED
{noformat}
{noformat}[disconnected /] embed-host-controller
launch-type DOMAIN
{noformat})
> Embedded host controller should set lunch type attribute to EMBEDDED
> --------------------------------------------------------------------
>
> Key: WFCORE-939
> URL: https://issues.jboss.org/browse/WFCORE-939
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-939) Embedded host controller should set lunch type attribute to EMBEDDED
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-939?page=com.atlassian.jira.plugin... ]
Petr Kremensky updated WFCORE-939:
----------------------------------
Description:
*DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded.
Looking into the LaunchType class, I believe that EMBEDDED value should be used.
{noformat}
/** The manner in which a server can be launched */
public static enum LaunchType {
/** Launched by a Host Controller in a managed domain */
DOMAIN(ProcessType.DOMAIN_SERVER),
/** Launched from the command line */
STANDALONE(ProcessType.STANDALONE_SERVER),
/** Launched by another process in which the server is embedded */
EMBEDDED(ProcessType.EMBEDDED_SERVER),
...
{noformat}
\\
*Additional info:*
{noformat}./standalone.sh
launch-type STANDALONE
{noformat}
{noformat}./domain.sh
launch-type DOMAIN
{noformat}
{noformat}[disconnected /] embed-server
launch-type EMBEDDED
{noformat}
{noformat}[disconnected /] embed-host-controller
launch-type DOMAIN
{noformat}
> Embedded host controller should set lunch type attribute to EMBEDDED
> --------------------------------------------------------------------
>
> Key: WFCORE-939
> URL: https://issues.jboss.org/browse/WFCORE-939
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
> *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded.
> Looking into the LaunchType class, I believe that EMBEDDED value should be used.
> {noformat}
> /** The manner in which a server can be launched */
> public static enum LaunchType {
> /** Launched by a Host Controller in a managed domain */
> DOMAIN(ProcessType.DOMAIN_SERVER),
> /** Launched from the command line */
> STANDALONE(ProcessType.STANDALONE_SERVER),
> /** Launched by another process in which the server is embedded */
> EMBEDDED(ProcessType.EMBEDDED_SERVER),
> ...
> {noformat}
> \\
> *Additional info:*
> {noformat}./standalone.sh
> launch-type STANDALONE
> {noformat}
> {noformat}./domain.sh
> launch-type DOMAIN
> {noformat}
> {noformat}[disconnected /] embed-server
> launch-type EMBEDDED
> {noformat}
> {noformat}[disconnected /] embed-host-controller
> launch-type DOMAIN
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFCORE-939) Embedded host controller should set lunch type attribute to EMBEDDED
by Petr Kremensky (JIRA)
[ https://issues.jboss.org/browse/WFCORE-939?page=com.atlassian.jira.plugin... ]
Petr Kremensky moved JBEAP-951 to WFCORE-939:
---------------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-939 (was: JBEAP-951)
Workflow: GIT Pull Request workflow (was: CDW v1)
Component/s: CLI
Domain Management
(was: CLI)
(was: Domain Management)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 2.0.0.Beta4
(was: 7.0.0.DR9)
> Embedded host controller should set lunch type attribute to EMBEDDED
> --------------------------------------------------------------------
>
> Key: WFCORE-939
> URL: https://issues.jboss.org/browse/WFCORE-939
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 2.0.0.Beta4
> Environment: *DomainRootDefinition.java* always set launch type to {noformat}new LaunchTypeHandler(ServerEnvironment.LaunchType.DOMAIN){noformat} even if the host controller process is embedded.
> Looking into the LaunchType class, I believe that EMBEDDED value should be used.
> {noformat}
> /** The manner in which a server can be launched */
> public static enum LaunchType {
> /** Launched by a Host Controller in a managed domain */
> DOMAIN(ProcessType.DOMAIN_SERVER),
> /** Launched from the command line */
> STANDALONE(ProcessType.STANDALONE_SERVER),
> /** Launched by another process in which the server is embedded */
> EMBEDDED(ProcessType.EMBEDDED_SERVER),
> ...
> {noformat}
> \\
> *Additional info:*
> {noformat}./standalone.sh
> launch-type STANDALONE
> {noformat}
> {noformat}./domain.sh
> launch-type DOMAIN
> {noformat}
> {noformat}[disconnected /] embed-server
> launch-type EMBEDDED
> {noformat}
> {noformat}[disconnected /] embed-host-controller
> launch-type DOMAIN
> {noformat}
> Reporter: Petr Kremensky
> Assignee: Ken Wills
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFLY-5235) CDI interceptors are not called when invoking observer method
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-5235?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-5235:
------------------------------------
[~dweil] Could you post the full stack trace? A reproducer/test application would be helpful as well.
> CDI interceptors are not called when invoking observer method
> -------------------------------------------------------------
>
> Key: WFLY-5235
> URL: https://issues.jboss.org/browse/WFLY-5235
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 9.0.1.Final
> Reporter: Dirk Weil
> Assignee: Martin Kouba
>
> The following code runs with an active transaction on WFLY 8.2.0, but failes with an TransactionRequiredException on WFLY 9.0.1:
> @ApplicationScoped
> public class InitCocktailDemoDataService
> {
> @PersistenceContext
> private EntityManager entityManager;
> @Transactional
> private void createDemoData(@Observes @Initialized(ApplicationScoped.class) Object event)
> {
> this.entityManager.merge(someEntity);
> }
> It seems that interceptors aren't called at all - at least for observers of scope lifecycle events.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months
[JBoss JIRA] (WFLY-5160) SingletonDeployment*TestCase fail on RHEL7
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-5160?page=com.atlassian.jira.plugin.... ]
Marek Kopecký reopened WFLY-5160:
---------------------------------
This issue is still valid on wildfly master
> SingletonDeployment*TestCase fail on RHEL7
> ------------------------------------------
>
> Key: WFLY-5160
> URL: https://issues.jboss.org/browse/WFLY-5160
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Reporter: Marek Kopecký
> Assignee: Paul Ferraro
> Fix For: 10.0.0.Beta2
>
>
> *Description of problem:*
> * Two tests fail with "expected:<405> but was:<200>" error
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentJBossAllTestCase(SYNC-tcp)#test
> ** org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentDescriptorTestCase(SYNC-tcp)#test
> *How reproducible:*
> * RHEL7
> * IBM JDK 8, Oracle JDK 8, Open JDK 8
> *Steps to Reproduce:*
> # ./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -Dnode0=$MYTESTIP_1 -Dnode1=$MYTESTIP_2 -Dmcast=$MCAST_ADDR -Dtest=SingletonDeploymentJBossAllTestCase,SingletonDeploymentDescriptorTestCase -DfailIfNoTests=false -Dts.clustering
> *Actual results:*
> {noformat}
> java.lang.AssertionError: expected:<405> but was:<200>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:743)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:555)
> at org.junit.Assert.assertEquals(Assert.java:542)
> at org.jboss.as.test.clustering.cluster.singleton.SingletonDeploymentTestCase.test(SingletonDeploymentTestCase.java:84)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:370)
> at org.jboss.arquillian.container.test.impl.execution.LocalTestExecuter.execute(LocalTestExecuter.java:60)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:53)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:129)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:92)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:73)
> at sun.reflect.GeneratedMethodAccessor5.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:136)
> at org.jboss.arquillian.junit.Arquillian$8.evaluate(Arquillian.java:363)
> at org.jboss.arquillian.junit.Arquillian$4.evaluate(Arquillian.java:245)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$5.evaluate(Arquillian.java:259)
> at org.jboss.arquillian.junit.Arquillian$7$1.invoke(Arquillian.java:315)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.execute(ClientBeforeAfterLifecycleEventExecuter.java:99)
> at org.jboss.arquillian.container.test.impl.execution.ClientBeforeAfterLifecycleEventExecuter.on(ClientBeforeAfterLifecycleEventExecuter.java:72)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:142)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createBeforeContext(ContainerEventController.java:124)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:130)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> 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:95)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> at java.lang.reflect.Method.invoke(Method.java:507)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:88)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:145)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:116)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.fireCustomLifecycle(EventTestRunnerAdaptor.java:159)
> at org.jboss.arquillian.junit.Arquillian$7.evaluate(Arquillian.java:311)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.jboss.arquillian.junit.Arquillian$2.evaluate(Arquillian.java:204)
> at org.jboss.arquillian.junit.Arquillian.multiExecute(Arquillian.java:422)
> at org.jboss.arquillian.junit.Arquillian.access$200(Arquillian.java:54)
> at org.jboss.arquillian.junit.Arquillian$3.evaluate(Arquillian.java:218)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:166)
> at org.junit.runners.Suite.runChild(Suite.java:127)
> at org.junit.runners.Suite.runChild(Suite.java:26)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:309)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:160)
> at org.junit.runner.JUnitCore.run(JUnitCore.java:138)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.createRequestAndRun(JUnitCoreWrapper.java:113)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.executeEager(JUnitCoreWrapper.java:85)
> at org.apache.maven.surefire.junitcore.JUnitCoreWrapper.execute(JUnitCoreWrapper.java:54)
> at org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:134)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:200)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:153)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:103)
> {noformat}
> *Expected results:*
> No failures in test case.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
10 years, 8 months