August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-9194) WeldLogger.componentInterceptorSupportNotAvailable returns an Exception that is never used

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9194: -------------------------------------- Summary: WeldLogger.componentInterceptorSupportNotAvailable returns an Exception that is never used Key: WFLY-9194 URL: https://issues.jboss.org/browse/WFLY-9194 Project: WildFly Issue Type: Bug Components: CDI / Weld Reporter: Brian Stansberry Assignee: Stuart Douglas Most likely the caller is forgetting to throw the exception. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9193) UndertowLogger has a number of methods that return exceptions that are never used

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9193: -------------------------------------- Summary: UndertowLogger has a number of methods that return exceptions that are never used Key: WFLY-9193 URL: https://issues.jboss.org/browse/WFLY-9193 Project: WildFly Issue Type: Bug Components: Clustering, Web (Undertow) Reporter: Brian Stansberry Assignee: Paul Ferraro Most likely the callers of these methods are neglecting to throw these exceptions. [~pferraro] At a glance the problem is in SingleSignOnSessionFactoryBuilder -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9192) InfinispanLogger executorIgnored() has no effect

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9192: -------------------------------------- Summary: InfinispanLogger executorIgnored() has no effect Key: WFLY-9192 URL: https://issues.jboss.org/browse/WFLY-9192 Project: WildFly Issue Type: Bug Components: Clustering Reporter: Brian Stansberry Assignee: Paul Ferraro The method isn't an @LogMessage method and its return value is unused. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9190) Comment out unused Logger methods

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9190: -------------------------------------- Summary: Comment out unused Logger methods Key: WFLY-9190 URL: https://issues.jboss.org/browse/WFLY-9190 Project: WildFly Issue Type: Task Reporter: Brian Stansberry Assignee: Brian Stansberry The various XXXLogger/XXXMessages classes over the years have accumulated numerous currently unused methods. That's wasted code, both in the interfaces and even more so in the generated implementations. That code wastes memory and loading it increases boot time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9191) Comment out unused Logger methods

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9191: -------------------------------------- Summary: Comment out unused Logger methods Key: WFLY-9191 URL: https://issues.jboss.org/browse/WFLY-9191 Project: WildFly Issue Type: Task Reporter: Brian Stansberry Assignee: Brian Stansberry The various XXXLogger/XXXMessages classes over the years have accumulated numerous currently unused methods. That's wasted code, both in the interfaces and even more so in the generated implementations. That code wastes memory and loading it increases boot time. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8431) Race conditions in JASPIC registration code

by István Tóth (JIRA)

