August 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2879) Implement the "Edit" icon that opens the editing mode, and the "✔️" that closes it

by Guilherme Carreiro (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2879?page=com.atlassian.jira.plugi... ] Guilherme Carreiro updated DROOLS-2879: --------------------------------------- Story Points: 3 (was: 2) > Implement the "Edit" icon that opens the editing mode, and the "✔️" that closes it > ---------------------------------------------------------------------------------- > > Key: DROOLS-2879 > URL: https://issues.jboss.org/browse/DROOLS-2879 > Project: Drools > Issue Type: Task > Components: DMN Editor > Reporter: Guilherme Carreiro > Assignee: Guilherme Carreiro > Labels: drools-tools > Attachments: demo.gif > > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-67) [Artemis 2.x upgrade] IndexOutOfBoundsException during receiving messages in remote JCA scenario between Artemis 1.5 and 2.x

by Clebert Suconic (JIRA)

[ https://issues.jboss.org/browse/WFWIP-67?page=com.atlassian.jira.plugin.s... ] Clebert Suconic commented on WFWIP-67: -------------------------------------- [~mnovak] thanks.. I figured out what's going on... the reconnect is breaking the version check. I'm adding a test into master and fixing it.. thanks a lot! > [Artemis 2.x upgrade] IndexOutOfBoundsException during receiving messages in remote JCA scenario between Artemis 1.5 and 2.x > ----------------------------------------------------------------------------------------------------------------------------- > > Key: WFWIP-67 > URL: https://issues.jboss.org/browse/WFWIP-67 > Project: WildFly WIP > Issue Type: Bug > Components: Artemis > Reporter: Martin Styk > Assignee: Martyn Taylor > Priority: Blocker > > *Scenario:* > Nodes A and B are in cluster. Destinations InQueue and OutQueue are deployed on them. > MDBs are deployed on node C and D. These MDBs read messages from InQueue of nodes A, B and sends them to OutQueue on A and B. > Nodes A,B are running Artemis 1.5. Nodes C,D are using Artemis 2.6. > # Client sends messages to InQueue on node A > # MDBs on nodes C,D read messages from remote InQueue and send them to remote OutQueue on nodes A,B > # During processing of messages nodes A and C are killed > # Client reads messages from OutQueue on node B. > *Issue* > At the end of the test, client is not able to read message > {code} > java.lang.IndexOutOfBoundsException: readerIndex(9) + length(128) exceeds writerIndex(133): UnpooledDuplicatedByteBuf(ridx: 9, widx: 133, cap: 606, unwrapped: UnpooledByteBufAllocator$InstrumentedUnpooledUnsafeHeapByteBuf(ridx: 0, widx: 606, cap: 606)) > at io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1405) > at io.netty.buffer.AbstractByteBuf.checkReadableBytes(AbstractByteBuf.java:1392) > at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:872) > at io.netty.buffer.AbstractByteBuf.readBytes(AbstractByteBuf.java:880) > at io.netty.buffer.WrappedByteBuf.readBytes(WrappedByteBuf.java:649) > at org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:183) > at org.apache.activemq.artemis.api.core.SimpleString.readSimpleString(SimpleString.java:171) > at org.apache.activemq.artemis.api.core.SimpleString.readNullableSimpleString(SimpleString.java:158) > at org.apache.activemq.artemis.core.buffers.impl.ChannelBufferWrapper.readNullableSimpleString(ChannelBufferWrapper.java:69) > at org.apache.activemq.artemis.reader.TextMessageUtil.readBodyText(TextMessageUtil.java:37) > at org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:112) > at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.getMessage(ActiveMQMessageConsumer.java:224) > at org.apache.activemq.artemis.jms.client.ActiveMQMessageConsumer.receive(ActiveMQMessageConsumer.java:132) > at org.jboss.qa.hornetq.apps.clients.Receiver11.receiveMessage(Receiver11.java:151) > at org.jboss.qa.hornetq.apps.clients.ReceiverTransAck.run(ReceiverTransAck.java:89) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2397) PMML modules have classloader issues in OSGi

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2397?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-2397: ---------------------------------- Sprint: 2018 Week 33-35 > PMML modules have classloader issues in OSGi > -------------------------------------------- > > Key: DROOLS-2397 > URL: https://issues.jboss.org/browse/DROOLS-2397 > Project: Drools > Issue Type: Bug > Affects Versions: 7.6.0.Final > Environment: Equinox OSGi container, Java 8 > Reporter: Jens Reimann > Assignee: Lance Leverich > > The drools PMML modules (drools-pmml and kie-pmml) both suffer from a few class loader issues when running inside an OSGi container. > The KieBase built for transforming the PMML model to Drools model selects the wrong class loader (based on the context class loader). The JAXB instance creator fails with the same problem. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-433) Score Cards: PMML4Compiler fails to load PMML- KBases

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-433?page=com.atlassian.jira.plugin... ] Tibor Zimányi updated DROOLS-433: --------------------------------- Sprint: 2018 Week 33-35 > Score Cards: PMML4Compiler fails to load PMML- KBases > ----------------------------------------------------- > > Key: DROOLS-433 > URL: https://issues.jboss.org/browse/DROOLS-433 > Project: Drools > Issue Type: Bug > Affects Versions: 6.0.0.Final > Reporter: Michael Anstis > Assignee: Lance Leverich > -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2749) DMN invoking and/or importing a bkm with a dot in name

