May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-536) The PermissionVerifier.from methods need to be public so they can be used.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-536?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-536. ---------------------------------- Resolution: Rejected > The PermissionVerifier.from methods need to be public so they can be used. > -------------------------------------------------------------------------- > > Key: ELY-536 > URL: https://issues.jboss.org/browse/ELY-536 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta6 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-536) The PermissionVerifier.from methods need to be public so they can be used.

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-536?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-536: --------------------------------- {noformat} $ javap -cp target/wildfly-elytron-1.1.0.Beta6-SNAPSHOT.jar org/wildfly/security/permission/PermissionVerifier Compiled from "PermissionVerifier.java" public interface org.wildfly.security.permission.PermissionVerifier { public static final org.wildfly.security.permission.PermissionVerifier NONE; public static final org.wildfly.security.permission.PermissionVerifier ALL; public abstract boolean implies(java.security.Permission); public org.wildfly.security.permission.PermissionVerifier and(org.wildfly.security.permission.PermissionVerifier); public org.wildfly.security.permission.PermissionVerifier or(org.wildfly.security.permission.PermissionVerifier); public org.wildfly.security.permission.PermissionVerifier xor(org.wildfly.security.permission.PermissionVerifier); public org.wildfly.security.permission.PermissionVerifier not(); public org.wildfly.security.permission.PermissionVerifier unless(org.wildfly.security.permission.PermissionVerifier); public void checkPermission(java.security.Permission) throws java.lang.SecurityException; public static org.wildfly.security.permission.PermissionVerifier from(java.security.Permission); public static org.wildfly.security.permission.PermissionVerifier from(java.security.PermissionCollection); public static org.wildfly.security.permission.PermissionVerifier from(java.security.ProtectionDomain); public static org.wildfly.security.permission.PermissionVerifier from(java.security.Policy, java.security.ProtectionDomain); public java.security.PermissionCollection toPermissionCollection(); static {}; } {noformat} > The PermissionVerifier.from methods need to be public so they can be used. > -------------------------------------------------------------------------- > > Key: ELY-536 > URL: https://issues.jboss.org/browse/ELY-536 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta6 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-536) The PermissionVerifier.from methods need to be public so they can be used.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-536?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse commented on ELY-536: -------------------------------------- Yeah looks like something in my workspace not picking them up. > The PermissionVerifier.from methods need to be public so they can be used. > -------------------------------------------------------------------------- > > Key: ELY-536 > URL: https://issues.jboss.org/browse/ELY-536 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta6 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-536) The PermissionVerifier.from methods need to be public so they can be used.

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-536?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-536: --------------------------------- Interface methods are always public. > The PermissionVerifier.from methods need to be public so they can be used. > -------------------------------------------------------------------------- > > Key: ELY-536 > URL: https://issues.jboss.org/browse/ELY-536 > Project: WildFly Elytron > Issue Type: Enhancement > Components: API / SPI > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta6 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-536) The PermissionVerifier.from methods need to be public so they can be used.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-536: ------------------------------------ Summary: The PermissionVerifier.from methods need to be public so they can be used. Key: ELY-536 URL: https://issues.jboss.org/browse/ELY-536 Project: WildFly Elytron Issue Type: Enhancement Components: API / SPI Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta6 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6363) Upgrade Infinispan to 8.2.2.Final

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6363?page=com.atlassian.jira.plugin.... ] Paul Ferraro updated WFLY-6363: ------------------------------- Summary: Upgrade Infinispan to 8.2.2.Final (was: Upgrade Infinispan to 8.2.1.Final) > Upgrade Infinispan to 8.2.2.Final > --------------------------------- > > Key: WFLY-6363 > URL: https://issues.jboss.org/browse/WFLY-6363 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Reporter: Thomas Diesler > Assignee: Paul Ferraro > Fix For: 10.1.0.Final > > > CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1137 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-535) Make use of realm events to handle password updates and resets for the OTP SASL mechanism

by Farah Juma (JIRA)

