[JBoss JIRA] (WFCORE-572) Review usage of the two different NoSuchResourceException's
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-572?page=com.atlassian.jira.plugin... ]
Brian Stansberry commented on WFCORE-572:
-----------------------------------------
In hipchat I proposed deprecating org.jboss.as.controller.registry.Resource.NoSuchResourceException, switching to org.jboss.as.controller.NoSuchResourceException, and dropping the NoSuchElementException aspect. I think I'll not do any of that, except hiding NoSuchElementException in the javadoc and specifying Resource throws org.jboss.as.controller.registry.Resource.NoSuchResourceException.
1) DMR ModelNode.require(...) throws NoSuchElementException, which is likely where Resource throwing it came from. Don't much like that exception (it's specified as being specifically for use by java.util.Enumeration) but since DMR throws it and we've thrown it in the past, I'll keep it for compatibility.
2) org.jboss.as.controller.NoSuchResourceException is little used, while org.jboss.as.controller.registry.Resource.NoSuchResourceException is used quite a lot. And, the latter is more closely associated with Resource. So, I'll deprecate the former and switch to the latter.
> Review usage of the two different NoSuchResourceException's
> -----------------------------------------------------------
>
> Key: WFCORE-572
> URL: https://issues.jboss.org/browse/WFCORE-572
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: James Perkins
> Assignee: Brian Stansberry
>
> There are two versions of the {{NoSuchResourceException}}, [{{org.jboss.as.controller.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/NoSuchResourceException.java] and [{{org.jboss.as.controller.registry.Resource.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/registry/Resource.java#L299]. The usages should be reviewed as some code seems to catch one where the other is likely thrown.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-572) Review usage of the two different NoSuchResourceException's
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-572?page=com.atlassian.jira.plugin... ]
Brian Stansberry updated WFCORE-572:
------------------------------------
Description: There are two versions of the {{NoSuchResourceException}}, [{{org.jboss.as.controller.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/NoSuchResourceException.java] and [{{org.jboss.as.controller.registry.Resource.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/registry/Resource.java#L299]. The usages should be reviewed as some code seems to catch one where the other is likely thrown. (was: There are two versions of the {{NoSuchResourceException}}, [{{org.jboss.as.controller.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/NoSuchResourceException.java] and [{{org.jboss.as.controller.registry.Resource.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/registry/Resource.java#L299]. The usages should be reviewed as some code seems to catch one where the other is likely thrown.
>From HipChat:
{quote}
Brian Stansberry
8:40 AM
it's the NoSuchElementException aspect we should get rid of
BasicResource threw that when it was first written, so then it got added to javadoc and the registry.resource one extended it to preserve compatibility
it should all go to the org.jboss.as.controller.NoSuchResourceException one
the registry.resource one can just be deprecated and extend org.jboss.as.controller.NoSuchResourceException, no more NoSuchElementException
{quote})
> Review usage of the two different NoSuchResourceException's
> -----------------------------------------------------------
>
> Key: WFCORE-572
> URL: https://issues.jboss.org/browse/WFCORE-572
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: James Perkins
> Assignee: Brian Stansberry
>
> There are two versions of the {{NoSuchResourceException}}, [{{org.jboss.as.controller.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/NoSuchResourceException.java] and [{{org.jboss.as.controller.registry.Resource.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/registry/Resource.java#L299]. The usages should be reviewed as some code seems to catch one where the other is likely thrown.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4401) Deployment fails with missing/unavailable dependencies
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4401?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-4401:
----------------------------------------
I assume WFLY-4401 is the same basic scenario as WFCORE-184.
> Deployment fails with missing/unavailable dependencies
> ------------------------------------------------------
>
> Key: WFLY-4401
> URL: https://issues.jboss.org/browse/WFLY-4401
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.2.0.Final
> Reporter: Thomas Diesler
> Assignee: Brian Stansberry
>
> Our testsuite bootstraps the server and then waits for the native management interface to become available on 8181
> A subsequent deployment (intermittently) fails with
> {code}
> domain-master> [Host Controller] [0m[0m05:09:40,678 INFO [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content added at location /opt/jboss/wildfly/domain/data/content/ef/3743938a6b38a2ae473f12778fef7ad0ce464c/content[0m
> domain-slave> [Server:server-one] [0m[31m05:09:41,654 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 5) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "domain-endpoint.war")]) - failure description: {"JBAS014771: Services with missing/unavailable dependencies" => ["jboss.deployment.unit.\"domain-endpoint.war\" is missing [jboss.deployment.chains]"]}[0m
> {code}
> There seems to be a missing guarantee that allows the management endpoint to answer deployment requests when the deployment chain services are not up.
> CrossLink: https://github.com/wildfly-extras/wildfly-camel/issues/175
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Abhijit Sarkar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4402?page=com.atlassian.jira.plugin.... ]
Abhijit Sarkar updated WFLY-4402:
---------------------------------
Attachment: availability-service-0.0.1-SNAPSHOT.war
> Fails to load JAX-RS Application class if deployment runtime name is changed
> ----------------------------------------------------------------------------
>
> Key: WFLY-4402
> URL: https://issues.jboss.org/browse/WFLY-4402
> Project: WildFly
> Issue Type: Bug
> Components: Class Loading
> Affects Versions: 8.2.0.Final
> Environment: Oracle JDK 1.8.0_25
> Reporter: Abhijit Sarkar
> Assignee: David Lloyd
> Priority: Critical
> Attachments: availability-service-0.0.1-SNAPSHOT.war
>
>
> If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
> {code}
> wildfly-server-8.2.0.Final.jar:8.2.0.Final]
> ... 5 more
> Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
> at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4402) Fails to load JAX-RS Application class if deployment runtime name is changed
by Abhijit Sarkar (JIRA)
Abhijit Sarkar created WFLY-4402:
------------------------------------
Summary: Fails to load JAX-RS Application class if deployment runtime name is changed
Key: WFLY-4402
URL: https://issues.jboss.org/browse/WFLY-4402
Project: WildFly
Issue Type: Bug
Components: Class Loading
Affects Versions: 8.2.0.Final
Environment: Oracle JDK 1.8.0_25
Reporter: Abhijit Sarkar
Assignee: David Lloyd
Priority: Critical
If the runtime name is modified during deployment, it fails with a {{ClassNotFoundException}}. The runtime name determines the context root so in most practical cases, it'd be different from the archive name. Seems related to WFLY-1521 which was closed.
{code}
wildfly-server-8.2.0.Final.jar:8.2.0.Final]
... 5 more
Caused by: java.lang.ClassNotFoundException: name.abhijitsarkar.microservices.availability.AvailabilityApp from [Module "deployment.availability-service:main" from Service Module Loader]
at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:213) [jboss-modules.jar:1.3.3.Final]
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-478) log4j ConsoleAppender won't display messages with per-deployment logging
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-478?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFCORE-478:
--------------------------------------
Because of the way the {{ConsoleAppender}} works and the fact the WildFly wraps {{System.out}} and {{System.err}} there are potential deadlocks with using a {{ConsoleAppender}} with per-deployment logging.
If you're not using any other special appenders you could just use a {{logging.properties}} file and the {{org.jboss.logmanager.handlers.ConsoleHandler}}. This will work the same regardless of the logging facade you use. The JBoss Log Manager {{logging.properties}} file looks similar to a log4j one. Here's an example of one using the {{ConsoleHandler}}
{code}
# Additional logger names to configure (root logger is always configured)
loggers=org.jboss.as.logging
# Root logger level
logger.level=INFO
# Root logger handlers
logger.handlers=CONSOLE
logger.org.jboss.as.logging.level=TRACE
# Console handler configuration
handler.CONSOLE=org.jboss.logmanager.handlers.ConsoleHandler
handler.CONSOLE.properties=autoFlush
handler.CONSOLE.level=TRACE
handler.CONSOLE.autoFlush=true
handler.CONSOLE.formatter=PATTERN
# Formatter pattern configuration
formatter.PATTERN=org.jboss.logmanager.formatters.PatternFormatter
formatter.PATTERN.properties=pattern
formatter.PATTERN.pattern=%d{HH:mm:ss,SSS} %-5p [%c] %s%e%n
{code}
Another option would be use a [jboss-deployment-structure.xml to exclude the logging subsystem|https://docs.jboss.org/author/display/WFLY8/How+To#HowTo-HowdoI...]. You'd then need to provide your own version of log4j in your deployment. That should get around the possible deadlock if you'd rather use log4j appenders.
A third option would be to use [logging profiles|https://docs.jboss.org/author/display/WFLY8/Logging+Configuratio...]. With these you can isolate the logging configuration per-deployment. I would advise not writing to the same file, e.g. {{server.log}}, though in each profile. Using a console handler should be fairly safe assuming {{System.out}} and/or {{System.err}} use appropriate locking.
As to changing the standalone.xml I hope you're not manually changing it :) It's much better to use CLI or some sort of management interface to make changes like that. They happen at runtime so there's no need to restart the server.
> log4j ConsoleAppender won't display messages with per-deployment logging
> ------------------------------------------------------------------------
>
> Key: WFCORE-478
> URL: https://issues.jboss.org/browse/WFCORE-478
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Reporter: James Perkins
> Assignee: James Perkins
> Priority: Minor
>
> Add the following log4j.properties file to a deployment and try to log.
> {code}
> # Root logger option
> log4j.rootLogger=INFO, stdout
> # Direct log messages to stdout
> log4j.appender.stdout=org.apache.log4j.ConsoleAppender
> log4j.appender.stdout.Target=System.out
> log4j.appender.stdout.layout=org.apache.log4j.PatternLayout
> log4j.appender.stdout.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c{1}:%L - %m%n
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-572) Review usage of the two different NoSuchResourceException's
by James Perkins (JIRA)
James Perkins created WFCORE-572:
------------------------------------
Summary: Review usage of the two different NoSuchResourceException's
Key: WFCORE-572
URL: https://issues.jboss.org/browse/WFCORE-572
Project: WildFly Core
Issue Type: Task
Components: Domain Management
Reporter: James Perkins
Assignee: Brian Stansberry
There are two versions of the {{NoSuchResourceException}}, [{{org.jboss.as.controller.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/NoSuchResourceException.java] and [{{org.jboss.as.controller.registry.Resource.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/registry/Resource.java#L299]. The usages should be reviewed as some code seems to catch one where the other is likely thrown.
>From HipChat:
{quote}
Brian Stansberry
8:40 AM
BasicResource threw that when it was first written, so then it got added to javadoc and the registry.resource one extended it to preserve compatibility
it should all go to the org.jboss.as.controller.NoSuchResourceException one
the registry.resource one can just be deprecated and extend org.jboss.as.controller.NoSuchResourceException, no more NoSuchElementException
{quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFCORE-572) Review usage of the two different NoSuchResourceException's
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-572?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-572:
---------------------------------
Description:
There are two versions of the {{NoSuchResourceException}}, [{{org.jboss.as.controller.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/NoSuchResourceException.java] and [{{org.jboss.as.controller.registry.Resource.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/registry/Resource.java#L299]. The usages should be reviewed as some code seems to catch one where the other is likely thrown.
>From HipChat:
{quote}
Brian Stansberry
8:40 AM
it's the NoSuchElementException aspect we should get rid of
BasicResource threw that when it was first written, so then it got added to javadoc and the registry.resource one extended it to preserve compatibility
it should all go to the org.jboss.as.controller.NoSuchResourceException one
the registry.resource one can just be deprecated and extend org.jboss.as.controller.NoSuchResourceException, no more NoSuchElementException
{quote}
was:
There are two versions of the {{NoSuchResourceException}}, [{{org.jboss.as.controller.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/NoSuchResourceException.java] and [{{org.jboss.as.controller.registry.Resource.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/registry/Resource.java#L299]. The usages should be reviewed as some code seems to catch one where the other is likely thrown.
>From HipChat:
{quote}
Brian Stansberry
8:40 AM
BasicResource threw that when it was first written, so then it got added to javadoc and the registry.resource one extended it to preserve compatibility
it should all go to the org.jboss.as.controller.NoSuchResourceException one
the registry.resource one can just be deprecated and extend org.jboss.as.controller.NoSuchResourceException, no more NoSuchElementException
{quote}
> Review usage of the two different NoSuchResourceException's
> -----------------------------------------------------------
>
> Key: WFCORE-572
> URL: https://issues.jboss.org/browse/WFCORE-572
> Project: WildFly Core
> Issue Type: Task
> Components: Domain Management
> Reporter: James Perkins
> Assignee: Brian Stansberry
>
> There are two versions of the {{NoSuchResourceException}}, [{{org.jboss.as.controller.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/NoSuchResourceException.java] and [{{org.jboss.as.controller.registry.Resource.NoSuchResourceException}}|https://github.com/wildfly/wildfly-core/blob/master/controller/src/main/java/org/jboss/as/controller/registry/Resource.java#L299]. The usages should be reviewed as some code seems to catch one where the other is likely thrown.
> From HipChat:
> {quote}
> Brian Stansberry
> 8:40 AM
> it's the NoSuchElementException aspect we should get rid of
> BasicResource threw that when it was first written, so then it got added to javadoc and the registry.resource one extended it to preserve compatibility
> it should all go to the org.jboss.as.controller.NoSuchResourceException one
> the registry.resource one can just be deprecated and extend org.jboss.as.controller.NoSuchResourceException, no more NoSuchElementException
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months
[JBoss JIRA] (WFLY-4349) SEVERE JSF error on undeploy of WS module after Mojarra upgrade to 2.2.10
by Farah Juma (JIRA)
[ https://issues.jboss.org/browse/WFLY-4349?page=com.atlassian.jira.plugin.... ]
Farah Juma commented on WFLY-4349:
----------------------------------
I've applied the fix for [JAVASERVERFACES-3797 | https://java.net/jira/browse/JAVASERVERFACES-3797] to our fork and I've created the following PR to upgrade master to the new jsf-impl version that contains this fix (2.2.10-jbossorg-2):
https://github.com/wildfly/wildfly/pull/7222
> SEVERE JSF error on undeploy of WS module after Mojarra upgrade to 2.2.10
> -------------------------------------------------------------------------
>
> Key: WFLY-4349
> URL: https://issues.jboss.org/browse/WFLY-4349
> Project: WildFly
> Issue Type: Bug
> Components: JSF
> Affects Versions: 9.0.0.Alpha1
> Environment: WildFly Full 9.0.0.Alpha2-SNAPSHOT (WildFly Core 1.0.0.Alpha18)
> Oracle JDK 1.7.0_80-ea-b05, Solaris SPARC 10
> Reporter: Frank Langelage
> Assignee: Farah Juma
> Labels: mojarra, undertow
>
> Since latest update I get a SEVERE entry in server.log for every web-module getting undeployed. Those Web-modules contain webservices and are war files inside and ear.
> 15.02. 21:31:48,151 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/production
> 15.02. 21:31:48,151 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi/maj2e-langfr-dev/web
> 15.02. 21:31:48,155 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,201 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/planning
> 15.02. 21:31:48,204 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,239 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,217 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/core
> 15.02. 21:31:48,359 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/sales
> 15.02. 21:31:48,372 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/costing
> 15.02. 21:31:48,379 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/purchase
> 15.02. 21:31:48,381 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,383 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/external
> 15.02. 21:31:48,396 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,397 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,399 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,402 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/inventory
> 15.02. 21:31:48,444 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,404 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/common
> 15.02. 21:31:48,407 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /mbi-ws/maj2e-langfr-dev/distribution
> 15.02. 21:31:48,408 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,480 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> 15.02. 21:31:48,481 SEVERE [javax.enterprise.resource.webcontainer.jsf.config#contextDestroyed] Unexpected state during contextDestroyed: no ConfigManager instance in current ServletContext but one is expected to exist.
> Undeploy of my war file does not generate this SEVERE error.
> 15.02. 21:43:24,243 INFO [org.wildfly.extension.undertow#unregisterDeployment] WFLYUT0022: Unregistered web context: /web-maj2e-langfr-dev
> When I go back to the previous Mojarra 2.2.9-jbossorg-2 the error message disappears.
> There are also a lot of theses SEVERE error messages in the testsuite output files (*.txt).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
9 years, 3 months