by Tibor Zimányi (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2749?page=com.atlassian.jira.plugi... ] Tibor Zimányi updated DROOLS-2749: ---------------------------------- Sprint: 2018 Week 27-29, 2018 Week 30-32 (was: 2018 Week 27-29, 2018 Week 30-32, 2018 Week 33-35) > DMN invoking and/or importing a bkm with a dot in name > ------------------------------------------------------ > > Key: DROOLS-2749 > URL: https://issues.jboss.org/browse/DROOLS-2749 > Project: Drools > Issue Type: Bug > Components: dmn engine > Reporter: Matteo Mortari > Assignee: Matteo Mortari > > # Verify when a DMN model Invoke (decision logic) a BKM with a dot in the name > # Verify when a DMN model import and invoke Invoke (decision logic) a BKM with a dot in the name -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-104) Multiple service modules in single EAR use same tracer instance

by Juraci Paixão Kröhling (JIRA)

[ https://issues.jboss.org/browse/WFWIP-104?page=com.atlassian.jira.plugin.... ] Juraci Paixão Kröhling updated WFWIP-104: ----------------------------------------- Sprint: Kiali Sprint #9 > Multiple service modules in single EAR use same tracer instance > --------------------------------------------------------------- > > Key: WFWIP-104 > URL: https://issues.jboss.org/browse/WFWIP-104 > Project: WildFly WIP > Issue Type: Bug > Components: MP Request Tracing > Reporter: Michal Jurc > Assignee: Juraci Paixão Kröhling > Priority: Blocker > > When deploying an EAR with two stand-alone JAX-RS services in stand-alone WAR modules, both of the services use the same {{Tracer}} instance. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-1624) BC FIPS with CLI: Could not connect to remote+https://127.0.0.1:9993. The connection timed out

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-1624?page=com.atlassian.jira.plugin.s... ] Farah Juma commented on ELY-1624: --------------------------------- [~mchoma] Stuart reviewed and approved the fix. He noted that it does waste memory when not using Bouncy Castle but he also said that any other fix would be very invasive. This parameter isn't currently configurable, but we could look at making it configurable in the future. The IllegalArgumentException was being thrown in [RemoteConnectionProvider#createSslConnection()|https://github.com/jboss-r...] preventing [ServerConnectionOpenListener#handleEvent()|https://github.com/jboss-remot...] from being called so the connection would just time out. The PR to get this into WildFly Core is here: https://github.com/wildfly/wildfly-core/pull/3450 > BC FIPS with CLI: Could not connect to remote+https://127.0.0.1:9993. The connection timed out > ---------------------------------------------------------------------------------------------- > > Key: ELY-1624 > URL: https://issues.jboss.org/browse/ELY-1624 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Martin Choma > Assignee: Farah Juma > Priority: Blocker > Attachments: eap_server.log, jboss-cli.log, keystore.bcfks, standalone.xml > > > I am trying to connect from jboss-cli.sh to EAP server. Server and client run with BC FIPS. > {code:java|title=jboss-cli.log} > 11:48:08,992 TRACE [org.jboss.remoting.remote] Attempting to connect to "remote+https://127.0.0.1:9993" with options {org.xnio.Options.SSL_STARTTLS=>false,org.xnio.Options.SSL_ENABLED=>true} > 11:48:14,005 ERROR [org.jboss.as.cli.impl.CliLauncher] Error processing CLI: org.jboss.as.cli.CliInitializationException: Failed to connect to the controller > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:330) > at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:304) > at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:45) > at org.jboss.modules.Module.run(Module.java:352) > at org.jboss.modules.Module.run(Module.java:320) > at org.jboss.modules.Main.main(Main.java:593) > Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at 127.0.0.1:9993 > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1447) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1226) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1203) > at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:1198) > at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:328) > ... 5 more > Caused by: java.io.IOException: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+https://127.0.0.1:9993. The connection timed out > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:149) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) > at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1394) > ... 9 more > Caused by: java.net.ConnectException: WFLYPRT0023: Could not connect to remote+https://127.0.0.1:9993. The connection timed out > at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:130) > at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:259) > at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70) > at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.getChannel(ManagementClientChannelStrategy.java:167) > at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:192) > at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:126) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:135) > at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:110) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) > at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) > {code} > It works when I use > - non-FIPS java for CLI and FIPS java for server when connecting to secured 9993 port > - FIPS java for CLI and non-FIPS java for server when connecting to unsecured port 9990 > Here I get getting over ELY-1621 and ELY-1622 > I would appreciate any hint for way of investigation. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2872) CSS for test results panel/dock TABS

