October 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (HAWKULARQE-183) Secure link from CloudForms to MW Provider using SSL

by Prachi Yadav (JIRA)

[ https://issues.jboss.org/browse/HAWKULARQE-183?page=com.atlassian.jira.pl... ] Prachi Yadav moved JMAN4-222 to HAWKULARQE-183: ----------------------------------------------- Project: Hawkular QE (was: JBoss Management Requirements) Key: HAWKULARQE-183 (was: JMAN4-222) > Secure link from CloudForms to MW Provider using SSL > ---------------------------------------------------- > > Key: HAWKULARQE-183 > URL: https://issues.jboss.org/browse/HAWKULARQE-183 > Project: Hawkular QE > Issue Type: Task > Reporter: Prachi Yadav > Assignee: Prachi Yadav > > The connection between the middleware provider in CloudForms and the middleware manager should be secure by certificates maintained/managed by CloudForms using SSL — Requires that the client box trusts Hawkular Services certificate. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1746) API changes review for Drools Core

by Andrey V. Ponomarenko (JIRA)

Andrey V. Ponomarenko created DROOLS-1746: --------------------------------------------- Summary: API changes review for Drools Core Key: DROOLS-1746 URL: https://issues.jboss.org/browse/DROOLS-1746 Project: Drools Issue Type: Enhancement Reporter: Andrey V. Ponomarenko Assignee: Edson Tirelli Attachments: drools-core-1.png, drools-core-2.png The review of API changes for the Drools Core library since 6.3.0 version: https://abi-laboratory.pro/java/tracker/timeline/drools-core/ Hope it will be helpful for users and maintainers of the library. The report is generated by the https://github.com/lvc/japi-tracker tool for jars found at http://central.maven.org/maven2/org/drools/drools-core/ according to https://wiki.eclipse.org/Evolving_Java-based_APIs_2. Thank you. !drools-core-2.png|API symbols timeline! !drools-core-1.png|API changes review! -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9411) Upgrade to EJB Client 4.0.2.Final (and related components)

by Jason Greene (JIRA)

Jason Greene created WFLY-9411: ---------------------------------- Summary: Upgrade to EJB Client 4.0.2.Final (and related components) Key: WFLY-9411 URL: https://issues.jboss.org/browse/WFLY-9411 Project: WildFly Issue Type: Component Upgrade Reporter: Jason Greene Assignee: Jason Greene Priority: Blocker Fix For: 11.0.0.Final -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1374) Make it build & work on JDK9

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1374?page=com.atlassian.jira.plugi... ] Jason Greene commented on WFCORE-1374: -------------------------------------- [~ctomc] Feel free to resolve this if I am wrong. > Make it build & work on JDK9 > ---------------------------- > > Key: WFCORE-1374 > URL: https://issues.jboss.org/browse/WFCORE-1374 > Project: WildFly Core > Issue Type: Task > Reporter: Tomaz Cerar > Assignee: Tomaz Cerar > > Parent task to track all JDK9 related work in wildfly core. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-178) Removing properties from the configuration should result in a null value being set

by James Perkins (JIRA)

