August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (LOGMGR-150) Add support for a more generic error handler

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-150?page=com.atlassian.jira.plugin... ] James Perkins reassigned LOGMGR-150: ------------------------------------ Fix Version/s: 2.1.0.Alpha3 Assignee: James Perkins Resolution: Done > Add support for a more generic error handler > -------------------------------------------- > > Key: LOGMGR-150 > URL: https://issues.jboss.org/browse/LOGMGR-150 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha3 > > > There are places, such as in the {{org.jboss.logmanager.LoggerNode}}, where exceptions are swallowed. Handlers have use an {{java.util.logging.ErrorHandler}}, but formatters and loggers do not. It would be helpful to have a way to either reuse or create a similar error handler concept for loggers and formatters. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1339) If SPNEGO authorization fails start the challenge process from scratch

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-1339: ------------------------------------- Summary: If SPNEGO authorization fails start the challenge process from scratch Key: ELY-1339 URL: https://issues.jboss.org/browse/ELY-1339 Project: WildFly Elytron Issue Type: Bug Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.CR7 -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9243) Upgrade to Hibernate Search 5.5.8.Final : compatibility with Hibernate ORM 5.1

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9243: -------------------------------------- Summary: Upgrade to Hibernate Search 5.5.8.Final : compatibility with Hibernate ORM 5.1 Key: WFLY-9243 URL: https://issues.jboss.org/browse/WFLY-9243 Project: WildFly Issue Type: Component Upgrade Components: JPA / Hibernate Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 11.0.0.CR1 upgrading from version {{5.5.5.Final}} to {{5.5.8.Final}}. Changelog for 5.5.6: - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... Changelog for 5.5.7: - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... Changelog for 5.5.8: - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9215) Upgrade to Hibernate Search 5.5.8.Final : compatibility with Hibernate ORM 5.1

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/WFLY-9215?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated WFLY-9215: ---------------------------------- Description: upgrading from version {{5.5.5.Final}} to {{5.5.8.Final}}. Changelog for 5.5.6: - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... Changelog for 5.5.7: - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... Changelog for 5.5.8: - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... was: upgrading from version {{5.5.5}} to {{5.5.7}}. Changelog for 5.5.6: - https://hibernate.atlassian.net/projects/HSEARCH/versions/25505/tab/relea... Changelog for 5.5.7: - https://hibernate.atlassian.net/projects/HSEARCH/versions/26600/tab/relea... > Upgrade to Hibernate Search 5.5.8.Final : compatibility with Hibernate ORM 5.1 > ------------------------------------------------------------------------------ > > Key: WFLY-9215 > URL: https://issues.jboss.org/browse/WFLY-9215 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 11.0.0.CR1 > > > upgrading from version {{5.5.5.Final}} to {{5.5.8.Final}}. > Changelog for 5.5.6: > - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... > Changelog for 5.5.7: > - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... > Changelog for 5.5.8: > - https://hibernate.atlassian.net/issues/?jql=project%20%3D%20HSEARCH%20AND... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9215) Upgrade to Hibernate Search 5.5.8.Final : compatibility with Hibernate ORM 5.1

by Sanne Grinovero (JIRA)

