[JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml resource in the released JGroups jar
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1962?page=com.atlassian.jira.plugin.... ]
Bela Ban edited comment on JGRP-1962 at 2/12/16 11:33 AM:
----------------------------------------------------------
Oops, my bad! I removed this from the ant based build, but I'm releasing artifacts via the stupid maven build! I hope to change this in 4.0 and only use ant&ivy to release artifacts [1].
Changed the POM as a result.
Workaround: use {{-Dlog4j.configurationFile=xyz.xml}}.
If you want to create your own JAR, run {{ant jar}} and the JGroups JAR will be in {{./dist}}.
[1] https://issues.jboss.org/browse/JGRP-1706
was (Author: belaban):
Oops, my bad! I removed this from the ant based build, but I'm releasing artifacts via the stupid maven build! I hope to change this in 4.0 and only use ant&ivy to release artifacts [1].
Changed the POM as a result.
If you want to create your own JAR, run {{ant jar}} and the JGroups JAR will be in {{./dist}}.
[1] https://issues.jboss.org/browse/JGRP-1706
> Do not include the log4j2.xml resource in the released JGroups jar
> ------------------------------------------------------------------
>
> Key: JGRP-1962
> URL: https://issues.jboss.org/browse/JGRP-1962
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.6.4
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Fix For: 3.6.6
>
>
> The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1368) Improve readability of missing dependency logs
by Bartosz Spyrko-Śmietanko (JIRA)
Bartosz Spyrko-Śmietanko created WFCORE-1368:
------------------------------------------------
Summary: Improve readability of missing dependency logs
Key: WFCORE-1368
URL: https://issues.jboss.org/browse/WFCORE-1368
Project: WildFly Core
Issue Type: Enhancement
Reporter: Bartosz Spyrko-Śmietanko
Assignee: Dennis Reed
When deploying an ear using initialize-in-order option, if one of the subdeployments contains an EJB that depends on an EJB from another subdeployment and the dependency subdeployment fails log output makes it hard to understand the root cause.
Structure of deployment is as follows:
{noformat}
reproducer.ear
|- service-locator.jar
| |- ServiceLocator (Stateless EJB)
| |- TestQueue (JNDI Resource)
|- client.jar
|- TestEjb (Stateless EJB)
|- ServiceLocator
{noformat}
If the TestQueue JNDI resource cannot be injected in the ServiceLocator, the deployment failure output lists a number of missing services per each EJB in the dependant subdeployment (.ORB, .HandleDelegate, .ValidatorFactory, etc).
When the dependant subdeployment has a larger number of EJBs the log output very quickly becomes hard to read.
Example with a single dependant EJB:
{noformat}
14:27:43,092 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "reproducer-1.0-SNAPSHOT.ear"}) - failure description: {
"WFLYCTL0180: Services with missing/unavailable dependencies" => [
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".batch.environment is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.ValidatorFactory is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.ORB is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.HandleDelegate is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
"jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".deploymentCompleteService is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".deploymentCompleteService]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.InstanceName is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.Validator is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.naming.context.java.comp.testEar.service-locator.test_ServiceLocator.env.queue.TestQueue is missing [jboss.naming.context.java.jboss.resources.queue.TestQueue]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.InAppClientContainer is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]"
],
"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
"Services that were unable to start:" => [
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".INSTALL",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".CLEANUP",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.JndiBindingsService",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.START",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".deploymentCompleteService",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".jndiDependencyService",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".moduleDeploymentRuntimeInformationStart",
"jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".CLEANUP"
]
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6197) @ClusteredSingleton is hardcoded to use a specific singleton policy name
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6197?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6197:
-------------------------------
Description: The default singleton policy happens to be named "default" in our default configuration. However, the EJB subsystem should not rely on this - as a user can change this. Part of the problem is, there is no registered capability that specifically refers to the default singleton policy. (was: The default singleton policy happens to be named "default" in our default configuration. However, the EJB subsystem should not rely on this. Part of the problem is, there is no registered capability that specifically refers to the default singleton policy.)
> @ClusteredSingleton is hardcoded to use a specific singleton policy name
> ------------------------------------------------------------------------
>
> Key: WFLY-6197
> URL: https://issues.jboss.org/browse/WFLY-6197
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final
>
>
> The default singleton policy happens to be named "default" in our default configuration. However, the EJB subsystem should not rely on this - as a user can change this. Part of the problem is, there is no registered capability that specifically refers to the default singleton policy.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6197) @ClusteredSingleton is hardcoded to use a specific singleton policy name
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6197?page=com.atlassian.jira.plugin.... ]
Paul Ferraro updated WFLY-6197:
-------------------------------
Summary: @ClusteredSingleton is hardcoded to use a specific singleton policy name (was: @ClusteredSingleton is hardcoded to a specific singleton policy name)
> @ClusteredSingleton is hardcoded to use a specific singleton policy name
> ------------------------------------------------------------------------
>
> Key: WFLY-6197
> URL: https://issues.jboss.org/browse/WFLY-6197
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, EJB
> Affects Versions: 10.0.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 10.1.0.Final
>
>
> The default singleton policy happens to be named "default" in our default configuration. However, the EJB subsystem should not rely on this. Part of the problem is, there is no registered capability that specifically refers to the default singleton policy.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFCORE-1245) Improve readability of missing dependency logs
by Bartosz Spyrko-Śmietanko (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1245?page=com.atlassian.jira.plugi... ]
Bartosz Spyrko-Śmietanko updated WFCORE-1245:
---------------------------------------------
Description:
When deploying an ear using initialize-in-order option, if one of the subdeployments contains an EJB that depends on an EJB from another subdeployment and the dependency subdeployment fails log output makes it hard to understand the root cause.
Structure of deployment is as follows:
{noformat}
reproducer.ear
|- service-locator.jar
| |- ServiceLocator (Stateless EJB)
| |- TestQueue (JNDI Resource)
|- client.jar
|- TestEjb (Stateless EJB)
|- ServiceLocator
{noformat}
If the TestQueue JNDI resource cannot be injected in the ServiceLocator, the deployment failure output lists a number of missing services per each EJB in the dependant subdeployment (.ORB, .HandleDelegate, .ValidatorFactory, etc).
When the dependant subdeployment has a larger number of EJBs the log output very quickly becomes hard to read.
Example with a single dependant EJB:
{noformat}
14:27:43,092 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "reproducer-1.0-SNAPSHOT.ear"}) - failure description: {
"WFLYCTL0180: Services with missing/unavailable dependencies" => [
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".batch.environment is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.ValidatorFactory is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.ORB is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.HandleDelegate is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
"jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".deploymentCompleteService is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".deploymentCompleteService]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.InstanceName is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.Validator is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
"jboss.naming.context.java.comp.testEar.service-locator.test_ServiceLocator.env.queue.TestQueue is missing [jboss.naming.context.java.jboss.resources.queue.TestQueue]",
"jboss.naming.context.java.comp.testEar.client.TestEjb.InAppClientContainer is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]"
],
"WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
"Services that were unable to start:" => [
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".INSTALL",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".CLEANUP",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.JndiBindingsService",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.START",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".deploymentCompleteService",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".jndiDependencyService",
"jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".moduleDeploymentRuntimeInformationStart",
"jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".CLEANUP"
]
{noformat}
was:When there is a problem with a failed deployment due to missing dependencies it is difficult to figure out what the problem is.
Attachment: bz1283294-reproducer.zip
> Improve readability of missing dependency logs
> ----------------------------------------------
>
> Key: WFCORE-1245
> URL: https://issues.jboss.org/browse/WFCORE-1245
> Project: WildFly Core
> Issue Type: Enhancement
> Reporter: Bartosz Spyrko-Śmietanko
> Assignee: Dennis Reed
> Attachments: bz1283294-reproducer.zip
>
>
> When deploying an ear using initialize-in-order option, if one of the subdeployments contains an EJB that depends on an EJB from another subdeployment and the dependency subdeployment fails log output makes it hard to understand the root cause.
> Structure of deployment is as follows:
> {noformat}
> reproducer.ear
> |- service-locator.jar
> | |- ServiceLocator (Stateless EJB)
> | |- TestQueue (JNDI Resource)
> |- client.jar
> |- TestEjb (Stateless EJB)
> |- ServiceLocator
> {noformat}
> If the TestQueue JNDI resource cannot be injected in the ServiceLocator, the deployment failure output lists a number of missing services per each EJB in the dependant subdeployment (.ORB, .HandleDelegate, .ValidatorFactory, etc).
> When the dependant subdeployment has a larger number of EJBs the log output very quickly becomes hard to read.
> Example with a single dependant EJB:
> {noformat}
> 14:27:43,092 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 2) WFLYCTL0013: Operation ("deploy") failed - address: ({"deployment" => "reproducer-1.0-SNAPSHOT.ear"}) - failure description: {
> "WFLYCTL0180: Services with missing/unavailable dependencies" => [
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".batch.environment is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.ValidatorFactory is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.ORB is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.HandleDelegate is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".weld.weldClassIntrospector is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".beanmanager]",
> "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".deploymentCompleteService is missing [jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".deploymentCompleteService]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.InstanceName is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.Validator is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]",
> "jboss.naming.context.java.comp.testEar.service-locator.test_ServiceLocator.env.queue.TestQueue is missing [jboss.naming.context.java.jboss.resources.queue.TestQueue]",
> "jboss.naming.context.java.comp.testEar.client.TestEjb.InAppClientContainer is missing [jboss.naming.context.java.comp.testEar.client.TestEjb]"
> ],
> "WFLYCTL0288: One or more services were unable to start due to one or more indirect dependencies not being available." => {
> "Services that were unable to start:" => [
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"client.jar\".INSTALL",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".CLEANUP",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.JndiBindingsService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".component.test_ServiceLocator.START",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".deploymentCompleteService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".jndiDependencyService",
> "jboss.deployment.subunit.\"reproducer-1.0-SNAPSHOT.ear\".\"service-locator.jar\".moduleDeploymentRuntimeInformationStart",
> "jboss.deployment.unit.\"reproducer-1.0-SNAPSHOT.ear\".CLEANUP"
> ]
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (JGRP-1962) Do not include the log4j2.xml resource in the released JGroups jar
by Todd VanderWoude (JIRA)
[ https://issues.jboss.org/browse/JGRP-1962?page=com.atlassian.jira.plugin.... ]
Todd VanderWoude commented on JGRP-1962:
----------------------------------------
log4j2.xml is still present in versions 3.6.6-Final and 3.6.7-Final even though this was marked as fixed in version 3.6.6. The source repository shows that the file was renamed back to log4j2.xml on the same day it was renamed to something else. This effectively prevents all logging in our application due to our use of infinispan which has a jgroups dependency. Looking at your source respository, it appears as though you haven't followed the standard of having src/main and src/test folders which would allow you to have a log4j2.xml in your src/test/resources folder so that it would only be used for the purposes of testing.
> Do not include the log4j2.xml resource in the released JGroups jar
> ------------------------------------------------------------------
>
> Key: JGRP-1962
> URL: https://issues.jboss.org/browse/JGRP-1962
> Project: JGroups
> Issue Type: Task
> Affects Versions: 3.6.4
> Reporter: Sanne Grinovero
> Assignee: Bela Ban
> Fix For: 3.6.6
>
>
> The {{log4j2.xml}} configuration file is included in JGroups, but this makes it hard to override the logging as this will likely conflict with other resources configured by end user applications.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months
[JBoss JIRA] (WFLY-6200) connection-url is required even when not used
by Rich DiCroce (JIRA)
Rich DiCroce created WFLY-6200:
----------------------------------
Summary: connection-url is required even when not used
Key: WFLY-6200
URL: https://issues.jboss.org/browse/WFLY-6200
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Reporter: Rich DiCroce
Assignee: Jason Greene
Per the comments on WFLY-6157 and WFLY-6198, connection-url is ignored in a datasource if datasource-class is defined. However, connection-url is currently mandatory. If it is not present, WildFly fails to start:
{noformat}
09:51:18,216 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 8) WFLYCTL0013: Operation ("add") failed - address: ([
("subsystem" => "datasources"),
("data-source" => "GamingPortalDS")
]) - failure description: "WFLYCTL0155: connection-url may not be null"
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 2 months