[JBoss JIRA] (WFLY-7816) Camel CXF version not compatible with WildFly CXF
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-7816?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-7816:
----------------------------------
Fix Version/s: (was: 12.0.0.Alpha1)
> Camel CXF version not compatible with WildFly CXF
> -------------------------------------------------
>
> Key: WFLY-7816
> URL: https://issues.jboss.org/browse/WFLY-7816
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Web Services
> Affects Versions: 10.1.0.Final
> Reporter: Thomas Diesler
> Assignee: Alessio Soldano
>
> cxf-3.1.9 distributed with camel-2.19.x is not compatible with cxf-3.1.6 from wildfly-10.1.0.Final
> {code}
> Caused by: java.lang.NoSuchMethodError: org.apache.cxf.message.Message.remove(Ljava/lang/Class;)Ljava/lang/Object;
> at org.apache.camel.component.cxf.CxfEndpoint$CamelCxfClientImpl.setParameters(CxfEndpoint.java:1239)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:470)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:416)
> at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:133)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1546
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-7816) Camel CXF version not compatible with WildFly CXF
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-7816?page=com.atlassian.jira.plugin.... ]
Alessio Soldano updated WFLY-7816:
----------------------------------
Fix Version/s: 12.0.0.Alpha1
(was: 10.2.0.Final)
(was: 11.0.0.Final)
> Camel CXF version not compatible with WildFly CXF
> -------------------------------------------------
>
> Key: WFLY-7816
> URL: https://issues.jboss.org/browse/WFLY-7816
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Web Services
> Affects Versions: 10.1.0.Final
> Reporter: Thomas Diesler
> Assignee: Alessio Soldano
> Fix For: 12.0.0.Alpha1
>
>
> cxf-3.1.9 distributed with camel-2.19.x is not compatible with cxf-3.1.6 from wildfly-10.1.0.Final
> {code}
> Caused by: java.lang.NoSuchMethodError: org.apache.cxf.message.Message.remove(Ljava/lang/Class;)Ljava/lang/Object;
> at org.apache.camel.component.cxf.CxfEndpoint$CamelCxfClientImpl.setParameters(CxfEndpoint.java:1239)
> at org.apache.cxf.endpoint.ClientImpl.doInvoke(ClientImpl.java:470)
> at org.apache.cxf.endpoint.ClientImpl.invoke(ClientImpl.java:416)
> at org.apache.camel.component.cxf.CxfProducer.process(CxfProducer.java:133)
> {code}
> CrossRef: https://github.com/wildfly-extras/wildfly-camel/issues/1546
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-7647) Configure Artemis thread pool size without reload
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFLY-7647?page=com.atlassian.jira.plugin.... ]
Jeff Mesnil commented on WFLY-7647:
-----------------------------------
The thread-pool-max-size is handled by Artemis in its configuration.
Changing this value on the fly will have no consequence until Artemis is restarted.
In order to do that, you will have to open an upstream issue in ARTEMIS to ask them to be able to change thread pool size at runtime.
> Configure Artemis thread pool size without reload
> -------------------------------------------------
>
> Key: WFLY-7647
> URL: https://issues.jboss.org/browse/WFLY-7647
> Project: WildFly
> Issue Type: Enhancement
> Components: JMS
> Affects Versions: 10.1.0.Final
> Reporter: Martin Styk
> Assignee: Jeff Mesnil
>
> Currently, thread pool size can not be adjusted without server reload. If server runs into performance problem caused by thread pool size, there is no way to adjust thread pool size without termination of all running tasks. Making this configurable "on fly" would prevent this scenario.
> Attribute {{thread-pool-max-size}} in {{/subsystem=messaging-activemq/server=default}} requires server reload.
> Size of global client thread pools can be set only before this thread pool is created. Adjusting values of system properties which configure client thread pool size has no effect on running server (with pool already created).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (DROOLS-1744) Inclusion of kbases containing rule templates results in duplicate rule names and kbase build failure.
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1744?page=com.atlassian.jira.plugi... ]
Mario Fusco updated DROOLS-1744:
--------------------------------
Sprint: 2017 Week 38-39
> Inclusion of kbases containing rule templates results in duplicate rule names and kbase build failure.
> ------------------------------------------------------------------------------------------------------
>
> Key: DROOLS-1744
> URL: https://issues.jboss.org/browse/DROOLS-1744
> Project: Drools
> Issue Type: Bug
> Components: decision tables
> Affects Versions: 7.3.0.Final
> Reporter: Alistair Black
> Assignee: Mario Fusco
> Fix For: 7.4.0.Final
>
>
> I am working on a multi-module BRMS project, with each module encapsulating a set of rules forming a single knowledge base. There is an empty "packaging" module which inherits each of these modules in order to generate a single KJAR for deployment purposes. The application then utilises this KJAR via the KieScanner/ReleaseId approach to facilitate dynamic rule loading at runtime and decoupling of application/rules.
> Having taken the above approach I have encountered an issue when including knowledge bases that contain rule templates. Drools is unable to build these knowledge bases, reporting duplicate rule names; it appears to believe that the rules exist in both the inheriting and inherited knowledge bases. This behaviour is not seen when including knowledge bases containing standard rules or decision tables - just rule templates.
> An example of the error reported is:
> {{4528 [main] INFO org.drools.compiler.kie.builder.impl.KieRepositoryImpl - KieModule was added: ZipKieModule[releaseId=my.drools.templates:ruleModuleOne:1.0-SNAPSHOT,file=C:\Users\black\.m2\repository\my\drools\templates\ruleModuleOne\1.0-SNAPSHOT\ruleModuleOne-1.0-SNAPSHOT.jar]
> 5145 [main] ERROR org.drools.compiler.kie.builder.impl.KieProject - Unable to build KieBaseModel:ruleModule_1_kbase
> [7,4]: Duplicate rule name: Rule One :: CCC_4
> [15,4]: Duplicate rule name: Rule One :: BBB_3
> [23,4]: Duplicate rule name: Rule One :: AAA_2
> [7,4]: Duplicate rule name: Rule Two :: EEE_3
> [16,4]: Duplicate rule name: Rule Two :: DDD_2
> 5329 [main] ERROR org.drools.compiler.kie.builder.impl.KieProject - Unable to build KieBaseModel:inheritedTemplateModules-ruleModule_1_kbase
> [7,4]: Duplicate rule name: Rule One :: CCC_4
> [15,4]: Duplicate rule name: Rule One :: BBB_3
> [23,4]: Duplicate rule name: Rule One :: AAA_2
> [7,4]: Duplicate rule name: Rule Two :: EEE_3
> [16,4]: Duplicate rule name: Rule Two :: DDD_2
> }}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months
[JBoss JIRA] (WFLY-9399) EJB remote and local methods are not calling through Threads
by David Lloyd (JIRA)
[ https://issues.jboss.org/browse/WFLY-9399?page=com.atlassian.jira.plugin.... ]
David Lloyd closed WFLY-9399.
-----------------------------
Resolution: Rejected
This is not a help forum, this is a bug tracker. If you are looking for help, try this link: [http://wildfly.org/gethelp/]
> EJB remote and local methods are not calling through Threads
> ------------------------------------------------------------
>
> Key: WFLY-9399
> URL: https://issues.jboss.org/browse/WFLY-9399
> Project: WildFly
> Issue Type: Feature Request
> Components: EJB
> Affects Versions: 9.0.2.Final
> Reporter: Karthika Udayasankar
> Priority: Blocker
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Hi,
> We are migrated from JBoss 5.1 to WildFly 9.0.2. After migrating I'm facing exception while calling EJB methods when it is coming through *Thread* concept otherwise it is working fine.
> 2017-09-28 16:03:38,981 ERROR [SIRAHULOG] (Thread-149) Thread ID:398:EjbUtils:getEJBInstance:Exception raised for name:java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote: javax.naming.NameNotFoundException: java:app/app-model-1.0-SNAPSHOT/FirmBaseEJB!com.sirahu.apptivo.model.ejb.common.session.FirmBaseEJBRemote
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.findContext(InitialContext.java:189)
> at org.jboss.as.naming.InitialContext$DefaultInitialContext.lookup(InitialContext.java:233)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:193)
> at org.jboss.as.naming.NamingContext.lookup(NamingContext.java:189)
> at javax.naming.InitialContext.lookup(InitialContext.java:411)
> at javax.naming.InitialContext.lookup(InitialContext.java:411)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getEJBInstance(EjbUtils.java:563)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getEjb(EjbUtils.java:498)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getRemoteEjb(EjbUtils.java:527)
> at com.sirahu.apptivo.view.framework.util.EjbUtils.getFirmOrCFRemoteEjb(EjbUtils.java:535)
> at com.sirahu.apptivo.view.framework.util.AppClusterEJBFactory.getFirmBaseEJBRemote(AppClusterEJBFactory.java:1105)
> at com.sirahu.apptivo.view.dao.service.BusinessAttributeService.getBusinessAtrributeMap(BusinessAttributeService.java:52)
> at com.sirahu.apptivo.view.action.common.MessageTemplateCommonService.getObjectMessageTemplateMap(MessageTemplateCommonService.java:124)
> at com.sirahu.apptivo.view.dao.service.MessageTemplateService.processMessageTemplate(MessageTemplateService.java:3033)
> at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:340)
> at com.sirahu.apptivo.view.dao.service.MessageTemplateService.replaceMessageTemplate(MessageTemplateService.java:167)
> at com.sirahu.apptivo.view.dao.servlet.v6.UpdateEmployeeSignatureThread.run(EmployeesServlet.java:7012)
> at java.lang.Thread.run(Thread.java:745)
> Is there anything need to config for Thread concepts.? Can anybody help me to fix this issue?
>
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 3 months