July 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-4162) Scenario Test: UX for background data

by Klara Kufova (Jira)

[ https://issues.jboss.org/browse/DROOLS-4162?page=com.atlassian.jira.plugi... ] Klara Kufova commented on DROOLS-4162: -------------------------------------- [~danielezonca], [~zhutaojiajia] I think we should only allow to specify one background for the whole test scenario table (exactly for situations similar to the one depicted in Daniele's screenshot). What I had in mind originally was something like this: above the test scenario table, there could be a button called *set background* (or similar). After clicking the button, a new test scenario table would appear above the original one. Here, you could set the background exactly the same way how the user works with the original table (_i.e._ using the right panel). There could be other buttons as well, such as *remove background* _etc._ However, I'm not sure if we're able to have more than one table in the canvas. Alternatively, there could be a new tab called *Background* (Model, Background, Overview, Data Objects). After selecting the tab, the same page as the original one would appear, where it would be possible to set the background. There could also be some sort of a "feedback" in the original page (something like "a background is set"). Let me know if this is useful. You can also propose something completely different if you have better ideas how this could work! > Scenario Test: UX for background data > ------------------------------------- > > Key: DROOLS-4162 > URL: https://issues.jboss.org/browse/DROOLS-4162 > Project: Drools > Issue Type: Task > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Tao Zhu > Priority: Major > Labels: ScenarioSimulation, UX, UXTeam > Attachments: Screenshot from 2019-07-08 14-12-18.png, design1.png, design2.png, design3.png > > > As user I want to be able to specify a set of data shared by all the scenarios inside a simulation. All the data will be not editable. > Please refer to Cucumber background feature for details https://cucumber.io/docs/gherkin/reference/#background -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4243) Test Scenario: rule scenarios with maps of simple types are failing

by Klara Kufova (Jira)

[ https://issues.jboss.org/browse/DROOLS-4243?page=com.atlassian.jira.plugi... ] Klara Kufova commented on DROOLS-4243: -------------------------------------- [~emmurphy], could you please change the title + the text according to RHDM-1015? It seems a little bit vague at this point. > Test Scenario: rule scenarios with maps of simple types are failing > ------------------------------------------------------------------- > > Key: DROOLS-4243 > URL: https://issues.jboss.org/browse/DROOLS-4243 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Daniele Zonca > Assignee: Daniele Zonca > Priority: Critical > Labels: ScenarioSimulation, rhpam74releasenote > > Create a map of simple type as value (i.e. Map<String, String>) and try to use it -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12188) Option READ_TIMEOUT is ignored

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFLY-12188?page=com.atlassian.jira.plugin... ] James Perkins updated WFLY-12188: --------------------------------- Labels: blocker-WF18 (was: ) > Option READ_TIMEOUT is ignored > ------------------------------ > > Key: WFLY-12188 > URL: https://issues.jboss.org/browse/WFLY-12188 > Project: WildFly > Issue Type: Bug > Components: EJB, Remoting > Affects Versions: 17.0.0.Final > Reporter: Joerg Baesner > Assignee: Flavia Rainone > Priority: Blocker > Labels: blocker-WF18 > > What's the difference of the {{READ_TIMEOUT}} in _ejb3_ subsystem vs. _remoting_ subsystem? See: > {code} > <remote connector-ref="http-remoting-connector" thread-pool-name="default"> > <channel-creation-options> > <option name="READ_TIMEOUT" value="${prop.remoting-connector.read.timeout:20}" type="xnio"/> > <option name="MAX_OUTBOUND_MESSAGES" value="1234" type="remoting"/> > </channel-creation-options> > </remote> > {code} > {code} > <subsystem xmlns="urn:jboss:domain:remoting:4.0"> > <endpoint/> > <http-connector name="http-remoting-connector" connector-ref="default" security-realm="ApplicationRealm"> >  > <properties> > <property name="org.jboss.remoting3.RemotingOptions.HEARTBEAT_INTERVAL" value="5000"/> > <property name="KEEP_ALIVE" value="true"/> > <property name="READ_TIMEOUT" value="10000"/> > <property name="WRITE_TIMEOUT" value="10000"/> > </properties> > </http-connector> > {code} > None of those options work. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12274) EJB Bean with mappedName is not binding

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12274?page=com.atlassian.jira.plugin... ] Cheng Fang moved JBEAP-17156 to WFLY-12274: ------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-12274 (was: JBEAP-17156) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: EJB (was: EJB) Affects Version/s: 17.0.1.Final 17.0.0.Beta1 16.0.0.Final (was: 7.2.0.GA) > EJB Bean with mappedName is not binding > --------------------------------------- > > Key: WFLY-12274 > URL: https://issues.jboss.org/browse/WFLY-12274 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 17.0.1.Final, 17.0.0.Beta1, 16.0.0.Final > Reporter: Cheng Fang > Assignee: Bartosz Baranowski > Priority: Major > Attachments: mapped-name.jar > > > EJB Bean with mappedName is not binding , the mappedName is vendor specific, it is not portable, however @EJB(mappedName=...) is expecting a global JNDI path, but @Stateless(mappedName=...) does not appear to be binding anything. > {code} > @Stateless(name="HelloBean", mappedName="MappedHelloBean") > public class HelloBean implements Hello { > ... > {code} > {code} > @Startup > @Singleton > public class TestSingleton { > @EJB(mappedName="MappedHelloBean") > private Hello ejb; > ... > {code} > So the @EJB causes the TestSingleton to fail. > {code} > 22:12:55,637 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 72) MSC000001: Failed to start service jboss.deployment.unit."mapped-name.jar".component.TestSingleton.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."mapped-name.jar".component.TestSingleton.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance > ... > Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.jboss.examples.ejb.TestSingleton/ejb > ... > Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.jboss.examples.ejb.TestSingleton/ejb > ... > Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.jboss.examples.ejb.TestSingleton/ejb [Root exception is java.lang.RuntimeException: javax.naming.NameNotFoundException: MappedHelloBean -- service jboss.naming.context.java.MappedHelloBean] > ... > Caused by: java.lang.RuntimeException: javax.naming.NameNotFoundException: MappedHelloBean -- service jboss.naming.context.java.MappedHelloBean > ... > Caused by: javax.naming.NameNotFoundException: MappedHelloBean -- service jboss.naming.context.java.MappedHelloBean > ... > {code} > [1] https://docs.oracle.com/javaee/6/api/javax/ejb/EJB.html#mappedName() -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-12274) EJB Bean with mappedName is not binding

