July 2020 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-13698) NullPointerException due to JSFDependencyProcessor adding null ModuleIdentifer

by Moulali Shikalwadi (Jira)

Moulali Shikalwadi created WFLY-13698: ----------------------------------------- Summary: NullPointerException due to JSFDependencyProcessor adding null ModuleIdentifer Key: WFLY-13698 URL: https://issues.redhat.com/browse/WFLY-13698 Project: WildFly Issue Type: Bug Components: JSF Reporter: Moulali Shikalwadi Assignee: Moulali Shikalwadi Caused by: java.lang.NullPointerException at org.jboss.modules.DependencySpec.createModuleDependencySpec(DependencySpec.java:637) [jboss-modules.jar:1.8.9.Final-redhat-00001] at org.jboss.modules.DependencySpec.createModuleDependencySpec(DependencySpec.java:593) [jboss-modules.jar:1.8.9.Final-redhat-00001] at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createDependencies(ModuleSpecProcessor.java:346) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createModuleService(ModuleSpecProcessor.java:236) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deployModuleSpec(ModuleSpecProcessor.java:130) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deploy(ModuleSpecProcessor.java:82) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:144) [wildfly-server-6.0.27.Final-redhat-00001.jar:6.0.27.Final-redhat-00001] ... 8 more -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5529) Implement test module for mining model in new PMML implementation

by Jiri Petrlik (Jira)

Jiri Petrlik created DROOLS-5529: ------------------------------------ Summary: Implement test module for mining model in new PMML implementation Key: DROOLS-5529 URL: https://issues.redhat.com/browse/DROOLS-5529 Project: Drools Issue Type: Task Reporter: Jiri Petrlik Assignee: Jiri Petrlik Implement test module for PMML mining model in new PMML implementation. This module should contain tests which simultaneously test compiler and evaluator. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-4582) Cell selection doesn't span the entire cell if you Insert RightMost Column

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-4582?page=com.atlassian.jira.plug... ] Yeser Amer updated DROOLS-4582: ------------------------------- Sprint: 2020 Week 25-27 (from Jun 15) (was: 2020 Week 25-27 (from Jun 15), 2020 Week 28-30 (from Jul 6)) > Cell selection doesn't span the entire cell if you Insert RightMost Column > -------------------------------------------------------------------------- > > Key: DROOLS-4582 > URL: https://issues.redhat.com/browse/DROOLS-4582 > Project: Drools > Issue Type: Bug > Components: Scenario Simulation and Testing > Reporter: Anna Dupliak > Assignee: Yeser Amer > Priority: Minor > Labels: CustomerFocus, drools-tools > Attachments: image-2019-10-01-10-50-42-411.png, span.webm > > > !image-2019-10-01-10-50-42-411.png|thumbnail! > Selection doesn't span entirely if you bind new column -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-5317) Scenario Simulation shows misleading data type if DMN applies a constraint

by Yeser Amer (Jira)

