September 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-7108) UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-7108?page=com.atlassian.jira.plugin.... ] Scott Marlow updated WFLY-7108: ------------------------------- Fix Version/s: 11.0.0.Alpha1 > UNSYNCHRONIZED extended persistence context associated but not joined with JTA transaction and target component is persistence context of SYNCHRONIZED, IllegalStateException should be thrown > ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFLY-7108 > URL: https://issues.jboss.org/browse/WFLY-7108 > Project: WildFly > Issue Type: Feature Request > Components: JPA / Hibernate > Affects Versions: 10.1.0.Final > Environment: *AppServer:* WildFly 10.1.0.Final > *WildFly-jpa:* wildfly-jpa-10.1.0.Final.jar > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 11.0.0.Alpha1 > > > As we mentioned in https://issues.jboss.org/browse/WFLY-6127 we found bug and made our solution. > > *The obtained defect:* > A defect related to the check of synchronization type (to satisfy JPA spec 2.1 section 7.6.4.1) was found in WildFly 10.1.0.Final. > The Method getSynchronizationType of class ExtendedEntityManager ALWAYS returns type of synchronization as SYNCHRONIZED (jar file: wildfly-jpa-10.1.0.Final.jar) > *FIX:* > We made a fork of WildFly-jpa project at: https://github.com/argustelecom/wildfly/tree/WFLY-6127 > Our Fix commit: https://github.com/wildfly/wildfly/commit/3bff5fde3cfc23f3999dc75c320029e... > _Changes_: The method getSynchronizationType returns declared synchronization type. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1810) PeriodicSizeRotatingFileHandler's are always replaced during boot

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1810?page=com.atlassian.jira.plugi... ] James Perkins edited comment on WFCORE-1810 at 9/20/16 12:00 PM: ----------------------------------------------------------------- [~panossot] Does this issue still exist? It looks like it was resolved in WFCORE-1018. was (Author: jamezp): Does this issue still exist? It looks like it was resolved in WFCORE-1018. > PeriodicSizeRotatingFileHandler's are always replaced during boot > ----------------------------------------------------------------- > > Key: WFCORE-1810 > URL: https://issues.jboss.org/browse/WFCORE-1810 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Panagiotis Sotiropoulos > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-433: -------------------------------------- I am thinking for this issue using the serial number. Or any other information we can pull from the cert to search for the LDAP entry. The LDAP KeyStore you have written will also be an alternative so I think that covers using LDAP as a trust store. > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 1.1.0.Beta10 > > > LDAP realm should be able to authenticate user using user certificate. > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-433 at 9/20/16 11:50 AM: ---------------------------------------------------------- It is possible to do this by two ways: * To use LDAP as trust-store and to have a whole certificate of user in database * To have a CA in trust-store and authenticate users by certificate serial number (Apache HTTP server do it by this way) * Not mentioning a possibility to use same property of certificate signed by CA Which way(s) do we want to support? was (Author: honza889): It is possible to do this by two ways: * To use LDAP as trust-store and authenticate directly by whole certificate * To have a CA in trust-store and authenticate users by certificate serial number (Apache HTTP server do it by this way) Which way(s) do we want to support? > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 1.1.0.Beta10 > > > LDAP realm should be able to authenticate user using user certificate. > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-433) Support verification of a users certificate against an LDAP Server

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-433?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-433: -------------------------------- It is possible to do this by two ways: * To use LDAP as trust-store and authenticate directly by whole certificate * To have a CA in trust-store and authenticate users by certificate serial number (Apache HTTP server do it by this way) Which way(s) do we want to support? > Support verification of a users certificate against an LDAP Server > ------------------------------------------------------------------ > > Key: ELY-433 > URL: https://issues.jboss.org/browse/ELY-433 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Realms, SSL > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Fix For: 1.1.0.Beta10 > > > LDAP realm should be able to authenticate user using user certificate. > This is specifically for authentication - NOT for general TrustManager requirements - another Jira issue is tracking looking into a KeyStore implementation backed by LDAP. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1810) PeriodicSizeRotatingFileHandler's are always replaced during boot

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1810?page=com.atlassian.jira.plugi... ] James Perkins commented on WFCORE-1810: --------------------------------------- Does this issue still exist? It looks like it was resolved in WFCORE-1018. > PeriodicSizeRotatingFileHandler's are always replaced during boot > ----------------------------------------------------------------- > > Key: WFCORE-1810 > URL: https://issues.jboss.org/browse/WFCORE-1810 > Project: WildFly Core > Issue Type: Bug > Components: Logging > Reporter: Panagiotis Sotiropoulos > Assignee: James Perkins > Fix For: 2.0.0.CR6 > > > A {{periodic-size-rotating-file-handler}} will be replaced during the subsystem add operation. This could be an issue with {{async-handler}}'s where the handler may see the old handler that was closed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7123) Use elytron ssl-context for undertow default https listener

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/WFLY-7123?page=com.atlassian.jira.plugin.... ] Darran Lofthouse reassigned WFLY-7123: -------------------------------------- Assignee: Darran Lofthouse (was: Stuart Douglas) > Use elytron ssl-context for undertow default https listener > ----------------------------------------------------------- > > Key: WFLY-7123 > URL: https://issues.jboss.org/browse/WFLY-7123 > Project: WildFly > Issue Type: Bug > Components: Security, Web (Undertow) > Affects Versions: 11.0.0.Alpha1 > Reporter: Martin Choma > Assignee: Darran Lofthouse > Priority: Blocker > > Default undertow https listener use legacy ssl context in standalone-elytron.xml . > {code} > <https-listener name="https" socket-binding="https" security-realm="ApplicationRealm" enable-http2="true"/> > {code} > Once elytron becomes default security solution in wildfly it has to use elytron ssl context. In meantime prepare such configuration in standalone-elytron.xml > {code} > <https-listener name="https" socket-binding="https" ssl-context="elytron-ssl-context" enable-http2="true"/> > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6700) MBeanServer.isRegistered() fails when the security manager is enabled

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-6700?page=com.atlassian.jira.plugin.... ] Brian Stansberry reassigned WFLY-6700: -------------------------------------- Assignee: Brian Stansberry (was: Jason Greene) > MBeanServer.isRegistered() fails when the security manager is enabled > --------------------------------------------------------------------- > > Key: WFLY-6700 > URL: https://issues.jboss.org/browse/WFLY-6700 > Project: WildFly > Issue Type: Bug > Affects Versions: 10.0.0.Final > Reporter: Derek Horton > Assignee: Brian Stansberry > > Calling MBeanServer.isRegistered() in a servlet fails with the following error when the security manager is enabled: > :WFSM000001: Permission check failed (permission "("org.jboss.as.controller.access.rbac.RunAsRolePermission" "org.jboss.as.controller.access.rbac.RunAsRolePermission.SUPERUSER")" in code source "(vfs:/content/SimpleWar.war/WEB-INF/classes <no signer certificates>)" of "null") > The code looks like the following: > final MBeanServer server = ManagementFactory.getPlatformMBeanServer(); > final ObjectName mbeanName = new ObjectName("ima.test:type=imaTest"); > System.out.println("*** calling MBeanServer.isRegistered() - "+server.isRegistered(mbeanName)); > The META-INF/jboss-permissions.xml looks like the following: > <?xml version="1.0" encoding="UTF-8"?> > <permissions xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="7"> > <permission> > <class-name>javax.management.MBeanServerPermission</class-name> > <name>createMBeanServer</name> > </permission> > <permission> > <class-name>org.jboss.as.controller.access.rbac.RunAsRolePermission</class-name> > <name>*</name> > </permission> > </permissions> -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7145) Key-store atttribute read-only occures in xsd, but not in model

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFLY-7145?page=com.atlassian.jira.plugin.... ] Brian Stansberry updated WFLY-7145: ----------------------------------- Component/s: Security > Key-store atttribute read-only occures in xsd, but not in model > --------------------------------------------------------------- > > Key: WFLY-7145 > URL: https://issues.jboss.org/browse/WFLY-7145 > Project: WildFly > Issue Type: Bug > Components: Security > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Minor > > There is a attribute {{read-only}} mentioned in XSD. > {code} > <xs:attribute name="read-only" type="xs:boolean" > use="optional" default="false"> > <xs:annotation> > <xs:documentation> > When set to 'true' this attribute prevents the in-memory > representation of the file from being written back to the file. > </xs:documentation> > </xs:annotation> > </xs:attribute> > {code} > But not in model. Therefore can't be used. Is that feature related to modifiable realms, which was deffered to 7.2? So probably should be removed from XSD? -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-7155) Update Hibernate to 5.0.11

by Frank Langelage (JIRA)

[ https://issues.jboss.org/browse/WFLY-7155?page=com.atlassian.jira.plugin.... ] Frank Langelage commented on WFLY-7155: --------------------------------------- PR for 10.x is https://github.com/wildfly/wildfly/pull/9209 > Update Hibernate to 5.0.11 > -------------------------- > > Key: WFLY-7155 > URL: https://issues.jboss.org/browse/WFLY-7155 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate > Affects Versions: 10.2.0.Final, 11.0.0.Alpha1 > Reporter: Frank Langelage > Assignee: Scott Marlow > Fix For: 10.2.0.Final, 11.0.0.Beta1 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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