September 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5366) Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5366?page=com.atlassian.jira.plugin.... ] Tomaz Cerar reassigned WFLY-5366: --------------------------------- Assignee: (was: Tomaz Cerar) > Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently. > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-5366 > URL: https://issues.jboss.org/browse/WFLY-5366 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 10.0.0.CR1 > Environment: Linux/Debian > Reporter: Thorsten Moeller > Fix For: Awaiting Volunteers > > > If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded. > Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same. > I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5366) Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5366?page=com.atlassian.jira.plugin.... ] Tomaz Cerar updated WFLY-5366: ------------------------------ Fix Version/s: Awaiting Volunteers > Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently. > ------------------------------------------------------------------------------------------------------ > > Key: WFLY-5366 > URL: https://issues.jboss.org/browse/WFLY-5366 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 10.0.0.CR1 > Environment: Linux/Debian > Reporter: Thorsten Moeller > Fix For: Awaiting Volunteers > > > If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded. > Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same. > I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5415) wildfly-init-debian.sh overwrites previous log

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFLY-5415?page=com.atlassian.jira.plugin.... ] Tomaz Cerar closed WFLY-5415. ----------------------------- Resolution: Rejected Configure logging in logging subsystem to log to server.log only and not also to console. This way you wont lose anything and it will also perform better. > wildfly-init-debian.sh overwrites previous log > ---------------------------------------------- > > Key: WFLY-5415 > URL: https://issues.jboss.org/browse/WFLY-5415 > Project: WildFly > Issue Type: Bug > Components: Scripts > Affects Versions: 9.0.1.Final > Environment: Wildfly 9.0.1 Final on Ubuntu 14.04 LTS running the Zanata (zanata.org) translations platform. > Reporter: Elizabeth K. Joseph > Assignee: Tomaz Cerar > Priority: Minor > > We had to restart Wildfly on our Ubuntu 14.04 LTS server due to some issues with the application on top of it, and during the restart the init script wiped out our old logs and replaced them with the new logs, leaving us with none of the debugging information needed to track down our problem. > It looks like this line is to blame in bin/init.d/wildfly-init-debian.sh: > cat /dev/null > "$JBOSS_CONSOLE_LOG" > Currently using wildfly-9.0.1.Final. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JBASMP-78) Requirement to ser JBOSS_HOME as soon as commands are executed

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/JBASMP-78?page=com.atlassian.jira.plugin.... ] James Perkins reassigned JBASMP-78: ----------------------------------- Assignee: (was: James Perkins) > Requirement to ser JBOSS_HOME as soon as commands are executed > -------------------------------------------------------------- > > Key: JBASMP-78 > URL: https://issues.jboss.org/browse/JBASMP-78 > Project: JBoss AS Maven Plugins > Issue Type: Bug > Components: common > Affects Versions: 7.7.Final > Environment: This at least happens on Windows Machines, Haven't tried on Linux/Unix based machines. > Reporter: Christofer Dutz > > If I run jboss-as:run without any configuration and no JBoss installed, the plugin correctly downloads JBoss and unpacks it in my ear projects target directory. It also correctly starts the server and tries to deploy the application. Unfortunately I need to do some configuration first, so I added some "before-deployment" commands. Now the build fails with a message, that the JBOSS_HOME variable isn't set. As soon as I set it to the "target/jboss-as-run/jboss-as-7.1.1.Final" it is able to continue. Would be good however if the plugin could already ensure the variable from being set. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-666) Log file validation should check if a path is absolute if a relative-to is defined

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-666?page=com.atlassian.jira.plugin... ] James Perkins reopened WFCORE-666: ---------------------------------- Wrong issue closed. > Log file validation should check if a path is absolute if a relative-to is defined > ---------------------------------------------------------------------------------- > > Key: WFCORE-666 > URL: https://issues.jboss.org/browse/WFCORE-666 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > The {{path}} attribute on a file should be validated to not be absolute if a {{relative-to}} attribute was also defined. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't display messages with per-deployment logging

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin... ] James Perkins closed WFCORE-478. -------------------------------- Resolution: Out of Date This was fixed at some point likely with the of org.jboss.logmanager:log4j-jboss-logmanager:1.1.2.Final. > log4j ConsoleAppender won't display messages with per-deployment logging > ------------------------------------------------------------------------ > > Key: WFCORE-478 > URL: https://issues.jboss.org/browse/WFCORE-478 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Minor > > Add the following log4j.properties file to a deployment and try to log. > {code} > # Root logger option > log4j.rootLogger=INFO, stdout > # Direct log messages to stdout > log4j.appender.stdout=org.apache.log4j.ConsoleAppender > log4j.appender.stdout.Target=System.out > log4j.appender.stdout.layout=org.apache.log4j.PatternLayout > log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-666) Log file validation should check if a path is absolute if a relative-to is defined

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-666?page=com.atlassian.jira.plugin... ] James Perkins closed WFCORE-666. -------------------------------- Resolution: Out of Date This was fixed at some point likely with the of org.jboss.logmanager:log4j-jboss-logmanager:1.1.2.Final. > Log file validation should check if a path is absolute if a relative-to is defined > ---------------------------------------------------------------------------------- > > Key: WFCORE-666 > URL: https://issues.jboss.org/browse/WFCORE-666 > Project: WildFly Core > Issue Type: Enhancement > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > > The {{path}} attribute on a file should be validated to not be absolute if a {{relative-to}} attribute was also defined. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5436) Lack of EmbeddedCacheManager.undefineConfiguration(String) can cause memory/classloader leaks

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5436?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-5436: ------------------------------- Git Pull Request: (was: https://github.com/infinispan/infinispan/pull/3516) > Lack of EmbeddedCacheManager.undefineConfiguration(String) can cause memory/classloader leaks > --------------------------------------------------------------------------------------------- > > Key: WFLY-5436 > URL: https://issues.jboss.org/browse/WFLY-5436 > Project: WildFly > Issue Type: Bug > Components: Clustering > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Critical > > EmbeddedCacheManager has defineConfiguration(...) methods for defining a new cache configuration, but has no equivalent "undefine" method. Consequently, once defined, a cache manager will retains a reference to the cache configuration object for the lifetime of the cache manager. While this is normally not a big deal, the configuration objects generated by WildFly contain references to the classloaders of foreign modules. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-301) SetKeyStoreCredentialAuthenticationConfiguration does not translate passwords before using them

by David Lloyd (JIRA)

David Lloyd created ELY-301: ------------------------------- Summary: SetKeyStoreCredentialAuthenticationConfiguration does not translate passwords before using them Key: ELY-301 URL: https://issues.jboss.org/browse/ELY-301 Project: WildFly Elytron Issue Type: Bug Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Alpha1 See description. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-910) Add an Undertow SPNEGO authentication mechanism

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-910?page=com.atlassian.jira.plug... ] RH Bugzilla Integration updated SECURITY-910: --------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1267738 Bugzilla Update: Perform > Add an Undertow SPNEGO authentication mechanism > ----------------------------------------------- > > Key: SECURITY-910 > URL: https://issues.jboss.org/browse/SECURITY-910 > Project: PicketBox > Issue Type: Feature Request > Components: Negotiation > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: Negotiation_3_0_0_CR1 > > > Undertow does contain an SPNEGO authentication mechanism however this is not compatible with the LoginModule approach of JBoss Negotiation so an alternative mechanism is required here. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 7 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira September 2015