[ https://issues.redhat.com/browse/DROOLS-5317?page=com.atlassian.jira.plug... ] Yeser Amer updated DROOLS-5317: ------------------------------- Fix Version/s: 7.41.0.Final > Scenario Simulation shows misleading data type if DMN applies a constraint > -------------------------------------------------------------------------- > > Key: DROOLS-5317 > URL: https://issues.redhat.com/browse/DROOLS-5317 > Project: Drools > Issue Type: Bug > Affects Versions: 7.37.0.Final > Reporter: Yeser Amer > Assignee: Yeser Amer > Priority: Major > Labels: drools-tools > Fix For: 7.41.0.Final > > -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2494) DNS_PING and failed probes

by Bela Ban (Jira)

[ https://issues.redhat.com/browse/JGRP-2494?page=com.atlassian.jira.plugin... ] Bela Ban resolved JGRP-2494. ---------------------------- Release Notes Text: Fixed by using a later version Resolution: Cannot Reproduce > DNS_PING and failed probes > -------------------------- > > Key: JGRP-2494 > URL: https://issues.redhat.com/browse/JGRP-2494 > Project: JGroups > Issue Type: Bug > Affects Versions: 4.1.9 > Reporter: Dewayne McNair > Assignee: Bela Ban > Priority: Major > Attachments: JGRP-2494.txt > > > Using DNS_PING in a DC/OS (marathon) deployment, there are two SRV records returned - one for the web port and one for the jgroups port. When the discovery request is sent, an exception is thrown and logged. The clustering is working, but logs are filling up due to the exception happening and being logged frequently. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13521) Upgrade Infinispan to 11.0.2.Final

by Paul Ferraro (Jira)

[ https://issues.redhat.com/browse/WFLY-13521?page=com.atlassian.jira.plugi... ] Paul Ferraro updated WFLY-13521: -------------------------------- Summary: Upgrade Infinispan to 11.0.2.Final (was: Upgrade Infinispan to 11.0.0.Final) > Upgrade Infinispan to 11.0.2.Final > ---------------------------------- > > Key: WFLY-13521 > URL: https://issues.redhat.com/browse/WFLY-13521 > Project: WildFly > Issue Type: Component Upgrade > Components: Clustering > Affects Versions: 20.0.0.Beta1 > Reporter: Paul Ferraro > Assignee: Paul Ferraro > Priority: Major > > https://issues.redhat.com/projects/ISPN/versions/12342851 -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName

by José Fernando Tepedino Martins (Jira)

[ https://issues.redhat.com/browse/WFLY-13697?page=com.atlassian.jira.plugi... ] José Fernando Tepedino Martins updated WFLY-13697: -------------------------------------------------- Description: With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'. For example, a job listener or other job artifact with the following code {code:java} @Resource(lookup="java:app/AppName") private String applicationName;{code} or {code:java} private String applicationName; @PostConstruct protected void initialize() throws NamingException { applicationName = InitialContext.doLookup("java:app/AppName"); }{code} when the batch job is started from JBoss CLI, the following error will be logged: {code:java} javax.naming.NameNotFoundException: java:app/AppName {code} was: With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'. For example, a job listener or other artifact with the following code {code:java} @Resource(lookup="java:app/AppName") private String applicationName;{code} or {code:java} private String applicationName; @PostConstruct protected void initialize() throws NamingException { applicationName = InitialContext.doLookup("java:app/AppName"); }{code} when the batch job is started from JBoss CLI, the following error will be logged: {code:java} javax.naming.NameNotFoundException: java:app/AppName {code} > JBoss CLI can't find java:app/AppName > ------------------------------------- > > Key: WFLY-13697 > URL: https://issues.redhat.com/browse/WFLY-13697 > Project: WildFly > Issue Type: Bug > Components: CLI > Affects Versions: JBoss AS7 7.2.0.Final > Reporter: José Fernando Tepedino Martins > Assignee: Jean Francois Denise > Priority: Minor > Labels: CLI, JNDI > > With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'. > For example, a job listener or other job artifact with the following code > {code:java} > @Resource(lookup="java:app/AppName") > private String applicationName;{code} > or > {code:java} > private String applicationName; > @PostConstruct > protected void initialize() throws NamingException { > applicationName = InitialContext.doLookup("java:app/AppName"); > }{code} > when the batch job is started from JBoss CLI, the following error will be logged: > {code:java} > javax.naming.NameNotFoundException: java:app/AppName > {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13697) JBoss CLI can't find java:app/AppName

by José Fernando Tepedino Martins (Jira)

José Fernando Tepedino Martins created WFLY-13697: ----------------------------------------------------- Summary: JBoss CLI can't find java:app/AppName Key: WFLY-13697 URL: https://issues.redhat.com/browse/WFLY-13697 Project: WildFly Issue Type: Bug Components: CLI Affects Versions: JBoss AS7 7.2.0.Final Reporter: José Fernando Tepedino Martins Assignee: Jean Francois Denise With a JEE aplication in a WAR package, when starting a functionality, as a Batch Job, via CLI, CDI injection and JNDI lookup fail to find resources 'java:app/AppName' and 'java:module/ModuleName'. For example, a job listener or other artifact with the following code {code:java} @Resource(lookup="java:app/AppName") private String applicationName;{code} or {code:java} private String applicationName; @PostConstruct protected void initialize() throws NamingException { applicationName = InitialContext.doLookup("java:app/AppName"); }{code} when the batch job is started from JBoss CLI, the following error will be logged: {code:java} javax.naming.NameNotFoundException: java:app/AppName {code} -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ] Richard Achmatowicz edited comment on WFLY-13433 at 7/23/20 5:15 PM: --------------------------------------------------------------------- The issue has now been fixed, the default and full profiles for EAP640 did not include an ejb cache-container (with an appropriate local cache defined) which is now required by the remote resource in the ejb3 subsystem via a capability reference, and so these had to be added to the mixed domain tests for those profiles via the LegacyConfigAdjuster640 class. was (Author: rachmato): The issue has now been fixed, the default and full profiles for EAP640 did not include an ejb cache-container (with an appropriate local cache defined) and so these had to be added to the mixed domain tests for those profiles via the LegacyConfigAdjuster640 class. > Improve capability support in EJB3 subsystem > -------------------------------------------- > > Key: WFLY-13433 > URL: https://issues.redhat.com/browse/WFLY-13433 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 20.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Attachments: successfulLegacyConfigTest.txt, unSuccessfulLegacyConfigTest.txt > > > Survey all external subsystem dependencies and introduce capability based dependencies where required. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-13433) Improve capability support in EJB3 subsystem

by Richard Achmatowicz (Jira)

[ https://issues.redhat.com/browse/WFLY-13433?page=com.atlassian.jira.plugi... ] Richard Achmatowicz edited comment on WFLY-13433 at 7/23/20 5:14 PM: --------------------------------------------------------------------- I'm running into a problem with the LegacyConfigXTestSuite tests in the mixed-domain testsuite module, where X=640, 700, 710, 720 and 730. All tests pass, except for X=640 which fails, complaining about missing capabilities. These tests do the following: * start a master HC and slave HC using a given domain.xml file * for each profile p in \{default, ha, full, full-ha} from the domain.xml file: ** start a server using profile p and wait for it to start ** check it has the correct profile name ** check we can connect via HTTP ** clean up the server An example output from a successful test can be seen in the attachment succssfulLegacyConfigTest for X=700. An example output from the unsuccessful test can be seen in the attachment unSuccssfulLegacyConfigTest for X=640. The strange thing is that for X=640, capabilities are checked when the master and slave start up (and problems with missing capabilities there ultimately cause them to fail to boot); however, capabilities are not checked in the other versions when the master and slave start up. I know this because I added a line in CapabilityRegistry.validateCapabilities() to dump out the registered capabilities. This method is being called in the failing test, but not in the passing tests. This is a mystery to me. [~yersan], [~brian.stansberry] any ideas? NOTE: please ignore the last comment, I was getting tangled up with operation execution and capability validation. was (Author: rachmato): I'm running into a problem with the LegacyConfigXTestSuite tests in the mixed-domain testsuite module, where X=640, 700, 710, 720 and 730. All tests pass, except for X=640 which fails, complaining about missing capabilities. These tests do the following: * start a master HC and slave HC using a given domain.xml file * for each profile p in \{default, ha, full, full-ha} from the domain.xml file: ** start a server using profile p and wait for it to start ** check it has the correct profile name ** check we can connect via HTTP ** clean up the server An example output from a successful test can be seen in the attachment succssfulLegacyConfigTest for X=700. An example output from the unsuccessful test can be seen in the attachment unSuccssfulLegacyConfigTest for X=640. The strange thing is that for X=640, capabilities are checked when the master and slave start up (and problems with missing capabilities there ultimately cause them to fail to boot); however, capabilities are not checked in the other versions when the master and slave start up. I know this because I added a line in CapabilityRegistry.validateCapabilities() to dump out the registered capabilities. This method is being called in the failing test, but not in the passing tests. This is a mystery to me. [~yersan], [~brian.stansberry] any ideas? > Improve capability support in EJB3 subsystem > -------------------------------------------- > > Key: WFLY-13433 > URL: https://issues.redhat.com/browse/WFLY-13433 > Project: WildFly > Issue Type: Enhancement > Components: EJB > Affects Versions: 20.0.0.Beta1 > Reporter: Richard Achmatowicz > Assignee: Richard Achmatowicz > Priority: Major > Attachments: successfulLegacyConfigTest.txt, unSuccessfulLegacyConfigTest.txt > > > Survey all external subsystem dependencies and introduce capability based dependencies where required. -- This message was sent by Atlassian Jira (v7.13.8#713008)

5 years, 11 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 2020