by Toni Rikkola (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2872?page=com.atlassian.jira.plugi... ] Toni Rikkola commented on DROOLS-2872: -------------------------------------- Since many of our components are dynamic I don't know how possible it is to work directly on the product code. I can help with running the existing codes if that is what is needed. If you have the HTML+CSS it should be easy to drop that in to our panel. > CSS for test results panel/dock TABS > ------------------------------------ > > Key: DROOLS-2872 > URL: https://issues.jboss.org/browse/DROOLS-2872 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Liz Clayton > Assignee: Sarah Rambacher > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Screen Shot 2018-08-09 at 11.27.12 AM.png > > > As a business analyst I want the ability to review simulation test results so that I can view the accuracy of my rules. > *Verification conditions:* > - CSS styles that employ relevant PatternFly styles and/or patterns, such as: http://www.patternfly.org/pattern-library/data-visualization/donut-chart/... > - CSS that articulates the design wireframe attached, and: > https://redhat.invisionapp.com/share/BVKORFBUJ24#/screens/302476070 > https://docs.google.com/document/d/1I_ghU9An--uQRzuVV9zXB387HLYjZcc01LXFX... > - Reviewed by scrum team prior to PR/dev delivery. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2870) [DMN Designer] Can not build project with multiple models

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2870?page=com.atlassian.jira.plugi... ] Edson Tirelli commented on DROOLS-2870: --------------------------------------- Michael, The Definitions properties that I think we need to expose are: * Id (probably read only) * name * namespace Also, the "description" element should probably be exposed somehow, although with lower priority. If you want just the minimal set, then the above. > [DMN Designer] Can not build project with multiple models > --------------------------------------------------------- > > Key: DROOLS-2870 > URL: https://issues.jboss.org/browse/DROOLS-2870 > Project: Drools > Issue Type: Bug > Components: DMN Editor > Affects Versions: 7.10.0.Final > Reporter: Jozef Marko > Assignee: Michael Anstis > Priority: Blocker > Labels: drools-tools > Fix For: 7.10.0.Final > > Attachments: Screenshot from 2018-08-09 10-20-16.png > > > If the project contains multiple dmn models, it can not be built. > h3. Manual acceptance test > - Prepare three models > -- Empty > -- Just graph nodes > -- Login inside graph nodes > - Check Deployment successful (/) -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9516) JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9516?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-9516: ------------------------------------ >From a JPA standard point of view, JPA 2.2 specification section 8.2.2 states that the scope of a persistence unit in a sub-deployment, is defined with in the jar or war and only visible to components defined in the jar or war. {code} 8.2.2 Persistence Unit Scope An EJB-JAR, WAR, application client jar, or EAR can define a persistence unit. When referencing a persistence unit using the unitName annotation element or persistence-unit-name deployment descriptor element, the visibility scope of the persistence unit is determined by its point of definition: • A persistence unit that is defined at the level of an EJB-JAR, WAR, or application client jar is scoped to that EJB-JAR, WAR, or application jar respectively and is visible to the components defined in that jar or war. • A persistence unit that is defined at the level of the EAR is generally visible to all components in the application. However, if a persistence unit of the same name is defined by an EJB-JAR, WAR, or application jar file within the EAR, the persistence unit of that name defined at EAR level will not be visible to the components defined by that EJB-JAR, WAR, or application jar file unless the persistence unit reference uses the persistence unit name # syntax to specify a path name to disambiguate the reference. When the # syntax is used, the path name is relative to the referencing application component jar file. For example, the syntax ../lib/persistenceUnitRoot.jar#myPersistenceUnit refers to a persistence unit whose name, as specified in the name element of the persistence.xml file, is myPersistenceUnit and for which the relative path name of the root of the persistence unit is ../lib/persistenceUnitRoot.jar. The # syntax may be used with both the unitName annotation element or persistence-unit-name deployment descriptor element to reference a persistence unit defined at EAR level. {code} Perhaps an option #3 solution, could be an extension, that if enabled, would scan sub-deployments for @PersistenceUnit/PersistenceContext references to other sub-deployments persistence units, such that sub-deployment1 could depend on a persistence unit in sub-deployment2, as long as sub-deployment2 doesn't depend on a persistence unit in sub-deployment1. I'm not sure if this would work but it could be attempted at some point. > JPA deployer adding cross sub deployment dependencies when multiple persistence units deployed > ---------------------------------------------------------------------------------------------- > > Key: WFLY-9516 > URL: https://issues.jboss.org/browse/WFLY-9516 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 11.0.0.Final > Reporter: Brad Maxwell > Assignee: Scott Marlow > > If an ear contains two EJB sub deployments which each contain a Persistence Unit and a Stateless EJB which injects the PU that is in its jar using @PersistenceContext. There is a dependency being added where in the Stateless EJB from one deployment depends on the PU from the other jar. It appears this is happening after this bug fix WFLY-1531 > {code} > app.ear > - ejb-with-pu1.jar > - ejb-with-pu2.jar > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

7 years, 11 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 August 2018