[JBoss JIRA] (LOGMGR-125) Log rotation fails on Windows if target already exists
by Dennis Reed (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-125?page=com.atlassian.jira.plugin... ]
Dennis Reed commented on LOGMGR-125:
------------------------------------
Overwriting the existing file (which is already the current behavior on other operating systems) is the most intuitive
behavior to me. I can't think of any use cases where the current behavior on Windows would be useful.
> Log rotation fails on Windows if target already exists
> ------------------------------------------------------
>
> Key: LOGMGR-125
> URL: https://issues.jboss.org/browse/LOGMGR-125
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: James Livingston
>
> PeriodicRotatingFileHandler (and others) use File.renameTo() to rename the file. That method is documented as having many implementation-defined aspects, see http://docs.oracle.com/javase/7/docs/api/java/io/File.html#renameTo%28jav...
> One that can be a problem is that on Windows, it will fail if the target file already exists. If you use a ".dd" suffix, this will occur when it rolls over to a new month. It has rarely been a problem, since most people use the year month and day so they are unique. Files.move() can replace existing files, so may be better, and some of the costs of that are likely not to be a problem with how it is using here.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1070) Improve XNIO performance for remote ejb
by Ståle Pedersen (JIRA)
Ståle Pedersen created WFCORE-1070:
--------------------------------------
Summary: Improve XNIO performance for remote ejb
Key: WFCORE-1070
URL: https://issues.jboss.org/browse/WFCORE-1070
Project: WildFly Core
Issue Type: Enhancement
Components: Remoting
Affects Versions: 2.0.0.CR7
Reporter: Ståle Pedersen
Assignee: David Lloyd
Changes where made to XNIO to improve Undertow performance, and this showed a regression on the EJB remote calls.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (LOGMGR-125) Log rotation fails on Windows if target already exists
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-125?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-125:
--------------------------------------
I guess the question is what's the correct behavior? I'd lean towards replacing myself, but you never know what different users expect. I guess currently the "new" rotated file would just be lost.
> Log rotation fails on Windows if target already exists
> ------------------------------------------------------
>
> Key: LOGMGR-125
> URL: https://issues.jboss.org/browse/LOGMGR-125
> Project: JBoss Log Manager
> Issue Type: Bug
> Reporter: James Livingston
>
> PeriodicRotatingFileHandler (and others) use File.renameTo() to rename the file. That method is documented as having many implementation-defined aspects, see http://docs.oracle.com/javase/7/docs/api/java/io/File.html#renameTo%28jav...
> One that can be a problem is that on Windows, it will fail if the target file already exists. If you use a ".dd" suffix, this will occur when it rolls over to a new month. It has rarely been a problem, since most people use the year month and day so they are unique. Files.move() can replace existing files, so may be better, and some of the costs of that are likely not to be a problem with how it is using here.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5561) Digest authentication mechanism unable to parse headers where username terminated with trailing '\'
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5561?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-5561:
-----------------------------------
Summary: Digest authentication mechanism unable to parse headers where username terminated with trailing '\' (was: Properties authentication in Security Realms does not work with username finishing with backslash)
> Digest authentication mechanism unable to parse headers where username terminated with trailing '\'
> ---------------------------------------------------------------------------------------------------
>
> Key: WFLY-5561
> URL: https://issues.jboss.org/browse/WFLY-5561
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR3
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 10.0.0.CR4
>
>
> In case when username finish with backslash then properties authentication in security realm does not work. It works correctly when backslash is used in the middle of username.
> Following expection is thrown:
> {code}
> java.lang.IllegalArgumentException: UT000025: Unexpected token 'delimiters-test", nonce' within header.
> at io.undertow.util.HeaderTokenParser.parseHeader(HeaderTokenParser.java:68)
> at io.undertow.security.impl.DigestAuthorizationToken.parseHeader(DigestAuthorizationToken.java:79)
> at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:156)
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:784)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFLY-5561) Properties authentication in Security Realms does not work with username finishing with backslash
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-5561?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse moved WFCORE-1069 to WFLY-5561:
------------------------------------------------
Project: WildFly (was: WildFly Core)
Key: WFLY-5561 (was: WFCORE-1069)
Component/s: Security
(was: Domain Management)
(was: Security)
Affects Version/s: 10.0.0.CR3
(was: 2.0.0.CR5)
Fix Version/s: 10.0.0.CR4
(was: 2.0.0.CR8)
> Properties authentication in Security Realms does not work with username finishing with backslash
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-5561
> URL: https://issues.jboss.org/browse/WFLY-5561
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 10.0.0.CR3
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 10.0.0.CR4
>
>
> In case when username finish with backslash then properties authentication in security realm does not work. It works correctly when backslash is used in the middle of username.
> Following expection is thrown:
> {code}
> java.lang.IllegalArgumentException: UT000025: Unexpected token 'delimiters-test", nonce' within header.
> at io.undertow.util.HeaderTokenParser.parseHeader(HeaderTokenParser.java:68)
> at io.undertow.security.impl.DigestAuthorizationToken.parseHeader(DigestAuthorizationToken.java:79)
> at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:156)
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:784)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1069) Properties authentication in Security Realms does not work with username finishing with backslash
by Darran Lofthouse (JIRA)
Darran Lofthouse created WFCORE-1069:
----------------------------------------
Summary: Properties authentication in Security Realms does not work with username finishing with backslash
Key: WFCORE-1069
URL: https://issues.jboss.org/browse/WFCORE-1069
Project: WildFly Core
Issue Type: Bug
Components: Domain Management, Security
Affects Versions: 2.0.0.CR5
Reporter: Darran Lofthouse
Assignee: Darran Lofthouse
Priority: Critical
Fix For: 2.0.0.CR8
In case when username finish with backslash then properties authentication in security realm does not work. It works correctly when backslash is used in the middle of username.
Following expection is thrown:
{code}
java.lang.IllegalArgumentException: UT000025: Unexpected token 'delimiters-test", nonce' within header.
at io.undertow.util.HeaderTokenParser.parseHeader(HeaderTokenParser.java:68)
at io.undertow.security.impl.DigestAuthorizationToken.parseHeader(DigestAuthorizationToken.java:79)
at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:156)
at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:784)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (WFCORE-1040) Properties authentication in Security Realms does not work with username finishing with backslash
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1040?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFCORE-1040:
-------------------------------------
Fix Version/s: 2.0.0.CR8
> Properties authentication in Security Realms does not work with username finishing with backslash
> -------------------------------------------------------------------------------------------------
>
> Key: WFCORE-1040
> URL: https://issues.jboss.org/browse/WFCORE-1040
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, Security
> Affects Versions: 2.0.0.CR5
> Reporter: Ondrej Lukas
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 2.0.0.CR8
>
>
> In case when username finish with backslash then properties authentication in security realm does not work. It works correctly when backslash is used in the middle of username.
> Following expection is thrown:
> {code}
> java.lang.IllegalArgumentException: UT000025: Unexpected token 'delimiters-test", nonce' within header.
> at io.undertow.util.HeaderTokenParser.parseHeader(HeaderTokenParser.java:68)
> at io.undertow.security.impl.DigestAuthorizationToken.parseHeader(DigestAuthorizationToken.java:79)
> at io.undertow.security.impl.DigestAuthenticationMechanism.authenticate(DigestAuthenticationMechanism.java:156)
> at org.jboss.as.domain.http.server.security.AuthenticationMechanismWrapper.authenticate(AuthenticationMechanismWrapper.java:52)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:233)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.transition(SecurityContextImpl.java:250)
> at io.undertow.security.impl.SecurityContextImpl$AuthAttempter.access$100(SecurityContextImpl.java:219)
> at io.undertow.security.impl.SecurityContextImpl.attemptAuthentication(SecurityContextImpl.java:121)
> at io.undertow.security.impl.SecurityContextImpl.authTransition(SecurityContextImpl.java:96)
> at io.undertow.security.impl.SecurityContextImpl.authenticate(SecurityContextImpl.java:89)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:50)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:198)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:784)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months
[JBoss JIRA] (LOGMGR-124) Add marker support
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/LOGMGR-124?page=com.atlassian.jira.plugin... ]
James Perkins commented on LOGMGR-124:
--------------------------------------
The JBoss Log Manager extends J.U.L. The reason for the change being large is it's not just a simple "add a Marker and an argument to one method". There are several methods that would need to be added. Then comes updating the slf4j bindings. Then deciding in if we need/want to support it in the jboss-logging facade. It's not just as simple as just adding an API for a marker.
There is a JIRA, LOGMGR-30, to add support for compression. Creating a simple zip when a file is rotated would be easy enough. Adding support for other compression algorithms would require a third-party library which might not be the end of the world. We only have a single optional dependency now so in some ways I'm a bit hesitant, but I'm starting to care less :) If you feel this is something that needs to be or should be a priority just let me know. It probably wouldn't be that difficult. Especially if we just want {{.zip}} support.
Marker support I'm honestly on the fence about. It would require quite a bit of work for something that, maybe a little more clumsy, but is achievable with standard filters.
As far replacing the log manager in WildFly that would be a huge change. We'd have to completely rewrite the logging subsystem. If you want to exclude the logging subsystem you should be able to use logback or log4j/log4j2 in a standalone server. It will not work on domain mode though as there are some dependencies on jboss-logmanager.
> Add marker support
> ------------------
>
> Key: LOGMGR-124
> URL: https://issues.jboss.org/browse/LOGMGR-124
> Project: JBoss Log Manager
> Issue Type: Feature Request
> Components: core
> Affects Versions: 2.0.2.Final
> Reporter: Rob Heine
> Priority: Optional
>
> The logging engine currently (talking about the one included in WF-9) does not support Markers (like in implementations like "logback" and/or "log4j2").
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 10 months