by Cheng Fang (Jira)

[ https://issues.jboss.org/browse/WFLY-12274?page=com.atlassian.jira.plugin... ] Cheng Fang reassigned WFLY-12274: --------------------------------- Assignee: Cheng Fang (was: Bartosz Baranowski) > EJB Bean with mappedName is not binding > --------------------------------------- > > Key: WFLY-12274 > URL: https://issues.jboss.org/browse/WFLY-12274 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final, 17.0.0.Beta1, 17.0.1.Final > Reporter: Cheng Fang > Assignee: Cheng Fang > Priority: Major > Attachments: mapped-name.jar > > > EJB Bean with mappedName is not binding , the mappedName is vendor specific, it is not portable, however @EJB(mappedName=...) is expecting a global JNDI path, but @Stateless(mappedName=...) does not appear to be binding anything. > {code} > @Stateless(name="HelloBean", mappedName="MappedHelloBean") > public class HelloBean implements Hello { > ... > {code} > {code} > @Startup > @Singleton > public class TestSingleton { > @EJB(mappedName="MappedHelloBean") > private Hello ejb; > ... > {code} > So the @EJB causes the TestSingleton to fail. > {code} > 22:12:55,637 ERROR [org.jboss.msc.service.fail] (ServerService Thread Pool -- 72) MSC000001: Failed to start service jboss.deployment.unit."mapped-name.jar".component.TestSingleton.START: org.jboss.msc.service.StartException in service jboss.deployment.unit."mapped-name.jar".component.TestSingleton.START: java.lang.IllegalStateException: WFLYEE0042: Failed to construct component instance > ... > Caused by: javax.ejb.EJBException: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.jboss.examples.ejb.TestSingleton/ejb > ... > Caused by: java.lang.RuntimeException: WFLYNAM0059: Resource lookup for injection failed: env/com.jboss.examples.ejb.TestSingleton/ejb > ... > Caused by: javax.naming.NamingException: WFLYNAM0062: Failed to lookup env/com.jboss.examples.ejb.TestSingleton/ejb [Root exception is java.lang.RuntimeException: javax.naming.NameNotFoundException: MappedHelloBean -- service jboss.naming.context.java.MappedHelloBean] > ... > Caused by: java.lang.RuntimeException: javax.naming.NameNotFoundException: MappedHelloBean -- service jboss.naming.context.java.MappedHelloBean > ... > Caused by: javax.naming.NameNotFoundException: MappedHelloBean -- service jboss.naming.context.java.MappedHelloBean > ... > {code} > [1] https://docs.oracle.com/javaee/6/api/javax/ejb/EJB.html#mappedName() -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1841) Update the pre-recorded messages in AcmeClientSpiTest using the latest Boulder instance

by Farah Juma (Jira)

[ https://issues.jboss.org/browse/ELY-1841?page=com.atlassian.jira.plugin.s... ] Farah Juma updated ELY-1841: ---------------------------- Component/s: Testsuite > Update the pre-recorded messages in AcmeClientSpiTest using the latest Boulder instance > --------------------------------------------------------------------------------------- > > Key: ELY-1841 > URL: https://issues.jboss.org/browse/ELY-1841 > Project: WildFly Elytron > Issue Type: Task > Components: Testsuite > Reporter: Farah Juma > Assignee: Ashley Abdel-Sayed > Priority: Major > Fix For: 1.10.0.CR3 > > > The tests in {{AcmeClientSpiTest}} simulate a mock Let's Encrypt server by using messages that were actually sent from Boulder (Let's Encrypt's testing server) to our ACME client. Wireshark was used to record the messages. The use of these recorded messages prevents us from having to integrate the complex Boulder setup into the Elytron testsuite. > Since these messages were pre-recorded just before the ACME protocol became an RFC, it would be good to update the pre-recorded messages used in these tests using the latest Boulder instance. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4562) Update the pre-recorded messages in CertificateAuthoritiesTestCase and KeyStoresTestCase using the latest Boulder instance

by Farah Juma (Jira)

Farah Juma created WFCORE-4562: ---------------------------------- Summary: Update the pre-recorded messages in CertificateAuthoritiesTestCase and KeyStoresTestCase using the latest Boulder instance Key: WFCORE-4562 URL: https://issues.jboss.org/browse/WFCORE-4562 Project: WildFly Core Issue Type: Task Components: Test Suite Reporter: Farah Juma Assignee: Ashley Abdel-Sayed The tests in {{CertificateAuthoritiesTestCase}} and {{KeyStoresTestCase}} simulate a mock Let's Encrypt server by using messages that were actually sent from Boulder (Let's Encrypt's testing server) to our ACME client. Wireshark was used to record the messages. The use of these recorded messages prevents us from having to integrate the complex Boulder setup into the Core testsuite. Since these messages were pre-recorded just before the ACME protocol became an RFC, it would be good to update the pre-recorded messages used in these tests using the latest Boulder instance. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (ELY-1841) Update the pre-recorded messages in AcmeClientSpiTest using the latest Boulder instance

by Farah Juma (Jira)

Farah Juma created ELY-1841: ------------------------------- Summary: Update the pre-recorded messages in AcmeClientSpiTest using the latest Boulder instance Key: ELY-1841 URL: https://issues.jboss.org/browse/ELY-1841 Project: WildFly Elytron Issue Type: Task Reporter: Farah Juma Assignee: Ashley Abdel-Sayed Fix For: 1.10.0.CR3 The tests in {{AcmeClientSpiTest}} simulate a mock Let's Encrypt server by using messages that were actually sent from Boulder (Let's Encrypt's testing server) to our ACME client. Wireshark was used to record the messages. The use of these recorded messages prevents us from having to integrate the complex Boulder setup into the Elytron testsuite. Since these messages were pre-recorded just before the ACME protocol became an RFC, it would be good to update the pre-recorded messages used in these tests using the latest Boulder instance. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-109) Update syslog handler attributes

by James Perkins (Jira)

[ https://issues.jboss.org/browse/WFCORE-109?page=com.atlassian.jira.plugin... ] James Perkins commented on WFCORE-109: -------------------------------------- Hi [~rornaz] Okay in that case I've got possible good news. In WildFly 17 WFCORE-4332 introduced a new {{named-formatter}} attribute so you can do that now. If you can't jump to WildFly 17 the following CLI command should work: {code} /subsystem=logging/custom-handler=syslog:add(module=org.jboss.logmanager, class=org.jboss.logmanager.handlers.SyslogHandler, properties={appName="my-app", syslogType="RFC5424", protocol="UDP"}, named-formatter=PATTERN) {code} > Update syslog handler attributes > -------------------------------- > > Key: WFCORE-109 > URL: https://issues.jboss.org/browse/WFCORE-109 > Project: WildFly Core > Issue Type: Feature Request > Components: Logging > Reporter: James Perkins > Assignee: James Perkins > Priority: Major > > The syslog handler does not currently expose the formatter for formatting messages. There will also be changes in a future logmanager release for TCP support and various other properties based on the new TCP support. -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4300) Karaf KIE features contains special maven keywords RELEASE

by Daniel Brownell (Jira)

[ https://issues.jboss.org/browse/DROOLS-4300?page=com.atlassian.jira.plugi... ] Daniel Brownell commented on DROOLS-4300: ----------------------------------------- Ok, found workaround Turns out 7.18.0.Final does not do this. > Karaf KIE features contains special maven keywords RELEASE > ---------------------------------------------------------- > > Key: DROOLS-4300 > URL: https://issues.jboss.org/browse/DROOLS-4300 > Project: Drools > Issue Type: Bug > Components: integration > Affects Versions: 7.11.0.Final > Environment: JBoss Fuse 7.3 on Centos 7 (inside Docker 18.09.7), openjdk version "1.8.0_212" > Reporter: Daniel Brownell > Assignee: Mario Fusco > Priority: Major > > In order to install KIE in Fuse, > one needs to run: > features:install kie > This requires adding a URL first: > features:addurl mvn:org.kie/kie-karaf-features/7.11.0.Final/xml/features > This however adds: > mvn:org.apache.camel.karaf/apache-camel/RELEASE/xml/features > and > mvn:org.apache.cxf.karaf/apache-cxf/3.2.7.fuse-sb2-740011/xml/features > to my feature:repo-list > These are Red Hat Fuse 7.4 features, because the maven special word, RELEASE, grabs the latest versions available. I'm using Fuse 7.3 though, and it crashes a bunch of our applications, and spews errors. > For example, it automatically tries to update all of the installed features to use the latest, and then gets into a loop of > "Error resolving artifact org.apache.cxf.xjc-utils:cxf-xjc-runtime:jar:3.2.4.fuse-740013" for whatever reason. > How does one work around this? What is a safe way to use KIE in Fuse? -- This message was sent by Atlassian Jira (v7.12.1#712002)

6 years, 10 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 July 2019