June 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13522) Upgrade jboss-ejb-client to 4.0.33.Final

by Cheng Fang (Jira)

[ https://issues.redhat.com/browse/WFLY-13522?page=com.atlassian.jira.plugi... ] Cheng Fang updated WFLY-13522: ------------------------------ Description: diff between 4.0.32.Final and 4.0.33.Final: https://github.com/wildfly/jboss-ejb-client/compare/4.0.32.Final...4.0.33... > Upgrade jboss-ejb-client to 4.0.33.Final > ---------------------------------------- > > Key: WFLY-13522 > URL: https://issues.redhat.com/browse/WFLY-13522 > Project: WildFly > Issue Type: Component Upgrade > Components: EJB > Reporter: Ilia Vassilev > Assignee: Tomasz Adamski > Priority: Major > Labels: downstream_dependency > Fix For: 20.0.0.Final > > > diff between 4.0.32.Final and 4.0.33.Final: https://github.com/wildfly/jboss-ejb-client/compare/4.0.32.Final...4.0.33... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13552) Upgrade wildfly-http-client to 1.0.21.Final

by Brian Stansberry (Jira)

Brian Stansberry created WFLY-13552: --------------------------------------- Summary: Upgrade wildfly-http-client to 1.0.21.Final Key: WFLY-13552 URL: https://issues.redhat.com/browse/WFLY-13552 Project: WildFly Issue Type: Component Upgrade Components: EJB, Naming Reporter: Brian Stansberry Assignee: Brian Stansberry Fix For: 20.0.0.Final Pull in https://issues.redhat.com/browse/WEJBHTTP-40, https://issues.redhat.com/browse/WEJBHTTP-41 -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13424) External pooled connection factory won't be properly injected if it has several JNDI entries

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-13424?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet commented on WFLY-13424: ------------------------------------------ That's exactly what we are doing in the fix (except we don't do it recursively as only one iteration is required). https://github.com/wildfly/wildfly/pull/13262/commits/a91eba91c96f0a511fe... happens only for aliases > External pooled connection factory won't be properly injected if it has several JNDI entries > -------------------------------------------------------------------------------------------- > > Key: WFLY-13424 > URL: https://issues.redhat.com/browse/WFLY-13424 > Project: WildFly > Issue Type: Bug > Components: JMS > Affects Versions: 19.1.0.Final > Reporter: Emmanuel Hugonnet > Assignee: Emmanuel Hugonnet > Priority: Major > Fix For: 20.0.0.Beta1 > > > If the default JNDI name for MDB to get the resource adapter is not the first entry of the JNDI names bound for a pooled-connection-factory then the injection fails. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5400) Executable model build fails with SerialVersionUID and key annotations

by Matteo Casalino (Jira)

[ https://issues.redhat.com/browse/DROOLS-5400?page=com.atlassian.jira.plug... ] Matteo Casalino commented on DROOLS-5400: ----------------------------------------- Note: this is similar to DROOLS-5340, but occurs when the declared type has all its fields annotated with _@key_ > Executable model build fails with SerialVersionUID and key annotations > ---------------------------------------------------------------------- > > Key: DROOLS-5400 > URL: https://issues.redhat.com/browse/DROOLS-5400 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.38.0.Final > Reporter: Matteo Casalino > Assignee: Mario Fusco > Priority: Minor > Attachments: serial-version-uid-exec-model.zip > > > Executable model compilation fails on declared types with both _@SerialVersionUID_ and _@key_ annotations. > Example of DRL that fails to compile: > {noformat} > declare ServiceInformation > @serialVersionUID( 0 ) > code: String @key > end > rule "create new ServiceInformation" > when > then > insert( new ServiceInformation("123456") ); > end > {noformat} > Error: > {noformat} > Error Messages: > Message [id=1, kieBase=binding-field-indexed-with-square-brackets, level=ERROR, path=null, line=56, column=0 > text=Duplicate method ServiceInformation(String) in type ServiceInformation] > Message [id=2, kieBase=binding-field-indexed-with-square-brackets, level=ERROR, path=null, line=61, column=0 > text=Duplicate method ServiceInformation(String) in type ServiceInformation] > {noformat} > The example works fine when compiling without executable model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10173) EjbInvocationStatisticsTestCase fails on Windows: wait-time=0

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-10173?page=com.atlassian.jira.plugi... ] Paul Ferraro reopened WFLY-10173: --------------------------------- [~cfang] We are still seeing this test intermittently fail in the CI. e.g. https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxJdk11/207534 https://ci.wildfly.org/buildConfiguration/WF_PullRequest_LinuxSm/207535 > EjbInvocationStatisticsTestCase fails on Windows: wait-time=0 > ------------------------------------------------------------- > > Key: WFLY-10173 > URL: https://issues.redhat.com/browse/WFLY-10173 > Project: WildFly > Issue Type: Bug > Components: Test Suite > Affects Versions: 12.0.0.Final > Reporter: Jan Kalina > Assignee: Cheng Fang > Priority: Major > Fix For: 20.0.0.Final > > > Sometime, when running EjbInvocationStatisticsTestCase on Windows, assertion fails, as wait-time is 0 (verified it is 0 by adding debug message). > For me it fails allTests in most of cases, but when running test standalone, it fails only in 1 of 4 cases. > I suppose it is because of too short sleep in AbstractManagedBean. (in test is called 4 times, each invocation include 50ms sleep, so I consider probable the wait-time is 0 - need to use longer sleeps to fulfill the test) > {code} > [ERROR] Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.078 s <<< FAILURE! - in org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase > [ERROR] testSingletonWaitTime(org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase) Time elapsed: 0.438 s <<< FAILURE! > java.lang.AssertionError > at org.junit.Assert.fail(Assert.java:86) > at org.junit.Assert.assertTrue(Assert.java:41) > at org.junit.Assert.assertTrue(Assert.java:52) > at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.validateWaitTimeStatistic(EjbInvocationStatisticsTestCase.java:179) > at org.jboss.as.test.integration.ejb.management.deployments.EjbInvocationStatisticsTestCase.testSingletonWaitTime(EjbInvocationStatisticsTestCase.java:148) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:564) > at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) > at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) > at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) > at org.jboss.arquillian.junit.Arquillian$8$1.invoke(Arquillian.java:379) > ... > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5400) Executable model build fails with SerialVersionUID and key annotations

