March 2019 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-3753) Create Master election system using ConfigMap on Openshift

by Massimiliano Dessi (Jira)

[ https://issues.jboss.org/browse/DROOLS-3753?page=com.atlassian.jira.plugi... ] Massimiliano Dessi updated DROOLS-3753: --------------------------------------- Summary: Create Master election system using ConfigMap on Openshift (was: Create Master election system using ETCD on Openshift) > Create Master election system using ConfigMap on Openshift > ---------------------------------------------------------- > > Key: DROOLS-3753 > URL: https://issues.jboss.org/browse/DROOLS-3753 > Project: Drools > Issue Type: Sub-task > Reporter: Massimiliano Dessi > Assignee: Massimiliano Dessi > Priority: Major > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11848) EJB WFLYEJB0473: JNDI bindings for ... ejb: is not correct when there is not an appName

by Chao Wang (Jira)

[ https://issues.jboss.org/browse/WFLY-11848?page=com.atlassian.jira.plugin... ] Chao Wang updated WFLY-11848: ----------------------------- Component/s: EJB > EJB WFLYEJB0473: JNDI bindings for ... ejb: is not correct when there is not an appName > --------------------------------------------------------------------------------------- > > Key: WFLY-11848 > URL: https://issues.jboss.org/browse/WFLY-11848 > Project: WildFly > Issue Type: Bug > Components: EJB > Affects Versions: 16.0.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > > EJB WFLYEJB0473: JNDI bindings for ... ejb: is not correct when there is not an appName > EAP 7.2 is logging the ejb: JNDI binding 'ejb:ejb-client/Hello!com.jboss.examples.ejb.Hello' which can be used by remote clients, but when the deployment is not an ear there is not an an AppName/ModuleName. > the format is: ejb: appName / moduleName / distinctName / EJBName!EJBInterface > For a deployment ejb-client.jar, the EJB it seeing appName == moduleName == ejb-client. But the way it has worked is if there is no sub deployment, then the appName is considered "", making the lookup: ejb:/ejb-client/Hello!com.jboss.examples.ejb.Hello > If the ejb-client.jar was packaged in app.ear, then the lookup would be ejb:app/ejb-client/Hello!com.jboss.examples.ejb.Hello > So all of that to say, there should be a / in the binding name when there is not an appName (ie not in an ear or not a subdeployment). > {code} > @Resource(lookup = "java:app/AppName") > private String appName; > @Resource(lookup = "java:module/ModuleName") > private String moduleName; > {code} > > https://docs.jboss.org/author/display/WFLY/EJB+invocations+from+a+remote+... > {code} > INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-5) WFLYEJB0473: JNDI bindings for session bean named 'Hello' in deployment unit 'deployment "ejb-client.jar"' are as follows: > java:global/ejb-client/Hello!com.jboss.examples.ejb.Hello > java:app/ejb-client/Hello!com.jboss.examples.ejb.Hello > java:module/Hello!com.jboss.examples.ejb.Hello > java:jboss/exported/ejb-client/Hello!com.jboss.examples.ejb.Hello > ejb:ejb-client/Hello!com.jboss.examples.ejb.Hello > java:global/ejb-client/Hello > java:app/ejb-client/Hello > java:module/Hello > {code} > org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor > {code} > // log EJB's ejb:/ namespace binding > final String ejbNamespaceBindingName = sessionBean.isStateful() ? ejbNamespaceBindingBaseName + "!" + viewClassName + "?stateful" : ejbNamespaceBindingBaseName + "!" + viewClassName; > logBinding(jndiBindingsLogMessage, ejbNamespaceBindingName); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11848) EJB WFLYEJB0473: JNDI bindings for ... ejb: is not correct when there is not an appName

by Chao Wang (Jira)

[ https://issues.jboss.org/browse/WFLY-11848?page=com.atlassian.jira.plugin... ] Chao Wang moved JBEAP-16551 to WFLY-11848: ------------------------------------------ Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-11848 (was: JBEAP-16551) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Fix Version/s: (was: 7.2.2.GA) > EJB WFLYEJB0473: JNDI bindings for ... ejb: is not correct when there is not an appName > --------------------------------------------------------------------------------------- > > Key: WFLY-11848 > URL: https://issues.jboss.org/browse/WFLY-11848 > Project: WildFly > Issue Type: Bug > Affects Versions: 16.0.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > > EJB WFLYEJB0473: JNDI bindings for ... ejb: is not correct when there is not an appName > EAP 7.2 is logging the ejb: JNDI binding 'ejb:ejb-client/Hello!com.jboss.examples.ejb.Hello' which can be used by remote clients, but when the deployment is not an ear there is not an an AppName/ModuleName. > the format is: ejb: appName / moduleName / distinctName / EJBName!EJBInterface > For a deployment ejb-client.jar, the EJB it seeing appName == moduleName == ejb-client. But the way it has worked is if there is no sub deployment, then the appName is considered "", making the lookup: ejb:/ejb-client/Hello!com.jboss.examples.ejb.Hello > If the ejb-client.jar was packaged in app.ear, then the lookup would be ejb:app/ejb-client/Hello!com.jboss.examples.ejb.Hello > So all of that to say, there should be a / in the binding name when there is not an appName (ie not in an ear or not a subdeployment). > {code} > @Resource(lookup = "java:app/AppName") > private String appName; > @Resource(lookup = "java:module/ModuleName") > private String moduleName; > {code} > > https://docs.jboss.org/author/display/WFLY/EJB+invocations+from+a+remote+... > {code} > INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-5) WFLYEJB0473: JNDI bindings for session bean named 'Hello' in deployment unit 'deployment "ejb-client.jar"' are as follows: > java:global/ejb-client/Hello!com.jboss.examples.ejb.Hello > java:app/ejb-client/Hello!com.jboss.examples.ejb.Hello > java:module/Hello!com.jboss.examples.ejb.Hello > java:jboss/exported/ejb-client/Hello!com.jboss.examples.ejb.Hello > ejb:ejb-client/Hello!com.jboss.examples.ejb.Hello > java:global/ejb-client/Hello > java:app/ejb-client/Hello > java:module/Hello > {code} > org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor > {code} > // log EJB's ejb:/ namespace binding > final String ejbNamespaceBindingName = sessionBean.isStateful() ? ejbNamespaceBindingBaseName + "!" + viewClassName + "?stateful" : ejbNamespaceBindingBaseName + "!" + viewClassName; > logBinding(jndiBindingsLogMessage, ejbNamespaceBindingName); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11848) EJB WFLYEJB0473: JNDI bindings for ... ejb: is not correct when there is not an appName

by Chao Wang (Jira)

[ https://issues.jboss.org/browse/WFLY-11848?page=com.atlassian.jira.plugin... ] Chao Wang updated WFLY-11848: ----------------------------- Affects Version/s: 16.0.0.Final > EJB WFLYEJB0473: JNDI bindings for ... ejb: is not correct when there is not an appName > --------------------------------------------------------------------------------------- > > Key: WFLY-11848 > URL: https://issues.jboss.org/browse/WFLY-11848 > Project: WildFly > Issue Type: Bug > Affects Versions: 16.0.0.Final > Reporter: Chao Wang > Assignee: Chao Wang > Priority: Major > > EJB WFLYEJB0473: JNDI bindings for ... ejb: is not correct when there is not an appName > EAP 7.2 is logging the ejb: JNDI binding 'ejb:ejb-client/Hello!com.jboss.examples.ejb.Hello' which can be used by remote clients, but when the deployment is not an ear there is not an an AppName/ModuleName. > the format is: ejb: appName / moduleName / distinctName / EJBName!EJBInterface > For a deployment ejb-client.jar, the EJB it seeing appName == moduleName == ejb-client. But the way it has worked is if there is no sub deployment, then the appName is considered "", making the lookup: ejb:/ejb-client/Hello!com.jboss.examples.ejb.Hello > If the ejb-client.jar was packaged in app.ear, then the lookup would be ejb:app/ejb-client/Hello!com.jboss.examples.ejb.Hello > So all of that to say, there should be a / in the binding name when there is not an appName (ie not in an ear or not a subdeployment). > {code} > @Resource(lookup = "java:app/AppName") > private String appName; > @Resource(lookup = "java:module/ModuleName") > private String moduleName; > {code} > > https://docs.jboss.org/author/display/WFLY/EJB+invocations+from+a+remote+... > {code} > INFO [org.jboss.as.ejb3.deployment] (MSC service thread 1-5) WFLYEJB0473: JNDI bindings for session bean named 'Hello' in deployment unit 'deployment "ejb-client.jar"' are as follows: > java:global/ejb-client/Hello!com.jboss.examples.ejb.Hello > java:app/ejb-client/Hello!com.jboss.examples.ejb.Hello > java:module/Hello!com.jboss.examples.ejb.Hello > java:jboss/exported/ejb-client/Hello!com.jboss.examples.ejb.Hello > ejb:ejb-client/Hello!com.jboss.examples.ejb.Hello > java:global/ejb-client/Hello > java:app/ejb-client/Hello > java:module/Hello > {code} > org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor > {code} > // log EJB's ejb:/ namespace binding > final String ejbNamespaceBindingName = sessionBean.isStateful() ? ejbNamespaceBindingBaseName + "!" + viewClassName + "?stateful" : ejbNamespaceBindingBaseName + "!" + viewClassName; > logBinding(jndiBindingsLogMessage, ejbNamespaceBindingName); > {code} -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11847) Upgrade ASM from 6.2.1 to 7.1

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFLY-11847?page=com.atlassian.jira.plugin... ] Richard Opalka updated WFLY-11847: ---------------------------------- Component/s: JPA / Hibernate > Upgrade ASM from 6.2.1 to 7.1 > ----------------------------- > > Key: WFLY-11847 > URL: https://issues.jboss.org/browse/WFLY-11847 > Project: WildFly > Issue Type: Component Upgrade > Components: JPA / Hibernate, Test Suite > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Labels: jdk13 > Fix For: 17.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11847) Upgrade ASM from 6.2.1 to 7.1

by Richard Opalka (Jira)

[ https://issues.jboss.org/browse/WFLY-11847?page=com.atlassian.jira.plugin... ] Richard Opalka updated WFLY-11847: ---------------------------------- Labels: jdk13 (was: ) > Upgrade ASM from 6.2.1 to 7.1 > ----------------------------- > > Key: WFLY-11847 > URL: https://issues.jboss.org/browse/WFLY-11847 > Project: WildFly > Issue Type: Component Upgrade > Components: Test Suite > Reporter: Richard Opalka > Assignee: Richard Opalka > Priority: Major > Labels: jdk13 > Fix For: 17.0.0.Beta1 > > -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11847) Upgrade ASM from 6.2.1 to 7.1

by Richard Opalka (Jira)

Richard Opalka created WFLY-11847: ------------------------------------- Summary: Upgrade ASM from 6.2.1 to 7.1 Key: WFLY-11847 URL: https://issues.jboss.org/browse/WFLY-11847 Project: WildFly Issue Type: Component Upgrade Components: Test Suite Reporter: Richard Opalka Assignee: Richard Opalka Fix For: 17.0.0.Beta1 -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11846) Deployment classloader leak on EE Concurrency managed threads

by Eduardo Martins (Jira)

[ https://issues.jboss.org/browse/WFLY-11846?page=com.atlassian.jira.plugin... ] Eduardo Martins updated WFLY-11846: ----------------------------------- Attachment: Screenshot 2019-03-13 at 20.21.19.png > Deployment classloader leak on EE Concurrency managed threads > ------------------------------------------------------------- > > Key: WFLY-11846 > URL: https://issues.jboss.org/browse/WFLY-11846 > Project: WildFly > Issue Type: Bug > Components: Concurrency Utilities > Affects Versions: 16.0.0.Final > Reporter: Eduardo Martins > Assignee: Eduardo Martins > Priority: Critical > Attachments: Screenshot 2019-03-13 at 20.21.19.png > > > A followup to WFLY-11678, managed threads have another deployment CL leak, which happens due to parent thread having a reference to it in its AccessControlContext. When a thread is created it inherits parent's AccessControlContext. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (WFLY-11846) Deployment classloader leak on EE Concurrency managed threads

by Eduardo Martins (Jira)

Eduardo Martins created WFLY-11846: -------------------------------------- Summary: Deployment classloader leak on EE Concurrency managed threads Key: WFLY-11846 URL: https://issues.jboss.org/browse/WFLY-11846 Project: WildFly Issue Type: Bug Components: Concurrency Utilities Affects Versions: 16.0.0.Final Reporter: Eduardo Martins Assignee: Eduardo Martins A followup to WFLY-11678, managed threads have another deployment CL leak, which happens due to parent thread having a reference to it in its AccessControlContext. When a thread is created it inherits parent's AccessControlContext. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

[JBoss JIRA] (AG-110) Support non-standard transaction isolation levels

by Rich DiCroce (Jira)

Rich DiCroce created AG-110: ------------------------------- Summary: Support non-standard transaction isolation levels Key: AG-110 URL: https://issues.jboss.org/browse/AG-110 Project: Agroal Issue Type: Enhancement Reporter: Rich DiCroce Assignee: Luis Barreiro Some databases support non-standard transaction isolation levels. For example, MS SQL Server has a SNAPSHOT isolation level. Agroal currently can't support this via the transaction isolation level config option because TransactionIsolation is an enum, so it can't have custom values. It would be nice if this were supported. WildFly's "old" datasources subsystem already supports non-standard isolation levels, so it would be nice if the Agroal subsystem had parity. There is a workaround, at least on MS SQL Server. initialSql (new-connection-sql in WildFly) can be used to execute "SET TRANSACTION ISOLATION LEVEL SNAPSHOT" when the connection is created. -- This message was sent by Atlassian Jira (v7.12.1#712002)

5 years, 10 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira March 2019