Farah Juma created ELY-535: ------------------------------ Summary: Make use of realm events to handle password updates and resets for the OTP SASL mechanism Key: ELY-535 URL: https://issues.jboss.org/browse/ELY-535 Project: WildFly Elytron Issue Type: Feature Request Components: SASL Reporter: Farah Juma Assignee: Farah Juma For the OTP SASL mechanism, the stored credential needs to be updated once a guess has been verified. In the standard case, this involves updating the stored hash based on the guess and decrementing the sequence number by 1. The OTP SASL mechanism also supports OTP sequence resets, where a user provides both a guess and a new OTP password with new parameters. If verification of the guess succeeds, then the stored credential is updated based on the new password and new parameters. However, if verification of the guess succeeds but the new password/parameters are invalid, then the stored hash is updated based on the guess and the sequence number is decremented by 1, as in the non-reset case (note that SASL auth fails in this case though). PR #277 [adds handling|https://github.com/kabir/wildfly-elytron/blob/otp-test/src/main/...] for a {{CredentialUpdateCallback}} in {{ServerAuthenticationContext}}. This is used to handle both the OTP sequence reset case as well as the non-reset case. Instead of manipulating the realm identity directly in the SAC callback handler, we should be able to make use of [realm events|https://github.com/wildfly-security/wildfly-elytron/pull/295] so that the realm itself can handle OTP updates and resets. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1180) Migrate QE tests upstream.

by Tibor Zimányi (JIRA)

Tibor Zimányi created DROOLS-1180: ------------------------------------- Summary: Migrate QE tests upstream. Key: DROOLS-1180 URL: https://issues.jboss.org/browse/DROOLS-1180 Project: Drools Issue Type: Enhancement Reporter: Tibor Zimányi Assignee: Tibor Zimányi Priority: Minor We have some regression tests in QE that could be migrated upstream. This is a tracking issue for this migration. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6620) Remove typo from BAControler interface and its implementations

by Gytis Trikleris (JIRA)