by Matteo Casalino (Jira)

Matteo Casalino created DROOLS-5400: --------------------------------------- Summary: Executable model build fails with SerialVersionUID and key annotations Key: DROOLS-5400 URL: https://issues.redhat.com/browse/DROOLS-5400 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.38.0.Final Reporter: Matteo Casalino Assignee: Mario Fusco Attachments: serial-version-uid-exec-model.zip Executable model compilation fails on declared types with both _@SerialVersionUID_ and _@key_ annotations. Example of DRL that fails to compile: {noformat} declare ServiceInformation @serialVersionUID( 0 ) code: String @key end rule "create new ServiceInformation" when then insert( new ServiceInformation("123456") ); end {noformat} Error: {noformat} Error Messages: Message [id=1, kieBase=binding-field-indexed-with-square-brackets, level=ERROR, path=null, line=56, column=0 text=Duplicate method ServiceInformation(String) in type ServiceInformation] Message [id=2, kieBase=binding-field-indexed-with-square-brackets, level=ERROR, path=null, line=61, column=0 text=Duplicate method ServiceInformation(String) in type ServiceInformation] {noformat} The example works fine when compiling without executable model. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5399) The collect/accumulate function with expired event is sensible to the order of inserted events

by Gary Hu (Jira)

[ https://issues.redhat.com/browse/DROOLS-5399?page=com.atlassian.jira.plug... ] Gary Hu closed DROOLS-5399. --------------------------- Resolution: Done > The collect/accumulate function with expired event is sensible to the order of inserted events > ---------------------------------------------------------------------------------------------- > > Key: DROOLS-5399 > URL: https://issues.redhat.com/browse/DROOLS-5399 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 7.38.0.Final > Reporter: Gary Hu > Assignee: Mario Fusco > Priority: Major > > If the function collect/accumulate is used in the beta node(left constraint) with expired event, it's sensible to the order of events being inserted, which should not. This issue didn't happen in bpms 6.4. It occurs in rhdm 7.x. > For example: > "import " + DummyEvent.class.getCanonicalName() + "\n" + > "import " + OtherEvent.class.getCanonicalName() + "\n" + > "import " + HashSet.class.getCanonicalName() + "\n" + > "declare DummyEvent " + > "@role( event ) " + > "@timestamp( eventTimestamp )\n" + > "@expires(0ms)" + > "end\n" + > "declare OtherEvent " + > "@role( event ) " + > "@timestamp( eventTimestamp )" + > "@expires(2d)" + > "end\n" + > "rule R0 when\n" + > " $d: OtherEvent() \n" + > " $r: HashSet ( size >= 2 ) from collect (DummyEvent())\n" + > "then\n" + > " System.out.println(\"R0 Fired\");" + > "end"; > If you insert events like: > ksession.insert( other); > ksession.insert( dummyEvent0 ); > ksession.insert( dummyEvent1); > The rule gets fired. But if you inserts the events like: > ksession.insert( dummyEvent0 ); > ksession.insert( other); > ksession.insert( dummyEvent1); > The rule doesn't get fired. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5399) The collect/accumulate function with expired event is sensible to the order of inserted events

by Gary Hu (Jira)

Gary Hu created DROOLS-5399: ------------------------------- Summary: The collect/accumulate function with expired event is sensible to the order of inserted events Key: DROOLS-5399 URL: https://issues.redhat.com/browse/DROOLS-5399 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.38.0.Final Reporter: Gary Hu Assignee: Mario Fusco If the function collect/accumulate is used in the beta node(left constraint) with expired event, it's sensible to the order of events being inserted, which should not. This issue didn't happen in bpms 6.4. It occurs in rhdm 7.x. For example: "import " + DummyEvent.class.getCanonicalName() + "\n" + "import " + OtherEvent.class.getCanonicalName() + "\n" + "import " + HashSet.class.getCanonicalName() + "\n" + "declare DummyEvent " + "@role( event ) " + "@timestamp( eventTimestamp )\n" + "@expires(0ms)" + "end\n" + "declare OtherEvent " + "@role( event ) " + "@timestamp( eventTimestamp )" + "@expires(2d)" + "end\n" + "rule R0 when\n" + " $d: OtherEvent() \n" + " $r: HashSet ( size >= 2 ) from collect (DummyEvent())\n" + "then\n" + " System.out.println(\"R0 Fired\");" + "end"; If you insert events like: ksession.insert( other); ksession.insert( dummyEvent0 ); ksession.insert( dummyEvent1); The rule gets fired. But if you inserts the events like: ksession.insert( dummyEvent0 ); ksession.insert( other); ksession.insert( dummyEvent1); The rule doesn't get fired. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-1978) (7.3.z) Update error message returned by AcmeClientSpi#getLocation

by Ilia Vassilev (Jira)

Ilia Vassilev created ELY-1978: ---------------------------------- Summary: (7.3.z) Update error message returned by AcmeClientSpi#getLocation Key: ELY-1978 URL: https://issues.redhat.com/browse/ELY-1978 Project: WildFly Elytron Issue Type: Bug Components: API / SPI Reporter: Ilia Vassilev Assignee: Sonia Zaldana Fix For: 1.12.0.Final The {{AcmeClientSpi#getLocation}} method returns the value of the "Location" header field if non-null. Otherwise, an exception is thrown. Currently, the error message is specific to accounts, i.e., the error message "No account location URL provided by ACME server" is returned. However, the {{AcmeClientSpi#getLocation}} method is actually called to retrieve the "Location" header field in other cases as well, like when obtaining the URL for orders and authorizations. This should be updated so that the exception that is thrown has an appropriate error message depending on the location URL that could not be retrieved (i.e., the error message should reference the "account location URL", the "order location URL", or the "authorization location URL" as appropriate). -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5398) The collect/accumulate function with expired event is sensible to the order of inserted events

by Gary Hu (Jira)

Gary Hu created DROOLS-5398: ------------------------------- Summary: The collect/accumulate function with expired event is sensible to the order of inserted events Key: DROOLS-5398 URL: https://issues.redhat.com/browse/DROOLS-5398 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 7.38.0.Final Reporter: Gary Hu Assignee: Mario Fusco If the function collect/accumulate is used in the beta node(left constraint) with expired event, it's sensible to the order of events being inserted, which should not. This issue didn't happen in bpms 6.4. It occurs in rhdm 7.x. For example: "import " + DummyEvent.class.getCanonicalName() + "\n" + "import " + OtherEvent.class.getCanonicalName() + "\n" + "import " + HashSet.class.getCanonicalName() + "\n" + "declare DummyEvent " + "@role( event ) " + "@timestamp( eventTimestamp )\n" + "@expires(0ms)" + "end\n" + "declare OtherEvent " + "@role( event ) " + "@timestamp( eventTimestamp )" + "@expires(2d)" + "end\n" + "rule R0 when\n" + " $d: OtherEvent() \n" + " $r: HashSet ( size >= 2 ) from collect (DummyEvent())\n" + "then\n" + " System.out.println(\"R0 Fired\");" + "end"; If you insert events like: ksession.insert( other); ksession.insert( dummyEvent0 ); ksession.insert( dummyEvent1); The rule gets fired. But if you inserts the events like: ksession.insert( dummyEvent0 ); ksession.insert( other); ksession.insert( dummyEvent1); The rule doesn't get fired. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 7 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 June 2020