October 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6854) Upgrade Hibernate ORM to 5.1.2

by Gail Badner (JIRA)

[ https://issues.jboss.org/browse/WFLY-6854?page=com.atlassian.jira.plugin.... ] Gail Badner commented on WFLY-6854: ----------------------------------- I'm changing the description to upgrade to 5.1.3, because 5.1.2 contains HHH-11155. The reason for branching Hibernate 5.1 was to allow "fetch groups". In 5.0 and earlier, if any lazy property was initialized, then all lazy properties would automatically get initialized. 5.1 allows different combinations of lazy properties to be put into a "fetch group". The idea is that if any lazy property is a group is explicitly initialized, then Hibernate will initialized all properties in the fetch group. Any lazy properties that are not in the fetch group are unaffected. HHH-11155 is a bug where an update does not happen unless all lazy properties, regardless of fetch group, are initialized. This bug should be fixed before upgrading to 5.1. > Upgrade Hibernate ORM to 5.1.2 > ------------------------------ > > Key: WFLY-6854 > URL: https://issues.jboss.org/browse/WFLY-6854 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Reporter: Emmanuel Bernard > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > > This is a follow up on WFLY-6682. > After looking at the list of potential incompatibilities, we decided to not upgrade to 5.2 but instead to 5.1 to provide a smoother experience to users. > We can consider adding a 5.2 optional switch via Jipijapa if bandwidth permit but let's treat it as a second issue and have [~smarlow] lead it. > PS: I put v11Alpha1 but feel free to adjust it to any WF 11 version that fits best. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6390) Elytron integration with Batch / JBeret

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFLY-6390?page=com.atlassian.jira.plugin.... ] James Perkins reassigned WFLY-6390: ----------------------------------- Assignee: James Perkins (was: Darran Lofthouse) > Elytron integration with Batch / JBeret > ---------------------------------------- > > Key: WFLY-6390 > URL: https://issues.jboss.org/browse/WFLY-6390 > Project: WildFly > Issue Type: Feature Request > Components: Batch > Reporter: Darran Lofthouse > Assignee: James Perkins > Fix For: 11.0.0.Alpha1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-931) PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access

by Peter Skopek (JIRA)