[ https://issues.jboss.org/browse/WFLY-9215?page=com.atlassian.jira.plugin.... ] Sanne Grinovero updated WFLY-9215: ---------------------------------- Summary: Upgrade to Hibernate Search 5.5.8.Final : compatibility with Hibernate ORM 5.1 (was: Upgrade to Hibernate Search 5.5.7.Final : micro bugfix upgrade) > Upgrade to Hibernate Search 5.5.8.Final : compatibility with Hibernate ORM 5.1 > ------------------------------------------------------------------------------ > > Key: WFLY-9215 > URL: https://issues.jboss.org/browse/WFLY-9215 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Reporter: Sanne Grinovero > Assignee: Sanne Grinovero > Fix For: 11.0.0.CR1 > > > upgrading from version {{5.5.5}} to {{5.5.7}}. > Changelog for 5.5.6: > - https://hibernate.atlassian.net/projects/HSEARCH/versions/25505/tab/relea... > Changelog for 5.5.7: > - https://hibernate.atlassian.net/projects/HSEARCH/versions/26600/tab/relea... -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3197) jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3197?page=com.atlassian.jira.plugi... ] Tomaz Cerar commented on WFCORE-3197: ------------------------------------- did you maybe try with scripts that are part of WildFly 11 Beta1? you can just copy them over to our 10.1 installation. > jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3197 > URL: https://issues.jboss.org/browse/WFCORE-3197 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.Final > Environment: centOs > Reporter: Nuno Godinho de Matos > Assignee: Tomaz Cerar > Priority: Trivial > > Hi, I am currently migrating some windows batch scripts associated to an automated create domain/stanadlone process. > One of these scripts, consists on faclitating the user to invoke the jboss cli to run a cli file. > While on windows the script is natrually working. > On linux centOs, the script immediately broke with the error: > {panel} > [johnDoe@localhost bin]$ sh 01_invoke_cli_file_script.sh "file99.sh" > ********************************************************** > SETUP CORE ENV VARIABLES > ********************************************************** > SET_CORE_ENV_VARS_SCRIPT_PATH=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin > CURRENT_WILDFLY_DOMAIN_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/.. > WILDFLY_DOMAINS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../.. > WILDFLY_USER_PROJECTS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../.. > WILDFLY_BASE_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../.. > WILDFLY_BIN_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../../bin > ********************************************************** > INVOKE jboss-cli.bat with script file: "file99.sh" > ********************************************************** > Error: Unable to access jarfile /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/jboss-modules.jar > <----- this some additional informaiton I am printing to make the point > RESOLVED_JBOSS_HOME: /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain > {panel} > What the above panel shows is that the RESOLVED_JBOSS_HOME is not being properly set. > This clearly constrasts with the windows behavior, where my base script can correctly invoke a : > call jboss-cli.bat -f someFilepath > and not break. > The reason for this seems that that while on windows, the script correctly makes no assumption on where the current working directory of the user is. > And only cares about the current location of the jboss-cli.bat script itself. > {panel} > if "%OS%" == "Windows_NT" ( > set "DIRNAME=%~dp0%" <-------- This here is a good approach > ) else ( > set DIRNAME=.\ > ) > {panel} > On linux, the same is not being done: > {panel} > # Setup JBOSS_HOME > RESOLVED_JBOSS_HOME=`cd "$DIRNAME/.."; pwd` <-------- This is not a good approach if dirname is calculated based on the command line DIRNAME=`dirname "$0"` > if [ "x$JBOSS_HOME" = "x" ]; then > # get the full path (without any relative bits) > JBOSS_HOME=$RESOLVED_JBOSS_HOME > else > SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME"; pwd` > if [ "$RESOLVED_JBOSS_HOME" != "$SANITIZED_JBOSS_HOME" ]; then > echo "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." > echo "" > fi > fi > export JBOSS_HOME > {panel} > I would suggest that linux scripts shouild cross cuttingly assume nothing about current working directory and do something like: > {code} > #DIRNAME=`dirname "$0"` > DIRNAME="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" > {code} > Since I do not want to be corrupting my wildfly installation and I want to leave all scripts completely untouched, I will be changing my script invocation from: > {panel} > # source "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > /bin/bash "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > {panel} > Which is not Ideal, since in some scripts I may want to set in my run time environment variables like JAVA_OPTS to override the default ones used on start up of an app server. > So for me, in the ideal case, I would like to be able to use the source command to run any arbitrary script in the /bin folder without my current directory location playing any relevant role. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3197) jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar

by Tomaz Cerar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3197?page=com.atlassian.jira.plugi... ] Tomaz Cerar updated WFCORE-3197: -------------------------------- Affects Version/s: 2.2.0.Final (was: 3.0.0.Beta31) > jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3197 > URL: https://issues.jboss.org/browse/WFCORE-3197 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 2.2.0.Final > Environment: centOs > Reporter: Nuno Godinho de Matos > Assignee: Tomaz Cerar > Priority: Trivial > > Hi, I am currently migrating some windows batch scripts associated to an automated create domain/stanadlone process. > One of these scripts, consists on faclitating the user to invoke the jboss cli to run a cli file. > While on windows the script is natrually working. > On linux centOs, the script immediately broke with the error: > {panel} > [johnDoe@localhost bin]$ sh 01_invoke_cli_file_script.sh "file99.sh" > ********************************************************** > SETUP CORE ENV VARIABLES > ********************************************************** > SET_CORE_ENV_VARS_SCRIPT_PATH=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin > CURRENT_WILDFLY_DOMAIN_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/.. > WILDFLY_DOMAINS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../.. > WILDFLY_USER_PROJECTS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../.. > WILDFLY_BASE_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../.. > WILDFLY_BIN_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../../bin > ********************************************************** > INVOKE jboss-cli.bat with script file: "file99.sh" > ********************************************************** > Error: Unable to access jarfile /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/jboss-modules.jar > <----- this some additional informaiton I am printing to make the point > RESOLVED_JBOSS_HOME: /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain > {panel} > What the above panel shows is that the RESOLVED_JBOSS_HOME is not being properly set. > This clearly constrasts with the windows behavior, where my base script can correctly invoke a : > call jboss-cli.bat -f someFilepath > and not break. > The reason for this seems that that while on windows, the script correctly makes no assumption on where the current working directory of the user is. > And only cares about the current location of the jboss-cli.bat script itself. > {panel} > if "%OS%" == "Windows_NT" ( > set "DIRNAME=%~dp0%" <-------- This here is a good approach > ) else ( > set DIRNAME=.\ > ) > {panel} > On linux, the same is not being done: > {panel} > # Setup JBOSS_HOME > RESOLVED_JBOSS_HOME=`cd "$DIRNAME/.."; pwd` <-------- This is not a good approach if dirname is calculated based on the command line DIRNAME=`dirname "$0"` > if [ "x$JBOSS_HOME" = "x" ]; then > # get the full path (without any relative bits) > JBOSS_HOME=$RESOLVED_JBOSS_HOME > else > SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME"; pwd` > if [ "$RESOLVED_JBOSS_HOME" != "$SANITIZED_JBOSS_HOME" ]; then > echo "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." > echo "" > fi > fi > export JBOSS_HOME > {panel} > I would suggest that linux scripts shouild cross cuttingly assume nothing about current working directory and do something like: > {code} > #DIRNAME=`dirname "$0"` > DIRNAME="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" > {code} > Since I do not want to be corrupting my wildfly installation and I want to leave all scripts completely untouched, I will be changing my script invocation from: > {panel} > # source "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > /bin/bash "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > {panel} > Which is not Ideal, since in some scripts I may want to set in my run time environment variables like JAVA_OPTS to override the default ones used on start up of an app server. > So for me, in the ideal case, I would like to be able to use the source command to run any arbitrary script in the /bin folder without my current directory location playing any relevant role. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3183) Unable to connect jboss-cli.sh using GS2-KRB5-PLUS

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3183?page=com.atlassian.jira.plugi... ] Jan Kalina commented on WFCORE-3183: ------------------------------------ Reopened, in the end will be resolved in wildfly-core. > Unable to connect jboss-cli.sh using GS2-KRB5-PLUS > -------------------------------------------------- > > Key: WFCORE-3183 > URL: https://issues.jboss.org/browse/WFCORE-3183 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta31 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Blocker > > I am unable to connect with jboss-cli.sh using GS2-KRB5-PLUS. This is not duplicity to JBEAP-12688. In this case even SASL client is not created. > In server.log I see > {code} > 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Initialized connection from /127.0.0.1:37230 to /127.0.0.1:9993 with options {org.jboss.remoting3.RemotingOptions.SASL_PROTOCOL=>remote} > 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Accepted connection from /127.0.0.1:37230 to localhost.localdomain/127.0.0.1:9993 > 17:25:10,564 TRACE [org.jboss.remoting.remote] (management I/O-2) Setting read listener to org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial@2cb6a081 > 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:25:10,564 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available > 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 28 bytes > 17:25:10,565 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel > 17:25:10,576 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 56 bytes > 17:25:10,577 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192] > 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=52 cap=8192] > 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request > 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1 > 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "cli-client" > 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported > 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.0.CR5-redhat-1" > 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40" > 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40" > 17:25:10,577 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service > 17:25:10,580 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer > 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism GS2-KRB5-PLUS > 17:25:10,583 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism PLAIN > 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available > 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 88 bytes > 17:25:10,583 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel > 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available > 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:25:10,637 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available > 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header > 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers > 17:25:10,638 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received EOF > 17:25:10,638 TRACE [org.jboss.remoting.remote] (management I/O-2) Received connection end-of-stream > 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) CLI executor output: > 17:25:10,971 INFO [org.jboss.eapqe.krbldap.utils.CustomCLIExecutor] (main) Failed to connect to the controller: Unable to authenticate against controller at localhost.localdomain:9993: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported > {code} > In jboss-cli.log I see. > {code} > 17:14:21,557 TRACE [org.wildfly.security] Created SaslClient [null] for mechanisms [GS2-KRB5-PLUS] > 17:14:21,557 TRACE [org.jboss.remoting.remote.connection] Connection error detail: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:571) > 17:14:21,558 DEBUG [org.jboss.remoting.remote.connection] JBREM000200: Remote connection failed: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported > 17:14:21,559 TRACE [org.jboss.remoting.endpoint] Registered exception result: javax.security.sasl.SaslException: Authentication failed: none of the mechanisms presented by the server (GS2-KRB5-PLUS, PLAIN) are supported > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:438) > at org.jboss.remoting3.remote.ClientConnectionOpenListener$Capabilities.handleEvent(ClientConnectionOpenListener.java:242) > at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92) > at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66) > at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89) > at org.xnio.nio.WorkerThread.run(WorkerThread.java:571) > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2441) Inconsistency between DMR and XSD representation of Elytron simple-permission-mapper

