[JBoss JIRA] (LOGMGR-141) StringIndexOutOfBoundsException throw while formatting log with truncation
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-141?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on LOGMGR-141:
------------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1350757|https://bugzilla.redhat.com/show_bug.cgi?id=1350757] from VERIFIED to CLOSED
> StringIndexOutOfBoundsException throw while formatting log with truncation
> --------------------------------------------------------------------------
>
> Key: LOGMGR-141
> URL: https://issues.jboss.org/browse/LOGMGR-141
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 1.5.7.Final, 2.0.5.Final, 2.1.0.Alpha1
>
>
> When value in left-justified field is longer than maximum width following exception is thrown:
> {code}
> java.lang.StringIndexOutOfBoundsException
> at java.lang.AbstractStringBuilder.delete(AbstractStringBuilder.java:733)
> at java.lang.StringBuilder.delete(StringBuilder.java:244)
> at org.jboss.logmanager.formatters.Formatters$JustifyingFormatStep.render(Formatters.java:212)
> at org.jboss.logmanager.formatters.MultistepFormatter.format(MultistepFormatter.java:83)
> at org.jboss.logmanager.ExtFormatter.format(ExtFormatter.java:32)
> at org.jboss.logmanager.handlers.WriterHandler.doPublish(WriterHandler.java:46)
> at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:302)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
> at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:310)
> at org.jboss.logmanager.Logger.logRaw(Logger.java:719)
> at org.jboss.logmanager.Logger.log(Logger.java:670)
> at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:50)
> at org.jboss.logging.Logger.logf(Logger.java:2096)
> {code}
> Steps to Reproduce:
> 1. Configure formatter with left-justified field with maximum width:
> {code}
> /subsystem=logging/periodic-rotating-file-handler=FILE:write-attribute(name=formatter,value="%d{HH:mm:ss,SSS} %-5p [%c{1.}] [%-20.-20t] %s%E%n")
> {code}
> (in the example above thread name should be truncated to 20 characters, left-justified)
> 2. Write a log from a thread which has a name containg 21 characters or more. During server startup logs are written by "MSC service thread 1-7" thread.
> It seems there is an error in {{org.jboss.logmanager.formatters.Formatters()}} class, line 212. There is:
> {code:java}
> builder.delete(oldLen, overflow + 1);
> {code}
> but should be:
> {code:java}
> builder.delete(oldLen, oldLen + overflow);
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2442) Incorrect realm for DIGEST-MD5 when Elytron SASL global factory is directly used
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2442?page=com.atlassian.jira.plugi... ]
Farah Juma resolved WFCORE-2442.
--------------------------------
Fix Version/s: 3.0.0.Beta26
Resolution: Done
Resolving this one since this was just a configuration issue as described in JBEAP-9029.
> Incorrect realm for DIGEST-MD5 when Elytron SASL global factory is directly used
> --------------------------------------------------------------------------------
>
> Key: WFCORE-2442
> URL: https://issues.jboss.org/browse/WFCORE-2442
> Project: WildFly Core
> Issue Type: Bug
> Components: Security
> Reporter: Ondrej Lukas
> Assignee: Farah Juma
> Priority: Blocker
> Fix For: 3.0.0.Beta26
>
>
> In case when some sasl-authentication-factory, which uses directly sasl-server-factory="global", is used for authentication and DIGEST-MD5 mechanism is used, then authentication fails. It is caused by incorrectly passed realm name used for authentication. See Steps to Reproduce for more details.
> Following is used for creating DIGEST-MD5 for authentication response (realm "localhost" is not correct used realm):
> {code}
> charset=utf-8,username="user1",realm="localhost",nonce="N7K8/KwSm/p8dxOK2LgcCBDPrhva3ILhHLQ4qWXO",nc=00000001,cnonce="MVJ6zYGtLDjffNPgt+l7OKXq62o1vu/QkPooB1EyCBxK6JiG",digest-uri="remote/localhost",maxbuf=65536,response=3acb12f0e1f42edc48e13cac8e77ae2e,qop=auth
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8973) RBAC, Security subsystem contains attributes with capabilities which don't set access-constraint.
by Stefan Guilhen (JIRA)
[ https://issues.jboss.org/browse/WFLY-8973?page=com.atlassian.jira.plugin.... ]
Stefan Guilhen updated WFLY-8973:
---------------------------------
Description:
Security subsystem contains attributes with capabilities which don't set access-constraint.
How to reproduce:
{code}
/subsystem=security:read-resource-description(recursive=true)
{code}
Resources elytron-realm, elytron-key-store, elytron-trust-store, elytron-key-manager and elytron-trust-manager all contain attributes that reference a JAAS security domain and that are missing the SECURITY_DOMAIN_REF constraint.
Furthermore, these resources expose Elytron capabilities and they should also define access constraints. In the Elytron subsystem all resources exposing capabilities use constraints named "elytron-security" and the legacy subsystem resources should follow the same convention for consistency.
was:
Security subsystem contains attributes with capabilities which don't set access-constraint.
How to reproduce:
{code}
/subsystem=security:read-resource-description(recursive=true)
{code}
Resources elytron-realm, elytron-key-store, elytron-trust-store, elytron-key-manager and elytron-trust-manager all contain attributes that reference a JAAS security domain and that are missing the SECURITY_DOMAIN_REF constraint.
> RBAC, Security subsystem contains attributes with capabilities which don't set access-constraint.
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-8973
> URL: https://issues.jboss.org/browse/WFLY-8973
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Stefan Guilhen
> Assignee: Stefan Guilhen
> Priority: Critical
>
> Security subsystem contains attributes with capabilities which don't set access-constraint.
> How to reproduce:
> {code}
> /subsystem=security:read-resource-description(recursive=true)
> {code}
> Resources elytron-realm, elytron-key-store, elytron-trust-store, elytron-key-manager and elytron-trust-manager all contain attributes that reference a JAAS security domain and that are missing the SECURITY_DOMAIN_REF constraint.
> Furthermore, these resources expose Elytron capabilities and they should also define access constraints. In the Elytron subsystem all resources exposing capabilities use constraints named "elytron-security" and the legacy subsystem resources should follow the same convention for consistency.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFLY-8032) CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-8032?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration commented on WFLY-8032:
-----------------------------------------------
Petr Penicka <ppenicka(a)redhat.com> changed the Status of [bug 1195079|https://bugzilla.redhat.com/show_bug.cgi?id=1195079] from VERIFIED to CLOSED
> CheckValidConnectionSQL can open a transaction, preventing application from changing transaction isolation level (PostgreSQL)
> -----------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-8032
> URL: https://issues.jboss.org/browse/WFLY-8032
> Project: WildFly
> Issue Type: Bug
> Components: JCA
> Affects Versions: 10.1.0.Final
> Reporter: Tomas Hofman
> Assignee: Tomas Hofman
> Fix For: 11.0.0.Beta1
>
>
> PostgreSQL driver only allows changing the transaction isolation level when transaction is not opened. Under certain circumstances, an application can receive a connection with already opened transaction and an attempt to change transaction isolation level will lead to exception.
> This happens with the PostgreSQL driver and with CheckValidConnectionSQL checker configured to run a select statement to verify connections retrieved from the pool.
> The scenario is as follows:
> # A connection is retrieved from the pool for the 1st app and CheckValidConnectionSQL verifies it by running a select statement (autocommit is set to true by default). This statement is run directly via the jdbc connection, not the wrapper.
> # 1st app receives the connection, sets autocommit=false, perform some work and commits a transaction.
> # The connection is returned to the pool, {{cleanup()}} method is called on LocalManagedConnection wrapper, which sets autocommit=true. This however doesn't reset autocommit on the wrapped jdbc connection yet, which would only happen just before executing another SQL statement f.i.
> # The same connection is retrieved from the pool for the 2nd app and CheckValidConnectionSQL runs the query. Because the jdbc connection has still autocommit=false, new transaction is opened.
> # 2nd app receives the connection and calls {{setTransactionIsolation()}}, which throws an exception because the transaction is open.
> Possible solution could be that the {{cleanup()}} method propagates the autocommit=true to the wrapped jdbc connection immediately.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2993) NPE after pressing tab in CLI when adding connector in remoting subsystem
by Jean-Francois Denise (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2993?page=com.atlassian.jira.plugi... ]
Jean-Francois Denise updated WFCORE-2993:
-----------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2572
> NPE after pressing tab in CLI when adding connector in remoting subsystem
> -------------------------------------------------------------------------
>
> Key: WFCORE-2993
> URL: https://issues.jboss.org/browse/WFCORE-2993
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI, Domain Management
> Reporter: Jean-Francois Denise
> Assignee: Jean-Francois Denise
> Priority: Critical
>
> NPE [1] pops up in server log when user wants to use auto complete in remoting subsystem in CLI. This is a regression against 7.0.0.GA.
> [1]
> {code}
> [Host Controller] 13:11:22,697 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("suggest-capabilities") failed - address: ([
> [Host Controller] ("host" => "master"),
> [Host Controller] ("core-service" => "capability-registry")
> [Host Controller] ]): java.lang.NullPointerException
> [Host Controller] at org.jboss.as.controller.capability.registry.IncludingResourceCapabilityScope.getIncludingScopes(IncludingResourceCapabilityScope.java:65)
> [Host Controller] at org.jboss.as.controller.CapabilityRegistry.findSatisfactoryCapability(CapabilityRegistry.java:902)
> [Host Controller] at org.jboss.as.controller.CapabilityRegistry.hasCapability(CapabilityRegistry.java:577)
> [Host Controller] at org.jboss.as.controller.CapabilityRegistry.lambda$getDynamicCapabilityNames$7(CapabilityRegistry.java:942)
> [Host Controller] at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:174)
> [Host Controller] at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
> [Host Controller] at java.util.TreeMap$KeySpliterator.forEachRemaining(TreeMap.java:2746)
> [Host Controller] at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
> [Host Controller] at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471)
> [Host Controller] at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708)
> [Host Controller] at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> [Host Controller] at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499)
> [Host Controller] at org.jboss.as.controller.CapabilityRegistry.getDynamicCapabilityNames(CapabilityRegistry.java:951)
> [Host Controller] at org.jboss.as.server.controller.resources.CapabilityRegistryResourceDefinition.lambda$registerOperations$4(CapabilityRegistryResourceDefinition.java:182)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:978)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:724)
> [Host Controller] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:448)
> [Host Controller] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1402)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:418)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.lambda$execute$1(ModelControllerImpl.java:243)
> [Host Controller] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:263)
> [Host Controller] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:229)
> [Host Controller] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:243)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:217)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$400(ModelControllerClientOperationHandler.java:137)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:161)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:157)
> [Host Controller] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:287)
> [Host Controller] at org.wildfly.security.auth.server.SecurityIdentity.runAs(SecurityIdentity.java:244)
> [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:254)
> [Host Controller] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:225)
> [Host Controller] at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:157)
> [Host Controller] at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$1.doExecute(ManagementRequestContextImpl.java:70)
> [Host Controller] at org.jboss.as.protocol.mgmt.ManagementRequestContextImpl$AsyncTaskRunner.run(ManagementRequestContextImpl.java:160)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Host Controller] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Host Controller] at java.lang.Thread.run(Thread.java:748)
> [Host Controller] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> [Host Controller]
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months
[JBoss JIRA] (WFCORE-2995) WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2995?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-2995:
---------------------------------------
Okay it does seem reasonable to explore.
> WildFly: support logback.xml in Per-deployment Logging (instead of silently ignoring logback.xml)
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-2995
> URL: https://issues.jboss.org/browse/WFCORE-2995
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Geoffrey De Smet
> Assignee: James Perkins
>
> Wildfly currently supports the following _Per deployment logging_ configurations [1]:
> logging.properties
> jboss-logging.properties
> log4j.properties
> log4j.xml
> jboss-log4j.xml
> All of these are stale because they are based on Log4j 1.x format which died about 8 years ago (along with using properties files for logging configuration).
> Modern popular options include Logback (with SLF4J), JBoss Logging and Log4j 2.x.
> *I regularly see WildFly users (included RH employees) that struggle to configure the logging configuration of their WildFly apps.* Spring Boot does not have this problem. _To fix this, WildFly should support logback.xml for Per deployment logging too._
> When I add a logback.xml in my war's WEB-INF/classes directory and explicitly add the logback-classic.jar in WEB-INF/lib directory - which works to configure Logback in any other JVM - then WildFly ignores it (~ it says GFY). My logs doesn't show up and developing on WildfFly is a pain due to blindness.
> Fake solution: Configuring the log files per WildFly installation is not practical for developers (it is for sys admins): the log configuration should be in my war's sources on github, so other developers automatically have it without needing to jump to wildfly installation hoops (which is sometimes not possible, think OpenShift).
> Although it's ok that WildFly favors JBoss Logging, it should not dictate it and support other logging systems such as Logback too for the war files at least (= per deployment).
> [1] https://docs.jboss.org/author/display/WFLY10/Logging+Configuration
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 10 months