[ https://issues.jboss.org/browse/WFLY-8431?page=com.atlassian.jira.plugin.... ] István Tóth commented on WFLY-8431: ----------------------------------- Is there anything I can do to get these fixes in WF 11 final ? > Race conditions in JASPIC registration code > ------------------------------------------- > > Key: WFLY-8431 > URL: https://issues.jboss.org/browse/WFLY-8431 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.1.0.Final > Environment: Centos 7 x86_64, with the included Java 8 environment > Reporter: István Tóth > Assignee: Darran Lofthouse > Attachments: GetFactoryTestCase.java > > > javax.security.auth.message.config.AuthConfigFactory and > org.jboss.security.auth.message.config.JBossAuthConfigFactory > have race conditions. > 1. javax.security.auth.message.config.AuthConfigFactory#getFactory() has a race condition. The checking and creation of the _factory object is not atomic. > I think the best and simplest solution would be to simply make the getFactory() method synchronized. (The same method in the Glassfish implmentation is synchronized) > 2. The keyTo*Map fields of the org.jboss.security.auth.message.config.JBossAuthConfigFactory are not thread safe. > Nearly all methods of this class manipulate these, without any synchronization. > In this case I believe that changing those from HashMaps to ConcurrentHashMaps should be enough to avoid the worst of the races, while incurring a negligible performance penalty. > The methods that modify the maps should also be made synchronized, or rewritten to use the > atomic ConcurrentHashMaps operations. > A possible workaround is to add a synchronized(AuthConfigFactory.class) block around the JASPIC initialization code, where the JBossAuthConfigFactory methods are called. Of course this only works if every webapp on the server can be modified this way. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-131) Generated source files with vararg arguments are not generated correctly

by James Perkins (JIRA)

James Perkins created LOGTOOL-131: ------------------------------------- Summary: Generated source files with vararg arguments are not generated correctly Key: LOGTOOL-131 URL: https://issues.jboss.org/browse/LOGTOOL-131 Project: Log Tool Issue Type: Bug Reporter: James Perkins Assignee: James Perkins Priority: Optional Fix For: 2.1.0.Beta2 Not a big issues but currently if an interface method uses varargs the implementation uses a standard array. This is not really a problem, but we should be consistent. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-130) Remove the usage of static strings from the generated source

by James Perkins (JIRA)

James Perkins created LOGTOOL-130: ------------------------------------- Summary: Remove the usage of static strings from the generated source Key: LOGTOOL-130 URL: https://issues.jboss.org/browse/LOGTOOL-130 Project: Log Tool Issue Type: Enhancement Reporter: James Perkins Assignee: James Perkins Fix For: 2.1.0.Beta2 Currently there is a private static string constant created for each message. This string is just returned in the `methodName$str()` method. Instead of creating the string constant just have the generated method return the message string. This reduces the size of the metaspace required for the class. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-129) Add a method to implementation classes that copies configures the stack trace elements

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-129?page=com.atlassian.jira.plugi... ] James Perkins reassigned LOGTOOL-129: ------------------------------------- Assignee: James Perkins > Add a method to implementation classes that copies configures the stack trace elements > -------------------------------------------------------------------------------------- > > Key: LOGTOOL-129 > URL: https://issues.jboss.org/browse/LOGTOOL-129 > Project: Log Tool > Issue Type: Enhancement > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Beta2 > > > Currently each exception that gets created gets the current stack traces, removes the first element, then sets the stack trace on the resulting exception. A method should be added to the class that handle the copying. This helps reduces the metaspace size of the objects. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3103) Embedded server doesn't close open file handles

by Jan Blizňák (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugi... ] Jan Blizňák commented on WFCORE-3103: ------------------------------------- [~luck3y], the reproducer isn't trying to find open handles, it just tries to delete files, exactly as the manual steps say: * start a CLI wrapper * start embed-server from given server path * stop embed-server * terminate CLI wrapper * try to delete given server path, ie. the files that were opened in order to start embed-server and that should no longer be opened after embed-server was stopped. So test should pass when all these steps succeeded, ie. after this jira is fixed. But the last step currently fails everytime on all Win OSes I tried because there are open files from modules dir (I don't have Win 10, but I suppose Win Server 2016 is equivalent in this case). I was using EAP 7.1.0.ER3 and also today's Wildfly 11.0.0.Beta1 (wildfly-core 3.0.0.Beta30). In case you want verbose output of the testcase, you need to download handle.exe tool from https://docs.microsoft.com/en-us/sysinternals/downloads/handle and execute the reproducer like this (the handle.exe serves only as additional info here to list locked files): {{mvn clean test "-Dwildfly.home=C:\tmp\wildfly-11.0.0.Beta1" "-Dhandle.exe=C:\tmp\handle.exe" -Dtest=ModulesFileLockingTestCase}} > Embedded server doesn't close open file handles > ----------------------------------------------- > > Key: WFCORE-3103 > URL: https://issues.jboss.org/browse/WFCORE-3103 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Modules > Reporter: Jan Blizňák > Assignee: Ken Wills > > When embedded server is started programatically (eg. via CLI wrapper) with specified jboss home, JARs from that path are opened via classloader. But these open handles are never released even after embedded server is stopped. > This causes problem in situation eg. when you want to delete that jboss home. This is exactly one of the scenarios used in EAP installer, you are not allowed to delete open files on Windows - see JBEAP-1404. > I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking > Run it with: > mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=ModulesFileLockingTestCase > Manual steps to reproduce in Java code: > * start a CLI wrapper > * start embed-server from given server path > * stop embed-server > * terminate CLI wrapper > * try to delete given server path -- 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