by Ilia Vassilev (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2441?page=com.atlassian.jira.plugi... ] Ilia Vassilev commented on WFCORE-2441: --------------------------------------- [~brian.stansberry] Thanks! I'll open PR then. > Inconsistency between DMR and XSD representation of Elytron simple-permission-mapper > ------------------------------------------------------------------------------------ > > Key: WFCORE-2441 > URL: https://issues.jboss.org/browse/WFCORE-2441 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta7 > Reporter: Ondrej Kotek > Assignee: Ilia Vassilev > Labels: user_experience > > There are inconsistencies between DMR and XSD representation of {{constant-permission-mapper}}. > According to XSD {{permission}} must occur at least one times in {{constant-permission-mapper}}. According to DMR it is {{"nillable" => true}}. This should be unified. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3197) jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3197?page=com.atlassian.jira.plugi... ] Brian Stansberry updated WFCORE-3197: ------------------------------------- Component/s: (was: Domain Management) > jboss-cli.sh - The RESOLVED_JBOSS_HOME strategy is not robust - Unable to access jarfile jboss-modules.jar > ---------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3197 > URL: https://issues.jboss.org/browse/WFCORE-3197 > Project: WildFly Core > Issue Type: Bug > Components: Scripts > Affects Versions: 3.0.0.Beta31 > Environment: centOs > Reporter: Nuno Godinho de Matos > Assignee: Tomaz Cerar > Priority: Trivial > > Hi, I am currently migrating some windows batch scripts associated to an automated create domain/stanadlone process. > One of these scripts, consists on faclitating the user to invoke the jboss cli to run a cli file. > While on windows the script is natrually working. > On linux centOs, the script immediately broke with the error: > {panel} > [johnDoe@localhost bin]$ sh 01_invoke_cli_file_script.sh "file99.sh" > ********************************************************** > SETUP CORE ENV VARIABLES > ********************************************************** > SET_CORE_ENV_VARS_SCRIPT_PATH=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin > CURRENT_WILDFLY_DOMAIN_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/.. > WILDFLY_DOMAINS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../.. > WILDFLY_USER_PROJECTS_DIR=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../.. > WILDFLY_BASE_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../.. > WILDFLY_BIN_DIRECTORY=/home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/bin/../../../../bin > ********************************************************** > INVOKE jboss-cli.bat with script file: "file99.sh" > ********************************************************** > Error: Unable to access jarfile /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain/jboss-modules.jar > <----- this some additional informaiton I am printing to make the point > RESOLVED_JBOSS_HOME: /home/johnDoe/AppServer/wildfly-10.1.0.Final/user_projects/domains/someStandAloneDomain > {panel} > What the above panel shows is that the RESOLVED_JBOSS_HOME is not being properly set. > This clearly constrasts with the windows behavior, where my base script can correctly invoke a : > call jboss-cli.bat -f someFilepath > and not break. > The reason for this seems that that while on windows, the script correctly makes no assumption on where the current working directory of the user is. > And only cares about the current location of the jboss-cli.bat script itself. > {panel} > if "%OS%" == "Windows_NT" ( > set "DIRNAME=%~dp0%" <-------- This here is a good approach > ) else ( > set DIRNAME=.\ > ) > {panel} > On linux, the same is not being done: > {panel} > # Setup JBOSS_HOME > RESOLVED_JBOSS_HOME=`cd "$DIRNAME/.."; pwd` <-------- This is not a good approach if dirname is calculated based on the command line DIRNAME=`dirname "$0"` > if [ "x$JBOSS_HOME" = "x" ]; then > # get the full path (without any relative bits) > JBOSS_HOME=$RESOLVED_JBOSS_HOME > else > SANITIZED_JBOSS_HOME=`cd "$JBOSS_HOME"; pwd` > if [ "$RESOLVED_JBOSS_HOME" != "$SANITIZED_JBOSS_HOME" ]; then > echo "WARNING JBOSS_HOME may be pointing to a different installation - unpredictable results may occur." > echo "" > fi > fi > export JBOSS_HOME > {panel} > I would suggest that linux scripts shouild cross cuttingly assume nothing about current working directory and do something like: > {code} > #DIRNAME=`dirname "$0"` > DIRNAME="$( cd "$( dirname "${BASH_SOURCE[0]}" )" && pwd )" > {code} > Since I do not want to be corrupting my wildfly installation and I want to leave all scripts completely untouched, I will be changing my script invocation from: > {panel} > # source "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > /bin/bash "$WILDFLY_BIN_DIRECTORY/jboss-cli.sh" --file="$fileNameWithoutPrefixSuffixQuotes" > {panel} > Which is not Ideal, since in some scripts I may want to set in my run time environment variables like JAVA_OPTS to override the default ones used on start up of an app server. > So for me, in the ideal case, I would like to be able to use the source command to run any arbitrary script in the /bin folder without my current directory location playing any relevant role. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

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 August 2017