October 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-11106) Kabir Test(For demo)

by Kabir Khan (Jira)

[ https://issues.jboss.org/browse/WFLY-11106?page=com.atlassian.jira.plugin... ] Kabir Khan updated WFLY-11106: ------------------------------ Labels: EAP-CD15 EAP-CD16 EAP-CD17 (was: ) > Kabir Test(For demo) > -------------------- > > Key: WFLY-11106 > URL: https://issues.jboss.org/browse/WFLY-11106 > Project: WildFly > Issue Type: Feature Request > Components: Management > Reporter: Kabir Khan > Assignee: Kabir Khan > Priority: Major > Labels: EAP-CD15, EAP-CD16, EAP-CD17 > > An issue for me to move around the board to test the tooling. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-208) Missing -Djava.util.logging.manager=org.jboss.logmanager.LogManager for tests on IBM JDK

by Nikoleta Žiaková (Jira)

Nikoleta Žiaková created LOGMGR-208: --------------------------------------- Summary: Missing -Djava.util.logging.manager=org.jboss.logmanager.LogManager for tests on IBM JDK Key: LOGMGR-208 URL: https://issues.jboss.org/browse/LOGMGR-208 Project: JBoss Log Manager Issue Type: Bug Affects Versions: 2.1.5.Final Reporter: Nikoleta Žiaková There are several test failures on IBM JDK with following error: {quote} The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager") {quote} This is similar to WFCORE-3797 but profile for IBM cannot be added since Maven is run with different JDK than the tests themselves - build requires JDK11 and the tests are run on IBM JDK 1.8 using {{java8.home}} property. Simple fix is to add "-Djava.util.logging.manager=org.jboss.logmanager.LogManager" to surefire argLine like at https://github.com/nziakova/jboss-logmanager/commit/ae67e8b517866b80f7797... [~jamezp] WDYT? -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1382) Destroy managed connection on failed reconnect

by Martin Simka (Jira)

[ https://issues.jboss.org/browse/JBJCA-1382?page=com.atlassian.jira.plugin... ] Martin Simka commented on JBJCA-1382: ------------------------------------- [~mitul.vora] version 1.4.12 containing this fix has not yet been released. When it is you download it from maven repository. Of course you can build it yourself from sources (https://github.com/ironjacamar/ironjacamar/). > Destroy managed connection on failed reconnect > ---------------------------------------------- > > Key: JBJCA-1382 > URL: https://issues.jboss.org/browse/JBJCA-1382 > Project: IronJacamar > Issue Type: Bug > Components: Core > Reporter: Brad Maxwell > Assignee: Stefano Maestri > Priority: Major > > Destroy managed connection on failed reconnect -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1382) Destroy managed connection on failed reconnect

by Martin Simka (Jira)

[ https://issues.jboss.org/browse/JBJCA-1382?page=com.atlassian.jira.plugin... ] Martin Simka edited comment on JBJCA-1382 at 10/31/18 11:01 AM: ---------------------------------------------------------------- [~mitul.vora] version 1.4.12 containing this fix has not yet been released. When it is you can download it from maven repository. Of course you can build it yourself from sources (https://github.com/ironjacamar/ironjacamar/). was (Author: simkam): [~mitul.vora] version 1.4.12 containing this fix has not yet been released. When it is you download it from maven repository. Of course you can build it yourself from sources (https://github.com/ironjacamar/ironjacamar/). > Destroy managed connection on failed reconnect > ---------------------------------------------- > > Key: JBJCA-1382 > URL: https://issues.jboss.org/browse/JBJCA-1382 > Project: IronJacamar > Issue Type: Bug > Components: Core > Reporter: Brad Maxwell > Assignee: Stefano Maestri > Priority: Major > > Destroy managed connection on failed reconnect -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3107) Provide optional lazy segment memories creation

by Mario Fusco (Jira)

[ https://issues.jboss.org/browse/DROOLS-3107?page=com.atlassian.jira.plugi... ] Mario Fusco resolved DROOLS-3107. --------------------------------- Fix Version/s: 7.14.0.Final Resolution: Done Implemented by https://github.com/kiegroup/drools/commit/2a3a8aa138a9e8022b24e280d7f7e99... > Provide optional lazy segment memories creation > ----------------------------------------------- > > Key: DROOLS-3107 > URL: https://issues.jboss.org/browse/DROOLS-3107 > Project: Drools > Issue Type: Enhancement > Components: core engine > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > Fix For: 7.14.0.Final > > > The execution of the very first ksession created from a kbase is (much) slower than the subsequent ones, because of lazy segment memories creation. It is requested to provide an option to eagerly create them at kbase creation time. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (SWSQE-477) REST Tests failed in Istio 1.0.3

by Hayk Hovsepyan (Jira)

Hayk Hovsepyan created SWSQE-477: ------------------------------------ Summary: REST Tests failed in Istio 1.0.3 Key: SWSQE-477 URL: https://issues.jboss.org/browse/SWSQE-477 Project: Kiali QE Issue Type: QE Task Reporter: Hayk Hovsepyan Assignee: Michael Foley Started happening after B12 installed with Istio 1.0.3. http://jenkins2.bc.jonqe.lab.eng.bos.redhat.com:8080/job/run-kiali-e2e-te... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4192) Server-server EJB invocation fails if no security is defined on target bean due to faulty permission check

by Jiri Ondrusek (Jira)

[ https://issues.jboss.org/browse/WFCORE-4192?page=com.atlassian.jira.plugi... ] Jiri Ondrusek moved JBEAP-15754 to WFCORE-4192: ----------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-4192 (was: JBEAP-15754) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Security (was: EJB) (was: Security) (was: Transactions) Affects Version/s: 7.0.0.Alpha4 (was: 7.1.0.CR4) > Server-server EJB invocation fails if no security is defined on target bean due to faulty permission check > ----------------------------------------------------------------------------------------------------------- > > Key: WFCORE-4192 > URL: https://issues.jboss.org/browse/WFCORE-4192 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 7.0.0.Alpha4 > Reporter: Jiri Ondrusek > Assignee: Jiri Ondrusek > Priority: Major > > Customer impact: > Possibly in testing scenarios, production scenarios will very likely use security. > Scenario description: Automated test ([source code|http://git.app.eng.bos.redhat.com/git/jbossqe/eap-tests-ejb.git/tree...]) which does these steps: > 1. starts two servers (with standalone-ha.xml profile, but they don't form a cluster): CLUSTER1_NODE1 and CLUSTER2_NODE1 (the original scenario was simplified from 2 clusters to 2 servers) > 2. creates remote outbound connection on CLUSTER1_NODE1 to CLUSTER2_NODE1: > {code:xml} > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <endpoint/> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"/> > <outbound-connections> > <remote-outbound-connection name="connection-to-cluster2" outbound-socket-binding-ref="connection-to-cluster2"/> > </outbound-connections> > </subsystem> > {code} > 3. deletes security-realm="ApplicationRealm" from CLUSTER2_NODE1: > {code:xml} > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <endpoint/> > <http-connector connector-ref="default" name="http-remoting-connector"/> > </subsystem> > {code} > 4. deploys intermediary bean on CLUSTER1_NODE1 ([source code|http://git.app.eng.bos.redhat.com/git/jbossqe/eap-tests-ejb.git/tree...]) and target bean on CLUSTER2_NODE1 ([source code|http://git.app.eng.bos.redhat.com/git/jbossqe/eap-tests-ejb.git/tree...]) > 5. invokes intermediary bean with this code: > {code:java} > final Properties properties = new Properties(); > properties.put(Context.INITIAL_CONTEXT_FACTORY, WildFlyInitialContextFactory.class.getName()); > final InitialContext ejbCtx = new InitialContext(properties); > final IntermediaryBeanRemote bean = (IntermediaryBeanRemote)ejbCtx > .lookup("ejb:/bean-intermediary/" + IntermediaryBeanStateless.class.getSimpleName() + "!" > + IntermediaryBeanRemote.class.getName()); > for (int i = 0; i < 200; i++) { > bean.call(); > } > {code} > When intermediary bean tries to invoke target bean, it gets this exception: > {code} > CLUSTER1_NODE1: 09:29:34,536 ERROR [org.jboss.as.ejb3.invocation] (default task-6) WFLYEJB0034: EJB Invocation failed on component IntermediaryBeanStateless for method public abstract void org.jboss.qa.ejb.tests.jbeap10217.beans.IntermediaryBeanRemote.call(): java.lang.SecurityException: WFTXN0013: The peer threw a SecurityException; see peer logs for more information > at org.wildfly.transaction.client.provider.remoting.TransactionClientChannel.setRollbackOnly(TransactionClientChannel.java:178) > at org.wildfly.transaction.client.provider.remoting.RemotingRemoteTransactionPeer$1.end(RemotingRemoteTransactionPeer.java:158) > at org.wildfly.transaction.client.SubordinateXAResource.end(SubordinateXAResource.java:130) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.doEnd(TransactionImple.java:1089) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.endAssociation(TransactionImple.java:1060) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.endAssociation(XAResourceRecord.java:1287) > at com.arjuna.ats.internal.jta.resources.arjunacore.XAResourceRecord.topLevelAbort(XAResourceRecord.java:313) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3023) > at com.arjuna.ats.arjuna.coordinator.BasicAction.doAbort(BasicAction.java:3002) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1674) > at com.arjuna.ats.arjuna.coordinator.BasicAction.Abort(BasicAction.java:1615) > at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:99) > at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162) > at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1289) > at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126) > at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89) > at org.wildfly.transaction.client.LocalTransaction.commitAndDissociate(LocalTransaction.java:73) > at org.wildfly.transaction.client.ContextTransactionManager.commit(ContextTransactionManager.java:71) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:92) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:332) > at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:240) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:509) > at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73) > at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:89) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:89) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:60) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:438) > at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:609) > at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:57) > at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:422) > at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:53) > at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198) > at org.jboss.as.ejb3.remote.AssociationImpl$$Lambda$1232/202321503.apply(Unknown Source) > at org.wildfly.security.auth.server.SecurityIdentity.runAsFunctionEx(SecurityIdentity.java:380) > at org.jboss.as.ejb3.remote.AssociationImpl.invokeWithIdentity(AssociationImpl.java:535) > at org.jboss.as.ejb3.remote.AssociationImpl.invokeMethod(AssociationImpl.java:530) > at org.jboss.as.ejb3.remote.AssociationImpl.lambda$receiveInvocationRequest$0(AssociationImpl.java:193) > at org.jboss.as.ejb3.remote.AssociationImpl$$Lambda$1230/1343168004.run(Unknown Source) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > Caused by: Remote exception java.lang.SecurityException: WFTXN0088: User anonymous does not have permission ("org.wildfly.transaction.client.RemoteTransactionPermission" "") > at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.getSecurityIdentity(TransactionServerChannel.java:745) > at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel.handleXaTxnRollbackOnly(TransactionServerChannel.java:390) > at org.wildfly.transaction.client.provider.remoting.TransactionServerChannel$ReceiverImpl.handleMessage(TransactionServerChannel.java:132) > at org.jboss.remoting3.remote.RemoteConnectionChannel.lambda$handleMessageData$3(RemoteConnectionChannel.java:430) > at org.jboss.remoting3.remote.RemoteConnectionChannel$$Lambda$901/21589536.run(Unknown Source) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor.lambda$execute$0(EndpointImpl.java:926) > at org.jboss.remoting3.EndpointImpl$TrackingExecutor$$Lambda$885/1175809082.run(Unknown Source) > ... 3 more > {code} > It seems, that transaction client is trying to check the "org.wildfly.transaction.client.RemoteTransactionPermission". This permission is bound to Elytron but Elytron is not running? > The permission is defined in standalone-ha.xml on CLUSTER2_NODE1: > {code:xml} > <permission-mapping> > <principal name="anonymous"/> > <permission module="org.wildfly.extension.batch.jberet" target-name="*" class-name="org.wildfly.extension.batch.jberet.deployment.BatchPermission"/> > <permission module="org.wildfly.transaction.client" class-name="org.wildfly.transaction.client.RemoteTransactionPermission"/> > <permission module="org.jboss.ejb-client" class-name="org.jboss.ejb.client.RemoteEJBPermission"/> > </permission-mapping> > {code} > Please check https://github.com/wildfly/wildfly-transaction-client/blob/master/src/mai... -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11263) Validate requirement for modules previously exported by javax.ejb.api on org.jboss.as.xts

by Yeray Borges (Jira)

Yeray Borges created WFLY-11263: ----------------------------------- Summary: Validate requirement for modules previously exported by javax.ejb.api on org.jboss.as.xts Key: WFLY-11263 URL: https://issues.jboss.org/browse/WFLY-11263 Project: WildFly Issue Type: Sub-task Components: Server Reporter: Yeray Borges Assignee: Yeray Borges Validate the need of these module dependencies in org.jboss.as.xts module: {code:xml} <module name="javax.xml.rpc.api"/> <module name="javax.rmi.api"/> {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-3215) Copying an empty folder in MemoryFileSystem fails with NPE

by Tibor Zimányi (Jira)

Tibor Zimányi created DROOLS-3215: ------------------------------------- Summary: Copying an empty folder in MemoryFileSystem fails with NPE Key: DROOLS-3215 URL: https://issues.jboss.org/browse/DROOLS-3215 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.13.0.Final Reporter: Tibor Zimányi Assignee: Tibor Zimányi When this test [1] is put into MemoryFileSystemTest and run, it ends with NullPointerException. The thing that triggers it is creating the folder with getFolder() method. [1] https://gist.github.com/baldimir/d6bac6de418eba1252e2d20cebaaad45 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11178) WSTrustTestCase failing on IBM

by David Lloyd (Jira)

[ https://issues.jboss.org/browse/WFLY-11178?page=com.atlassian.jira.plugin... ] David Lloyd commented on WFLY-11178: ------------------------------------ I believe there is no fix in JBoss Modules that will solve this. The property simply must not be set; setting the property results in undefined and unsupported behavior. > WSTrustTestCase failing on IBM > ------------------------------ > > Key: WFLY-11178 > URL: https://issues.jboss.org/browse/WFLY-11178 > Project: WildFly > Issue Type: Bug > Components: MSC > Affects Versions: 14.0.0.Final > Reporter: Jan Blizňák > Assignee: Alessio Soldano > Priority: Major > Attachments: log.txt > > > As discovered during investigation in WFLY-10336, we are now getting test failures in WSTrustTestCase when IBM JDK is used. The relevant part of the exception is: > {code:java} > Caused by: java.lang.IllegalArgumentException: Provider org.apache.xerces.jaxp.validation.XMLSchemaFactory not found > at javax.xml.validation.SchemaFactory.newInstance(Unknown Source) > at org.opensaml.core.xml.config.XMLConfigurator.<init>(XMLConfigurator.java:94) > at org.apache.wss4j.common.saml.OpenSAMLBootstrap.bootstrap(OpenSAMLBootstrap.java:85) > at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:91) > at org.apache.wss4j.common.saml.OpenSAMLUtil.initSamlEngine(OpenSAMLUtil.java:75) > at org.apache.wss4j.common.saml.SamlAssertionWrapper.<init>(SamlAssertionWrapper.java:184) > at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createSamlToken(SAMLTokenProvider.java:308) > at org.apache.cxf.sts.token.provider.SAMLTokenProvider.createToken(SAMLTokenProvider.java:120) > ... 102 more > {code} > It turned out the issue is in wildfly for some time, the breaking change was identified as https://github.com/wildfly/wildfly-core/pull/3201/ -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 9 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2018