October 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5340) Unable to specify module when specifying custom JACC policy class.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-5340?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-5340: ----------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1263336|https://bugzilla.redhat.com/show_bug.cgi?id=1263336] from MODIFIED to ON_QA > Unable to specify module when specifying custom JACC policy class. > ------------------------------------------------------------------ > > Key: WFLY-5340 > URL: https://issues.jboss.org/browse/WFLY-5340 > Project: WildFly > Issue Type: Bug > Components: Security > Affects Versions: 10.0.0.Beta2 > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 10.0.0.CR1 > > > It is currently possible to specify the 'javax.security.jacc.policy.provider' system property, however it is not possible to specify a module. > From the JACC specification: - > _For each JRE of a J2EE 1.4 or later version Java EE application server, if the > system property > “javax.security.jacc.policy.provider > ” is defined, > the application server must construct an > instance of the class identified by the > system property, confirm that the > resulting object is an instance of > java.security.Policy, > and set, by calling the > java.security.Policy.setPolicy > method, the resulting object as the > corresponding Policy object u > sed by the JRE. _ > The specification only specifies that the system property identifies the class, it does not specify how. > In it's simplest form we should assume this is just a class name, in a more complex form we should allow the module to be specified. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-888) Revert changes made in SECURITY-868

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-888?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-888: -------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from MODIFIED to ON_QA > Revert changes made in SECURITY-868 > ----------------------------------- > > Key: SECURITY-888 > URL: https://issues.jboss.org/browse/SECURITY-888 > Project: PicketBox > Issue Type: Task > Affects Versions: PicketBox_4_9_1.Final > Reporter: Stefan Guilhen > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_2.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-882) Fix for SECURITY-868 breaks flush-cache capability

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-882?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-882: -------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from MODIFIED to ON_QA > Fix for SECURITY-868 breaks flush-cache capability > -------------------------------------------------- > > Key: SECURITY-882 > URL: https://issues.jboss.org/browse/SECURITY-882 > Project: PicketBox > Issue Type: Bug > Components: AS-Integration > Affects Versions: PicketBox_4_0_19.Final > Environment: EAP 6.3.3, JDV 6.1.0 > Reporter: Hisanobu Okuda > Assignee: Stefan Guilhen > > The member field ThreadLocal<CompoundInfo> validatedDomainInfo was introduced for the fix of SECURITY-868. When you are authenticated, a valid security info is stored in the field thread-locally. Then, you flushes the JAAS cache via CLI or API in another thread, org.jboss.security.authentication.JBossCachedAuthenticationManager.flushCache() is invoked, but validatedDomainInfo is not flushed properly, since it is ThreadLocal. As a result, a cached security info is re-used unexpectedly. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (SECURITY-868) Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/SECURITY-868?page=com.atlassian.jira.plug... ] RH Bugzilla Integration commented on SECURITY-868: -------------------------------------------------- Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1219778|https://bugzilla.redhat.com/show_bug.cgi?id=1219778] from MODIFIED to ON_QA > Multithread issue when validate with cached hased password + nonce credential info from JBossCachedAuthenticationManager > -------------------------------------------------------------------------------------------------------------------------- > > Key: SECURITY-868 > URL: https://issues.jboss.org/browse/SECURITY-868 > Project: PicketBox > Issue Type: Task > Components: PicketBox > Reporter: Jim Ma > Assignee: Stefan Guilhen > Fix For: PicketBox_4_9_0.Final > > Attachments: stacktraces.log > > > When the new security domain is configured with catch-type=default in standalone.xml, the validated credential will be put in the JBossCachedAuthenticationManager with principal and domaininfo value pair. In multithread environment, a new validated credential can overwrite the previous thread cached domain info. This will cause even in the same thread , the cached authentication info could not work. For example if one user login with username , password and nonce in two threads : thread A and thread B ;thread A caches the validated credential(hased password +nonce) in JBossCachedAuthenticationMessager, thread B does the authentication, then caches the validated credential (hashed password + nonce) , even it's the same user and passoword, the credential is different because the nonce is diffrent. So the new credential created in thread B will overwrite the previous value created by thread A . So in thread A, the cached validation info won't work and following validation with cached credential will all fail. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-967) Update the managed version of org.apache.aries.blueprint.noosgi in test dependencies and re-enable all of the kie-aries-blueprint tests

by Michael Reynolds (JIRA)

