October 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3214) [DMN Designer] Function: Add parameter data-types

by Jozef Marko (Jira)

[ https://issues.jboss.org/browse/DROOLS-3214?page=com.atlassian.jira.plugi... ] Jozef Marko updated DROOLS-3214: -------------------------------- Description: Our "Function Grid" does not support data-types for parameters... it should! h2. Acceptance test - Create model like used in [PR|https://github.com/kiegroup/drools/pull/2123] was:Our "Function Grid" does not support data-types for parameters... it should! > [DMN Designer] Function: Add parameter data-types > ------------------------------------------------- > > Key: DROOLS-3214 > URL: https://issues.jboss.org/browse/DROOLS-3214 > Project: Drools > Issue Type: Enhancement > Components: DMN Editor > Reporter: Michael Anstis > Assignee: Michael Anstis > Priority: Major > Labels: drools-tools > > Our "Function Grid" does not support data-types for parameters... it should! > h2. Acceptance test > - Create model like used in [PR|https://github.com/kiegroup/drools/pull/2123] -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11264) The BatchJobExecutionResource.hasChild() needs to be reviewed for purged jobs

by James Perkins (Jira)

James Perkins created WFLY-11264: ------------------------------------ Summary: The BatchJobExecutionResource.hasChild() needs to be reviewed for purged jobs Key: WFLY-11264 URL: https://issues.jboss.org/browse/WFLY-11264 Project: WildFly Issue Type: Bug Components: Batch Reporter: James Perkins Assignee: Cheng Fang The {{BatchJobExecutionResource.hasChild()}} invokes the {{hasJobExecution()}} method which does not by default refresh the children. This could mean that a purged job returns {{true}} when it should be {{false}}. This was originally done for performance reasons however there is a bug (WFLY-11261) which causes issues when a job is purged. In general this resource should be reviewed and performance tested to ensure purged jobs no longer show up. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11146) org.apache.activemq.artemis.journal module should not depend on org.apache.activemq.artemis

by ehsavoie Hugonnet (Jira)

[ https://issues.jboss.org/browse/WFLY-11146?page=com.atlassian.jira.plugin... ] ehsavoie Hugonnet reassigned WFLY-11146: ---------------------------------------- Assignee: ehsavoie Hugonnet (was: Jeff Mesnil) > org.apache.activemq.artemis.journal module should not depend on org.apache.activemq.artemis > ------------------------------------------------------------------------------------------- > > Key: WFLY-11146 > URL: https://issues.jboss.org/browse/WFLY-11146 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 14.0.0.Final > Reporter: Jeff Mesnil > Assignee: ehsavoie Hugonnet > Priority: Major > > While looking at Weld dependency, Jean-Francois found the dependency chain: > /org.jboss.as.weld/org.jboss.weld.core/javax.ejb.api/javax.rmi.api/javax.orb.api/org.wildfly.iiop-openjdk/org.jboss.jts/org.apache.activemq.artemis.journal/org.apache.activemq.artemis > org.jboss.jts dependency to org.apache.activemq.artemis.journal is correct as Naryana uses Artemis journal for its transaction log. > However org.apache.activemq.artemis.journal should not depend on org.apache.activemq.artemis. It depends on it for the artemis-commons jar (as explained in https://github.com/wildfly/wildfly/blob/47b1db08fadb745706df7ba411db4f725... but code should be refactored so that this dependency is no longer required). -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 11 months

1
0
0 / 0

[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)

6 years, 11 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)

6 years, 11 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)

6 years, 11 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)

6 years, 11 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)

6 years, 11 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)

6 years, 11 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)

6 years, 11 months

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 2018