[JBoss JIRA] (WFCORE-3576) deployment is not accessible in runtime when deployed with runtime-name not using .war extension
by Chao Wang (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3576?page=com.atlassian.jira.plugi... ]
Chao Wang commented on WFCORE-3576:
-----------------------------------
https://github.com/wildfly/wildfly-core/pull/3084#issuecomment-363946644 PR is rejected by core
{quote} I do not agree with this. It is not a requirement of WildFly Core, nor of WildFly, that deployments end in ear war jar sar etc, or really any pattern whatsoever. An extension isn't even required, as is shown by the point mentioned in the JIRA about arquillian-service. This is an architectural violation in that it has the kernel imposing requirements that an Extension, by design, is free to violate.{quote}
speaking of the arquillian-service, it does show that it's free to deploy without a file extension. In such case (this violation is free for new Extension), I think we should at least note it in document and let user be aware of normal scenario. How does that sound to you? [~brian.stansberry] ?
> deployment is not accessible in runtime when deployed with runtime-name not using .war extension
> ------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3576
> URL: https://issues.jboss.org/browse/WFCORE-3576
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Deployment Scanner, Domain Management
> Affects Versions: 4.0.0.Alpha9
> Reporter: Jan Stourac
> Assignee: Chao Wang
>
> According to the folowing [blog-post|https://developer.jboss.org/thread/221251], when using custom --name or --runtime-name for deployment, the file extension (.war, .jar, .ear,...) need to be included so server can distinguish type of deployment somehow.
> Currently there is no such check - when I try to deploy any .war app using either web-console or CLI with my custom '\-\-runtime-name' and/or '\-\-name' without .war suffix, server does not complain anyhow:
> {code}
> deploy --runtime-name=alice --name=bob /tmp/eve.war
> {code}
> Message in server log:
> {code}
> 17:30:48,469 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) WFLYSRV0027: Starting deployment of "bob" (runtime-name: "alice")
> 17:30:48,499 INFO [org.jboss.as.server] (management-handler-thread - 6) WFLYSRV0010: Deployed "bob" (runtime-name : "alice")
> {code}
> Although, when I try to access content of the war app via URL, I get only {{404 Not found}} HTTP response. Also I cannot see any deployment content when browsing via CLI:
> {code}
> /deployment=bob/subsystem=undertow/...
> {code}
> Even when I raise logging level to DEBUG, I can see no suspicious messages that deployed app has not been completely deployed.
> If such suffix is required, we need to inform user about it. We need to update description text for '\-\-name' and '\-\-runtime-name' atributes of deploy command in CLI (see {{deploy --help}}). Also when no such suffix is provided (and/or we fail to distinguish type of deployment in a different way) we need to print error message that deploy operation was not completely successful so customer is aware of it right-away.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3580) /host=xxx:add is required now after embedding the host controller
by Ken Wills (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3580?page=com.atlassian.jira.plugi... ]
Ken Wills resolved WFCORE-3580.
-------------------------------
Resolution: Rejected
Rejected as not-an-issue.
> /host=xxx:add is required now after embedding the host controller
> -----------------------------------------------------------------
>
> Key: WFCORE-3580
> URL: https://issues.jboss.org/browse/WFCORE-3580
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 4.0.0.Alpha9
> Reporter: Alexey Loubyansky
> Assignee: Ken Wills
>
> This is just to report a change in behavior. This is not a critical issue for what I personally am doing.
> The issue is that I used to have a script that would generate a domain.xml configuration (let's say for the core distribution) that would start like this
> {code:java}
> embed-host-controller --empty-host-config --remove-existing-host-config --empty-domain-config --remove-existing-domain-config --host-config=pm-tmp-host.xml --domain-config=domain.xml
> /interface=public:add(inet-address=${jboss.bind.address:127.0.0.1})
> /interface=management:add(inet-address=${jboss.bind.address.management:127.0.0.1})
> ...
> {code}
> A script like this will fail now because we need to explicitly add a host before executing any management operation. E.g.
> {code:java}
> embed-host-controller --empty-host-config --remove-existing-host-config --empty-domain-config --remove-existing-domain-config --host-config=pm-tmp-host.xml --domain-config=domain.xml
> /host=tmp:add
> /interface=public:add(inet-address=${jboss.bind.address:127.0.0.1})
> /interface=management:add(inet-address=${jboss.bind.address.management:127.0.0.1})
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3581) Graceful shutdown via sigterm cannot be resumed
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3581?page=com.atlassian.jira.plugi... ]
Brian Stansberry resolved WFCORE-3581.
--------------------------------------
Resolution: Rejected
This is not feasible. The OS is terminating the process; the process doesn't get to say no.
TBH I don't consider resuming a server that's in the middle of graceful shutdown initiated via a management op to be supported behavior either. It's pure luck if it happens to work; AFAIK it was never intended behavior.
> Graceful shutdown via sigterm cannot be resumed
> -----------------------------------------------
>
> Key: WFCORE-3581
> URL: https://issues.jboss.org/browse/WFCORE-3581
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Jan Stourac
> Assignee: Brian Stansberry
> Attachments: long-running-servlet.war
>
>
> When server is sent SIGTERM signal to perform graceful shutdown just at the moment it is crunching a long-time running request, it cannot be resumed anymore with the :resume() CLI operation.
> See server output (NOTE: NPE in server log is probably caused by this WFCORE-3572.):
> {code}
> 17:47:30,141 INFO [org.jboss.qa.management.web.resources.HeavyProcessingServlet] (default task-1) Started request processing
> 17:47:34,367 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0211: Suspending server with 10000 ms timeout.
> 17:47:34,368 INFO [org.jboss.as.ejb3] (Thread-2) WFLYEJB0493: EJB subsystem suspension complete
> 17:47:36,022 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0212: Resuming server
> 17:47:36,023 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested via an OS signal
> 17:47:36,034 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 70) WFLYUT0022: Unregistered web context: '/long-running-servlet' from server 'default-server'
> 17:47:36,050 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-8) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS]
> 17:47:36,055 INFO [org.wildfly.extension.undertow] (MSC service thread 1-3) WFLYUT0019: Host default-host stopping
> 17:47:36,058 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-3) WFLYJCA0019: Stopped Driver service with driver-name = h2
> 17:47:36,067 ERROR [org.jboss.threads.errors] (management task-1) Thread Thread[management task-1,5,main] threw an uncaught exception: java.lang.NullPointerException
> at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:72)
> at org.xnio.XnioWorker$1.run(XnioWorker.java:138)
> at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1755)
> at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1578)
> at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
> at java.lang.Thread.run(Thread.java:748)
> 17:47:36,070 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 69) WFLYCLINF0003: Stopped client-mappings cache from ejb container
> 17:47:36,086 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0008: Undertow HTTPS listener https suspending
> 17:47:36,086 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTP listener default suspending
> 17:47:36,086 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0007: Undertow HTTPS listener https stopped, was bound to 127.0.0.1:8443
> 17:47:36,086 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080
> 17:47:36,087 INFO [org.jboss.as.server.deployment] (MSC service thread 1-6) WFLYSRV0028: Stopped deployment long-running-servlet.war (runtime-name: long-running-servlet.war) in 61ms
> 17:47:36,089 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0004: Undertow 1.4.22.Final stopping
> {code}
> This is server output in case that graceful shutdown is called via :shutdown(timeout=<time>) CLI operation:
> {code}
> 17:46:34,064 INFO [org.jboss.as.clustering.infinispan] (ServerService Thread Pool -- 62) WFLYCLINF0002: Started client-mappings cache from ejb container
> 17:46:34,184 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 66) WFLYUT0021: Registered web context: '/long-running-servlet' for server 'default-server'
> 17:46:34,194 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0010: Deployed "long-running-servlet.war" (runtime-name : "long-running-servlet.war")
> 17:46:34,249 INFO [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 17:46:34,251 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:9990/management
> 17:46:34,251 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:9990
> 17:46:34,251 INFO [org.jboss.as] (Controller Boot Thread) WFLYSRV0025: WildFly Full 12.0.0.Alpha1-SNAPSHOT (WildFly Core 4.0.0.Beta1-SNAPSHOT) started in 2915ms - Started 396 of 607 services (333 services are lazy, passive or on-demand)
> 17:46:36,122 INFO [org.jboss.qa.management.web.resources.HeavyProcessingServlet] (default task-1) Started request processing
> 17:46:39,998 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0211: Suspending server with 10000 ms timeout.
> 17:46:40,000 INFO [org.jboss.as.ejb3] (management-handler-thread - 1) WFLYEJB0493: EJB subsystem suspension complete
> 17:46:42,197 INFO [org.jboss.as.server] (management-handler-thread - 1) WFLYSRV0212: Resuming server
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3580) /host=xxx:add is required now after embedding the host controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3580?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3580:
------------------------------------------
[~luck3y] I've assigned this to you. I forgot when talking to Alexey about it that what he had before wouldn't have worked at all with WF 11 / WF Core 3. So as long as there is no regression versus a .Final release or you don't see something else wrong this can be rejected.
> /host=xxx:add is required now after embedding the host controller
> -----------------------------------------------------------------
>
> Key: WFCORE-3580
> URL: https://issues.jboss.org/browse/WFCORE-3580
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 4.0.0.Alpha9
> Reporter: Alexey Loubyansky
> Assignee: Ken Wills
>
> This is just to report a change in behavior. This is not a critical issue for what I personally am doing.
> The issue is that I used to have a script that would generate a domain.xml configuration (let's say for the core distribution) that would start like this
> {code:java}
> embed-host-controller --empty-host-config --remove-existing-host-config --empty-domain-config --remove-existing-domain-config --host-config=pm-tmp-host.xml --domain-config=domain.xml
> /interface=public:add(inet-address=${jboss.bind.address:127.0.0.1})
> /interface=management:add(inet-address=${jboss.bind.address.management:127.0.0.1})
> ...
> {code}
> A script like this will fail now because we need to explicitly add a host before executing any management operation. E.g.
> {code:java}
> embed-host-controller --empty-host-config --remove-existing-host-config --empty-domain-config --remove-existing-domain-config --host-config=pm-tmp-host.xml --domain-config=domain.xml
> /host=tmp:add
> /interface=public:add(inet-address=${jboss.bind.address:127.0.0.1})
> /interface=management:add(inet-address=${jboss.bind.address.management:127.0.0.1})
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3580) /host=xxx:add is required now after embedding the host controller
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3580?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-3580:
-------------------------------------
Component/s: Domain Management
(was: Server)
> /host=xxx:add is required now after embedding the host controller
> -----------------------------------------------------------------
>
> Key: WFCORE-3580
> URL: https://issues.jboss.org/browse/WFCORE-3580
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 4.0.0.Alpha9
> Reporter: Alexey Loubyansky
> Assignee: Jason Greene
>
> This is just to report a change in behavior. This is not a critical issue for what I personally am doing.
> The issue is that I used to have a script that would generate a domain.xml configuration (let's say for the core distribution) that would start like this
> {code:java}
> embed-host-controller --empty-host-config --remove-existing-host-config --empty-domain-config --remove-existing-domain-config --host-config=pm-tmp-host.xml --domain-config=domain.xml
> /interface=public:add(inet-address=${jboss.bind.address:127.0.0.1})
> /interface=management:add(inet-address=${jboss.bind.address.management:127.0.0.1})
> ...
> {code}
> A script like this will fail now because we need to explicitly add a host before executing any management operation. E.g.
> {code:java}
> embed-host-controller --empty-host-config --remove-existing-host-config --empty-domain-config --remove-existing-domain-config --host-config=pm-tmp-host.xml --domain-config=domain.xml
> /host=tmp:add
> /interface=public:add(inet-address=${jboss.bind.address:127.0.0.1})
> /interface=management:add(inet-address=${jboss.bind.address.management:127.0.0.1})
> ...
> {code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months