[JBoss JIRA] (WFCORE-474) Custom formatter property changes not written to, but overriden by logging.properties
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-474?page=com.atlassian.jira.plugin... ]
James Perkins commented on WFCORE-474:
--------------------------------------
At this point there's no way to be notified if system property has been changed. You'd have to execute a reload to have the {{logging.properties}} file rewritten or restart the container.
Note to self when looking at this issue have a look at the {{ProcessEnvironmentSystemPropertyUpdater}}. It's possible this isn't meant to be used by subsystems.
> Custom formatter property changes not written to, but overriden by logging.properties
> -------------------------------------------------------------------------------------
>
> Key: WFCORE-474
> URL: https://issues.jboss.org/browse/WFCORE-474
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Environment: Wildfly 8.1.0.Final
> Reporter: Vsevolod Golovanov
> Assignee: James Perkins
> Attachments: standalone.xml
>
>
> When you first add custom formatter with properties to standalone.xml, on server start property values get correctly resolved and written to logging.properties.
> If you change property values in standalone.xml of an existing custom formatter, that was flushed to logging.properties before, then on the next server start new values don't get written to logging.properties and formatter instance gets the old values from logging.properties.
> For properties with static values that are defined in standalone.xml there is a workaround: change the custom formatter name each time you change a property value.
> But with more dynamic properties, e.g. that rely on system properties, it's not so simple...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-655) Customizable Console Log Viewer
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-655?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-655:
---------------------------------
Priority: Optional (was: Major)
> Customizable Console Log Viewer
> -------------------------------
>
> Key: WFCORE-655
> URL: https://issues.jboss.org/browse/WFCORE-655
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Logging
> Reporter: Carlton Zachary
> Assignee: James Perkins
> Priority: Optional
>
> Currently the Console log viewer only points to jboss.server.log.dir. In our Domain environment we have our server.log write to a non-default location. This is defined in the host-slave.xml as:
> <paths>
> <path name="custom.jboss.server.log.dir" path="/apps/logs/server1"/>
> </paths>
> it is then referenced in the domain.xml file logging subsystem as:
> <file relative-to="custom.jboss.server.log.dir" path="server.log"/>
> Can the Console logviewer be enhanced to allow it to be configured to point to a custom server.log location?
> https://bugzilla.redhat.com/show_bug.cgi?id=1191180
> Thanks
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-483) Allow hooking into logging subsystem through Management API
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-483?page=com.atlassian.jira.plugin... ]
James Perkins updated WFCORE-483:
---------------------------------
Priority: Optional (was: Major)
> Allow hooking into logging subsystem through Management API
> -----------------------------------------------------------
>
> Key: WFCORE-483
> URL: https://issues.jboss.org/browse/WFCORE-483
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Ondrej Zizka
> Assignee: James Perkins
> Priority: Optional
> Labels: logging
>
> Provide a way to poll log messages through the management API.
> Could be then used in the AS console. Some kind of detached window, or perhaps tab, with log, perhaps pushed through Servlet 3.2's onDataAvailable() ...
> Note that this is different from AS7-2213, which needs AS to keep some history. This doesn't.
> BTW, JBDS gets the logs through SSH, because the AS may fail booting before anything is able to hook in like this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-4199) App redeploy exceptions
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4199?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-4199.
-------------------------------
Resolution: Cannot Reproduce
I can't reproduce this.
> App redeploy exceptions
> -----------------------
>
> Key: WFLY-4199
> URL: https://issues.jboss.org/browse/WFLY-4199
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Reporter: Eduardo Martins
> Assignee: James Perkins
>
> I'm noticing intermittent occurrences of exceptions when redeploying quickstarts, and unfortunately the chance seems quite high. The exceptions,a at least on my end, may be reproduced by using app "thread-racing" of the following branches of my quickstarts fork:
> Web Services) https://github.com/emmartins/quickstart/tree/redeploy-exceptions , where the following exception occur at an alarming 8 out of 10 redeploys:
> {code}
> 19:41:38,502 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/emmartins/wildfly/git/wildfly/dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/b5/1306d722adbe53ba6b7445f1b2d72facd66201/content
> 19:41:38,504 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0022: Unregistered web context: /wildfly-thread-racing
> 19:41:38,519 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0010: Stopping weld service for deployment wildfly-thread-racing.war
> 19:41:38,527 INFO [org.jboss.as.server.deployment] (MSC service thread 1-12) WFLYSRV0028: Stopped deployment wildfly-thread-racing.war (runtime-name: wildfly-thread-racing.war) in 24ms
> 19:41:38,528 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "wildfly-thread-racing.war" (runtime-name: "wildfly-thread-racing.war")
> 19:41:38,556 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-14) MSC000001: Failed to start service jboss.deployment.unit."wildfly-thread-racing.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-thread-racing.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "wildfly-thread-racing.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.jboss.as.webservices.deployers.WebservicesDescriptorDeploymentProcessor.getWebServicesDescriptorURL(WebservicesDescriptorDeploymentProcessor.java:70)
> at org.jboss.as.webservices.deployers.WebservicesDescriptorDeploymentProcessor.deploy(WebservicesDescriptorDeploymentProcessor.java:52)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
> 19:41:38,559 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment wildfly-thread-racing.war (runtime-name: wildfly-thread-racing.war) in 30ms
> 19:41:38,560 INFO [org.jboss.as.server.deployment] (MSC service thread 1-12) WFLYSRV0027: Starting deployment of "wildfly-thread-racing.war" (runtime-name: "wildfly-thread-racing.war")
> 19:41:38,593 WARN [org.jboss.weld.deployer] (MSC service thread 1-13) WFLYWELD0012: Warning while parsing vfs:/content/wildfly-thread-racing.war/WEB-INF/beans.xml:22 cvc-complex-type.4: Attribute 'bean-discovery-mode' must appear on element 'beans'.
> 19:41:38,609 INFO [org.jboss.weld.deployer] (MSC service thread 1-2) WFLYWELD0003: Processing weld deployment wildfly-thread-racing.war
> 19:41:38,633 INFO [org.jboss.as.messaging] (MSC service thread 1-2) WFLYMSG0002: Bound messaging object to jndi name java:global/threadRacing/stages/jms/requestQueue
> 19:41:38,637 INFO [org.jboss.weld.deployer] (MSC service thread 1-9) WFLYWELD0006: Starting Services for CDI deployment: wildfly-thread-racing.war
> 19:41:38,641 INFO [org.jboss.weld.deployer] (MSC service thread 1-5) WFLYWELD0009: Starting weld service for deployment wildfly-thread-racing.war
> 19:41:38,643 INFO [org.jboss.as.ejb3] (MSC service thread 1-10) WFLYEJB0042: Started message driven bean 'JMSRaceStageMessageListener' with 'hornetq-ra.rar' resource adapter
> 19:41:38,753 INFO [io.undertow.websockets.jsr] (MSC service thread 1-7) UT026003: Adding annotated server endpoint class org.jboss.as.quickstarts.threadracing.stage.websocket.ServerEndpoint for path /ws
> 19:41:38,754 INFO [io.undertow.websockets.jsr] (MSC service thread 1-7) UT026004: Adding annotated client endpoint class org.jboss.as.quickstarts.threadracing.stage.websocket.ClientEndpoint
> 19:41:38,758 INFO [org.wildfly.extension.undertow] (MSC service thread 1-7) WFLYUT0021: Registered web context: /wildfly-thread-racing
> 19:41:38,770 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0013: Redeployed "wildfly-thread-racing.war"
> 19:41:38,770 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0016: Replaced deployment "wildfly-thread-racing.war" with deployment "wildfly-thread-racing.war"
> 19:41:38,771 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /Users/emmartins/wildfly/git/wildfly/dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/98/04cfcd3addc74805031f222ee036ff47b62f5d/content
> {code}
> Web) https://github.com/emmartins/quickstart/tree/redeploy-exceptions2 , where the following exception occur about half of redeploys:
> {code}
> 20:27:05,715 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0001: Content added at location /Users/emmartins/wildfly/git/wildfly/dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/c4/abc434ff307278c10061fb9dbbd3fcd0aff116/content
> 20:27:05,717 INFO [org.wildfly.extension.undertow] (MSC service thread 1-13) WFLYUT0022: Unregistered web context: /wildfly-thread-racing
> 20:27:05,734 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 77) WFLYJPA0011: Stopping Persistence Unit (phase 2 of 2) Service 'wildfly-thread-racing.war#RacePU'
> 20:27:05,735 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0010: Stopping weld service for deployment wildfly-thread-racing.war
> 20:27:05,735 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 77) WFLYJPA0011: Stopping Persistence Unit (phase 1 of 2) Service 'wildfly-thread-racing.war#RacePU'
> 20:27:05,745 INFO [org.jboss.as.server.deployment] (MSC service thread 1-9) WFLYSRV0028: Stopped deployment wildfly-thread-racing.war (runtime-name: wildfly-thread-racing.war) in 28ms
> 20:27:05,746 INFO [org.jboss.as.server.deployment] (MSC service thread 1-14) WFLYSRV0027: Starting deployment of "wildfly-thread-racing.war" (runtime-name: "wildfly-thread-racing.war")
> 20:27:05,775 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-8) MSC000001: Failed to start service jboss.deployment.unit."wildfly-thread-racing.war".PARSE: org.jboss.msc.service.StartException in service jboss.deployment.unit."wildfly-thread-racing.war".PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "wildfly-thread-racing.war"
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.JBossWebParsingDeploymentProcessor.deploy(JBossWebParsingDeploymentProcessor.java:61)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156)
> ... 5 more
> 20:27:05,780 INFO [org.jboss.as.server.deployment] (MSC service thread 1-15) WFLYSRV0028: Stopped deployment wildfly-thread-racing.war (runtime-name: wildfly-thread-racing.war) in 33ms
> 20:27:05,782 INFO [org.jboss.as.server.deployment] (MSC service thread 1-11) WFLYSRV0027: Starting deployment of "wildfly-thread-racing.war" (runtime-name: "wildfly-thread-racing.war")
> 20:27:05,819 INFO [org.jboss.as.jpa] (MSC service thread 1-10) WFLYJPA0002: Read persistence.xml for RacePU
> 20:27:05,833 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 77) WFLYJPA0010: Starting Persistence Unit (phase 1 of 2) Service 'wildfly-thread-racing.war#RacePU'
> 20:27:05,833 INFO [org.hibernate.jpa.internal.util.LogHelper] (ServerService Thread Pool -- 77) HHH000204: Processing PersistenceUnitInfo [
> name: RacePU
> ...]
> 20:27:05,838 INFO [org.jboss.weld.deployer] (MSC service thread 1-12) WFLYWELD0003: Processing weld deployment wildfly-thread-racing.war
> 20:27:05,841 INFO [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-12) JNDI bindings for session bean named RaceResults in deployment unit deployment "wildfly-thread-racing.war" are as follows:
> java:global/wildfly-thread-racing/RaceResults!org.jboss.as.quickstarts.threadracing.results.RaceResults
> java:app/wildfly-thread-racing/RaceResults!org.jboss.as.quickstarts.threadracing.results.RaceResults
> java:module/RaceResults!org.jboss.as.quickstarts.threadracing.results.RaceResults
> java:global/wildfly-thread-racing/RaceResults
> java:app/wildfly-thread-racing/RaceResults
> java:module/RaceResults
> 20:27:05,872 INFO [org.jboss.as.messaging] (MSC service thread 1-12) WFLYMSG0002: Bound messaging object to jndi name java:global/threadRacing/stages/jms/requestQueue
> 20:27:05,878 INFO [org.jboss.weld.deployer] (MSC service thread 1-4) WFLYWELD0006: Starting Services for CDI deployment: wildfly-thread-racing.war
> 20:27:05,883 INFO [org.jboss.weld.deployer] (MSC service thread 1-12) WFLYWELD0009: Starting weld service for deployment wildfly-thread-racing.war
> 20:27:05,885 INFO [org.jboss.as.ejb3] (MSC service thread 1-13) WFLYEJB0042: Started message driven bean 'JMSRaceStageMessageListener' with 'hornetq-ra.rar' resource adapter
> 20:27:05,887 INFO [org.jboss.as.jpa] (ServerService Thread Pool -- 77) WFLYJPA0010: Starting Persistence Unit (phase 2 of 2) Service 'wildfly-thread-racing.war#RacePU'
> 20:27:05,893 INFO [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 77) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
> 20:27:05,893 WARN [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 77) HHH000431: Unable to determine H2 database version, certain features may not work
> 20:27:05,899 INFO [org.hibernate.hql.internal.ast.ASTQueryTranslatorFactory] (ServerService Thread Pool -- 77) HHH000397: Using ASTQueryTranslatorFactory
> 20:27:05,921 INFO [org.hibernate.dialect.Dialect] (ServerService Thread Pool -- 77) HHH000400: Using dialect: org.hibernate.dialect.H2Dialect
> 20:27:05,922 WARN [org.hibernate.dialect.H2Dialect] (ServerService Thread Pool -- 77) HHH000431: Unable to determine H2 database version, certain features may not work
> 20:27:06,057 INFO [io.undertow.websockets.jsr] (MSC service thread 1-15) UT026003: Adding annotated server endpoint class org.jboss.as.quickstarts.threadracing.WebSocketRace for path /race
> 20:27:06,085 INFO [org.jboss.resteasy.spi.ResteasyDeployment] (MSC service thread 1-15) Deploying javax.ws.rs.core.Application: class org.jboss.as.quickstarts.threadracing.stage.jaxrs.BoxApplication$Proxy$_$$_WeldClientProxy
> 20:27:06,086 INFO [org.jboss.resteasy.spi.ResteasyDeployment] (MSC service thread 1-15) Adding class resource org.jboss.as.quickstarts.threadracing.stage.jaxrs.BoxService from Application class org.jboss.as.quickstarts.threadracing.stage.jaxrs.BoxApplication$Proxy$_$$_WeldClientProxy
> 20:27:06,088 INFO [org.wildfly.extension.undertow] (MSC service thread 1-15) WFLYUT0021: Registered web context: /wildfly-thread-racing
> 20:27:06,102 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0013: Redeployed "wildfly-thread-racing.war"
> 20:27:06,102 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0016: Replaced deployment "wildfly-thread-racing.war" with deployment "wildfly-thread-racing.war"
> 20:27:06,103 INFO [org.jboss.as.repository] (management-handler-thread - 1) WFLYDR0002: Content removed from location /Users/emmartins/wildfly/git/wildfly/dist/target/wildfly-9.0.0.Alpha2-SNAPSHOT/standalone/data/content/fe/8d3392468fc3e5e8b15d722d003fe3e0f851af/content
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-4449) Default JNDI bindings should set the server in a reload required state when changed
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-4449?page=com.atlassian.jira.plugin.... ]
James Perkins closed WFLY-4449.
-------------------------------
Resolution: Rejected
This should be a {{reload-required}}. Deployment components need to be restarted for {{@Resource}} injection.
> Default JNDI bindings should set the server in a reload required state when changed
> -----------------------------------------------------------------------------------
>
> Key: WFLY-4449
> URL: https://issues.jboss.org/browse/WFLY-4449
> Project: WildFly
> Issue Type: Bug
> Components: EE, Naming
> Reporter: James Perkins
> Assignee: James Perkins
>
> When a write operation like {{/subsystem=ee/service=default-bindings:write-attribute(name=datasource,value="java:jboss/datasources/DefaultDS")}} is executed on the default bindings the server is not set into {{reload-required}} state as it should be. The names in the service are also changed. This means new deployments or new lookups could see a different name than was originally configured when the server started.
> The other default resource names should also be looked at to ensure they don't override current settings.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6605) Domain Setup docs doesn't explain domain.xml vs host.xml
by John Mazzitelli (JIRA)
John Mazzitelli created WFLY-6605:
-------------------------------------
Summary: Domain Setup docs doesn't explain domain.xml vs host.xml
Key: WFLY-6605
URL: https://issues.jboss.org/browse/WFLY-6605
Project: WildFly
Issue Type: Enhancement
Components: Documentation
Affects Versions: 10.0.0.Final
Reporter: John Mazzitelli
Assignee: ANGELA ROBERTSON
There looks to be some information missing from:
https://docs.jboss.org/author/display/WFLY10/Domain+Setup
Or at least it is confusing. Notice that some of the instructions have this:
"(See domain/configuration/host.xml)"
and in other parts it has this:
"(See domain/configuration/domain.xml)"
Other than that, there is no mention of "host.xml" versus "domain.xml". This is confusing because the names of the files seem to infer that "domain.xml" is the configuration for the domain controller and "host.xml" is the configuration for the slave host controllers, but that clearly isn't the case (as the instructions both say to edit host.xml to configure both DC and HC). Both DC and HC's config files have:
<host xmlns="urn:jboss:domain:3.0"> ...
as the root node, whereas domain.xml has "<domain>".
The docs should make it clear what and when domain.xml is used versus host.xml. It still isn't clear to me when domain.xml is used/when it is parsed. I assume it is read in by the DC during initialization.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6600) NPE thrown during EAR deployment
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6600?page=com.atlassian.jira.plugin.... ]
Matthew Casperson updated WFLY-6600:
------------------------------------
Affects Version/s: 10.0.0.Final
> NPE thrown during EAR deployment
> --------------------------------
>
> Key: WFLY-6600
> URL: https://issues.jboss.org/browse/WFLY-6600
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Matthew Casperson
>
> We deploy an EAR file to a Wildfly domain with two slaves. On one slave, we'll frequently see this exception:
> {code}
> [Server:main-server] 2016-05-08 16:06:13+1000 INFO [[org.jboss.as.server]] [[ServerService Thread Pool -- 359]] WFLYSRV0016: Replaced deployment "services.war" with deployment "services.war"
> [Server:main-server] 2016-05-09 06:05:08+1000 ERROR [[org.jboss.as.controller.management-operation]] [[ServerService Thread Pool -- 384]] WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> [Server:main-server] ("deployment" => "OnlineSystemsApplications.ear"),
> [Server:main-server] ("subdeployment" => "systemcheck.war"),
> [Server:main-server] ("subsystem" => "undertow"),
> [Server:main-server] ("servlet" => "javax.ws.rs.core.Application")
> [Server:main-server] ]): java.lang.NullPointerException
> [Server:main-server] at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:125)
> [Server:main-server] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> [Server:main-server] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> [Server:main-server] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
> [Server:main-server] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:main-server] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:main-server] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> At the same time we'll see this on the second node
> {code}
> [Server:main-server] 2016-05-06 16:17:59+1000 ERROR [[org.jboss.as.controller.management-operation]] [[ServerService Thread Pool -- 276]] WFLYCTL0190: Step handler org.jboss.as.server.deployment.DeploymentHandlerUtil$4@14bd8919 for operation {"operation" => "full-replace-deployment","name" => "OnlineSystemsApplications.ear","enabled" => true,"content" => [{"hash" => bytes { 0x73, 0xec, 0x83, 0x82, 0xb6, 0x67, 0x2d, 0x92, 0x36, 0x7a, 0xb7, 0x7c, 0x7a, 0x4e, 0xc4, 0x93, 0x00, 0xc1, 0xf3, 0xc3 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "76dbe681-46d0-4f2e-a4c7-82f615919ff0"},"address" => [],"runtime-name" => undefined,"persistent" => true,"owner" => undefined} at address [] failed handling operation rollback -- java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child 'name' exists
> [Server:main-server] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:377)
> [Server:main-server] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299)
> [Server:main-server] at org.jboss.dmr.ModelNode.require(ModelNode.java:870)
> [Server:main-server] at org.jboss.as.server.deployment.DeploymentHandlerUtil$4$1.handleResult(DeploymentHandlerUtil.java:277)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:main-server] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:main-server] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> The WAR file in question doesn't actually use JAX-RS, so I'm not sure why javax.ws.rs.core.Application would be causing any issues.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFLY-6600) NPE thrown during EAR deployment
by Matthew Casperson (JIRA)
[ https://issues.jboss.org/browse/WFLY-6600?page=com.atlassian.jira.plugin.... ]
Matthew Casperson commented on WFLY-6600:
-----------------------------------------
[~brian.stansberry] - Apologies, this was for WildFly 10.0.0.Final.
> NPE thrown during EAR deployment
> --------------------------------
>
> Key: WFLY-6600
> URL: https://issues.jboss.org/browse/WFLY-6600
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Reporter: Matthew Casperson
>
> We deploy an EAR file to a Wildfly domain with two slaves. On one slave, we'll frequently see this exception:
> {code}
> [Server:main-server] 2016-05-08 16:06:13+1000 INFO [[org.jboss.as.server]] [[ServerService Thread Pool -- 359]] WFLYSRV0016: Replaced deployment "services.war" with deployment "services.war"
> [Server:main-server] 2016-05-09 06:05:08+1000 ERROR [[org.jboss.as.controller.management-operation]] [[ServerService Thread Pool -- 384]] WFLYCTL0013: Operation ("read-attribute") failed - address: ([
> [Server:main-server] ("deployment" => "OnlineSystemsApplications.ear"),
> [Server:main-server] ("subdeployment" => "systemcheck.war"),
> [Server:main-server] ("subsystem" => "undertow"),
> [Server:main-server] ("servlet" => "javax.ws.rs.core.Application")
> [Server:main-server] ]): java.lang.NullPointerException
> [Server:main-server] at org.wildfly.extension.undertow.DeploymentServletDefinition$AbstractMetricsHandler.execute(DeploymentServletDefinition.java:125)
> [Server:main-server] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecuteInternal(ReadAttributeHandler.java:174)
> [Server:main-server] at org.jboss.as.controller.operations.global.ReadAttributeHandler.doExecute(ReadAttributeHandler.java:137)
> [Server:main-server] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AbstractMultiTargetHandler.execute(GlobalOperationHandlers.java:263)
> [Server:main-server] at org.jboss.as.controller.operations.global.GlobalOperationHandlers$AvailableResponseWrapper.execute(GlobalOperationHandlers.java:933)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:main-server] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:main-server] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> At the same time we'll see this on the second node
> {code}
> [Server:main-server] 2016-05-06 16:17:59+1000 ERROR [[org.jboss.as.controller.management-operation]] [[ServerService Thread Pool -- 276]] WFLYCTL0190: Step handler org.jboss.as.server.deployment.DeploymentHandlerUtil$4@14bd8919 for operation {"operation" => "full-replace-deployment","name" => "OnlineSystemsApplications.ear","enabled" => true,"content" => [{"hash" => bytes { 0x73, 0xec, 0x83, 0x82, 0xb6, 0x67, 0x2d, 0x92, 0x36, 0x7a, 0xb7, 0x7c, 0x7a, 0x4e, 0xc4, 0x93, 0x00, 0xc1, 0xf3, 0xc3 }}],"operation-headers" => {"access-mechanism" => "NATIVE","domain-uuid" => "76dbe681-46d0-4f2e-a4c7-82f615919ff0"},"address" => [],"runtime-name" => undefined,"persistent" => true,"owner" => undefined} at address [] failed handling operation rollback -- java.util.NoSuchElementException: No child 'name' exists: java.util.NoSuchElementException: No child 'name' exists
> [Server:main-server] at org.jboss.dmr.ModelValue.requireChild(ModelValue.java:377)
> [Server:main-server] at org.jboss.dmr.ObjectModelValue.requireChild(ObjectModelValue.java:299)
> [Server:main-server] at org.jboss.dmr.ModelNode.require(ModelNode.java:870)
> [Server:main-server] at org.jboss.as.server.deployment.DeploymentHandlerUtil$4$1.handleResult(DeploymentHandlerUtil.java:277)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1384)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1366)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1328)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1185)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeResultHandlerPhase(AbstractOperationContext.java:767)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:753)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> [Server:main-server] at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> [Server:main-server] at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> [Server:main-server] at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler.internalExecute(TransactionalProtocolOperationHandler.java:247)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler.doExecute(TransactionalProtocolOperationHandler.java:185)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:138)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$1.run(TransactionalProtocolOperationHandler.java:134)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at javax.security.auth.Subject.doAs(Subject.java:360)
> [Server:main-server] at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:81)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:157)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2$1.run(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at java.security.AccessController.doPrivileged(Native Method)
> [Server:main-server] at org.jboss.as.controller.remote.TransactionalProtocolOperationHandler$ExecuteRequestHandler$2.execute(TransactionalProtocolOperationHandler.java:153)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> [Server:main-server] at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> [Server:main-server] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> [Server:main-server] at java.lang.Thread.run(Thread.java:745)
> [Server:main-server] at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {code}
> The WAR file in question doesn't actually use JAX-RS, so I'm not sure why javax.ws.rs.core.Application would be causing any issues.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1549) Application context specific log handler
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1549?page=com.atlassian.jira.plugi... ]
James Perkins moved WFLY-6601 to WFCORE-1549:
---------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1549 (was: WFLY-6601)
Component/s: Logging
(was: Logging)
Affects Version/s: (was: 10.0.0.Final)
> Application context specific log handler
> ----------------------------------------
>
> Key: WFCORE-1549
> URL: https://issues.jboss.org/browse/WFCORE-1549
> Project: WildFly Core
> Issue Type: Feature Request
> Components: Logging
> Reporter: Nicklas Karlsson
> Assignee: James Perkins
>
> There are many cases where it would be handy to group log events on some application specific information (e.g. placed in the MDC). Examples are
> * Collecting all user session interaction loggings into a separate file
> * Collecting all log entries related to a specific client machine into a separate file
> * Collecting the entire lifecycle of an entity (long-lived order, process etc) into a separate file
> This could perhaps be implemented with a LogFilePolicyClass that would return the correct (existing or fresh) file based on the MDC data?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months
[JBoss JIRA] (WFCORE-1548) Access denied when deploying to wildfly 10
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1548?page=com.atlassian.jira.plugi... ]
James Perkins commented on WFCORE-1548:
---------------------------------------
It's possible that's it. I booted my Windows VM, disabled Windows Defender and the error was no reproduced. I also ran ProcMon while the error occurred. I didn't see any weird errors however I could see Windows Defender scanning the file around the time of the failure.
> Access denied when deploying to wildfly 10
> ------------------------------------------
>
> Key: WFCORE-1548
> URL: https://issues.jboss.org/browse/WFCORE-1548
> Project: WildFly Core
> Issue Type: Bug
> Environment: Wildfly 10, Windows 7, java 1.8_05, maven 3.0.5, maven 3.3.9
> Reporter: Srecko Mandelj
> Assignee: James Perkins
> Priority: Minor
> Attachments: server.log, TestMavenPlugin.zip
>
>
> I have a war application containing web services. I have no problems deploying war to wildfly 8.1. After upgrade to wildfly 10, the plugin doesn't work any more. I get this error when trying to deploy:
> {code}
> [Server:server-one] 09:36:51,162 INFO [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 132) Initializing Mojarra 2.2.12-jbossorg-2 20150729-1131 for context '/ActivatorFrontEnd'
> [Server:server-one] 09:36:51,220 SEVERE [javax.enterprise.resource.webcontainer.
> jsf.config] (ServerService Thread Pool -- 132) Critical error during deployment:
> : com.sun.faces.config.ConfigurationException: java.util.concurrent.ExecutionException: javax.faces.FacesException: java.io.FileNotFoundException: C:\podatki\jboss_configurations\wildfly10\domainController\servers\server-one\tmp\vfs\temp\temp1e3a1daf9121b0e4\content-34b685741ee5aeb4\content-6322725066713898564.tmp (Access is denied)
> {code}
> It looks like a concurrency issue - one process is trying to use a file that other process is using. If I deploy through web console or via CLI, I don't have this issue. It is somehow related to jsf implementation. If I remove jsf from wildfly configuration file (the module and subsystem), deploy works ok (Mojara is then not triggered and deploy is successful).
> I tried to deploy with 1.1.9.Alpha8, but I get the same error.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 11 months