[JBoss JIRA] (WFLY-4179) Three web integration test failures with security manager enabled
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4179?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-4179:
--------------------------------
Attachment: (was: org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase.txt)
> Three web integration test failures with security manager enabled
> -----------------------------------------------------------------
>
> Key: WFLY-4179
> URL: https://issues.jboss.org/browse/WFLY-4179
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Test Suite
> Reporter: James Perkins
> Assignee: Stuart Douglas
> Attachments: org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase-output.txt
>
>
> The following test fail when the security manager is enabled for the {{testsuite/integration/web}} tests.
> * org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase
> The tests are set to be ignored if the {{-Dsecurity.manager}} property is enabled. Once resolved the profile in the pom.xml for the web integration tests should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4179) Three web integration test failures with security manager enabled
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4179?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-4179:
--------------------------------
Attachment: (was: org.jboss.as.test.integration.jsp.JspTagTestCase-output.txt)
> Three web integration test failures with security manager enabled
> -----------------------------------------------------------------
>
> Key: WFLY-4179
> URL: https://issues.jboss.org/browse/WFLY-4179
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Test Suite
> Reporter: James Perkins
> Assignee: Stuart Douglas
> Attachments: org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase-output.txt
>
>
> The following test fail when the security manager is enabled for the {{testsuite/integration/web}} tests.
> * org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase
> The tests are set to be ignored if the {{-Dsecurity.manager}} property is enabled. Once resolved the profile in the pom.xml for the web integration tests should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4179) Three web integration test failures with security manager enabled
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4179?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-4179:
--------------------------------
Description:
The following test fail when the security manager is enabled for the {{testsuite/integration/web}} tests.
* org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase
The tests are set to be ignored if the {{-Dsecurity.manager}} property is enabled. Once resolved the profile in the pom.xml for the web integration tests should be removed.
was:
The following 3 tests fail when the security manager is enabled for the {{testsuite/integration/web}} tests.
* org.jboss.as.test.integration.jsp.JspTagTestCase
* org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase
* org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase
The tests are set to be ignored if the {{-Dsecurity.manager}} property is enabled. Once resolved the profile in the pom.xml for the web integration tests should be removed.
Steps to Reproduce:
>From the {{testsuite/integration/web}} directory execute:
{code}
mvn clean test -Dsecurity.manager -Dtest=CustomErrorsUnitTestCase
{code}
was:
>From the {{testsuite/integration/web}} directory execute:
{code}
mvn clean test -Dsecurity.manager -Dtest=JspTagTestCase,ServletLifecycleMethodDescriptorTestCase,CustomErrorsUnitTestCase
{code}
> Three web integration test failures with security manager enabled
> -----------------------------------------------------------------
>
> Key: WFLY-4179
> URL: https://issues.jboss.org/browse/WFLY-4179
> Project: WildFly
> Issue Type: Bug
> Components: Security Manager, Test Suite
> Reporter: James Perkins
> Assignee: Stuart Douglas
> Attachments: org.jboss.as.test.integration.jsp.JspTagTestCase-output.txt, org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase-output.txt, org.jboss.as.test.integration.web.servlet.lifecycle.ServletLifecycleMethodDescriptorTestCase.txt
>
>
> The following test fail when the security manager is enabled for the {{testsuite/integration/web}} tests.
> * org.jboss.as.test.integration.web.customerrors.CustomErrorsUnitTestCase
> The tests are set to be ignored if the {{-Dsecurity.manager}} property is enabled. Once resolved the profile in the pom.xml for the web integration tests should be removed.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4182) wildfly-arquillian-container-managed: conflicting xnio versions
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/WFLY-4182?page=com.atlassian.jira.plugin.... ]
Brett Meyer closed WFLY-4182.
-----------------------------
Resolution: Rejected
> wildfly-arquillian-container-managed: conflicting xnio versions
> ---------------------------------------------------------------
>
> Key: WFLY-4182
> URL: https://issues.jboss.org/browse/WFLY-4182
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Tomaz Cerar
>
> wildfly-arquillian-container-managed:8.2.0.Final produces the following stack when it tries to start Wildfly 8.2:
> {code}
> java.lang.AbstractMethodError: org.xnio.XnioWorker.chooseThread()Lorg/xnio/XnioIoThread;
> at org.xnio.XnioWorker.openStreamConnection(XnioWorker.java:342)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState.doUpgrade(HttpUpgrade.java:247)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState.access$100(HttpUpgrade.java:165)
> at org.xnio.http.HttpUpgrade.performUpgrade(HttpUpgrade.java:112)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:116)
> at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:221)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:78)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:109)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:148)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState(ManagementClient.java:186)
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:192)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:112)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
> at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
> at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> {code}
> org.wildfly:wildfly-arquillian-container-managed:8.2.0.Final includes the following transitive dependencies:
> org.jboss.xnio:xnio-api:3.3.0.Final
> org.jboss.xnio:xnio-nio:3.0.9.GA
> Does the xnio-nio version need upgraded to 3.3.0? Would anything else be causing this?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4182) wildfly-arquillian-container-managed: conflicting xnio versions
by Brett Meyer (JIRA)
[ https://issues.jboss.org/browse/WFLY-4182?page=com.atlassian.jira.plugin.... ]
Brett Meyer commented on WFLY-4182:
-----------------------------------
Argh. Tomaz, my mistake, it looks like the IP BOM is wrecking havoc on several other transitive dependencies, including xnio. Sorry for the wild goose chase.
> wildfly-arquillian-container-managed: conflicting xnio versions
> ---------------------------------------------------------------
>
> Key: WFLY-4182
> URL: https://issues.jboss.org/browse/WFLY-4182
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Tomaz Cerar
>
> wildfly-arquillian-container-managed:8.2.0.Final produces the following stack when it tries to start Wildfly 8.2:
> {code}
> java.lang.AbstractMethodError: org.xnio.XnioWorker.chooseThread()Lorg/xnio/XnioIoThread;
> at org.xnio.XnioWorker.openStreamConnection(XnioWorker.java:342)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState.doUpgrade(HttpUpgrade.java:247)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState.access$100(HttpUpgrade.java:165)
> at org.xnio.http.HttpUpgrade.performUpgrade(HttpUpgrade.java:112)
> at org.jboss.remoting3.remote.HttpUpgradeConnectionProvider.createConnection(HttpUpgradeConnectionProvider.java:116)
> at org.jboss.remoting3.remote.RemoteConnectionProvider.connect(RemoteConnectionProvider.java:221)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:298)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:78)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:109)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:148)
> at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.arquillian.container.ManagementClient.isServerInRunningState(ManagementClient.java:186)
> at org.jboss.as.arquillian.container.managed.ManagedDeployableContainer.startInternal(ManagedDeployableContainer.java:192)
> at org.jboss.as.arquillian.container.CommonDeployableContainer.start(CommonDeployableContainer.java:112)
> at org.jboss.arquillian.container.impl.ContainerImpl.start(ContainerImpl.java:199)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:163)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$8.perform(ContainerLifecycleController.java:157)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forContainer(ContainerLifecycleController.java:255)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startContainer(ContainerLifecycleController.java:156)
> at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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.impl.client.ContainerDeploymentContextHandler.createContainerContext(ContainerDeploymentContextHandler.java:57)
> at sun.reflect.GeneratedMethodAccessor1.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:77)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController$2.perform(ContainerLifecycleController.java:70)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.forEachSuiteContainer(ContainerLifecycleController.java:221)
> at org.jboss.arquillian.container.impl.client.container.ContainerLifecycleController.startSuiteContainers(ContainerLifecycleController.java:69)
> at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:67)
> at org.jboss.arquillian.container.test.impl.client.ContainerEventController.execute(ContainerEventController.java:86)
> at sun.reflect.GeneratedMethodAccessor7.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:60)
> at sun.reflect.GeneratedMethodAccessor6.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> 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:135)
> at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:115)
> at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.beforeSuite(EventTestRunnerAdaptor.java:68)
> at org.jboss.arquillian.junit.Arquillian.run(Arquillian.java:97)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:264)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:153)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:124)
> {code}
> org.wildfly:wildfly-arquillian-container-managed:8.2.0.Final includes the following transitive dependencies:
> org.jboss.xnio:xnio-api:3.3.0.Final
> org.jboss.xnio:xnio-nio:3.0.9.GA
> Does the xnio-nio version need upgraded to 3.3.0? Would anything else be causing this?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-3397) Redhat/Debian script problem when deleting Console Handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-3397?page=com.atlassian.jira.plugin.... ]
James Perkins commented on WFLY-3397:
-------------------------------------
Not really as there is no way to know what the address and port the management resources are bound to. This will actually break in WildFly 10 anyway. Ideally you'd want to check the process rather than the stdout anyway.
> Redhat/Debian script problem when deleting Console Handler
> ----------------------------------------------------------
>
> Key: WFLY-3397
> URL: https://issues.jboss.org/browse/WFLY-3397
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.1.0.CR2
> Reporter: Marcial Atiénzar Navarro
> Assignee: James Perkins
> Priority: Minor
>
> The scripts to start wildfly as service on redhat/debian use this code:
> {code}
> until [ $count -gt $STARTUP_WAIT ]
> do
> grep 'JBAS015874:' "$JBOSS_CONSOLE_LOG" > /dev/null
> if [ $? -eq 0 ] ; then
> launched=1
> break
> fi
> sleep 1
> count=$((count + 1));
> done
> {code}
> But if you have delete console handler in production enviroment, and increase the startup_wait because you have more applications deployed on server, it takes to start all the time specified on STARTUP_WAIT
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-3397) Redhat/Debian script problem when deleting Console Handler
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3397?page=com.atlassian.jira.plugin.... ]
Jorge Solorzano edited comment on WFLY-3397 at 12/16/14 2:02 PM:
-----------------------------------------------------------------
This is due to the wait it takes to start and check if started successfully.
¨[~jamezp] do you know a reliable way to check if the server is running, maybe using jboss-cli?
was (Author: jorsol):
This is due to the wait it takes to start... ¨[~jamezp] do you know a reliable way to check if the server is running, maybe using jboss-cli?
> Redhat/Debian script problem when deleting Console Handler
> ----------------------------------------------------------
>
> Key: WFLY-3397
> URL: https://issues.jboss.org/browse/WFLY-3397
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.1.0.CR2
> Reporter: Marcial Atiénzar Navarro
> Assignee: James Perkins
> Priority: Minor
>
> The scripts to start wildfly as service on redhat/debian use this code:
> {code}
> until [ $count -gt $STARTUP_WAIT ]
> do
> grep 'JBAS015874:' "$JBOSS_CONSOLE_LOG" > /dev/null
> if [ $? -eq 0 ] ; then
> launched=1
> break
> fi
> sleep 1
> count=$((count + 1));
> done
> {code}
> But if you have delete console handler in production enviroment, and increase the startup_wait because you have more applications deployed on server, it takes to start all the time specified on STARTUP_WAIT
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-3397) Redhat/Debian script problem when deleting Console Handler
by Jorge Solorzano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3397?page=com.atlassian.jira.plugin.... ]
Jorge Solorzano commented on WFLY-3397:
---------------------------------------
This is due to the wait it takes to start... ¨[~jamezp] do you know a reliable way to check if the server is running, maybe using jboss-cli?
> Redhat/Debian script problem when deleting Console Handler
> ----------------------------------------------------------
>
> Key: WFLY-3397
> URL: https://issues.jboss.org/browse/WFLY-3397
> Project: WildFly
> Issue Type: Bug
> Components: Scripts
> Affects Versions: 8.1.0.CR2
> Reporter: Marcial Atiénzar Navarro
> Assignee: James Perkins
> Priority: Minor
>
> The scripts to start wildfly as service on redhat/debian use this code:
> {code}
> until [ $count -gt $STARTUP_WAIT ]
> do
> grep 'JBAS015874:' "$JBOSS_CONSOLE_LOG" > /dev/null
> if [ $? -eq 0 ] ; then
> launched=1
> break
> fi
> sleep 1
> count=$((count + 1));
> done
> {code}
> But if you have delete console handler in production enviroment, and increase the startup_wait because you have more applications deployed on server, it takes to start all the time specified on STARTUP_WAIT
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4186) Improve Infinispan module distribution to improve compatibility with older releases
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-4186?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-4186:
-------------------------------
Description:
Infinispan 7 moved a bunch of classes from the org.infinispan:infinispan-core maven module into the org.infinispan:infinispan-commons module (which, itself, was introduced in Infinispan 6), which can cause user deployments that previously depended on org.infinispan to fail with mysterious NoClassDefFoundErrors if the org.infinispan.commons module was not also previously declared as a deployment dependency.
I suggest we either:
1. Export org.infinispan.commons from the org.infinispan module
2. Rename org.infinispan to org.infinispan.core, and create a new org.infinispan that exports both org.infinispan.core and org.infinispan.commons.
was:
Infinispan 7 moved a bunch of classes from the org.infinispan:infinispan-core maven module into the org.infinispan:infinispan-commons module, which can cause user deployments that previously depended on org.infinispan to fail with mysterious NoClassDefFoundErrors if the org.infinispan.commons module was not also previously declared as a deployment dependency.
I suggest we either:
1. Export org.infinispan.commons from the org.infinispan module
2. Rename org.infinispan to org.infinispan.core, and create a new org.infinispan that exports both org.infinispan.core and org.infinispan.commons.
> Improve Infinispan module distribution to improve compatibility with older releases
> -----------------------------------------------------------------------------------
>
> Key: WFLY-4186
> URL: https://issues.jboss.org/browse/WFLY-4186
> Project: WildFly
> Issue Type: Enhancement
> Components: Clustering
> Affects Versions: 9.0.0.Alpha1
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> Infinispan 7 moved a bunch of classes from the org.infinispan:infinispan-core maven module into the org.infinispan:infinispan-commons module (which, itself, was introduced in Infinispan 6), which can cause user deployments that previously depended on org.infinispan to fail with mysterious NoClassDefFoundErrors if the org.infinispan.commons module was not also previously declared as a deployment dependency.
> I suggest we either:
> 1. Export org.infinispan.commons from the org.infinispan module
> 2. Rename org.infinispan to org.infinispan.core, and create a new org.infinispan that exports both org.infinispan.core and org.infinispan.commons.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (LOGMGR-119) Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-119?page=com.atlassian.jira.plugin... ]
James Perkins closed LOGMGR-119.
--------------------------------
Resolution: Rejected
Not a bug. Use {{YYYY-ww}} as described in the comment.
> Wrong backup file names by PeriodicRotatingFileHandler when suffix "yyyy-ww"
> ----------------------------------------------------------------------------
>
> Key: LOGMGR-119
> URL: https://issues.jboss.org/browse/LOGMGR-119
> Project: JBoss Log Manager
> Issue Type: Bug
> Affects Versions: 1.5.2.Final
> Reporter: Osamu Nagano
> Assignee: James Perkins
>
> When {{PeriodicRotatingFileHandler}} with suffix "yyyy-ww" rotates a log file over a year, file that belongs to the new year is incorrectly named using the previous year.
> Here is a demonstrating test code supposed to be pasted into {{src/test/java/org/jboss/logmanager/handlers/PeriodicSizeRotatingFileHandlerTests.java}}. It mimics a record started from 2014-12-24 and the resulting backup log file is named {{rotating-file-handler.log.2014-01}}. It should be 2015 instead.
> {code}
> /*
> * Run with the following command:
> * mvn compile test -Dtest=PeriodicSizeRotatingFileHandlerTests#testPeriodicRotateWeekOfYear
> */
> @Test
> public void testPeriodicRotateWeekOfYear() throws Exception {
> SimpleDateFormat fmt = periodFormatMap.get(Calendar.WEEK_OF_YEAR);
> Calendar cal = Calendar.getInstance(java.util.TimeZone.getTimeZone("GMT"));
>
> PeriodicRotatingFileHandler handler = new PeriodicRotatingFileHandler();
> handler.setAutoFlush(true);
> handler.setFormatter(new PatternFormatter("%d{yyyy-MM-dd HH:mm:ss,SSS} %-5p [%c] (%t) %s%E%n"));
> handler.setSuffix("." + fmt.toPattern());
> handler.setFile(logFile);
>
> cal.set(Calendar.YEAR, 2014);
> cal.set(Calendar.MONTH, 12 - 1);
> cal.set(Calendar.DAY_OF_MONTH, 24);
> cal.set(Calendar.HOUR_OF_DAY, 12);
>
> for (int i = 0; i < 14; i++) {
> long tim = cal.getTimeInMillis();
> String fdate = fmt.format(tim);
> ExtLogRecord record = createLogRecord("%02d th formatted date is %s", i, fdate);
> record.setMillis(tim);
> handler.publish(record);
>
> cal.add(Calendar.DAY_OF_MONTH, 1);
> }
>
> handler.close();
>
> for (String logFile : BASE_LOG_DIR.list()) {
> System.out.println(logFile);
> }
> Assert.assertTrue("Dummy.", true);
> }
> {code}
> And here is the result of the test method.
> {code}
> % ll logs
> total 12K
> -rw-r--r--. 1 onagano onagano 228 Dec 5 17:09 rotating-file-handler.log
> -rw-r--r--. 1 onagano onagano 532 Dec 5 17:09 rotating-file-handler.log.2014-01
> -rw-r--r--. 1 onagano onagano 0 Dec 5 17:09 rotating-file-handler.log.2014-49
> -rw-r--r--. 1 onagano onagano 304 Dec 5 17:09 rotating-file-handler.log.2014-52
> % cat logs/rotating-file-handler.log.2014-52
> 2014-12-24 21:09:43,921 INFO [null] (main) 00 th formatted date is 2014-52
> 2014-12-25 21:09:43,921 INFO [null] (main) 01 th formatted date is 2014-52
> 2014-12-26 21:09:43,921 INFO [null] (main) 02 th formatted date is 2014-52
> 2014-12-27 21:09:43,921 INFO [null] (main) 03 th formatted date is 2014-52
> % cat logs/rotating-file-handler.log.2014-01
> 2014-12-28 21:09:43,921 INFO [null] (main) 04 th formatted date is 2014-01
> 2014-12-29 21:09:43,921 INFO [null] (main) 05 th formatted date is 2014-01
> 2014-12-30 21:09:43,921 INFO [null] (main) 06 th formatted date is 2014-01
> 2014-12-31 21:09:43,921 INFO [null] (main) 07 th formatted date is 2014-01
> 2015-01-01 21:09:43,921 INFO [null] (main) 08 th formatted date is 2015-01
> 2015-01-02 21:09:43,921 INFO [null] (main) 09 th formatted date is 2015-01
> 2015-01-03 21:09:43,921 INFO [null] (main) 10 th formatted date is 2015-01
> % cat logs/rotating-file-handler.log
> 2015-01-04 21:09:43,921 INFO [null] (main) 11 th formatted date is 2015-02
> 2015-01-05 21:09:43,921 INFO [null] (main) 12 th formatted date is 2015-02
> 2015-01-06 21:09:43,921 INFO [null] (main) 13 th formatted date is 2015-02
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years