July 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-4855) Test case for CXF-6469 (schemaLocation in xsd import is not rewritten)

by Tomas Hofman (JIRA)

Tomas Hofman created WFLY-4855: ---------------------------------- Summary: Test case for CXF-6469 (schemaLocation in xsd import is not rewritten) Key: WFLY-4855 URL: https://issues.jboss.org/browse/WFLY-4855 Project: WildFly Issue Type: Enhancement Components: Test Suite Affects Versions: 10.0.0.Alpha4 Reporter: Tomas Hofman Assignee: Tomas Hofman -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-4731) Change default value for journal-type to NIO

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-4731?page=com.atlassian.jira.plugin.... ] Miroslav Novak updated WFLY-4731: --------------------------------- Security: (was: Red Hat Internal) > Change default value for journal-type to NIO > -------------------------------------------- > > Key: WFLY-4731 > URL: https://issues.jboss.org/browse/WFLY-4731 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 10.0.0.Alpha2 > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > > Attribute journal-type is not specified and defaults to ASYNCIO. This has a side effect that EAP 7.0.0.DR2 (with ActiveMQ) prints warning to log if AIO is not located (on Windows, Solaris, HP-UX). > For this reason EAP 6.4 has default value for journal-type=NIO. We should keep it for EAP 7 as well. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-788) Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation

by Brian Stansberry (JIRA)

