[JBoss JIRA] (WFLY-12090) Unknown service name jboss.ejb and txn
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12090?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12090:
---------------------------------
Fix Version/s: 17.0.0.Final
(was: 17.0.0.Beta1)
> Unknown service name jboss.ejb and txn
> --------------------------------------
>
> Key: WFLY-12090
> URL: https://issues.jboss.org/browse/WFLY-12090
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 17.0.0.Alpha1
> Reporter: Flavia Rainone
> Assignee: Flavia Rainone
> Priority: Major
> Fix For: 17.0.0.Final
>
>
> When EJBRemoting service is not started (it is LAZY), but XA recovery has, we could have the following sort of error:
> {code}
> 16:51:46,785 WARN [com.arjuna.ats.jta] (Periodic Recovery) ARJUNA016027: Local XARecoveryModule.xaRecovery got XA exception XAException.XAER_RMERR: javax.transaction.xa.XAException: WFTXN0034: Failed to acquire a connection for this operation
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.getOperationsXA(RemotingRemoteTransactionPeer.java:139)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer.recover(RemotingRemoteTransactionPeer.java:202)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:201)
> at org.wildfly.transaction.client@1.1.3.Final//org.wildfly.transaction.client.SubordinateXAResource.recover(SubordinateXAResource.java:197)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.xaRecoveryFirstPass(XARecoveryModule.java:634)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:226)
> at org.jboss.jts//com.arjuna.ats.internal.jta.recovery.arjunacore.XARecoveryModule.periodicWorkFirstPass(XARecoveryModule.java:171)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.doWorkInternal(PeriodicRecovery.java:770)
> at org.jboss.jts//com.arjuna.ats.internal.arjuna.recovery.PeriodicRecovery.run(PeriodicRecovery.java:382)
> Caused by: org.jboss.remoting3.ServiceOpenException: Unknown service name jboss.ejb
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:429)
> at org.jboss.remoting@5.0.10.Final-SNAPSHOT//org.jboss.remoting3.remote.RemoteReadListener.handleEvent(RemoteReadListener.java:46)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.jboss.xnio@3.7.2.Final-SNAPSHOT//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> at org.jboss.xnio.nio@3.7.2.Final-SNAPSHOT//org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> Suppressed: org.jboss.remoting3.ServiceOpenException: Unknown service name txn
> ... 6 more
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12051) Elytron: Ability to load the attributes of an identity from multiple sources
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12051?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12051:
---------------------------------
Fix Version/s: 17.0.0.Final
(was: 17.0.0.Beta1)
> Elytron: Ability to load the attributes of an identity from multiple sources
> ----------------------------------------------------------------------------
>
> Key: WFLY-12051
> URL: https://issues.jboss.org/browse/WFLY-12051
> Project: WildFly
> Issue Type: Feature Request
> Components: Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 17.0.0.Final
>
>
> In previous versions a {{security-domain}} was used to merge or add roles from multiple repositories. For example the roles for the users were obtained from two different ldaps and a database. All the roles were merged and the final authenticated principal belonged to all of them. The old picketbox subsystem used stacking of login modules (and password) to implement this feature. This use-case is not rare among the customers.
> This issue is avoiding migrations from the old security subsystem to elytron.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-12045) Some clustering test cases do not close JNDI InitialContext between tests
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-12045?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-12045:
---------------------------------
Fix Version/s: 17.0.0.Final
(was: 17.0.0.Beta1)
> Some clustering test cases do not close JNDI InitialContext between tests
> -------------------------------------------------------------------------
>
> Key: WFLY-12045
> URL: https://issues.jboss.org/browse/WFLY-12045
> Project: WildFly
> Issue Type: Bug
> Components: Test Suite
> Affects Versions: 17.0.0.Alpha1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Priority: Major
> Fix For: 17.0.0.Final
>
>
> The test case RemoteStatelessFailoverTestCase makes use of the helper class EJBRemoteDirectory to lookup JNDI names for beans in test cases. The EJB client then uses the resulting proxies to make invocations on the beans.
> This helper class is defined statically and initialized before any of the test cases run. Consequenty, the InitialContext created by the helper class is used across multiple test cases. The effect of this is that all of the proxies used in the test case are created from the same InitialContext. Consequently, they share a RemoteEJBDiscoveryProvider instance which is a class used to maintain information about server and module deployments which the EJB client references during invocation to find a suitable target for the invocation.
> This means that any server startup or shutdown activities are passed from one test case to another. This is not wanted as crash failures or shutdowns in one test will contaminate the next test, and this is exactly what is happening in a particular failure of this test.
> If your test class only involves one test, then static usage will work, but probably not recommended.
> UPDATE: This problem is present in a few other test cases, so I have updated them.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11991) Add Hibernate ORM transformer option to transform any method parameter of type org.hibernate.engine.spi.SessionImplementor
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11991?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11991:
---------------------------------
Fix Version/s: 17.0.0.Final
(was: 17.0.0.Beta1)
> Add Hibernate ORM transformer option to transform any method parameter of type org.hibernate.engine.spi.SessionImplementor
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-11991
> URL: https://issues.jboss.org/browse/WFLY-11991
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Scott Marlow
> Assignee: Scott Marlow
> Priority: Major
> Fix For: 17.0.0.Final
>
> Attachments: afterchange.zip, beforechange.zip
>
>
> The idea is to transform any class method parameter of type org.hibernate.engine.spi.SessionImplementor, in user application, to instead use type org.hibernate.engine.spi.SharedSessionContractImplementor.
> The test case (change) is for this enhancement is [https://github.com/simkam/wildfly/compare/hibernate_transformer].
> The test case change is adding an internalNullSafeGet method that should also be transformed to use the SharedSessionContractImplementor type but was not, which led to an application failure with code:
> {code}
> public Object nullSafeGet(ResultSet rs, String[] names, SessionImplementor session, Object owner) throws HibernateException, SQLException {
> return internalNullSafeGet(rs, names, session, owner);
> }
> private Object internalNullSafeGet(ResultSet rs, String[] names, SessionImplementor session, Object owner) throws HibernateException, SQLException {
> internalSessionImplementorUsingMethod(session);
> session.isTransactionInProgress();
> int result = rs.getInt( names[0] );
> if ( rs.wasNull() ) return null;
> return State.values()[result];
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11935) Remove unused commons-cli, commons-lang and commons-lang3 modules
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11935?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11935:
---------------------------------
Fix Version/s: 17.0.0.Final
(was: 17.0.0.Beta1)
> Remove unused commons-cli, commons-lang and commons-lang3 modules
> -----------------------------------------------------------------
>
> Key: WFLY-11935
> URL: https://issues.jboss.org/browse/WFLY-11935
> Project: WildFly
> Issue Type: Task
> Components: JSF, Server
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Major
> Fix For: 17.0.0.Final
>
>
> Currently WildFly includes 3 JBoss Modules modules that are not used in our runtime. I would like to remove these in WildFly 17:
> org.apache.commons.cli
> org.apache.commons.lang[1]
> org.apache.commons.lang3
> All three have the "jboss.api" = "private" property set in their module.xml, meaning they are marked for internal use only and we are free to remove them. End user applications should not have referenced these modules, and if they do we log a WARN on boot advising not to do that.
> However, other projects that extend WildFly (i.e. write their own subsystems) may be using these modules, so I sent out a notification that these may be going away:
> http://lists.jboss.org/pipermail/wildfly-dev/2019-April/006829.html
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11720) Cannot invoke EJB over HTTP on JDK 11
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11720?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11720:
---------------------------------
Fix Version/s: 17.0.0.Beta1
(was: 18.0.0.Beta1)
> Cannot invoke EJB over HTTP on JDK 11
> -------------------------------------
>
> Key: WFLY-11720
> URL: https://issues.jboss.org/browse/WFLY-11720
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Remoting
> Affects Versions: 16.0.0.Beta1
> Environment: JDK 11
> Reporter: Jan Kasik
> Assignee: Cheng Fang
> Priority: Critical
> Fix For: 17.0.0.Beta1
>
> Attachments: classes.zip, client-app.zip
>
>
> Run of client app calling EJB over HTTP fails on JDK 11 with following log:
> {noformat}
> Feb 14, 2019 12:49:30 PM org.wildfly.naming.client.Version <clinit>
> INFO: WildFly Naming version 1.0.6.Final
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by org.wildfly.security.manager.GetAccessibleDeclaredFieldAction (file:/home/hudson/hudson_workspace/mod_cluster/client/wildfly-elytron-1.1.3.Final.jar) to field java.security.AccessControlContext.context
> WARNING: Please consider reporting this to the maintainers of org.wildfly.security.manager.GetAccessibleDeclaredFieldAction
> WARNING: Use --illegal-access=warn to enable warnings of further illegal reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> Feb 14, 2019 12:49:30 PM org.wildfly.security.Version <clinit>
> INFO: ELY00001: WildFly Elytron version 1.1.3.Final
> Feb 14, 2019 12:49:30 PM org.jboss.ejb.client.EJBClient <clinit>
> INFO: JBoss EJB Client version 4.0.2.Final
> Feb 14, 2019 12:49:30 PM org.xnio.Xnio <clinit>
> INFO: XNIO version 3.6.5.Final
> Feb 14, 2019 12:49:30 PM org.xnio.nio.NioXnio <clinit>
> INFO: XNIO NIO Implementation Version 3.6.5.Final
> Feb 14, 2019 12:49:30 PM org.jboss.threads.Version <clinit>
> INFO: JBoss Threads version 2.3.0.Beta2
> Feb 14, 2019 12:49:30 PM org.jboss.remoting3.EndpointImpl <clinit>
> INFO: JBoss Remoting version 5.0.0.Final
> Feb 14, 2019 12:49:30 PM org.jboss.threads.LoggingUncaughtExceptionHandler uncaughtException
> ERROR: Thread Thread[XNIO-1 task-1,5,main] threw an uncaught exception
> java.lang.ExceptionInInitializerError
> at org.jboss.marshalling.river.RiverMarshaller.<clinit>(RiverMarshaller.java:1335)
> at org.jboss.marshalling.river.RiverMarshallerFactory.createMarshaller(RiverMarshallerFactory.java:54)
> at org.wildfly.httpclient.common.HttpTargetContext.createMarshaller(HttpTargetContext.java:132)
> at org.wildfly.httpclient.ejb.HttpEJBReceiver.marshalEJBRequest(HttpEJBReceiver.java:367)
> at org.wildfly.httpclient.ejb.HttpEJBReceiver.lambda$processInvocation$1(HttpEJBReceiver.java:185)
> at org.wildfly.httpclient.common.HttpTargetContext$1.lambda$completed$0(HttpTargetContext.java:338)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1871)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1400)
> at java.base/java.lang.Thread.run(Thread.java:834)
> Caused by: java.lang.IllegalStateException: No standard field found for reverse order comparator!
> at org.jboss.marshalling.river.Protocol.<clinit>(Protocol.java:287)
> ... 9 more
> {noformat}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
James Perkins updated WFLY-1598:
--------------------------------
Fix Version/s: 18.0.0.Final
(was: 17.0.0.Beta1)
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Management, Security
> Reporter: Darran Lofthouse
> Assignee: Farah Juma
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 18.0.0.Final
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11214) Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11214?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11214:
---------------------------------
Fix Version/s: 18.0.0.Final
(was: 17.0.0.Beta1)
> Periodic recovery does not recover XAResource after jvm crash when agroal subsystem is used
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-11214
> URL: https://issues.jboss.org/browse/WFLY-11214
> Project: WildFly
> Issue Type: Bug
> Components: Agroal, Transactions
> Reporter: Ivan Straka
> Assignee: Luis Barreiro
> Priority: Critical
> Fix For: 18.0.0.Final
>
> Attachments: JPACrashRecoveryTestCase_commitHaltSecond_jta_server.log, JPACrashRecoveryTestCase_commitHaltSecond_jts_server.log
>
>
> Scenario:
> Halts server at commit phase ...
> # enlist TestXA resource
> # enlist XA resource
> # prepare TestXA resource
> # prepare XA resource
> # commit Test XA resource
> # JVM crash
> # recovery started
> # commit XA resource
> Periodic recovery does not recover xa resource. It looks like agroal subsystem does not register xa resource to xa recovery module.
> Test outcome:
> {code:java}
> Running org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 109.002 sec <<< FAILURE! - in org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase
> commitHaltSecond(org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase) Time elapsed: 102.976 sec <<< FAILURE!
> java.lang.AssertionError: Incorrect data in database after crash recovery. expected:<2> but was:<1>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:645)
> at org.jboss.as.test.jbossts.crashrec.test.JPABaseCrashRecoveryTestCase.checkAfterTestExecution(JPABaseCrashRecoveryTestCase.java:150)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltTest(TestBaseCrashRecovery.java:485)
> at org.jboss.as.test.jbossts.crashrec.test.TestBaseCrashRecovery.commitHaltSecond(TestBaseCrashRecovery.java:418)
> at org.jboss.as.test.jbossts.crashrec.test.JPACrashRecoveryTestCase.commitHaltSecond(JPACrashRecoveryTestCase.java:76)
> {code}
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months
[JBoss JIRA] (WFLY-11101) Add CredentialStore documentation
by James Perkins (Jira)
[ https://issues.jboss.org/browse/WFLY-11101?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-11101:
---------------------------------
Fix Version/s: 18.0.0.Final
(was: 17.0.0.Beta1)
> Add CredentialStore documentation
> ---------------------------------
>
> Key: WFLY-11101
> URL: https://issues.jboss.org/browse/WFLY-11101
> Project: WildFly
> Issue Type: Task
> Components: Documentation, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Major
> Fix For: 18.0.0.Final
>
>
> The CredentialStore is a significant component within WildFly Elytron, however it is not really covered in the documentation.
> We have a couple of different approaches to creating the store, we then have referencing the store. Finally we have custom implementations.
> New features are also being developed so really we need a source of documentation to add descriptions of the new features to.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)
7 years, 2 months