March 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-2328) CLI connect command should accept a --bind parameter

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2328?page=com.atlassian.jira.plugi... ] Jean-Francois Denise commented on WFCORE-2328: ---------------------------------------------- For reference, the implementation in the new CLI.next branch: https://github.com/jfdenise/wildfly-core/commit/2635a31e5e2adcd81ef48442c... > CLI connect command should accept a --bind parameter > ---------------------------------------------------- > > Key: WFCORE-2328 > URL: https://issues.jboss.org/browse/WFCORE-2328 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Brian Stansberry > Assignee: Jean-Francois Denise > Priority: Minor > > When you launch the CLI you can pass a --bind=xxx param which then controls the client side bind address used for connections. But you can't specify this with the connect command itself. > This is minor; I just noticed it while experimenting with the fix for WFCORE-2225 when I wanted to confirm the fix was working by using the CLI. > Also, I noticed that if I did a "connect --bind=192.168.1.10" the CLI accepted the invalide command. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin... ] Martin Simka edited comment on JBJCA-1341 at 3/13/17 9:13 AM: -------------------------------------------------------------- I'm working on test for this and I think it would be better to trim each configured message and also each message obtained from exception. Also there is obvious limitation that configured message cannot contain char *_,_* [~iweiss] [~maeste] What do you think about message trimming? was (Author: simkam): I'm working on test for this and I think it would be better to trim each configured message and also each message obtained from exception. Also there is obvious limitation that configured message cannot contain char *_,_* > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (JBJCA-1341) Account for additional DB2 FATAL connection errors

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1341?page=com.atlassian.jira.plugin... ] Martin Simka commented on JBJCA-1341: ------------------------------------- I'm working on test for this and I think it would be better to trim each configured message and also each message obtained from exception. Also there is obvious limitation that configured message cannot contain char *_,_* > Account for additional DB2 FATAL connection errors > -------------------------------------------------- > > Key: JBJCA-1341 > URL: https://issues.jboss.org/browse/JBJCA-1341 > Project: IronJacamar > Issue Type: Enhancement > Components: Validator > Reporter: Ingo Weiss > Assignee: Ingo Weiss > Original Estimate: 2 days > Time Spent: 2 days > Remaining Estimate: 0 minutes > > Various version of pre 11.x DB2 drivers utilize the -99999 error code for a SQLException. Not all -99999 errors are fatal. For those variations that are known to be fatal, a check should be added to treat as such. > One example would be the -99999 error that indicates "Connection is closed" -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2527) There is wrong default *relative-to* path for CredentialStore

by Hynek Švábek (JIRA)

Hynek Švábek created WFCORE-2527: ------------------------------------ Summary: There is wrong default *relative-to* path for CredentialStore Key: WFCORE-2527 URL: https://issues.jboss.org/browse/WFCORE-2527 Project: WildFly Core Issue Type: Bug Components: Security Reporter: Hynek Švábek Assignee: Darran Lofthouse There is set wrong default *relative-to* path for CredentialStore. Default *relative-to* path is set to folder from which we started EAP server. e.g.: * cd EAP_FOLDER * ./bin/standalone.sh * relative-to is se to EAP_FOLDER or * cd EAP_FODER/bin * ./standalone.sh * relative-to is se to EAP_FOLDER/bin *How to reproduce* {code} /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/folderNotExist/keystorecs007.jceks?create=true", credential-reference= {clear-text=pass123}) {code} {code} /subsystem=elytron/credential-store=cs007/alias=newCs007:add(secret-value=Elytron) {code} Now you can see in EAP_FOLDER/folderNotExist (it can be different, see above) keystorecs007.jceks file -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-350) Domain reflects jboss.server.xy properties

by John Mazzitelli (JIRA)

