[JBoss JIRA] (WFCORE-476) Redhat/Debian script problem when deleting Console Handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-476?page=com.atlassian.jira.plugin... ]
James Perkins moved WFLY-3397 to WFCORE-476:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-476 (was: WFLY-3397)
Affects Version/s: (was: 8.1.0.CR2)
Component/s: Scripts
(was: Scripts)
> Redhat/Debian script problem when deleting Console Handler
> ----------------------------------------------------------
>
> Key: WFCORE-476
> URL: https://issues.jboss.org/browse/WFCORE-476
> Project: WildFly Core
> Issue Type: Bug
> Components: Scripts
> 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)
11 years, 7 months
[JBoss JIRA] (WFCORE-474) Custom formatter property changes not written to, but overriden by logging.properties
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-474?page=com.atlassian.jira.plugin... ]
James Perkins moved WFLY-3931 to WFCORE-474:
--------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-474 (was: WFLY-3931)
Affects Version/s: (was: 8.1.0.Final)
Component/s: Logging
(was: Logging)
> Custom formatter property changes not written to, but overriden by logging.properties
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-474
> URL: https://issues.jboss.org/browse/WFCORE-474
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Environment: Wildfly 8.1.0.Final
> Reporter: Vsevolod Golovanov
> Assignee: James Perkins
> Attachments: standalone.xml
>
>
> When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties.
> If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties.
> For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value.
> But with more dynamic properties, e.g. that rely on system properties, it's not so simple...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[JBoss JIRA] (WFLY-4032) Standalone.bat not support log dir with spaces in path (jboss.server.log.dir)
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4032?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-4032.
-------------------------------
Resolution: Out of Date
This should be working upstream
> Standalone.bat not support log dir with spaces in path (jboss.server.log.dir)
> -----------------------------------------------------------------------------
>
> Key: WFLY-4032
> URL: https://issues.jboss.org/browse/WFLY-4032
> Project: WildFly
> Issue Type: Bug
> Components: Batch, Logging, Scripts
> Affects Versions: 8.1.0.Final
> Environment: Windows 7
> Reporter: Duc Quoc
> Assignee: James Perkins
> Priority: Minor
>
> I tried to specify a custom log folder for WildFly, by overriding property jboss.server.log.dir
> https://docs.jboss.org/author/display/WFLY8/Command+line+parameters
> But it only works for folder without space in path. The ones with space when used with "jboss.server.log.dir" will prevent wildfly from starting.
> Working:
> C:\>start C:\wildfly-8.1.0.Final\bin\standalone.bat
> C:\>start C:\wildfly-8.1.0.Final\bin\standalone.bat -Djboss.server.log.dir="C:\Windows"
> Not working (server can not start):
> C:\>start C:\wildfly-8.1.0.Final\bin\standalone.bat -Djboss.server.log.dir="C:\Program Files"
> (More info:
> JBoss AS 7.1 works:
> C:\> start C:\jboss-as-7.1.1.Final\bin\standalone.bat -Djboss.server.log.dir="C:\Program Files"
> JBoss EAP 6 and WildFly 8.0 not working either:
> C:\> start C:\jboss-eap-6.2\bin\standalone.bat -Djboss.server.log.dir="C:\Program Files"
> C:\> start C:\wildfly-8.0.0.Final\bin\standalone.bat -Djboss.server.log.dir="C:\Program Files"
> Aready tried setting jboss.server.log.dir="C:\Program Files" in JAVA_OPTS but did not work either. Should have been fixed in WFLY-1358 or WFLY-2348.
> )
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 7 months
[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:
---------------------------------------
In that case I can make the check to the process status and not verify the log output.... but this way it will return OK right away even if there is an error in the start, for example problems of permissions, etc. Since the process is really started but not fully operational.
BTW is a bad practice to remove the console handler since it makes difficult to diagnose possible problems on startup.
> 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)
11 years, 7 months
[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)
11 years, 7 months
[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)
11 years, 7 months
[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)
11 years, 7 months
[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)
11 years, 7 months