[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ]
Lin Gao updated WFCORE-761:
---------------------------
Priority: Major (was: Minor)
> Not possible to overlay non existing file in WAR
> ------------------------------------------------
>
> Key: WFCORE-761
> URL: https://issues.jboss.org/browse/WFCORE-761
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Bartosz Baranowski
> Assignee: Lin Gao
>
> It is either bug in how deployments are treated or how overlay/vfs work.
> Steps to reproduce:
> 1. deploy undexploded war with jar inside
> 2. add overlay that will add non existing file in jar
> Result: exception:
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt
> Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}}
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67)
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67)
> Expectation:
> should work. It actually does work, if war is really exploded or
> 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1201) Could not upload new deployment
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1201?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1201:
-------------------------------------
Fix Version/s: 2.0.5.Final
(was: 2.0.5.CR1)
> Could not upload new deployment
> -------------------------------
>
> Key: WFCORE-1201
> URL: https://issues.jboss.org/browse/WFCORE-1201
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 1.0.2.Final
> Environment: 2 different machines
> Linux Debian Squeeze & Jessie
> Oracle Java SE 8
> Reporter: Claudio Weiler
> Assignee: Harald Pehl
> Fix For: 2.0.5.Final
>
>
> WildFly stop to accept deployments via interface upload with following stacktrace:
> ERROR [io.undertow.request] (XNIO-1 task-2) Undertow request failed HttpServerExchange{ POST /management-upload}: java.io.IOException: UT000036: Connection terminated parsing multipart data
> at io.undertow.server.handlers.form.MultiPartParserDefinition$MultiPartUploadHandler.parseBlocking(MultiPartParserDefinition.java:203)
> at org.jboss.as.domain.http.server.DomainApiGenericOperationHandler.handleRequest(DomainApiGenericOperationHandler.java:104)
> at io.undertow.server.handlers.encoding.EncodingHandler.handleRequest(EncodingHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:72)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler$1.run(SubjectDoAsHandler.java:68)
> at java.security.AccessController.doPrivileged(Native Method)
> at javax.security.auth.Subject.doAs(Subject.java:422)
> at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:68)
> at org.jboss.as.domain.http.server.security.SubjectDoAsHandler.handleRequest(SubjectDoAsHandler.java:63)
> at io.undertow.server.handlers.BlockingHandler.handleRequest(BlockingHandler.java:56)
> at org.jboss.as.domain.http.server.DomainApiCheckHandler.handleRequest(DomainApiCheckHandler.java:87)
> at io.undertow.security.handlers.AuthenticationCallHandler.handleRequest(AuthenticationCallHandler.java:52)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Same artifact was used before with success, nothing changed.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1128) Improve the subsystem test schema test coverage
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1128?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1128:
-------------------------------------
Fix Version/s: 2.0.5.Final
(was: 2.0.5.CR1)
> Improve the subsystem test schema test coverage
> -----------------------------------------------
>
> Key: WFCORE-1128
> URL: https://issues.jboss.org/browse/WFCORE-1128
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.1.Final
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 2.0.5.Final
>
>
> Currently the way to enable the AbstractSubsystemBaseTest testSchema() and testSchemaOfSubsystemTemplates() tests is to override getSubsystemXsdPath() and getSubsystemTemplatePaths().
> Rather than making it explicit to turn on, it should be explicit to turn off.
> Also the current way of doing this uses Assume.assumeTrue() to check if a test has provided a schema file, which provides a lot of ignored test noise in the test output. If the xsd should not be tested, methods should instead override testSchema() or testSchemaOfSubsystemTemplates() and provide an empty implementation with a comment saying why it is not important.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-366) Support timeout of management operations
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-366?page=com.atlassian.jira.plugin... ]
Brian Stansberry resolved WFCORE-366.
-------------------------------------
Fix Version/s: 2.0.5.CR1
(was: 3.0.0.Alpha1)
Resolution: Done
WFLY-2741 and WFCORE-368, the two original subtasks for this issue, are done, so this can be resolved.
> Support timeout of management operations
> ----------------------------------------
>
> Key: WFCORE-366
> URL: https://issues.jboss.org/browse/WFCORE-366
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 2.0.5.CR1
>
>
> There have been various situations where bugs in WF or in user code have prevented management operations from completing, leaving the ModelController locked permanently, unless the process is stopped. There should be mechanism via which timeouts can be set.
> My proposal is to allow a timeout to be set via a management operation header. In addition, there will be a standard timeout that will apply if no header is present.
> The standard timeout will be quite lengthy, probably several minutes. The goal is to allow a management process to eventually auto-recover, not to do prompt detection of failures. Users can use the header if they wish prompt detection a failures. A short standard timeout runs the risk of false positives, particularly with large deployments.
> The meaning of this timeout is not to be an overall maximum time for operation execution. There would be no valid default for such a timeout in a managed domain, where the time it would take to roll out a change would depend on the size of the domain and the rollout plan.
> Rather, this timeout is meant to be the maximum period operation execution threads can block in various points. Blocking for longer than the timeout would result in operation failure.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-1214) Operation headers not propagated to domain servers when 'composite' op is used
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1214?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1214:
-------------------------------------
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/1305 (was: https://github.com/wildfly/wildfly-core/pull/1310)
> Operation headers not propagated to domain servers when 'composite' op is used
> ------------------------------------------------------------------------------
>
> Key: WFCORE-1214
> URL: https://issues.jboss.org/browse/WFCORE-1214
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 2.0.4.Final
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Priority: Critical
> Fix For: 2.0.5.CR1
>
>
> When the user adds request headers to an op, they are not propagated to the servers during domain rollout if the 'composite' op is involved.
> For example, if I add some stdout printing of what the headers are on the various processes and invoke this:
> {code}
> [domain@localhost:9990 /] deploy ~/tmp/helloworld.war --headers={blocking-timeout=5;rollback-on-runtime-failure=false} --all-server-groups
> {code}
> Then on a HC with two servers, this is logged:
> [Host Controller] 10:53:40,697 INFO [stdout] (management-handler-thread - 3) "composite" headers: {
> [Host Controller] 10:53:40,697 INFO [stdout] (management-handler-thread - 3) "blocking-timeout" => "5",
> [Host Controller] 10:53:40,698 INFO [stdout] (management-handler-thread - 3) "rollback-on-runtime-failure" => "false",
> [Host Controller] 10:53:40,698 INFO [stdout] (management-handler-thread - 3) "caller-type" => "user",
> [Host Controller] 10:53:40,698 INFO [stdout] (management-handler-thread - 3) "access-mechanism" => "NATIVE"
> [Host Controller] 10:53:40,698 INFO [stdout] (management-handler-thread - 3) }
> [Host Controller] 10:53:40,727 INFO [org.jboss.as.repository] (management-handler-thread - 3) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-2.0.5.Final-SNAPSHOT/domain/data/content/6f/cd9eae343ed6d5aa9fffa83012d155b1ef911c/content
> [Server:server-one] 10:53:40,772 INFO [stdout] (ServerService Thread Pool -- 11) "composite" headers: null
> [Server:server-two] 10:53:40,772 INFO [stdout] (ServerService Thread Pool -- 11) "composite" headers: null
> The HC logs, then the servers report. The user-specified headers are not included.
> Invoke the same op without the batch and this is logged:
> {code}
> [Host Controller] 10:43:50,400 INFO [stdout] (management-handler-thread - 4) "composite" headers: {
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) "blocking-timeout" => "5",
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) "rollback-on-runtime-failure" => "false",
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) "caller-type" => "user",
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) "access-mechanism" => "NATIVE"
> [Host Controller] 10:43:50,401 INFO [stdout] (management-handler-thread - 4) }
> [Host Controller] 10:43:50,425 INFO [org.jboss.as.repository] (management-handler-thread - 4) WFLYDR0001: Content added at location /Users/bstansberry/dev/wildfly/wildfly-core/dist/target/wildfly-core-2.0.5.Final-SNAPSHOT/domain/data/content/6f/cd9eae343ed6d5aa9fffa83012d155b1ef911c/content
> [Server:server-two] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "composite" headers: {
> [Server:server-two] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "blocking-timeout" => "5",
> [Server:server-two] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "rollback-on-runtime-failure" => "false",
> [Server:server-one] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "composite" headers: {
> [Server:server-two] 10:43:50,464 INFO [stdout] (ServerService Thread Pool -- 11) "access-mechanism" => "NATIVE",
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "blocking-timeout" => "5",
> [Server:server-two] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "domain-uuid" => "216d2e99-dba5-4c89-8020-b0c16bd553c5"
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "rollback-on-runtime-failure" => "false",
> [Server:server-two] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) }
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "access-mechanism" => "NATIVE",
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) "domain-uuid" => "216d2e99-dba5-4c89-8020-b0c16bd553c5"
> [Server:server-one] 10:43:50,465 INFO [stdout] (ServerService Thread Pool -- 11) }
> {code}
> Expected headers are present.
> Note the CLI 'deploy' is far from the only time the 'composite' op is used. Among other places, the high level CLI 'batch' command in a domain involves use of 'composite'.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFCORE-851) Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-851?page=com.atlassian.jira.plugin... ]
Brian Stansberry reassigned WFCORE-851:
---------------------------------------
Fix Version/s: 2.0.5.CR1
Assignee: Filippe Spolti (was: David Lloyd)
Resolution: Done
> Remoting Subsystem RemoteOutboundConnectionService is caching ConnectionURI causing issues when DNS changes
> -----------------------------------------------------------------------------------------------------------
>
> Key: WFCORE-851
> URL: https://issues.jboss.org/browse/WFCORE-851
> Project: WildFly Core
> Issue Type: Bug
> Components: Remoting
> Reporter: Brad Maxwell
> Assignee: Filippe Spolti
> Fix For: 2.0.5.CR1
>
>
> Description of problem:
> EJB CLient was configured with DNS FQDN to configure access to a remote EJB. If run a simple test adding an entry in /etc/hosts file pointing that FQDN to localhost for tests everything works. However, after finish the tests and remove the entry, the client still connects to localhost instead of resolve the new IP address. Even adding networkaddress.cache.ttl=30 inside security settings didn't work too.
> How reproducible:
> Everytime you use DNS names to connect to a remote EJB.
> Steps to Reproduce:
> 1. Configure a simple client that connects to a remote EJB using dns name
> 2. add an entry in /etc/hosts mapping the dns name to localhost
> 3. run the client code
> 4. remove the entry in /etc/hosts
> 5. run the client code again
> Actual results:
> EJB remote is still reached from localhost
> Expected results:
> After changing DNS record EJB will be reached in this new address
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5484) Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5484?page=com.atlassian.jira.plugin.... ]
Paul Ferraro resolved WFLY-5484.
--------------------------------
Resolution: Done
This jira was reopened for no apparent reason. Resetting status to resolved.
> Calling HttpServletRequest.logout() with single sign-on enabled only works every second time
> --------------------------------------------------------------------------------------------
>
> Key: WFLY-5484
> URL: https://issues.jboss.org/browse/WFLY-5484
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
>
> See "Steps to Reproduce". Logging out from an application only works every second time, e.g. HttpRequestServlet.logout() has to be called twice in order to have any effect
> This doesn't occur without <single-sign-on/> enabled - logout() has the expected effect. The issue is security related, thus I'm adding our security team members as watchers.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5473) Session.invalidate() does not invalidate SSO context for non-distributable applications
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5473?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5473:
------------------------------------
[~rjanik] Can you attach a reproducer? We have a test that validate this in our testsuite - so I'm not sure how you are reproducing this issue.
> Session.invalidate() does not invalidate SSO context for non-distributable applications
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-5473
> URL: https://issues.jboss.org/browse/WFLY-5473
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Web (Undertow)
> Reporter: Richard Janík
> Assignee: Paul Ferraro
> Priority: Blocker
> Fix For: 10.0.0.CR5
>
>
> See "Steps to Reproduce" for detailed description.
> According to my limited knowledge, this was also the core issue in https://bugzilla.redhat.com/show_bug.cgi?id=924456 which has been dispatched as a one-off to a customer. Thus, I'm setting the priority to blocker as this is a regression against 6.4.x. No exceptions have been observed in the server output however.
> Adding Clustering component as I've been trying this with standalone-ha.xml and BZ 924456 relates to clustering.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months
[JBoss JIRA] (WFLY-5857) HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-5857?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-5857:
------------------------------------
Can you reproduce this against WF 10?
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but start is not called in Node1 again after Node1 is selected Master again
> ---------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-5857
> URL: https://issues.jboss.org/browse/WFLY-5857
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.1.Final
> Environment: Wildfly-9.0.1.Final. Full HA Configuration. Cluster Full Ha
> Reporter: Serg Jakean19019
> Assignee: Paul Ferraro
>
> HASingleton Stop is called in Node1 (Master) during down of Node2 in cluster, but Start is not called in Node1 again after Node1 is selected Master again.
> If Node2 ist started again, than Start is called in Node1 again.
> This Solution worked in 8.2.0.Final and was taken from GitHub
> Part of Log after Stop in Singletone:
> 2015-12-16 10:25:39,832 WARN [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0007: Just reached required quorum of 1 for jboss.quickstart.ha.singleton.default service. If this cluster loses another member, no node will be chosen to provide this service.
> 2015-12-16 10:25:39,832 INFO [org.wildfly.clustering.server] (remote-thread--p8-t5) WFLYCLSV0003: DevNode1 elected as the singleton provider of the jboss.quickstart.ha.singleton.default service
> 2015-12-16 10:25:40,410 WARN [org.hornetq.core.client] (Thread-514 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,424 WARN [org.hornetq.core.client] (Thread-515 (HornetQ-client-global-threads-816000930)) HQ212037: Connection failure has been detected: HQ119015: The connection was disconnected because of server shutdown [code=DISCONNECTED]
> 2015-12-16 10:25:40,442 INFO [org.hornetq.core.server] (Thread-16 (HornetQ-server-HornetQServerImpl::serverUUID=5f62a17c-a33d-11e5-b968-cda4b2119720-1601129088)) HQ221029: stopped bridge sf.my-cluster.b27b8fc6-a33e-11e5-84b8-b7bbc6dfe24c
> 2015-12-16 10:25:40,495 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel server: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,496 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel ejb: [Node1|2] (1) [DevNode1]
> 2015-12-16 10:25:40,497 INFO [org.infinispan.remoting.transport.jgroups.JGroupsTransport] (Incoming-5,ee,DevNode1) ISPN000094: Received new cluster view for channel hibernate: [DevNode1|2] (1) [DevNode1]
> 2015-12-16 10:25:57,010 WARNING [org.jgroups.protocols.UDP] (INT-1,hq-cluster,DevNode1) JGRP000012: discarded message from different cluster ee (our cluster is hq-cluster). Sender was DevNode1 (received 38 identical messages from DevNode1 in the last 63946 ms)
> 2015-12-16 10:26:30,810 WARNING [org.jgroups.protocols.UDP] (Incoming-13,ee,DevNode1) JGRP000012: discarded message from different cluster hq-cluster (our cluster is ee). Sender was DevNode1 (received 80 identical messages from DevNode1 in the last 60008 ms)
> This issue also in:
> https://developer.jboss.org/thread/266831
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 7 months