August 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-3216) Elytron - Unable to create security domain without a realm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3216?page=com.atlassian.jira.plugi... ] Jan Kalina updated WFCORE-3216: ------------------------------- Labels: (was: eap7.1.0-to-prd) > Elytron - Unable to create security domain without a realm > ---------------------------------------------------------- > > Key: WFCORE-3216 > URL: https://issues.jboss.org/browse/WFCORE-3216 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.1.Final > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > > It's not possible to create an Elytron security domain without a security realm (default-realm attribute is mandatory). > When an administrator wants to allow just ANONYMOUS access, he/she has to use a dummy security realm to configure such a security domain. It should be possible to have domain without realms too. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1352) Simple permission mapper is not simple due to lack of default fallback

by David Lloyd (JIRA)

David Lloyd created ELY-1352: -------------------------------- Summary: Simple permission mapper is not simple due to lack of default fallback Key: ELY-1352 URL: https://issues.jboss.org/browse/ELY-1352 Project: WildFly Elytron Issue Type: Bug Reporter: David Lloyd Assignee: David Lloyd Priority: Blocker Certain common constructs are unnecessarily complicated or effectively impossible for everyday users to configure in the management model (such as "if these principals match, use these permissions, else use these permissions") due to the lack of backend support for a default case in the {{SimplePermissionMapper}}. Add a way to introduce a {{Mapping}} which matches all principals. The most general way to do this simply is to change the principal set into a principal predicate. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1717) Concurrency problems with enum constraints in MVEL

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1717?page=com.atlassian.jira.plugi... ] Mario Fusco updated DROOLS-1717: -------------------------------- Sprint: 2017 Week 34-35 > Concurrency problems with enum constraints in MVEL > -------------------------------------------------- > > Key: DROOLS-1717 > URL: https://issues.jboss.org/browse/DROOLS-1717 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.2.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Labels: concurrency > > Having a test case like this [1], it sometimes fails on > java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] > [Near : {... enumValue == AnEnum.SECOND ....}] > ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. > Tested with mvel 2.2.8 on 6.5.x branch, 2.3.0 and 2.3.1 on master branch. > [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af > [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 > [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1717) Concurrency problems with enum constraints in MVEL

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1717?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1717: ------------------------------------- [~tzimanyi] I think I fixed the problem in mvel with this commit https://github.com/mvel/mvel/commit/061ce2dab4e3ce4bdc8bca67873f9e09e985adc2 I let your reproducer running for more than 10K times and couldn't reproduce this issue anymore. Please confirm that this is ok also for you and I'll drop another stable release of mvel asap. > Concurrency problems with enum constraints in MVEL > -------------------------------------------------- > > Key: DROOLS-1717 > URL: https://issues.jboss.org/browse/DROOLS-1717 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.2.0.Final > Reporter: Tibor Zimányi > Assignee: Mario Fusco > Labels: concurrency > > Having a test case like this [1], it sometimes fails on > java.lang.RuntimeException: java.util.concurrent.ExecutionException: [Error: unable to resolve method using strict-mode: org.drools.compiler.integrationtests.facts.FactWithEnum.AnEnum()] > [Near : {... enumValue == AnEnum.SECOND ....}] > ... see here [2]. When using direct imports that are commented out in the pasted example, I see very rarely also a ClassCastException. See stacktrace here [3]. > Tested with mvel 2.2.8 on 6.5.x branch, 2.3.0 and 2.3.1 on master branch. > [1] https://gist.github.com/baldimir/d0f5f21d5b1a383887c5ebfb6013e5af > [2] https://gist.github.com/baldimir/da5c9cb23fab2eae1576948c8ca2a4c8 > [3] https://gist.github.com/baldimir/72eafe3909c21e25265cd3ee9a731d8e -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-172) Initializing the StandardOutputStreams in the LogManager should account for a security manager

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-172?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-172: --------------------------------- Fix Version/s: 2.1.0.Alpha3 > Initializing the StandardOutputStreams in the LogManager should account for a security manager > ---------------------------------------------------------------------------------------------- > > Key: LOGMGR-172 > URL: https://issues.jboss.org/browse/LOGMGR-172 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > Fix For: 2.1.0.Alpha3 > > > The {{StandardOutputStreams}} is initialized in the log managers static initializer, but doesn't account for a possible security manager. This should safely handle loading this class. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-172) Initializing the StandardOutputStreams in the LogManager should account for a security manager

by James Perkins (JIRA)

