April 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13361) Upgrade jboss-ejb-client to 4.0.32.Final

by Tomasz Adamski (Jira)

Tomasz Adamski created WFLY-13361: ------------------------------------- Summary: Upgrade jboss-ejb-client to 4.0.32.Final Key: WFLY-13361 URL: https://issues.redhat.com/browse/WFLY-13361 Project: WildFly Issue Type: Component Upgrade Reporter: Tomasz Adamski Assignee: Brian Stansberry -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-10612) Include EJB's IIOP Binding when EJB is deployed logging

by Ranabir Chakraborty (Jira)

[ https://issues.redhat.com/browse/WFLY-10612?page=com.atlassian.jira.plugi... ] Ranabir Chakraborty commented on WFLY-10612: -------------------------------------------- [~bmaxwell] is this issue still there ? > Include EJB's IIOP Binding when EJB is deployed logging > ------------------------------------------------------- > > Key: WFLY-10612 > URL: https://issues.redhat.com/browse/WFLY-10612 > Project: WildFly > Issue Type: Enhancement > Components: IIOP > Affects Versions: 12.0.0.Final > Reporter: Brad Maxwell > Assignee: Tomasz Adamski > Priority: Major > > It would be useful when EJBs configured with IIOP enabled or when enabled by default for all, that it log the binding for the IIOP interface as it is different from the JNDI bindings. > <iiop enable-by-default="true" use-qualified-name="true"/> > {code} > INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-4) WFLYEJB0473: JNDI bindings for session bean named 'HelloSessionBean' in deployment unit 'deployment "iiop-eap7.jar"' are as follows: > java:global/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloSessionBean > java:app/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloSessionBean > java:module/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloSessionBean > java:global/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome > java:app/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome > java:module/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome > java:jboss/exported/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemoteHome > java:global/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote > java:app/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote > java:module/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote > java:jboss/exported/iiop-eap7/HelloSessionBean!com.jboss.examples.ejb3.iiop.HelloRemote > {code} > Something like this when use-qualified-name="true" > {code} > IIOP bindings for for session bean named 'HelloSessionBean' in deployment unit 'deployment "iiop-eap7.jar"' are as follows: > iiop-eap7/HelloSessionBean > {code} > or use-qualified-name="false" > {code} > IIOP bindings for for session bean named 'HelloSessionBean' in deployment unit 'deployment "iiop-eap7.jar"' are as follows: > HelloSessionBean > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 months

1
0
0 / 0

[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 commented on WFLY-13360: ------------------------------------------------ Adding a multi-version testcase : https://github.com/jboss-set/eap-additional-testsuite/pull/134 > 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)

6 years, 3 months

1
0
0 / 0

[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)

6 years, 3 months

1
0
0 / 0

[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)

Panagiotis Sotiropoulos created WFLY-13360: ---------------------------------------------- Summary: 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 -- This message was sent by Atlassian Jira (v7.13.8#713008)

6 years, 3 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)

6 years, 3 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)

6 years, 3 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)

6 years, 3 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)

6 years, 3 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)

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