[ https://issues.jboss.org/browse/WFCORE-350?page=com.atlassian.jira.plugin... ] John Mazzitelli edited comment on WFCORE-350 at 3/13/17 9:07 AM: ----------------------------------------------------------------- See: http://lists.jboss.org/pipermail/wildfly-dev/2017-March/005810.html I would say the solution should involve any properties, not just jboss.server.xxx properties. In my case, I'm trying to inject a javaagent into the host controller but I do NOT want the javaagent in the spawned servers. Because my javaagent uses JBoss Logging (JUL) I'm forced to pass in "-Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager" and "-Djava.util.logging.manager=org.jboss.logmanager.LogManager" so the host controller can start up. But these gets passed to the spawned servers and causes them to fail to boot up (because while my -javaagent command line argument isn't passed to their JVM, the -D sys props are and those combination of sys props are deadly without a JUL-enabled javaagent). NOTE: I opened a new JIRA for this: https://issues.jboss.org/browse/WFCORE-2526 was (Author: mazz): See: http://lists.jboss.org/pipermail/wildfly-dev/2017-March/005810.html I would say the solution should involve any properties, not just jboss.server.xxx properties. In my case, I'm trying to inject a javaagent into the host controller but I do NOT want the javaagent in the spawned servers. Because my javaagent uses JBoss Logging (JUL) I'm forced to pass in "-Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager" and "-Djava.util.logging.manager=org.jboss.logmanager.LogManager" so the host controller can start up. But these gets passed to the spawned servers and causes them to fail to boot up (because while my -javaagent command line argument isn't passed to their JVM, the -D sys props are and those combination of sys props are deadly without a JUL-enabled javaagent). > Domain reflects jboss.server.xy properties > ------------------------------------------ > > Key: WFCORE-350 > URL: https://issues.jboss.org/browse/WFCORE-350 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Rostislav Svoboda > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 3.0.0.Alpha23 > > > Domain reflects jboss.server.xy properties, tested with jboss.server.log.dir property. > The same server.log file is used for both server-one and server-two. Only file boot.log is created in domain/servers/server-one/log and domain/servers/server-two/log directory. In my case file server.log contains log only for server-one, there is no log for server-two. > I think jboss.server.xy properties shouldn't be reflected in domain instances. > Even structure of https://docs.jboss.org/author/display/AS71/Command+line+parameters implies that jboss.server.xy properties are used for Standalone. > Reproducer of my steps: > {code} > rm -rf domain/servers > bin/domain.sh -Djboss.server.log.dir=/tmp/ > ls -aR domain/servers/server-one/log > ls -aR domain/servers/server-two/log > ls -l /tmp/server* > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2527) There is wrong default *relative-to* path for CredentialStore, is set to folder from which we started EAP server.

by Hynek Švábek (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2527?page=com.atlassian.jira.plugi... ] Hynek Švábek updated WFCORE-2527: --------------------------------- Summary: There is wrong default *relative-to* path for CredentialStore, is set to folder from which we started EAP server. (was: There is wrong default *relative-to* path for CredentialStore) > There is wrong default *relative-to* path for CredentialStore, is set to folder from which we started EAP server. > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-2527 > URL: https://issues.jboss.org/browse/WFCORE-2527 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Hynek Švábek > Assignee: Darran Lofthouse > > There is set wrong default *relative-to* path for CredentialStore. > Default *relative-to* path is set to folder from which we started EAP server. > e.g.: > * cd EAP_FOLDER > * ./bin/standalone.sh > * relative-to is se to EAP_FOLDER > or > * cd EAP_FODER/bin > * ./standalone.sh > * relative-to is se to EAP_FOLDER/bin > *How to reproduce* > {code} > /subsystem=elytron/credential-store=cs007:add(uri="cr-store://test/folderNotExist/keystorecs007.jceks?create=true", credential-reference= {clear-text=pass123}) > {code} > {code} > /subsystem=elytron/credential-store=cs007/alias=newCs007:add(secret-value=Elytron) > {code} > Now you can see in EAP_FOLDER/folderNotExist (it can be different, see above) keystorecs007.jceks file -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2526) Domain mode passed unwanted sys props to spawned servers

by John Mazzitelli (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2526?page=com.atlassian.jira.plugi... ] John Mazzitelli edited comment on WFCORE-2526 at 3/13/17 9:06 AM: ------------------------------------------------------------------ Note that I say "I would say the solution should involve any properties, not just jboss.server.xxx properties" but frankly I only care about those two I reference in the description :} was (Author: mazz): Note that I say "the solution to that only involves filtering out some but not all unwanted sys props." but frankly I only care about those two I reference in the description :} > Domain mode passed unwanted sys props to spawned servers > -------------------------------------------------------- > > Key: WFCORE-2526 > URL: https://issues.jboss.org/browse/WFCORE-2526 > Project: WildFly Core > Issue Type: Task > Reporter: John Mazzitelli > > This is related to WFCORE-350, except the solution to that only involves filtering out some but not all unwanted sys props. > I would say the solution should involve any properties, not just jboss.server.xxx properties. > In my case, I'm trying to inject a javaagent into the host controller but I do NOT want the javaagent in the spawned servers. Because my javaagent uses JBoss Logging (JUL) I'm forced to pass in "-Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager" and > "-Djava.util.logging.manager=org.jboss.logmanager.LogManager" so the host controller can start up. > But these gets passed to the spawned servers and causes them to fail to boot up (because while my -javaagent command line argument isn't passed to their JVM, the -D sys props are and those combination of sys props are deadly without a JUL-enabled javaagent). > See: http://lists.jboss.org/pipermail/wildfly-dev/2017-March/005810.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2526) Domain mode passed unwanted sys props to spawned servers