James Perkins created LOGMGR-172: ------------------------------------ Summary: Initializing the StandardOutputStreams in the LogManager should account for a security manager Key: LOGMGR-172 URL: https://issues.jboss.org/browse/LOGMGR-172 Project: JBoss Log Manager Issue Type: Bug Reporter: James Perkins Assignee: James Perkins The {{StandardOutputStreams}} is initialized in the log managers static initializer, but doesn't account for a possible security manager. This should safely handle loading this class. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-172) Initializing the StandardOutputStreams in the LogManager should account for a security manager

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-172?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-172: --------------------------------- Priority: Blocker (was: Major) > Initializing the StandardOutputStreams in the LogManager should account for a security manager > ---------------------------------------------------------------------------------------------- > > Key: LOGMGR-172 > URL: https://issues.jboss.org/browse/LOGMGR-172 > Project: JBoss Log Manager > Issue Type: Bug > Reporter: James Perkins > Assignee: James Perkins > Priority: Blocker > > The {{StandardOutputStreams}} is initialized in the log managers static initializer, but doesn't account for a possible security manager. This should safely handle loading this class. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1351) Elytron - Unable to create security domain without a realm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1351?page=com.atlassian.jira.plugin.s... ] Jan Kalina moved JBEAP-12928 to ELY-1351: ----------------------------------------- Project: WildFly Elytron (was: JBoss Enterprise Application Platform) Key: ELY-1351 (was: JBEAP-12928) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Authentication Server (was: Security) Affects Version/s: 1.2.0.Beta1 (was: 7.1.0.ER1) > Elytron - Unable to create security domain without a realm > ---------------------------------------------------------- > > Key: ELY-1351 > URL: https://issues.jboss.org/browse/ELY-1351 > Project: WildFly Elytron > Issue Type: Bug > Components: Authentication Server > Affects Versions: 1.2.0.Beta1 > Reporter: Jan Kalina > Assignee: Jan Kalina > Priority: Critical > Labels: eap7.1.0-to-prd > > It's not possible to create an Elytron security domain without a security realm (default-realm attribute is mandatory). > When an administrator wants to allow just ANONYMOUS access, he/she has to use a dummy security realm to configure such a security domain. It should be possible to have domain without realms too. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-171) Add a PlatformLoggingMXBean implementation

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-171?page=com.atlassian.jira.plugin... ] James Perkins commented on LOGMGR-171: -------------------------------------- This actually might not be replaceable the more I look at the implementation details. I thought it would working using the standard {{ServiceLoader}} SPI. However this does not seem to be the case. In OpenJDK 8 this always seems to use the {{java.util.logging.LoggingProxyImpl}} which delegates to the {{LogManager.getLoggingMXBean()}}. Currently the {{org.jboss.logmanager.LogManager}} hacks doesn't seem to be setting the correct bean. While looking at this it does look like {{org.jboss.logmanager.LogManager}} doesn't fully adhere to the {{java.util.logging.LogManager}} contract. At least for the {{getLogger()}} and {{getParentLogger()}} methods. At this point it's likely something we can't change, but it also means the contracts for the {{PlatformLoggingMXBean}} are also incorrect unless there is a way to actually override the default implementation. > Add a PlatformLoggingMXBean implementation > ------------------------------------------ > > Key: LOGMGR-171 > URL: https://issues.jboss.org/browse/LOGMGR-171 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Perkins > Assignee: James Perkins > > The {{LoggingMXBean}} is deprecated in Java 9. The {{PlatformLoggingMXBean}} has been available since Java 7 and should be implemented to be better context aware for JBoss Log Manager. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8954) Wildfly 10 with eclipselink Onscucess observer gets stale entity

by Nuno Godinho de Matos (JIRA)

[ https://issues.jboss.org/browse/WFLY-8954?page=com.atlassian.jira.plugin.... ] Nuno Godinho de Matos edited comment on WFLY-8954 at 8/31/17 12:14 PM: ----------------------------------------------------------------------- Hi, As requested, there is now a branch based on the master with the source code to run the discussed test. The following branch comparison shows the changes. https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from... This branch is called: WFLY-8954-from-master I do not have a big time window available to me. But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components. And see where I might be bale to override functionality to what you suggest. The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue. https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using. I setup a smal rest service to return me the output of: {panel} (TransactionSynchronizationRegistry) initContext .doLookup("java:comp/TransactionSynchronizationRegistry"); {panel} I get a good result. {panel} {"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@edacee0 \r\n timeToRunJndiLookup: 0 ms"}} {panel} The jndi lookup looks fast, cannot be measured in ms. If it is always like this it is perfect. Let us see how the fishing goes. Many thanks. was (Author: nuno.godinhomatos): Hi, As requested, there is now a branch based on the master with the source code to run the discussed test. The following branch comparison shows the changes. https://github.com/wildfly/wildfly/compare/master...99sono:WFLY-8954-from... This branch is called: WFLY-8954-from-master I do not have a big time window available to me. But I will now study the org.eclipse.persistence.transaction package of eclipselink, see the class architecture present within this package and the business process implemented by these components. And see where I might be bale to override functionality to what you suggest. The following image is a basic class diagram with the core components that may have to be hacked/overriden to address this issue. https://drive.google.com/open?id=0B_dEiNBGUsxqX1k1T3pqak1FSnc Ok, I supect tha to get a hold of the TransactionSynchronizationRegistry we should be using. I setup a smal rest service to return me the output of: {panel} (TransactionSynchronizationRegistry) initContext .doLookup("java:comp/TransactionSynchronizationRegistry"); {panel} I get a good result. {panel} {"value":{"type":"string","value":"The lookup returned: org.jboss.as.txn.service.internal.tsr.TransactionSynchronizationRegistryWrapper@edacee0 "}} {panel} Hopefully these jndi lookups within the container are fast. I have noticed that the MBean server in wildfly, when I clean queus on active MQ is significantly slower than on weblogic. So I am a bit afraid of expensive calls to get resources... The rest call is taking me 22 ms, on average ... the timing here is too expensive. Let us see how the fishing goes. Many thanks. > Wildfly 10 with eclipselink Onscucess observer gets stale entity > ---------------------------------------------------------------- > > Key: WFLY-8954 > URL: https://issues.jboss.org/browse/WFLY-8954 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Nuno Godinho de Matos > Assignee: Scott Marlow > > Hi, > In widlfly there seems to be an important issue concerning CDI events and observing these events during onsuccess. At least while using eclipselink. > When using wildfly 10.0.0.Final together with eclipselink, if an application modifies an entity A, fires an event stating entity A has been modified, and an observer consumes this event during transaction success. > Then the observer will be working with stale entities that do not reflect the modifications done to the entity. > A sample application for this issue is available in: > https://github.com/99sono/wildfly10-observe-on-success-stale-entity > The widlfly configuration xml for the sample application, is available in the application itself, as can be seen in the readme documentation. > Many thanks for taking a look. > Kindest regards. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 3 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira August 2017