[ https://issues.jboss.org/browse/LOGMGR-178?page=com.atlassian.jira.plugin... ] James Perkins updated LOGMGR-178: --------------------------------- Fix Version/s: 2.1.0.Alpha5 > Removing properties from the configuration should result in a null value being set > ---------------------------------------------------------------------------------- > > Key: LOGMGR-178 > URL: https://issues.jboss.org/browse/LOGMGR-178 > Project: JBoss Log Manager > Issue Type: Enhancement > Reporter: James Perkins > Assignee: James Perkins > Fix For: 2.1.0.Alpha5 > > > In the configuration API if a {{PropertyConfigurable.removeProperty()}} is invoked the property is only removed from the configured properties. The value is left alone on the target instance. For non-primitive types a {{null}} value should be passed to the setter and for primitives a default value should be passed to the setter. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (LOGMGR-178) Removing properties from the configuration should result in a null value being set

by James Perkins (JIRA)

James Perkins created LOGMGR-178: ------------------------------------ Summary: Removing properties from the configuration should result in a null value being set Key: LOGMGR-178 URL: https://issues.jboss.org/browse/LOGMGR-178 Project: JBoss Log Manager Issue Type: Enhancement Reporter: James Perkins Assignee: James Perkins In the configuration API if a {{PropertyConfigurable.removeProperty()}} is invoked the property is only removed from the configured properties. The value is left alone on the target instance. For non-primitive types a {{null}} value should be passed to the setter and for primitives a default value should be passed to the setter. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1059) Drools can't find rules under stress

by Gireesh Sahukar (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1059?page=com.atlassian.jira.plugi... ] Gireesh Sahukar commented on DROOLS-1059: ----------------------------------------- [~mfusco] - Is there any chance your fix is available for the Drools 6.3.0 version that it was reported against? We're using a platform that comes bundled with that version and I'd prefer to just patch rather than incur performing regression of an entire platform. > Drools can't find rules under stress > ------------------------------------ > > Key: DROOLS-1059 > URL: https://issues.jboss.org/browse/DROOLS-1059 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: Massinissa BOUZIAD > Assignee: Mario Fusco > Priority: Blocker > Fix For: 6.4.0.Final, 7.0.0.Final > > Attachments: DroolsBugReproducerTest.java, reproducerRule.drl > > > In my knowledge base, I have many rules. > All of them are working very well in production with drools 6.0.1-FINAL even in stress condition hight trafic (arount 40 hits seconds) > This bug append when we made an upgrade with drools 6.3.0-FINAL which is compatible with jdk8 mandatory in my case. > So now when I put my rules under stress test (benchmarking) I got this random error. > Drools is unable to find a query (not always the same one). > I got this error for 0,6% of my requests. > *+Following the stack trace : +* > Unable to find query 'checkAndBindBasket' > at org.drools.core.phreak.SegmentUtilities.getQueryLiaNode(SegmentUtilities.java:518) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.phreak.SegmentUtilities.getQuerySegmentMemory(SegmentUtilities.java:208) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.SegmentMemory$QueryMemoryPrototype.populateMemory(SegmentMemory.java:505) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.SegmentMemory$Prototype.newSegmentMemory(SegmentMemory.java:400) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.impl.KnowledgeBaseImpl.createSegmentFromPrototype(KnowledgeBaseImpl.java:1424) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.phreak.SegmentUtilities.restoreSegmentFromPrototype(SegmentUtilities.java:186) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.phreak.SegmentUtilities.createSegmentMemory(SegmentUtilities.java:83) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.LeftInputAdapterNode.assertObject(LeftInputAdapterNode.java:167) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:60) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:145) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:494) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:384) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:298) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:93) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1289) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) ~[darty-pricing-ws-2.0.2.jar:2.0.2] > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260) ~[darty-pricing-ws-2.0.2.jar:2.0.2] -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9406) [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1)

by Alessio Soldano (JIRA)

[ https://issues.jboss.org/browse/WFLY-9406?page=com.atlassian.jira.plugin.... ] Alessio Soldano commented on WFLY-9406: --------------------------------------- [~ctomc], I've set this as blocked by the upgrade to Apache CXF 3.2, which is also scheduled for WFLY 12. > [WildFly 11] Upgrade ASM with Version 5.2 (unable to use Arquillian+JaCoCo with ASM 3.3.1) > ------------------------------------------------------------------------------------------ > > Key: WFLY-9406 > URL: https://issues.jboss.org/browse/WFLY-9406 > Project: WildFly > Issue Type: Component Upgrade > Components: Build System, JPA / Hibernate, Web Services > Affects Versions: 11.0.0.CR1 > Reporter: Tibor Digana > Assignee: Alessio Soldano > Priority: Minor > Fix For: 12.0.0.Alpha1 > > > Reported in GitHub https://github.com/wildfly/wildfly/issues/10531 > Arquillian dependends on JaCoCo does not work on WildFLy because AS uses ASM 3.3.1 and JaCoCo uses ASM 5.2. > The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} extends ASM class {{org.objectweb.asm.ClassVisitor}}. The problem is that {{ClassVisitor}} is interface in ASM 3.3.1. > Please upgrade it in POM: > https://github.com/wildfly/wildfly/blob/master/pom.xml -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3327) Confusion about the recording of the org.wildfly.remoting.endpoint capability and the resource that configures it

by Alexey Loubyansky (JIRA)

[ https://issues.jboss.org/browse/WFCORE-3327?page=com.atlassian.jira.plugi... ] Alexey Loubyansky commented on WFCORE-3327: ------------------------------------------- 2) is even more work in case we want to re-work other subsystems this way. That includes at least undertow and ejb3. While 2) looks the most reasonable approach to modeling these kind of cases, 1) may still be ok if the dependency from the parent to its child is expressed in the model, i.e. remoting -> endpoint (by means of caps or attribute refs). It may look confusing to the user performing manual configuration. On the the other hand, the provisioning mechanism has already figured out how to handle these cases by properly ordering the features and automatically starting batches where necessary. > Confusion about the recording of the org.wildfly.remoting.endpoint capability and the resource that configures it > ----------------------------------------------------------------------------------------------------------------- > > Key: WFCORE-3327 > URL: https://issues.jboss.org/browse/WFCORE-3327 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management, Remoting > Affects Versions: 3.0.3.Final > Reporter: Brian Stansberry > Assignee: Brian Stansberry > Fix For: 4.0.0.Beta1 > > > The org.wildfly.remoting.endpoint capability is reported by the /subsystem=remoting resource, but it is the /subsystem=remoting/configuration=endpoint that actually configures it. This is confusing for humans and difficult for tooling like the new provisioning tools. > The configuration=endpoint child is essentially a singleton and internally it just provides configuration to its parent. Further, if the user does not configure this resource, a default one is added automatically. This child resources is really just a configuration chunk for its parent. > In the end it is the parent resource that actually provides the capability, by installing a service. It reads its child resource to configure the capability. > There are a couple possibilities here: > 1) Simply move the declaration of the capability to the child resource. Per discussion with [~aloubyansky] is seems that solves the tool problem. It leaves the actual situation obscure though, because now a seemingly non-required child resource is the thing that provides a capability that actually will always be present. > 2) Deprecate that child resource and add a complex attribute to the parent. The child resource continues to exist in the API for compatibility reasons, but simply modifies the attribute on the parent. The cap remains on the parent. > Note that 2) may require some manipulation of how we handle undefined complex attributes; i.e. that when we resolve them, even if the root attribute is undefined, we need to resolve the fields, in case those have default values, with the resolved parent then including the default field values. That can be tricky though, e.g. in cases of things like the defaulted attribute having requires, or other fields in the complex attribute being required. > This latter point is relevant because it would be a 'worker' field in a complex attribute that would actually declare the name of the needed io worker capability. That field would have a default value 'default'. > Perhaps the declaration of the complex attribute itself (i.e. ObjectTypeAttributeDefinition) would need to indicate how things should be handled. That could just be the complex attribute itself has a default value, {"worker"=>"default"}. Or it could be a flag that enables looking at the fields for defaults if the top level attribute is undefined. Or maybe investigation will show this isn't a problem at all. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9410) Can't run mvn install against testsuite-shared module twice without an intervening clean

by Brian Stansberry (JIRA)

Brian Stansberry created WFLY-9410: -------------------------------------- Summary: Can't run mvn install against testsuite-shared module twice without an intervening clean Key: WFLY-9410 URL: https://issues.jboss.org/browse/WFLY-9410 Project: WildFly Issue Type: Bug Components: Test Suite Reporter: Brian Stansberry Trying to build testsuite/shared twice without a clean results in failure. Really annoying as a standard build of WildFly builds this module. Failure is: {code} [ERROR] Failed to execute goal org.codehaus.mojo:keytool-maven-plugin:1.5:generateKeyPair (gen-server-keystore) on project wildfly-testsuite-shared: Failed executing '/bin/sh -c cd /Users/bstansberry/dev/wildfly/wildfly/testsuite/shared && /Library/Java/JavaVirtualMachines/jdk1.8.0_77.jdk/Contents/Home/jre/../bin/keytool -genkeypair -v -keystore /Users/bstansberry/dev/wildfly/wildfly/testsuite/shared/target/shared-keystores/application.keystore -storepass '*****' -storetype JKS -alias server -dname 'cn=server, ou=organizationUnit, o=organizationName, c=countryCode' -keypass '*****' -validity 365 -keyalg RSA -keysize 2048' - exitcode 1 -> [Help 1] {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

8 years, 7 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira October 2017