April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13360) Log WARN when EJB does not implement Business interface and is not compliant with EJB 3.2 spec

by Panagiotis Sotiropoulos (Jira)

[ https://issues.redhat.com/browse/WFLY-13360?page=com.atlassian.jira.plugi... ] Panagiotis Sotiropoulos updated WFLY-13360: ------------------------------------------- Description: >From the specification every business interface need to be declared explicitly as a business interface by @Remote or @Local annotation or deployment descriptor. EJB 3.2 specification 4.9.7 Session Bean’s Business Interface - The bean class must implement the interface or the interface must be designated as a local or remote business interface of the bean by means of the Local or Remote annotation or in the deployment descriptor. - All business interfaces must be explicitly designated as such if any of the following is true: - the bean exposes a no-interface view - any interface of the bean class is explicitly designated as a business interface of the bean by either of the following means: - using the Local or Remote annotation with a non-empty value on the bean class - using the Local or Remote annotation on the interface - in the deployment descriptor If EJB A implements I and EJB B extends A , EJB B must also declare it implements I in order to be spec compliant: public interface I {...} @Stateless public class A implements I {...} @Stateless public class B extends A {...} > Log WARN when EJB does not implement Business interface and is not compliant with EJB 3.2 spec > ---------------------------------------------------------------------------------------------- > > Key: WFLY-13360 > URL: https://issues.redhat.com/browse/WFLY-13360 > Project: WildFly > Issue Type: Bug > Reporter: Panagiotis Sotiropoulos > Assignee: Panagiotis Sotiropoulos > Priority: Major > > From the specification every business interface need to be declared explicitly as a business interface by @Remote or @Local annotation or deployment descriptor. > EJB 3.2 specification > 4.9.7 Session Bean’s Business Interface > - The bean class must implement the interface or the interface must be designated as a local or remote business interface of the bean by means of the Local or Remote annotation or in the deployment descriptor. > - All business interfaces must be explicitly designated as such if any of the following is true: > - the bean exposes a no-interface view > - any interface of the bean class is explicitly designated as a business interface of the bean by either of the following means: > - using the Local or Remote annotation with a non-empty value on the bean class > - using the Local or Remote annotation on the interface > - in the deployment descriptor > If EJB A implements I and EJB B extends A , EJB B must also declare it implements I in order to be spec compliant: > public interface I {...} > > @Stateless > public class A implements I {...} > > @Stateless > public class B extends A {...} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5227) Investigate performance degradation of fact type API usage in drools 7

by Mario Fusco (Jira)

[ https://issues.redhat.com/browse/DROOLS-5227?page=com.atlassian.jira.plug... ] Mario Fusco resolved DROOLS-5227. --------------------------------- Resolution: Done Fixed by https://github.com/kiegroup/drools/commit/88e4ab47fe173739866a3a54c22c5dd... > Investigate performance degradation of fact type API usage in drools 7 > ---------------------------------------------------------------------- > > Key: DROOLS-5227 > URL: https://issues.redhat.com/browse/DROOLS-5227 > Project: Drools > Issue Type: Task > Reporter: Mario Fusco > Assignee: Mario Fusco > Priority: Major > > In Drools 7 a big amount of time is spent to manage a NoSuchFieldExceptions in Class.getDeclaredField. This happens when client code tries to get/set a value of a non-existent field of a Fact Type: while in Drools 6 it immediately returns a null, in Drools 7 causes the execution of a recursive routine introspecting the class itself. Very likely this change behaviour has been introduced by this commit https://github.com/kiegroup/drools/commit/435f7ead86e20b361e25abd60f1b228... -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFWIP-301) SingleServerRuntimeTest intermittent failure in CodeReady Studio jobs

by Josef Kopriva (Jira)

[ https://issues.redhat.com/browse/WFWIP-301?page=com.atlassian.jira.plugin... ] Josef Kopriva commented on WFWIP-301: ------------------------------------- HI, the tests are now failing for CRS 12.15.0.AM1 the reason: on slaves is installed old version webkitgtk, new eclipse needs to have new version webkitgtk4. [~simkam] is working on updating library. > SingleServerRuntimeTest intermittent failure in CodeReady Studio jobs > --------------------------------------------------------------------- > > Key: WFWIP-301 > URL: https://issues.redhat.com/browse/WFWIP-301 > Project: WildFly WIP > Issue Type: Bug > Reporter: Marek Kopecky > Assignee: Josef Kopriva > Priority: Blocker > > [CodeReady Studio Jenkins jobs|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/vie...] is not stable. > I started this job a few times and it seems that there is intermittent failure of SingleServerRuntimeTest operate no-configuration test, see [this jenkins run|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view...] or [this run|https://eap-qe-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/view/EAP7/view...], both with EAP 7.3.0.GA.CR3. > EAP QE needs clear statement on behalf of JBDS QE Team whether "this test failure doesn't block EAP7-1128 RFE and can be ignored" or let me know when the job will be stable. Until that, I consider that the job is not ready and blocks EAP7-1128 RFE. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4913) Upgrade wildfly-discovery-client to 1.2.1.Final

by Tomasz Adamski (Jira)

Tomasz Adamski created WFCORE-4913: -------------------------------------- Summary: Upgrade wildfly-discovery-client to 1.2.1.Final Key: WFCORE-4913 URL: https://issues.redhat.com/browse/WFCORE-4913 Project: WildFly Core Issue Type: Component Upgrade Affects Versions: 12.0.0.Beta1 Reporter: Tomasz Adamski Assignee: Tomasz Adamski -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4908) The write-attribute operation does not work on a hosts JVM resource

by Chao Wang (Jira)

[ https://issues.redhat.com/browse/WFCORE-4908?page=com.atlassian.jira.plug... ] Chao Wang commented on WFCORE-4908: ----------------------------------- Is that expected to complete the attribute name with [ after hitting TAB in below command ? {code} [domain@localhost:9990 /] /host=master/server-config=server-one/jvm=default:write-attribute(name=jvm-options {code} added here https://github.com/wildfly/wildfly-core/blob/12.0.0.Beta1/cli/src/main/ja... It seems to me that misleads to the wrong syntax described in the description. {code} [domain@localhost:9990 /] /host=master/server-config=server-one/jvm=default:write-attribute(name=jvm-options[... {code} > The write-attribute operation does not work on a hosts JVM resource > ------------------------------------------------------------------- > > Key: WFCORE-4908 > URL: https://issues.redhat.com/browse/WFCORE-4908 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Management > Reporter: James Perkins > Assignee: Jeff Mesnil > Priority: Major > Labels: domain-mode > > Under a hosts server config, {{/host=master/server-config=server-one/}}, there is a {{jvm}} resource. On this resource the {{write-attribute}} operation does not work expected. > {code} > [domain@embedded /] /host=master/server-config=server-one/jvm=default:add > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > [domain@embedded /] /host=master/server-config=server-one/jvm=default:write-attribute(name=jvm-options["-Xlog:gc*:file=${jboss.domain.servers.dir}/server-two/log/gc.log"]) > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > [domain@embedded /] /host=master/server-config=server-one/jvm=default:read-resource > { > "outcome" => "success", > "result" => { > "agent-lib" => undefined, > "agent-path" => undefined, > "debug-enabled" => undefined, > "debug-options" => undefined, > "env-classpath-ignored" => undefined, > "environment-variables" => undefined, > "heap-size" => undefined, > "java-agent" => undefined, > "java-home" => undefined, > "jvm-options" => undefined, > "launch-command" => undefined, > "max-heap-size" => undefined, > "max-permgen-size" => undefined, > "permgen-size" => undefined, > "stack-size" => undefined, > "type" => undefined > } > } > {code} > As you can see from the above command does not update the {{jvm-options}}. However if you use the {{add-jvm-option}} operation that does work. It seems the {{write-attribute}} operation should also work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-4908) The write-attribute operation does not work on a hosts JVM resource

by Jean Francois Denise (Jira)

[ https://issues.redhat.com/browse/WFCORE-4908?page=com.atlassian.jira.plug... ] Jean Francois Denise commented on WFCORE-4908: ---------------------------------------------- The write-attribute expects a value otherwise the value is undefined. The write syntax should be: /host=master/server-config=server-one/jvm=default:write-attribute(name=jvm-options, value=["-Xlog:gc*:file=${jboss.domain.servers.dir}/server-two/log/gc.log"]) CLI send it as is, the server strips out the bogus part there: https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... That is called: https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/j... So to me we don't have an issue there. > The write-attribute operation does not work on a hosts JVM resource > ------------------------------------------------------------------- > > Key: WFCORE-4908 > URL: https://issues.redhat.com/browse/WFCORE-4908 > Project: WildFly Core > Issue Type: Bug > Components: CLI, Management > Reporter: James Perkins > Assignee: Jeff Mesnil > Priority: Major > Labels: domain-mode > > Under a hosts server config, {{/host=master/server-config=server-one/}}, there is a {{jvm}} resource. On this resource the {{write-attribute}} operation does not work expected. > {code} > [domain@embedded /] /host=master/server-config=server-one/jvm=default:add > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > [domain@embedded /] /host=master/server-config=server-one/jvm=default:write-attribute(name=jvm-options["-Xlog:gc*:file=${jboss.domain.servers.dir}/server-two/log/gc.log"]) > { > "outcome" => "success", > "result" => undefined, > "server-groups" => undefined > } > [domain@embedded /] /host=master/server-config=server-one/jvm=default:read-resource > { > "outcome" => "success", > "result" => { > "agent-lib" => undefined, > "agent-path" => undefined, > "debug-enabled" => undefined, > "debug-options" => undefined, > "env-classpath-ignored" => undefined, > "environment-variables" => undefined, > "heap-size" => undefined, > "java-agent" => undefined, > "java-home" => undefined, > "jvm-options" => undefined, > "launch-command" => undefined, > "max-heap-size" => undefined, > "max-permgen-size" => undefined, > "permgen-size" => undefined, > "stack-size" => undefined, > "type" => undefined > } > } > {code} > As you can see from the above command does not update the {{jvm-options}}. However if you use the {{add-jvm-option}} operation that does work. It seems the {{write-attribute}} operation should also work. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5231) Wrong BitMask created by a nested property in modify block

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5231?page=com.atlassian.jira.plug... ] Toshiya Kobayashi updated DROOLS-5231: -------------------------------------- Sprint: 2020 Week 13-15 (from Mar 23) > Wrong BitMask created by a nested property in modify block > ---------------------------------------------------------- > > Key: DROOLS-5231 > URL: https://issues.redhat.com/browse/DROOLS-5231 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.35.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > > When a nested property is modified in modify block like this: > {noformat} > rule R1 > when > $pet : Pet(age == 3) > then > modify ($pet) { getOwner().setLikes("Cookie") }; > end > {noformat} > executable model creates BitMask for "owner" and "likes" thus causes a build error. > {noformat} > [ERROR] testNestedPropInRHS[PATTERN_DSL](org.drools.modelcompiler.PropertyReactivityTest) Time elapsed: 2.702 s <<< ERROR! > java.lang.RuntimeException: Unknown property 'likes' for class class class org.drools.modelcompiler.domain.Pet > at org.drools.test.DomainClassesMetadata9429289867DBA6AE1EE0D6F3F6F68A4D$org_drools_modelcompiler_domain_Pet_Metadata.getPropertyIndex(DomainClassesMetadata9429289867DBA6AE1EE0D6F3F6F68A4D.java:24) > at org.drools.model.bitmask.BitMaskUtil.calculatePatternMask(BitMaskUtil.java:61) > at org.drools.model.BitMask.getPatternMask(BitMask.java:54) > at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4DRuleMethods0.rule_R1(Rules9429289867DBA6AE1EE0D6F3F6F68A4DRuleMethods0.java:24) > at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4D.getRulesList(Rules9429289867DBA6AE1EE0D6F3F6F68A4D.java:60) > at org.drools.test.Rules9429289867DBA6AE1EE0D6F3F6F68A4D.<init>(Rules9429289867DBA6AE1EE0D6F3F6F68A4D.java:64) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45) > at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:490) > at java.base/java.lang.Class.newInstance(Class.java:584) > at org.drools.modelcompiler.CanonicalKieModule.createInstance(CanonicalKieModule.java:410) > {noformat} -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13302) Add ARM64 versions for libartemis-native.so and libwfssl.so

by Emmanuel Hugonnet (Jira)

[ https://issues.redhat.com/browse/WFLY-13302?page=com.atlassian.jira.plugi... ] Emmanuel Hugonnet commented on WFLY-13302: ------------------------------------------ Apache Activemq Artemis doesn't provide those binaries. I've created a issue for it : https://issues.apache.org/jira/browse/ARTEMIS-2705 > Add ARM64 versions for libartemis-native.so and libwfssl.so > ----------------------------------------------------------- > > Key: WFLY-13302 > URL: https://issues.redhat.com/browse/WFLY-13302 > Project: WildFly > Issue Type: Feature Request > Components: Build System > Affects Versions: 19.0.0.Final > Reporter: Martin Grigorov > Assignee: Farah Juma > Priority: Major > > Hello WildFly team, > I'd like to ask you to add arm64/aarch64 versions of the libartemis-native.so and libwfssl.so binaries to the release distribution. > The TGZ download from https://wildfly.org/downloads/ has the following .so files: > {code} > wildfly-19.0.0.Final $ find ./ -name "*.so" > ./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-i686/libartemis-native-32.so > ./modules/system/layers/base/org/apache/activemq/artemis/journal/main/lib/linux-x86_64/libartemis-native-64.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-x86_64/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/linux-i386/libwfssl.so > ./modules/system/layers/base/org/wildfly/openssl/main/lib/solaris-x86_64/libwfssl.so > {code} > Since recently there is a TeamCity agent running on Ubuntu 18.04.4 ARM64: https://ci.wildfly.org/viewType.html?buildTypeId=WF_MasterLinuxArm64OpenJ911 > I guess it could be used to build those binaries too -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5025) Wrong BitMask created by a complex setter argument in modify block

by Toshiya Kobayashi (Jira)

[ https://issues.redhat.com/browse/DROOLS-5025?page=com.atlassian.jira.plug... ] Toshiya Kobayashi reassigned DROOLS-5025: ----------------------------------------- Assignee: Toshiya Kobayashi (was: Luca Molteni) > Wrong BitMask created by a complex setter argument in modify block > ------------------------------------------------------------------ > > Key: DROOLS-5025 > URL: https://issues.redhat.com/browse/DROOLS-5025 > Project: Drools > Issue Type: Bug > Components: executable model > Affects Versions: 7.32.0.Final > Reporter: Toshiya Kobayashi > Assignee: Toshiya Kobayashi > Priority: Major > Labels: good-first-issue > > With a complex setter argument in modify block like this: > {noformat} > import org.drools.modelcompiler.domain.Person; > rule R > when > $p: Person(address.street == "street1") > then > modify($p) { setLikes( String.valueOf(($p.getAddress().getStreet() + $p.getAddress().getCity()))) }; > end > {noformat} > executable model creates BitMask for "likes" and "address" thus causes a wrong property reactivity behavior. -- This message was sent by Atlassian Jira (v7.13.8#713008)

4 years, 6 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13359) Upgrade JGroups to 4.2.2.Final

by Radoslav Husar (Jira)

[ https://issues.redhat.com/browse/WFLY-13359?page=com.atlassian.jira.plugi... ] Radoslav Husar updated WFLY-13359: ---------------------------------- Description: Issues resolved https://issues.redhat.com/projects/JGRP/versions/12345154 Code changes https://github.com/belaban/JGroups/compare/JGroups-4.2.1.Final...JGroups-... was: Changelog https://github.com/belaban/JGroups/compare/JGroups-4.2.1.Final...JGroups-... > Upgrade JGroups to 4.2.2.Final > ------------------------------ > > Key: WFLY-13359 > URL: https://issues.redhat.com/browse/WFLY-13359 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Priority: Major > Fix For: 20.0.0.Beta1 > > > Issues resolved > https://issues.redhat.com/projects/JGRP/versions/12345154 > Code changes > https://github.com/belaban/JGroups/compare/JGroups-4.2.1.Final...JGroups-... -- This message was sent by Atlassian Jira (v7.13.8#713008)

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