[ https://issues.jboss.org/browse/WFCORE-788?page=com.atlassian.jira.plugin... ] Brian Stansberry commented on WFCORE-788: ----------------------------------------- The discard of the model isn't happening in this situation. https://github.com/wildfly/wildfly-core/pull/853 needs work. > Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-788 > URL: https://issues.jboss.org/browse/WFCORE-788 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > > This does seem to be somewhat of an edge case as the only way to reproduce it is to add the {{allow-resource-service-restart=true}} header to a composite operation. The first operation must also need access to a capability provided by a resource being removed. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again. > The issue seems to be that the [capability is removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...] on the first execution that fails and is rolled back. On the second execution of the composite operation there is no [capability registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...] registered in the {{RuntimeCapabilityRegistration}} so the [remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...] of the capability doesn't happen. This allows the first operation to pass. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-788) Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/WFCORE-788?page=com.atlassian.jira.plugin... ] James Perkins updated WFCORE-788: --------------------------------- Description: This does seem to be somewhat of an edge case as the only way to reproduce it is to add the {{allow-resource-service-restart=true}} header to a composite operation. The first operation must also need access to a capability provided by a resource being removed. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again. The issue seems to be that the [capability is removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...] on the first execution that fails and is rolled back. On the second execution of the composite operation there is no [capability registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...] registered in the {{RuntimeCapabilityRegistration}} so the [remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...] of the capability doesn't happen. This allows the first operation to pass. was: This seems to be somewhat of an edge case, but it does exist. In the reproduce instructions you'll see a {{disable}} followed by a {{remove}} composite operation fails if the {{allow-resource-service-restart=true}} is set. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again. The issue seems to be that the [capability is removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...] on the first execution that fails and is not added back. On the second execution of the composite operation there is no [capability registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...] so the [remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...] of the capability doesn't happen which makes the first step of the operation happy as the capability still exists. > Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation > -------------------------------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-788 > URL: https://issues.jboss.org/browse/WFCORE-788 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Reporter: James Perkins > Assignee: Brian Stansberry > > This does seem to be somewhat of an edge case as the only way to reproduce it is to add the {{allow-resource-service-restart=true}} header to a composite operation. The first operation must also need access to a capability provided by a resource being removed. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again. > The issue seems to be that the [capability is removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...] on the first execution that fails and is rolled back. On the second execution of the composite operation there is no [capability registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...] registered in the {{RuntimeCapabilityRegistration}} so the [remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...] of the capability doesn't happen. This allows the first operation to pass. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-788) Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation

by James Perkins (JIRA)

James Perkins created WFCORE-788: ------------------------------------ Summary: Executing a composite operation allowing services to restart fails if the first operation relies on a capability of a remove operation Key: WFCORE-788 URL: https://issues.jboss.org/browse/WFCORE-788 Project: WildFly Core Issue Type: Bug Components: Domain Management Reporter: James Perkins Assignee: Brian Stansberry This seems to be somewhat of an edge case, but it does exist. In the reproduce instructions you'll see a {{disable}} followed by a {{remove}} composite operation fails if the {{allow-resource-service-restart=true}} is set. It's likely an acceptable failure, but the failure isn't seen when executing the same composite operation again. The issue seems to be that the [capability is removed|https://github.com/bstansberry/wildfly-core/blob/discard-model/co...] on the first execution that fails and is not added back. On the second execution of the composite operation there is no [capability registered|https://github.com/bstansberry/wildfly-core/blob/discard-model...] so the [remove|https://github.com/bstansberry/wildfly-core/blob/discard-model/con...] of the capability doesn't happen which makes the first step of the operation happy as the capability still exists. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-2990) Forward port EAP 6.2/6.3 xml schemas

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-2990?page=com.atlassian.jira.plugin.... ] Jason Greene resolved WFLY-2990. -------------------------------- Assignee: Jason Greene Resolution: Done > Forward port EAP 6.2/6.3 xml schemas > ------------------------------------ > > Key: WFLY-2990 > URL: https://issues.jboss.org/browse/WFLY-2990 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Brian Stansberry > Assignee: Jason Greene > Priority: Blocker > Fix For: 9.0.0.Final > > > EAP 6.3 will be introducing new versions of domain configuration xml schemas. These will basically be schemas containing some subset of the diff between the AS 7.2 schemas and the WF 9 schemas. > These schemas and parsing thereof need to be forward ported into WF. > Hopefully the schemas used for EAP 6.2 are already forward ported and this is mostly about 6.3. > This is a parent task to capture the overall requirement and the task of analyzing what areas need the forward port. Subtasks or linked issues should be used for the specific porting tasks (e.g. one per subsystem) -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-3681) General Schema Sync with EAP

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-3681?page=com.atlassian.jira.plugin.... ] Jason Greene updated WFLY-3681: ------------------------------- Parent: (was: WFLY-2990) Issue Type: Task (was: Sub-task) > General Schema Sync with EAP > ---------------------------- > > Key: WFLY-3681 > URL: https://issues.jboss.org/browse/WFLY-3681 > Project: WildFly > Issue Type: Task > Components: Domain Management > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Priority: Critical > Fix For: 10.0.0.Alpha5 > > > This may actually be more about pushing some changes to EAP, new schemas are being tracked by individual issues but for the remaining schemas where cosmetic changes have been made or corrections to default values and min/max occurs we need to sync with EAP. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-796) Native maven pom parser doesn't work under OSGi

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-796?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-796. -------------------------------- Fix Version/s: 6.3.0.Beta2 Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/e80b85407 > Native maven pom parser doesn't work under OSGi > ----------------------------------------------- > > Key: DROOLS-796 > URL: https://issues.jboss.org/browse/DROOLS-796 > Project: Drools > Issue Type: Bug > Affects Versions: 6.2.0.Final > Reporter: David virgil naranjo > Assignee: Mario Fusco > Fix For: 6.3.0.Beta2 > > Attachments: switchyard-example-rules-kie.zip > > > The KieScanner is used on Switchyard (layer of drools). It is failing for certains cases. > In the example attached, this is the error obtained when the kieScanner tires to read the pom.xml of the project uploadded to the maven repo: > https://gist.github.com/dvirgiln/e5c69afc7434367e04c1 > This is executed on EAP. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-215) Corrupted Working/Production memory

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-215?page=com.atlassian.jira.plugin... ] Mario Fusco resolved DROOLS-215. -------------------------------- Resolution: Won't Fix > Corrupted Working/Production memory > ----------------------------------- > > Key: DROOLS-215 > URL: https://issues.jboss.org/browse/DROOLS-215 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final > Reporter: Ales Dolecek > Assignee: Mario Fusco > Attachments: ConcurrentNodeMemories.java > > > Experienced ClassCastException mixing BetaMemory and AlphaMemory. There is debate in the mailing list/forum. The problem seems to be related to dymanic updates of knowledgebase. > Saddly there is no deterministic way how to reproduce the issue, but that should not prevent tracking it here. > Stack trace from my project: > java.lang.ClassCastException: org.drools.reteoo.BetaMemory cannot be cast to org.drools.reteoo.AlphaNode$AlphaMemory > at org.drools.reteoo.AlphaNode.assertObject(AlphaNode.java:136) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:497) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:382) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.reteoo.ObjectTypeNode.assertObject(ObjectTypeNode.java:235) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.reteoo.EntryPointNode.assertObject(EntryPointNode.java:240) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:350) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.common.NamedEntryPoint.insert(NamedEntryPoint.java:311) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.common.AbstractWorkingMemory.insert(AbstractWorkingMemory.java:903) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:192) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.base.DefaultKnowledgeHelper.insert(DefaultKnowledgeHelper.java:186) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.defaultConsequence(Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1.java:7) ~[na > :na] > at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvokerGenerated.evaluate(Unknown Source) ~[na:na] > at cz.nextiraone.screening.rules.screening.Rule_Telefonni_cislo_z_textu__jen_cifry__225b11d6cd07418aac8c06cf5c86b4b1DefaultConsequenceInvoker.evaluate(Unknown Source) ~[na:na] > at org.drools.common.DefaultAgenda.fireActivation(DefaultAgenda.java:1287) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1221) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1456) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:710) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.common.AbstractWorkingMemory.fireAllRules(AbstractWorkingMemory.java:674) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] > at org.drools.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:230) ~[drools-core-5.5.0.Final.jar:5.5.0.Final] -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-185) ClassCastException at ConditionEvaluator

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-185?page=com.atlassian.jira.plugin... ] Mario Fusco closed DROOLS-185. ------------------------------ Resolution: Won't Fix > ClassCastException at ConditionEvaluator > ---------------------------------------- > > Key: DROOLS-185 > URL: https://issues.jboss.org/browse/DROOLS-185 > Project: Drools > Issue Type: Bug > Affects Versions: 5.5.0.Final > Reporter: Sergey Alaev > Assignee: Mario Fusco > > Stacktrace: > Caused by: java.lang.ClassCastException: ***** cannot be cast to ****** > at ConditionEvaluator443abf2927ca4f64a4ad86407ae34799.evaluate(Unknown Source) > at org.drools.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:200) > at org.drools.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:157) > at org.drools.reteoo.FromNode.checkConstraintsAndPropagate(FromNode.java:318) > at org.drools.reteoo.FromNode.assertLeftTuple(FromNode.java:164) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.doPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:232) > at org.drools.reteoo.CompositeLeftTupleSinkAdapter.createAndPropagateAssertLeftTuple(CompositeLeftTupleSinkAdapter.java:116) > at org.drools.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:154) > at org.drools.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:59) > Reason: > ConditionEvaluator seems to be using lazy initializing and then caches generated class to evaluate this expression with another arguments. > Given following: > interface A { > String getString(); > } > interface B { > String getString(); > } > class X implements B, A {} > class Y implements A{} > rule "test rule" > when: > A(string != null) > then: > end > When rule engine is called for the first time with instance of class X, ConditionEvaluator will bind itself to first found interface implementing method getString(), i.e. interface B. > Thus second call with instance of class Y will cause ClassCastException of casting Y to B. > Solution: force MVEL to bind bytecode generated methods to class/interface declared in the rule explicitly, in our case - to interface A. > Quickfix: use following declaration of class X: > class X implements A, B {} > Because ConditionEvaluator binds to first available interface, it will bind now to correct interface - to interface A. -- This message was sent by Atlassian JIRA (v6.3.15#6346)

8 years, 10 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 July 2015