Michael Reynolds created DROOLS-967: --------------------------------------- Summary: Update the managed version of org.apache.aries.blueprint.noosgi in test dependencies and re-enable all of the kie-aries-blueprint tests Key: DROOLS-967 URL: https://issues.jboss.org/browse/DROOLS-967 Project: Drools Issue Type: Feature Request Reporter: Michael Reynolds Assignee: Mark Proctor Priority: Minor All of the unit tests in kie-aries-blueprint are ignored with the message to re-enable them once org.apache.aries.blueprint.noosgi 1.0.1 is out. As of right now the latest version of Blueprint noosgi is 1.1.0. Since the enforcer plugin ensures that all dependencies are managed, we just need to update the managed version and then re-enable the code for adding the namespace handler and unit tests. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5612) UnsupportedOperationException on SingletonService.getValue()

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-5612?page=com.atlassian.jira.plugin.... ] Paul Ferraro commented on WFLY-5612: ------------------------------------ Couple things: # Under which server profile does this test run? # org.wildfly.clustering.server is a private module. Singleton services should be created using the public module. e.g. https://github.com/wildfly/wildfly/blob/9.x/testsuite/integration/cluster... > UnsupportedOperationException on SingletonService.getValue() > ------------------------------------------------------------ > > Key: WFLY-5612 > URL: https://issues.jboss.org/browse/WFLY-5612 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.2.Final > Reporter: Thomas Diesler > Assignee: Paul Ferraro > > {code} > java.lang.IllegalStateException: java.lang.UnsupportedOperationException > at java.util.Collections$1.remove(Collections.java:4684) > at org.wildfly.clustering.server.singleton.SingletonService$SingletonDispatcher.getValueRef(SingletonService.java:266) > at org.wildfly.clustering.server.singleton.SingletonService.getValue(SingletonService.java:225) > at org.wildfly.clustering.server.singleton.SingletonService.getValue(SingletonService.java:69) > at org.wildfly.clustering.service.AsynchronousServiceBuilder.getValue(AsynchronousServiceBuilder.java:92) > at org.jboss.msc.service.ServiceControllerImpl.awaitValue(ServiceControllerImpl.java:1166) > at org.wildfly.camel.test.singleton.SingletonRouteTest.testSingletonService(SingletonRouteTest.java:138) > {code} > This is happening when I try to provide a code example for a singleton service like [this|https://github.com/wildfly-extras/wildfly-camel/blob/master/itests/s...] > CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/77 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ] Tomasz Adamski edited comment on WFLY-5413 at 10/30/15 12:46 PM: ----------------------------------------------------------------- To make the change that you ask for we would need a change to PersistentResourceXMLDescription class in wildfly-core which currently does not marshall default values. I don't agree with "Bug" status of this Jira though - migration is working correctly, attributes have correct values which can be checked in CLI - this is only a presentation issue. Can you switch it's type to enhancement please? was (Author: tomekadamski): To make the change that you ask for we would need a change to PersistentResourceXMLDescription class in wildfly-core which currently does not marshall default values. Will make this change when possible. I don't agree with "Bug" status of this Jira though - migration is working correctly, attributes have correct values which can be checked in CLI - this is only a presentation issue. Can you switch it's type to enhancement please? > On IIOP migration default properties are not persisted > ------------------------------------------------------ > > Key: WFLY-5413 > URL: https://issues.jboss.org/browse/WFLY-5413 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 10.0.0.CR1 > Reporter: Ondřej Chaloupka > Assignee: Ondřej Chaloupka > > If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML. > It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly. > The example of such properties which do not persist because of its default values are > * initializers: security="none" > * security: client-supports="ServerAuth" server-supports="MutualAuth" > * security: client-requires="None" server-requires="None" > * transport-config: detect-misordering="none" > * as-context: auth-method="username_password" required="false" > * sas-context caller-propagation="none" > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5536) Recovery manager is not able to recover MDB and shows warnings on each run.

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5536?page=com.atlassian.jira.plugin.... ] Jeff Mesnil updated WFLY-5536: ------------------------------ Attachment: TEST-org.jboss.as.test.jbossts.crashrec.test.JMSMdbCrashRecoveryTestCase-jta.xml log for tests related to comment https://issues.jboss.org/browse/WFLY-5536?focusedCommentId=13123928&page=... > Recovery manager is not able to recover MDB and shows warnings on each run. > --------------------------------------------------------------------------- > > Key: WFLY-5536 > URL: https://issues.jboss.org/browse/WFLY-5536 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR2 > Reporter: Hayk Hovsepyan > Assignee: Jeff Mesnil > Priority: Blocker > Attachments: MDB_JMS_XA.log, TEST-org.jboss.as.test.jbossts.crashrec.test.JMSMdbCrashRecoveryTestCase-jta.xml > > > Recovery manager is not able to recover MDB and shows warnings. > This causes to see the same warning log in server each time recovery is run. > This happens when server is crashed before transaction state is saved. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5413) On IIOP migration default properties are not persisted

by Tomasz Adamski (JIRA)

