[JBoss JIRA] (WFCORE-3761) Deprecate OperationDefinition validateXXX methods
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-3761:
----------------------------------------
Summary: Deprecate OperationDefinition validateXXX methods
Key: WFCORE-3761
URL: https://issues.jboss.org/browse/WFCORE-3761
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Priority: Minor
The OperationDefinition validateAndSet and validateOperation methods are not used. Since the whole class will likely be replaced before we would start using these in a general way, we should deprecate them.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ELY-1529) OAuth2SaslClientV10Test or OAuth2SaslClientV11Test intermittently fails during MockWebServer binding
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1529?page=com.atlassian.jira.plugin.s... ]
Jan Kalina reassigned ELY-1529:
-------------------------------
Assignee: Jan Kalina
> OAuth2SaslClientV10Test or OAuth2SaslClientV11Test intermittently fails during MockWebServer binding
> ----------------------------------------------------------------------------------------------------
>
> Key: ELY-1529
> URL: https://issues.jboss.org/browse/ELY-1529
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Testsuite
> Affects Versions: 1.2.0.Final
> Reporter: Ondrej Lukas
> Assignee: Jan Kalina
>
> OAuth2SaslClientV10Test or OAuth2SaslClientV11Test intermittently fails during MockWebServer binding, for example for OAuth2SaslClientV10Test:
> {code}
> java.net.BindException: Address already in use (Bind failed)
> at java.net.PlainSocketImpl.socketBind(Native Method)
> at java.net.AbstractPlainSocketImpl.bind(AbstractPlainSocketImpl.java:387)
> at java.net.ServerSocket.bind(ServerSocket.java:375)
> at okhttp3.mockwebserver.MockWebServer.start(MockWebServer.java:317)
> at okhttp3.mockwebserver.MockWebServer.start(MockWebServer.java:300)
> at okhttp3.mockwebserver.MockWebServer.start(MockWebServer.java:289)
> at org.wildfly.security.sasl.oauth2.OAuth2SaslClientV10Test.onBefore(OAuth2SaslClientV10Test.java:82)
> {code}
> When this happens it causes only one of test methods to fail. Other tests in OAuth2SaslClientV10Test/OAuth2SaslClientV11Test finish successfully. It seems this test issue is not depended on any platform or JDK.
> Part of log when test fails:
> {code}
> ...
> 04:44:06,995 TRACE (main) [org.wildfly.security] <ServerAuthenticationContext.java:1015> Handling AuthenticationCompleteCallback: succeed
> 04:44:06,995 TRACE (main) [org.wildfly.security] <ServerAuthenticationContext.java:1032> Handling SecurityIdentityCallback: identity = SecurityIdentity{principal=jdoe, securityDomain=org.wildfly.security.auth.server.SecurityDomain@e7f11d, authorizationIdentity=org.wildfly.security.auth.realm.token.TokenSecurityRealm$TokenRealmIdentity$1@3d687a, realmInfo=RealmInfo{name='oauth-realm', securityRealm=org.wildfly.security.auth.realm.token.TokenSecurityRealm@a370f4}, creationTime=2018-02-27T09:44:06.981Z}
> 04:44:06,996 INFO (MockWebServer 50831) [okhttp3.mockwebserver.MockWebServer] <MockWebServer.java:349> MockWebServer[50831] done accepting connections: Socket closed
> 04:44:12,006 INFO (MockWebServer 50831) [okhttp3.mockwebserver.MockWebServer] <MockWebServer.java:323> MockWebServer[50831] starting to accept connections
> 04:44:12,006 TRACE (main) [org.wildfly.security] <AuthenticationContextConfigurationClient.java:121> getAuthenticationConfiguration uri=protocol://test7.org, protocolDefaultPort=-1, abstractType=null, abstractTypeAuthority=null, MatchRule=[host=test7.org], AuthenticationConfiguration=[AuthenticationConfiguration:principal=anonymous,set-host=test7.org,set-protocol=protocol,credentials-present,providers-supplier=org.wildfly.security.auth.client.ElytronXmlParser$DeferredSupplier@18ca3c8,mechanism-properties={wildfly.sasl.local-user.quiet-auth=true}]
> 04:44:12,008 TRACE (main) [org.wildfly.security] <SecurityProviderSaslClientFactory.java:114> Created SaslClient for mechanism OAUTHBEARER, using Provider WildFlyElytron and protocol protocol
> ...
> {code}
> It also causes that Exception is thrown during {{@After}} for the same test, example for OAuth2SaslClientV10Test:
> {code}
> java.io.IOException: Gave up waiting for executor to shut down
> at okhttp3.mockwebserver.MockWebServer.shutdown(MockWebServer.java:375)
> at org.wildfly.security.sasl.oauth2.OAuth2SaslClientV10Test.onAfter(OAuth2SaslClientV10Test.java:88)
> {code}
> After those exceptions in {{@Before}} and {{@After}} are thrown for some particular test then all following tests works correctly.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10280) can't enable stateful EJB passivation when EJB remote service is removed
by Ladislav Thon (JIRA)
Ladislav Thon created WFLY-10280:
------------------------------------
Summary: can't enable stateful EJB passivation when EJB remote service is removed
Key: WFLY-10280
URL: https://issues.jboss.org/browse/WFLY-10280
Project: WildFly
Issue Type: Bug
Components: Clustering, EJB
Affects Versions: 12.0.0.Final
Reporter: Ladislav Thon
Assignee: Paul Ferraro
Attachments: tinyEjbPassivation.war
In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug.
Steps to reproduce:
{code}
unzip wildfly-12.0.0.Final.zip
cd wildfly-12.0.0.Final
cp tinyEjbPassivation.war standalone/deployments # any EJB deployment should do
./bin/jboss-cli.sh
embed-server --admin-only --std-out=echo --server-config=standalone-full.xml
/subsystem=ejb3:write-attribute(name=default-sfsb-cache,value=passivating)
/subsystem=ejb3/service=remote:remove
reload --start-mode=normal
{code}
What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default).
When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry:
{code}
17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
WFLYCTL0184: New missing/unsatisfied dependencies:
service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache]
service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService]
service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START]
service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService]
service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager]
service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings]
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10109) [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
by Erich Duda (JIRA)
[ https://issues.jboss.org/browse/WFLY-10109?page=com.atlassian.jira.plugin... ]
Erich Duda commented on WFLY-10109:
-----------------------------------
[~jmesnil] I tried to run it with Artemis upstream (aa2f4f7bc57e9fc609bcc5c87ab5fe3e9df493cf), see build \[1\]. It failed with the same exception as previous run with Artemis 2.5 - RA didn't receive initial broadcast from cluster.
\[1] https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/eduda-verifier...
> [Artemis 2.x upgrade] MDB connected to remote server does not get activated when using discovery group with JGroups
> --------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10109
> URL: https://issues.jboss.org/browse/WFLY-10109
> Project: WildFly
> Issue Type: Bug
> Components: JMS
> Reporter: Miroslav Novak
> Assignee: Jeff Mesnil
> Priority: Blocker
> Labels: feature-branch-blocker
> Attachments: log
>
>
> Sometimes happens that MDB does not start to consume messages from remote server. There are not warning or error messages in log.
> Test Scenario:
> * Start server with deployed InQueue and OutQueue
> * Start 2nd server with configured pooled-connection-factory to connect to 1st server
> * Deploy MDB to 2nd server - mdb is consuming messages from InQueue and sending to OutQueue
> * Start sending messages to InQueue to 1st server
> * Let MDB processing messages from InQueue
> * Start consuming messages from OutQueue from 1st server
> Pass Criteria: There is the same number of sent and received messages
> Actual Result: Sometimes happens that Mdb does not start to consume messages.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10258) Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
by Ondra Chaloupka (JIRA)
[ https://issues.jboss.org/browse/WFLY-10258?page=com.atlassian.jira.plugin... ]
Ondra Chaloupka edited comment on WFLY-10258 at 4/20/18 10:15 AM:
------------------------------------------------------------------
[~dmlloyd] a good point, agree and on top of it I can see you already implemented the functionality ;-P
Anyway, if you permit a small side step:
I think it would be a hard to involve your idea about using {{XAResource.end}} call to decide about the resource future. First the {{XAResource}} API is not providing way to return a value back to the caller (https://docs.oracle.com/javaee/7/api/javax/transaction/xa/XAResource.html...). The other issue is the Narayana implementation which calls the {{.end}} just before {{prepare}} call on the each {{XAResource}} (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...). Refactoring the code and moving the {{end}} call to some top-level place where the decision about 1PC/2PC is done (https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) I consider difficult.
Back to the prior point:
As I was investigating your point I can see that the wfly transactional client delists itself from the current transaction in {{beforeCompletion}} calllback when it knows there was no work done (https://github.com/wildfly/wildfly-transaction-client/blob/master/src/mai...). That's good but delisting at the Narayana side (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...) seems not removing the xa resource from the list (https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) which defines if 1PC is applied.
{code}
Thread [default task-2] (Suspended (breakpoint at line 129 in SubordinateXAResource))
owns: Object (id=531)
SubordinateXAResource.end(Xid, int) line: 129
TransactionImple.delistResource(XAResource, int) line: 897
LocalTransaction.delistResource(XAResource, int) line: 162
XAOutflowedResources$1.beforeCompletion() line: 74
921870613.accept(Object) line: not available
1900321310.accept(Object, Object) line: not available
LocalTransaction(AbstractTransaction).performConsumer(ExceptionBiConsumer<T,U,E>, T, U) line: 209
LocalTransaction(AbstractTransaction).performConsumer(ExceptionConsumer<T,E>, T) line: 220
AbstractTransaction$AssociatingSynchronization.beforeCompletion() line: 265
SynchronizationImple.beforeCompletion() line: 76
AtomicAction(TwoPhaseCoordinator).beforeCompletion() line: 368
AtomicAction(TwoPhaseCoordinator).end(boolean) line: 91
AtomicAction(AtomicAction).commit(boolean) line: 162
TransactionImple.commitAndDisassociate() line: 1289
TransactionManagerImple(BaseTransaction).commit() line: 126
TransactionManagerDelegate(BaseTransactionManagerDelegate).commit() line: 89
LocalTransaction.commitAndDissociate() line: 73
ContextTransactionManager.commit() line: 71
CMTTxInterceptor.endTransaction(Transaction) line: 88
CMTTxInterceptor.invokeInOurTx(InterceptorContext, EJBComponent) line: 261
CMTTxInterceptor.required(InterceptorContext, EJBComponent, int) line: 362
CMTTxInterceptor.processInvocation(InterceptorContext) line: 144
InterceptorContext.proceed() line: 422
{code}
*/edit* I found the started discussion at the forum: https://developer.jboss.org/message/982119
was (Author: ochaloup):
[~dmlloyd] a good point, agree and on top of it I can see you already implemented the functionality ;-P
Anyway, if you permit a small side step:
I think it would be a hard to involve your idea about using {{XAResource.end}} call to decide about the resource future. First the {{XAResource}} API is not providing way to return a value back to the caller (https://docs.oracle.com/javaee/7/api/javax/transaction/xa/XAResource.html...). The other issue is the Narayana implementation which calls the {{.end}} just before {{prepare}} call on the each {{XAResource}} (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...). Refactoring the code and moving the {{end}} call to some top-level place where the decision about 1PC/2PC is done (https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) I consider difficult.
Back to the prior point:
As I was investigating your point I can see that the wfly transactional client delists itself from the current transaction in {{beforeCompletion}} calllback when it knows there was no work done (https://github.com/wildfly/wildfly-transaction-client/blob/master/src/mai...). That's good but delisting at the Narayana side (https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...) seems not removing the xa resource from the list (https://github.com/jbosstm/narayana/blob/master/ArjunaCore/arjuna/classes...) which defines if 1PC is applied.
*/edit* I found the started discussion at the forum: https://developer.jboss.org/message/982119
> Prevent enlisting additional resources on EJB caller side in case of server side @RequiresNew
> ---------------------------------------------------------------------------------------------
>
> Key: WFLY-10258
> URL: https://issues.jboss.org/browse/WFLY-10258
> Project: WildFly
> Issue Type: Bug
> Components: EJB, Transactions
> Affects Versions: 12.0.0.Final
> Reporter: Jörg Bäsner
>
> Scenario:
> - server-1 (intermediary)
> -- Running standalone profile
> -- Has a remote-outbound-connection pointing at server-2 through server-2's public IP address
> -- Intermediary bean need to lookup the Target bean in server-2 and also inject the {{TransactionManager}}
> -- Intermediary bean need to enlist a _dummy_ XAResource
> - server-2 (target)
> -- disable {{JBOSS-LOCAL-USER}} auth
> -- Target bean needs to be annotated with {{@REQUIRES_NEW}} (important)
> - Standalone EJB client invokes an intermediary bean server-1, which as a result invokes target bean on server-2.
> The _dummy_ XAResource should log in the {{commit}} method whether one-phase optimization is being used like:
> {code}
> @Override
> public void commit(Xid arg0, boolean onePhaseOptim) throws XAException {
> logger.info("-- Committing in the client resource. One-phase optimisation is: " + onePhaseOptim + " --"
> + (onePhaseOptim ? "" : " -> TWO-PHASE COMMIT !!!"));
> }
> {code}
> In this scenario it is expected that the one-phase optimization is being used!
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (ELY-1565) local-kerberos can be removed/deprecated from authentication client
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1565?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1565:
----------------------------
Description:
As described in ELY-1541, obtaining GSSCredential using local-kerberos is redundant.
If not credential is provided, GSS based authentication mechanims will obtain it hiself.
When credential is not provided, kerberos-based mechanism will obtain appropriate GSSCredential from ccache himself.
Note on both, Oracle [1] and IBM JDK [2] can be path to the ccache defined using {{KRB5CCNAME}} environment variable - no need to set any JAAS login options for obtaining.
[1] https://bugs.openjdk.java.net/browse/JDK-6832353
[2] https://www.ibm.com/support/knowledgecenter/en/SSYKE2_9.0.0/com.ibm.java....
was:
As described in ELY-1541, obtaining GSSCredential using local-kerberos is redundant.
If not credential is provided, GSS based authentication mechanims will obtain it hiself.
> local-kerberos can be removed/deprecated from authentication client
> -------------------------------------------------------------------
>
> Key: ELY-1565
> URL: https://issues.jboss.org/browse/ELY-1565
> Project: WildFly Elytron
> Issue Type: Task
> Affects Versions: 1.2.4.Final
> Reporter: Jan Kalina
> Assignee: Jan Kalina
>
> As described in ELY-1541, obtaining GSSCredential using local-kerberos is redundant.
> If not credential is provided, GSS based authentication mechanims will obtain it hiself.
> When credential is not provided, kerberos-based mechanism will obtain appropriate GSSCredential from ccache himself.
> Note on both, Oracle [1] and IBM JDK [2] can be path to the ccache defined using {{KRB5CCNAME}} environment variable - no need to set any JAAS login options for obtaining.
> [1] https://bugs.openjdk.java.net/browse/JDK-6832353
> [2] https://www.ibm.com/support/knowledgecenter/en/SSYKE2_9.0.0/com.ibm.java....
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years