Gytis Trikleris created WFLY-6620: ------------------------------------- Summary: Remove typo from BAControler interface and its implementations Key: WFLY-6620 URL: https://issues.jboss.org/browse/WFLY-6620 Project: WildFly Issue Type: Task Components: XTS Reporter: Gytis Trikleris Assignee: Gytis Trikleris Priority: Minor -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6011) Remote branch of a transaction gets rolled back incorrectly.

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6011?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6011: ----------------------------------------------- Ondrej Chaloupka <ochaloup(a)redhat.com> changed the Status of [bug 1298161|https://bugzilla.redhat.com/show_bug.cgi?id=1298161] from ON_QA to VERIFIED > Remote branch of a transaction gets rolled back incorrectly. > ------------------------------------------------------------- > > Key: WFLY-6011 > URL: https://issues.jboss.org/browse/WFLY-6011 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Jason Greene > Assignee: David Lloyd > > The use case is as follow: > Client makes a call to a bean on server-1 > bean (server-1) inserts a row into table-1 > bean (server-1) calls to a bean on server-2 > bean (server-2) inserts a row into table-2 > bean (server-2) goes to sleep for 3 minutes > periodic recovery (server-1) flags the remote branchof the transaction (on server-2) as in doubt and rolls it back. > (server-1 log) > {noformat} > 11:53:37,991 TRACE [com.arjuna.ats.arjuna] (Periodic Recovery) RecoveryXids _whenFirstSeen toRecover no RecoveryOnlyEJBXAResource{receiverContext=EJBReceiverContext{clientContext=org.jboss.ejb.client.EJBClientContext@322f7790, receiver=Remoting connection EJB receiver [connection=Remoting connection <2c1ab3f6>,channel=jboss.ejb,nodename=server2]}, transactionOriginNodeIdentifier='server1'} 1452599607985 === 1452599617991 > 11:53:37,991 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Have 1 Xids to recover on this pass. > 11:53:37,992 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) No record found for < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > > 11:53:37,992 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTATransactionLogXAResourceOrphanFilter voted ABSTAIN > 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) node name of < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > is server1 > 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) XAResourceOrphanFilter com.arjuna.ats.internal.jta.recovery.arjunacore.JTANodeNameXAResourceOrphanFilter voted ROLLBACK > 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) subordinate node name of < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > is server2 > 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Checking whether Xid < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > exists in ObjectStore. > 11:53:37,993 DEBUG [com.arjuna.ats.jta] (Periodic Recovery) Looking for 0:ffffc0a80164:-fa2e9db:5694e833:2c and /StateManager/BasicAction/TwoPhaseCoordinator/AtomicAction/SubordinateAtomicAction/JCA > 11:53:37,993 INFO [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016013: Rolling back < formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-fa2e9db:5694e833:39, subordinatenodename=server2, eis_name=unknown eis name > > {noformat} > (server-2 log) > {noformat} > 11:53:37,997 TRACE [com.arjuna.ats.jta] (EJB default - 5) TransactionImple.getStatus: javax.transaction.Status.STATUS_ACTIVE > 11:53:37,998 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::phase2Abort() for action-id 0:ffffc0a80164:-41fcd6d0:5694e85a:34 > 11:53:37,998 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::doAbort (XAResourceRecord < resource:XAResourceWrapperImpl@3de8e444[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@6440856e pad=false overrideRmValue=false productName=PostgreSQL productVersion=9.4.1 jndiName=java:jboss/datasources/testJBossDS], txid:< formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-41fcd6d0:5694e85a:3e, subordinatenodename=server2, eis_name=java:jboss/datasources/testJBossDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.4.1, jndiName: java:jboss/datasources/testJBossDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@32ff4c6d >) > 11:53:37,998 TRACE [com.arjuna.ats.jta] (EJB default - 5) XAResourceRecord.topLevelAbort for XAResourceRecord < resource:XAResourceWrapperImpl@3de8e444[xaResource=org.jboss.jca.adapters.jdbc.xa.XAManagedConnection@6440856e pad=false overrideRmValue=false productName=PostgreSQL productVersion=9.4.1 jndiName=java:jboss/datasources/testJBossDS], txid:< formatId=131077, gtrid_length=35, bqual_length=43, tx_uid=0:ffffc0a80164:-fa2e9db:5694e833:2c, node_name=server1, branch_uid=0:ffffc0a80164:-41fcd6d0:5694e85a:3e, subordinatenodename=server2, eis_name=java:jboss/datasources/testJBossDS >, heuristic: TwoPhaseOutcome.FINISH_OK, product: PostgreSQL/9.4.1, jndiName: java:jboss/datasources/testJBossDS com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord@32ff4c6d >, record id=0:ffffc0a80164:-41fcd6d0:5694e85a:3f > 11:53:37,998 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$MyXaMCF] (EJB default - 5) Unlock: HeldByCurrentThread: Yes, Locked: Yes, HoldCount: 1, QueueLength: 0 > 11:53:37,998 TRACE [org.jboss.as.connector.subsystems.datasources.AbstractDataSourceService$MyXaMCF] (EJB default - 5) Owner: Thread[EJB default - 5,5,EJB default] > 11:53:37,999 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::doAbort() result for action-id (0:ffffc0a80164:-41fcd6d0:5694e85a:34) on record id: (0:ffffc0a80164:-41fcd6d0:5694e85a:3f) is (TwoPhaseOutcome.FINISH_OK) node id: (server2) > 11:53:37,999 TRACE [com.arjuna.ats.arjuna] (EJB default - 5) BasicAction::updateState() for action-id 0:ffffc0a80164:-41fcd6d0:5694e85a:34 > 11:53:37,999 TRACE [com.arjuna.ats.jta] (EJB default - 5) SynchronizationImple.afterCompletion > {noformat} > bean (server-2) wake up > bean (server-1) updates the row in table-1 > at this point the parent transaction gets committed without an error > {noformat} > 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) BasicAction::removeChildThread () action 0:ffffc0a80164:-fa2e9db:5694e833:2c removing TSThread:1 > 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) BasicAction::removeChildThread () action 0:ffffc0a80164:-fa2e9db:5694e833:2c removing TSThread:1 result = true > 11:55:31,104 TRACE [com.arjuna.ats.arjuna] (EJB default - 3) TransactionReaper::remove ( BasicAction: 0:ffffc0a80164:-fa2e9db:5694e833:2c status: ActionStatus.COMMITTED ) > {noformat} > client call ends > When I look at the table in the database I see a row in table-1 but no row in table-2. I would expect to see both tables empty. > When I switch to JTS and run the same use case it all works as expected. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

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