[ https://issues.jboss.org/browse/WFLY-5413?page=com.atlassian.jira.plugin.... ] Tomasz Adamski reassigned WFLY-5413: ------------------------------------ Assignee: Ondřej Chaloupka (was: Tomasz Adamski) To make the change that you ask for we would need a change to PersistentResourceXMLDescription class in wildfly-core which currently does not marshall default values. Will make this change when possible. I don't agree with "Bug" status of this Jira though - migration is working correctly, attributes have correct values which can be checked in CLI - this is only a presentation issue. Can you switch it's type to enhancement please? > On IIOP migration default properties are not persisted > ------------------------------------------------------ > > Key: WFLY-5413 > URL: https://issues.jboss.org/browse/WFLY-5413 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 10.0.0.CR1 > Reporter: Ondřej Chaloupka > Assignee: Ondřej Chaloupka > > If there are some enumeration set in {{jacorb}} subsystem that should be migrate to new {{iiop}} subsystem with the {{:migrate}} operation then if value of such property matches the the defaults set for the new {{iiop}} such property with value is not persisted to XML. > It would be nice if properties would be persisted for user can see what's happened after migration directly and not being confused that migration forgot for some value. Or he will need to check what are defaults and if all settings was migrated correctly. > The example of such properties which do not persist because of its default values are > * initializers: security="none" > * security: client-supports="ServerAuth" server-supports="MutualAuth" > * security: client-requires="None" server-requires="None" > * transport-config: detect-misordering="none" > * as-context: auth-method="username_password" required="false" > * sas-context caller-propagation="none" > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-5536) Recovery manager is not able to recover MDB and shows warnings on each run.

by Jeff Mesnil (JIRA)

[ https://issues.jboss.org/browse/WFLY-5536?page=com.atlassian.jira.plugin.... ] Jeff Mesnil commented on WFLY-5536: ----------------------------------- There was an issue in the WildFly module definitions and the Artemis RA was using the default Artemis XAResourceWrapper instead of the one specific to WildFly. Before, the trace was: {noformat} 16:58:57,500 TRACE [org.apache.activemq.artemis.ra] (EJB default - 2) XAResource=org.apache.activemq.artemis.service.extensions.xa.ActiveMQXAResourceWrapperImpl@3696bea {noformat} After the change (to import the services defined in the messaging-activemq extension) in https://github.com/wildfly/wildfly/compare/master...jmesnil:WFLY-5536_rec..., I now see: {noformat} 17:17:26,576 TRACE [org.apache.activemq.artemis.ra] (EJB default - 4) XAResource=org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper@7cd8de4e {noformat} This org.jboss.activemq.artemis.wildfly.integration.WildFlyActiveMQXAResourceWrapper class implants org.jboss.tm.XAResourceWrapper while its superclass is not implementing it. However even with that change, the test is still failing. For one transaction I can see that the Artemis RA start, ends and commits its xares: {noformat} 17:16:03,598 TRACE [org.apache.activemq.artemis.ra] (EJB default - 5) start(< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80104:2ff694c:563397b2:1d, node_name=1, branch_uid=0:ffffc0a80104:2ff694c:563397b2:22, subordinatenodename=null, eis_name=java:/JmsXA NodeId:7a934c2e-7f21-11e5-83e2-a7afda8ee76d >, 0) ... 17:16:03,616 TRACE [org.apache.activemq.artemis.ra] (EJB default - 5) end(< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80104:2ff694c:563397b2:1d, node_name=1, branch_uid=0:ffffc0a80104:2ff694c:563397b2:22, subordinatenodename=null, eis_name=java:/JmsXA NodeId:7a934c2e-7f21-11e5-83e2-a7afda8ee76d >, 67108864) ... 17:16:03,618 TRACE [org.apache.activemq.artemis.ra] (EJB default - 5) commit(< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80104:2ff694c:563397b2:1d, node_name=1, branch_uid=0:ffffc0a80104:2ff694c:563397b2:22, subordinatenodename=null, eis_name=java:/JmsXA NodeId:7a934c2e-7f21-11e5-83e2-a7afda8ee76d >, true) {noformat} But for the transaction that's making the test fail (0:ffffc0a80104:2ff694c:563397b2:25), I see not such start/end/commit logs. I only see: {noformat} 17:16:36,390 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016037: Could not find new XAResource to use for recovering non-serializable XAResource XAResourceRecord < resource:null, txid:< formatId=131077, gtrid_length=29, bqual_length=36, tx_uid=0:ffffc0a80104:2ff694c:563397b2:25, node_name=1, branch_uid=0:ffffc0a80104:2ff694c:563397b2:28, subordinatenodename=null, eis_name=java:/JmsXA NodeId:null >, heuristic: TwoPhaseOutcome.FINISH_OK, product: ActiveMQ Artemis/1.1.0.wildfly.007, jndiName: java:/JmsXA NodeId:null com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@eabf2ff > {noformat} > Recovery manager is not able to recover MDB and shows warnings on each run. > --------------------------------------------------------------------------- > > Key: WFLY-5536 > URL: https://issues.jboss.org/browse/WFLY-5536 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.CR2 > Reporter: Hayk Hovsepyan > Assignee: Jeff Mesnil > Priority: Blocker > Attachments: MDB_JMS_XA.log > > > Recovery manager is not able to recover MDB and shows warnings. > This causes to see the same warning log in server each time recovery is run. > This happens when server is crashed before transaction state is saved. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

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 October 2015