by John Mazzitelli (JIRA)

John Mazzitelli created WFCORE-2526: --------------------------------------- Summary: Domain mode passed unwanted sys props to spawned servers Key: WFCORE-2526 URL: https://issues.jboss.org/browse/WFCORE-2526 Project: WildFly Core Issue Type: Task Reporter: John Mazzitelli This is related to WFCORE-350, except the solution to that only involves filtering out some but not all unwanted sys props. I would say the solution should involve any properties, not just jboss.server.xxx properties. In my case, I'm trying to inject a javaagent into the host controller but I do NOT want the javaagent in the spawned servers. Because my javaagent uses JBoss Logging (JUL) I'm forced to pass in "-Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager" and "-Djava.util.logging.manager=org.jboss.logmanager.LogManager" so the host controller can start up. But these gets passed to the spawned servers and causes them to fail to boot up (because while my -javaagent command line argument isn't passed to their JVM, the -D sys props are and those combination of sys props are deadly without a JUL-enabled javaagent). See: http://lists.jboss.org/pipermail/wildfly-dev/2017-March/005810.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2526) Domain mode passed unwanted sys props to spawned servers

by John Mazzitelli (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2526?page=com.atlassian.jira.plugi... ] John Mazzitelli commented on WFCORE-2526: ----------------------------------------- Note that I say "the solution to that only involves filtering out some but not all unwanted sys props." but frankly I only care about those two I reference in the description :} > Domain mode passed unwanted sys props to spawned servers > -------------------------------------------------------- > > Key: WFCORE-2526 > URL: https://issues.jboss.org/browse/WFCORE-2526 > Project: WildFly Core > Issue Type: Task > Reporter: John Mazzitelli > > This is related to WFCORE-350, except the solution to that only involves filtering out some but not all unwanted sys props. > I would say the solution should involve any properties, not just jboss.server.xxx properties. > In my case, I'm trying to inject a javaagent into the host controller but I do NOT want the javaagent in the spawned servers. Because my javaagent uses JBoss Logging (JUL) I'm forced to pass in "-Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager" and > "-Djava.util.logging.manager=org.jboss.logmanager.LogManager" so the host controller can start up. > But these gets passed to the spawned servers and causes them to fail to boot up (because while my -javaagent command line argument isn't passed to their JVM, the -D sys props are and those combination of sys props are deadly without a JUL-enabled javaagent). > See: http://lists.jboss.org/pipermail/wildfly-dev/2017-March/005810.html -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-350) Domain reflects jboss.server.xy properties

by John Mazzitelli (JIRA)

[ https://issues.jboss.org/browse/WFCORE-350?page=com.atlassian.jira.plugin... ] John Mazzitelli commented on WFCORE-350: ---------------------------------------- See: http://lists.jboss.org/pipermail/wildfly-dev/2017-March/005810.html I would say the solution should involve any properties, not just jboss.server.xxx properties. In my case, I'm trying to inject a javaagent into the host controller but I do NOT want the javaagent in the spawned servers. Because my javaagent uses JBoss Logging (JUL) I'm forced to pass in "-Djboss.modules.system.pkgs=org.jboss.byteman,org.jboss.logmanager" and "-Djava.util.logging.manager=org.jboss.logmanager.LogManager" so the host controller can start up. But these gets passed to the spawned servers and causes them to fail to boot up (because while my -javaagent command line argument isn't passed to their JVM, the -D sys props are and those combination of sys props are deadly without a JUL-enabled javaagent). > Domain reflects jboss.server.xy properties > ------------------------------------------ > > Key: WFCORE-350 > URL: https://issues.jboss.org/browse/WFCORE-350 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: Rostislav Svoboda > Assignee: ehsavoie Hugonnet > Priority: Minor > Fix For: 3.0.0.Alpha23 > > > Domain reflects jboss.server.xy properties, tested with jboss.server.log.dir property. > The same server.log file is used for both server-one and server-two. Only file boot.log is created in domain/servers/server-one/log and domain/servers/server-two/log directory. In my case file server.log contains log only for server-one, there is no log for server-two. > I think jboss.server.xy properties shouldn't be reflected in domain instances. > Even structure of https://docs.jboss.org/author/display/AS71/Command+line+parameters implies that jboss.server.xy properties are used for Standalone. > Reproducer of my steps: > {code} > rm -rf domain/servers > bin/domain.sh -Djboss.server.log.dir=/tmp/ > ls -aR domain/servers/server-one/log > ls -aR domain/servers/server-two/log > ls -l /tmp/server* > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2017