[ https://issues.jboss.org/browse/SECURITY-931?page=com.atlassian.jira.plug... ] Peter Skopek resolved SECURITY-931. ----------------------------------- Resolution: Done https://github.com/picketbox/picketbox/pull/66 > PicketBoxMessages.authorizationFailedMessage misspelled Acces => Access > ----------------------------------------------------------------------- > > Key: SECURITY-931 > URL: https://issues.jboss.org/browse/SECURITY-931 > Project: PicketBox > Issue Type: Bug > Components: PicketBox > Reporter: Brad Maxwell > Assignee: Brad Maxwell > Priority: Minor > > Acces should be Access in : > security-spi/common/src/main/java/org/jboss/security/PicketBoxMessages.java: @Message(id = 17, value = "Acces denied: authorization failed") -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1335) Add protection in RaXmlDeployer to prevent from loading xml resource

by Brad Maxwell (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1335?page=com.atlassian.jira.plugin... ] Brad Maxwell resolved JBJCA-1335. --------------------------------- Resolution: Done merged https://github.com/ironjacamar/ironjacamar/commit/5bb9b2dd7b276f6960772b0... > Add protection in RaXmlDeployer to prevent from loading xml resource > -------------------------------------------------------------------- > > Key: JBJCA-1335 > URL: https://issues.jboss.org/browse/JBJCA-1335 > Project: IronJacamar > Issue Type: Enhancement > Components: Deployer > Affects Versions: 1.2.7.Final > Reporter: COLLIGNON Thomas > Priority: Minor > Fix For: 1.2.8.Final > > > If we place a -ra.xml in jar file, the class RaXmlDeployer will fail with "URI not hierarchical error", because it doesn't handle jar file. > The goal of this issue is prevent for loading jar file in RaXmlDeployer . > The second goal is to provide ability of overring RaXmlDeployer in custom deployer who extends this class. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1875) Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1875?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-1875: --------------------------------------- This is more than likely an issue with the {{SocketHandler}} in the log manager. I'll leave this issue open here for now until I get have a more detailed look at it. > Logstash TCP-Input throws "Bad record MAC" when trying to connect with WildFly over SSL/TLS > ------------------------------------------------------------------------------------------- > > Key: WFCORE-1875 > URL: https://issues.jboss.org/browse/WFCORE-1875 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Patrick Kleindienst > Assignee: James Perkins > Labels: jboss, logging, ssl > > I use the jboss-logmanger-ext library for transfering log records to Logstash over a secure socket. For that purpose, my Logstash TCP-Input config authenticates with WildFly by means of a self-signed certificate. However, some time after SSL handshake has started, the following exception is thrown: > {code:java} > LogManager error of type FLUSH_FAILURE: Error on flush > java.net.SocketException: Socket is closed > at sun.security.ssl.SSLSocketImpl.getOutputStream(SSLSocketImpl.java:2240) > at org.jboss.logmanager.handlers.TcpOutputStream.flush(TcpOutputStream.java:210) > at org.jboss.logmanager.handlers.UninterruptibleOutputStream.flush(UninterruptibleOutputStream.java:110) > at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:297) > at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) > at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) > at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340) > at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169) > at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104) > at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322) > at org.jboss.logmanager.Logger.logRaw(Logger.java:850) > at org.jboss.logmanager.Logger.log(Logger.java:596) > at org.jboss.stdio.AbstractLoggingWriter.write(AbstractLoggingWriter.java:71) > at org.jboss.stdio.WriterOutputStream.finish(WriterOutputStream.java:143) > at org.jboss.stdio.WriterOutputStream.flush(WriterOutputStream.java:164) > at java.io.PrintStream.write(PrintStream.java:482) > at org.jboss.stdio.StdioContext$DelegatingPrintStream.write(StdioContext.java:264) > at java.io.PrintStream.write(PrintStream.java:480) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) > at sun.nio.cs.StreamEncoder.flushBuffer(StreamEncoder.java:104) > at java.io.OutputStreamWriter.flushBuffer(OutputStreamWriter.java:185) > at java.io.PrintStream.newLine(PrintStream.java:546) > at java.io.PrintStream.println(PrintStream.java:696) > at sun.misc.HexDumpEncoder.encodeLineSuffix(HexDumpEncoder.java:116) > at sun.misc.CharacterEncoder.encodeBuffer(CharacterEncoder.java:297) > at sun.security.ssl.CipherBox.encrypt(CipherBox.java:306) > at sun.security.ssl.OutputRecord.encrypt(OutputRecord.java:264) > at sun.security.ssl.SSLSocketImpl.writeRecordInternal(SSLSocketImpl.java:859) > at sun.security.ssl.SSLSocketImpl.writeRecord(SSLSocketImpl.java:847) > at sun.security.ssl.AppOutputStream.write(AppOutputStream.java:123) > at org.jboss.logmanager.handlers.TcpOutputStream.write(TcpOutputStream.java:182) > at org.jboss.logmanager.handlers.UninterruptibleOutputStream.write(UninterruptibleOutputStream.java:84) > at sun.nio.cs.StreamEncoder.writeBytes(StreamEncoder.java:221) > at sun.nio.cs.StreamEncoder.implFlushBuffer(StreamEncoder.java:291) > at sun.nio.cs.StreamEncoder.implFlush(StreamEncoder.java:295) > at sun.nio.cs.StreamEncoder.flush(StreamEncoder.java:141) > at java.io.OutputStreamWriter.flush(OutputStreamWriter.java:229) > at org.jboss.logmanager.ext.handlers.SocketHandler.safeFlush(SocketHandler.java:340) > at org.jboss.logmanager.ext.handlers.SocketHandler.flush(SocketHandler.java:169) > at org.jboss.logmanager.ExtHandler.doPublish(ExtHandler.java:104) > at org.jboss.logmanager.ext.handlers.SocketHandler.doPublish(SocketHandler.java:159) > at org.jboss.logmanager.ExtHandler.publish(ExtHandler.java:76) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:314) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322) > at org.jboss.logmanager.LoggerNode.publish(LoggerNode.java:322) > at org.jboss.logmanager.Logger.logRaw(Logger.java:850) > at org.jboss.logmanager.Logger.log(Logger.java:802) > at org.jboss.logging.JBossLogManagerLogger.doLogf(JBossLogManagerLogger.java:53) > at org.jboss.logging.Logger.logf(Logger.java:2398) > at org.jboss.msc.service.ServiceLogger_$logger.greeting(ServiceLogger_$logger.java:65) > at org.jboss.msc.service.ServiceContainerImpl.<clinit>(ServiceContainerImpl.java:93) > at org.jboss.msc.service.ServiceContainer$Factory.create(ServiceContainer.java:258) > at org.jboss.as.server.BootstrapImpl$ShutdownHook.register(BootstrapImpl.java:214) > {code} > > On the Logstash side, the following error message appears in the logs: > {code} > :message=>"An error occurred. Closing connection", :exception=>#<IOError: bad record MAC> > {code} > Afterwards, WildFly hangs forever without deploying my webapp or doing anything else. Before that happens, the handshake goes through these phases: > * *** ClientHello, TLSv1.2 > * *** ServerHello, TLSv1.2 > * %% Initialized: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256] > * Found trusted certificate > * *** ECDH ServerKeyExchange > * *** ServerHelloDone > * *** ECDHClientKeyExchange > * SESSION KEYGEN: > * CONNECTION KEYGEN: > * *** Finished > > When disabling SSL both on WildFly and Logstash side, everything works fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ] Radoslav Husar commented on WFCORE-1836: ---------------------------------------- Actually, the issue still holds. What we need is different set of attribute checkers for the same path but different operations since there is and add and write-attribute ops at the same address. What I am doing in WFLY-7362 still a workaround. > Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-1836 > URL: https://issues.jboss.org/browse/WFCORE-1836 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Paul Ferraro > Assignee: Brian Stansberry > > For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails. > This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1836) Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1836?page=com.atlassian.jira.plugi... ] Radoslav Husar reopened WFCORE-1836: ------------------------------------ > Rejection-style transformer tests assume each operation generated by parser has distinct PathAddress > ---------------------------------------------------------------------------------------------------- > > Key: WFCORE-1836 > URL: https://issues.jboss.org/browse/WFCORE-1836 > Project: WildFly Core > Issue Type: Bug > Components: Test Suite > Reporter: Paul Ferraro > Assignee: Brian Stansberry > > For rejection-style transformer tests, the subsystem test framework stores expected rejected operations in a map keyed by PathAddress. This is fine when the subsystem's parser only generates add operations. However, if the parser generates an add operation as well as a a write-attribute operation, these 2 operations will have the same path address. If we expect one of these operations to be rejected, but not the other, we end up with an unexpected rejection - and the test fails. > This is a little hard to explain in the abstract, so let me know if any of the above doesn't make sense. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (SECURITY-927) Option roleRecursion does not work in LdapRolesMappingProvider

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-927?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-927: -------------------------------------------------- Peter Palaga <ppalaga(a)redhat.com> changed the Status of [bug 1269826|https://bugzilla.redhat.com/show_bug.cgi?id=1269826] from POST to MODIFIED > Option roleRecursion does not work in LdapRolesMappingProvider > -------------------------------------------------------------- > > Key: SECURITY-927 > URL: https://issues.jboss.org/browse/SECURITY-927 > Project: PicketBox > Issue Type: Bug > Components: JBossSX > Affects Versions: PicketBox_5_0_0.Alpha2 > Reporter: Ondrej Lukas > Assignee: Ryan Emerson > > Option roleRecursion does not work in org.jboss.security.mapping.providers.role.LdapRolesMappingProvider. Only entries without recursion are found. No recursive search is done by LdapRolesMappingProvider since LdapRolesMappingProvider.rolesSearch method tries to make a recursive search with same parameters. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-96) Static & default interface methods in Logger interface require annotation

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-96?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGTOOL-96: -------------------------------------- I'll make sure to do a release soon. Hopefully I can get to it this week as it has been a while. > Static & default interface methods in Logger interface require annotation > ------------------------------------------------------------------------- > > Key: LOGTOOL-96 > URL: https://issues.jboss.org/browse/LOGTOOL-96 > Project: Log Tool > Issue Type: Bug > Reporter: Radim Vansa > Assignee: James Perkins > Fix For: 2.1.0.Alpha1 > > > When I want to add a static helper method to the interface used for message logger, I get an error about requiring the @Message annotation. I think that this should not be required for static methods. > My usecase: > {code} > @MessageLogger(projectCode = "FOO") > public interface FooMessageLogger extends BasicLogger { > static FooMessageLogger getLog(Class clazz) { > return Logger.getMessageLogger(FooMessageLogger.class, clazz.getName()); > } > /* regular annotated logging methods */ > } > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 months

1
0
0 / 0

[JBoss JIRA] (ELY-636) No log messages comming from Elytron - principal mapping

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-636?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-636: ------------------------------ Assignee: Jan Kalina (was: Darran Lofthouse) > No log messages comming from Elytron - principal mapping > -------------------------------------------------------- > > Key: ELY-636 > URL: https://issues.jboss.org/browse/ELY-636 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta9 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > > Elytron is missing any log messages related to principal mapping. These log messages should be added. See JBEAP-6041 for more details. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 6 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 October 2016