[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3726:
----------------------------------------
FYI, you can use the the --admin-only switch at server launch to get a server that can be remotely configured but won't start services unrelated to management.
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFLY-3726
> URL: https://issues.jboss.org/browse/WFLY-3726
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: Emmanuel Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFCORE-50) CLI tests using non-standard output stream don't reset the terminal when done
by Alexey Loubyansky (JIRA)
Alexey Loubyansky created WFCORE-50:
---------------------------------------
Summary: CLI tests using non-standard output stream don't reset the terminal when done
Key: WFCORE-50
URL: https://issues.jboss.org/browse/WFCORE-50
Project: WildFly Core
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: CLI, Test Suite
Affects Versions: 1.0.0.Alpha4
Reporter: Alexey Loubyansky
Assignee: Alexey Loubyansky
Fix For: 1.0.0.Alpha5
The problem appears only when running single tests. If the tests are run using a wildcard, there is no problem.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Jess Holle (JIRA)
[ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.... ]
Jess Holle commented on WFLY-3726:
----------------------------------
Thanks for the recommendation.
I would tend to (programmatically) edit the XML rather than use the CLI -- as the CLI requires the server to be running before one gets it configured.
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFLY-3726
> URL: https://issues.jboss.org/browse/WFLY-3726
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: Emmanuel Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-3726?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-3726:
----------------------------------------
I recommend using the CLI or the web admin console and explicitly doing what you want without a scanner in the middle to mediate. For exploded deployments, with the scanner you have to use marker files. I don't see how that's easier than just using the CLI.
> Filesystem deployment scanner deployment failure removes unrelated deployments
> ------------------------------------------------------------------------------
>
> Key: WFLY-3726
> URL: https://issues.jboss.org/browse/WFLY-3726
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Domain Management
> Affects Versions: 8.0.0.Final
> Environment: WIndows and Linux platforms both exhibit the issue
> Reporter: Jess Holle
> Assignee: Emmanuel Hugonnet
>
> If one's standalone-full.xml configuration contains something like:
> <deployments>
> <deployment name="MyWebApp.war" runtime-name="MyWebApp.war" enabled="true">
> <fs-exploded path="../../SomeDir/MyWebApp.war" relative-to="jboss.home.dir"/>
> </deployment>
> </deployments>
> whether manually inserted (while the server is not running) or installed via the CLI via
> /deployment=ServiceCenter.war/:add(runtime-name=ServiceCenter.war,content=[{archive=false,path="../../Windchill/ServiceCenter.war",relative-to="jboss.home.dir"}])
> and a deployment scanner like:
> <subsystem xmlns="urn:jboss:domain:deployment-scanner:2.0">
> <deployment-scanner name="1" path="../../../Applications" relative-to="jboss.server.base.dir" scan-interval="5000" auto-deploy-exploded="true"/>
> </subsystem>
> a failure by a deployment-scanner to deploy an application (exploded in my case, though I'm not sure this makes a difference) will cause the explicitly listed <deployments> to be removed from the configuration!
> This occurs irrespective of the value used for auto-deploy-exploded and to <deployment> elements that had already successfully been deployed and started.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (JBMETA-378) Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBMETA-378?page=com.atlassian.jira.plugin... ]
Jean-Frederic Clere commented on JBMETA-378:
--------------------------------------------
According to the specs both servlet-name and url-pattern are required.
> Presence of <servlet-name> and <url-pattern> is not validated for <servlet-mapping> inside the web.xml
> ------------------------------------------------------------------------------------------------------
>
> Key: JBMETA-378
> URL: https://issues.jboss.org/browse/JBMETA-378
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: web
> Affects Versions: 8.0.1.Final
> Reporter: Jay Kumar SenSharma
> Assignee: Jean-Frederic Clere
>
> - JBoss Metadata APIs do not validate if the <servlet-mapping> tag has valid mappings or not. This should have been handled properly.
> *Example:* If following kind of web.xml based application is deployed on WildFly9 then
> {code}
> <?xml version="1.0"?>
> <web-app xmlns="http://java.sun.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"
> version="3.0">
> <servlet>
> <servlet-name>MyServlet</servlet-name>
> <servlet-class>servlets.MyServlet</servlet-class>
> <load-on-startup>1</load-on-startup>
> </servlet>
> <servlet-mapping>
> <servlet-name>MyServlet</servlet-name>
> <!--url-pattern></url-pattern--> <!-- NOTICE url-pattern-tag is missing here -->
> </servlet-mapping>
> </web-app>
> {code}
> - With the above kind of web.xml a NullPointerException is encountered during deployment.
> {code}
> 15:50:20,207 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-7) MSC000001: Failed to start service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> Caused by: java.lang.NullPointerException
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.handleServletMappings(UndertowDeploymentInfoService.java:910)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.createServletConfig(UndertowDeploymentInfoService.java:656)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.start(UndertowDeploymentInfoService.java:252)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> ... 3 more
> 15:50:20,348 ERROR [org.jboss.as.controller.management-operation] (DeploymentScanner-threads - 1) WFLYCTL0013: Operation ("deploy") failed - address: ([("deployment" => "ContextParamNullDemo.war")]) - failure description: {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService" => "org.jboss.msc.service.StartException in service jboss.undertow.deployment.default-server.default-host./ContextParamNullDemo.UndertowDeploymentInfoService: Failed to start service
> Caused by: java.lang.NullPointerException"}}
> {code}
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (JBMETA-363) Validation errors with "jboss-web_7_0.xsd
by Jean-Frederic Clere (JIRA)
[ https://issues.jboss.org/browse/JBMETA-363?page=com.atlassian.jira.plugin... ]
Jean-Frederic Clere commented on JBMETA-363:
--------------------------------------------
I guess I miss something the jar contains the file I don't see why eclipse can't find them...
+++
[jfclere@dhcp-144-227 metadata]$ jar tvf ./ear/target/jboss-metadata-ear-7.1.1.Final-SNAPSHOT.jar | grep jboss-app_7_0.xsd
5253 Fri Jun 20 18:01:10 CEST 2014 schema/jboss-app_7_0.xsd
+++
> Validation errors with "jboss-web_7_0.xsd
> -----------------------------------------
>
> Key: JBMETA-363
> URL: https://issues.jboss.org/browse/JBMETA-363
> Project: JBoss Metadata
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: web
> Affects Versions: 7.0.5.Final, 8.1.0.Beta1
> Environment: Eclipse
> Reporter: Wolfgang Knauf
> Assignee: Jean-Frederic Clere
>
> I tried to create a "jboss-web.xml" file based on the "jboss-web_7_1.xsd"
> As this is not uploaded to the web up to now, I created it with a schema location pointing to my local JBoss 7.2.0Alpha1 snapshot:
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web xmlns="http://www.jboss.com/xml/ns/javaee"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
> xsi:schemaLocation="http://www.jboss.com/xml/ns/javaee file:///C:/Temp/jboss-as-7.2.0.Alpha1-SNAPSHOT/docs/schema/jboss-web_7_0.xsd"
> version="7.0">
> ...
> </jboss-web>
> Eclipse shows validation errors in the XSD file.
> The first on is:
> sch-props-correct.2: A schema cannot contain two global components with the same name; this schema contains two
> occurences of 'http://java.sun.com/xml/ns/javaee,descriptionGroup'
> (occurs in javaee_6.xsd, line 88)
> And a lot more of those.
> The file was created as part of https://issues.jboss.org/browse/AS7-1262 - and the one who created it found the same validation error.
> It seems the fix is quite simple:
> "jboss-web_7_0.xsd" contains this import:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="web-app_3_0.xsd"/>
> Change it to:
> <xsd:import namespace="http://java.sun.com/xml/ns/javaee" schemaLocation="http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd"/>
> The reason seems to be: "jboss-web_7_0.xsd" imports "jboss-common_6-0.xsd", and this one imports "javaee_6.xsd" with a full schema location.
> The "web-app_3_0.xsd" in "jboss-web_7_0.xsd" has a local schema location, thus the "javaee_6.xsd" import in "web-app_3_0.xsd" points also to local.
> And this seems to cause a duplicate import of the file.
> (might also be an Eclipse valiation bug)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months
[JBoss JIRA] (WFLY-3662) CLI: non-batchable commands appearing in control flow statements executed regardless of condition
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-3662?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky updated WFLY-3662:
------------------------------------
Summary: CLI: non-batchable commands appearing in control flow statements executed regardless of condition (was: CLI control flow statements not working for commands)
Fix Version/s: 9.0.0.Beta1
Git Pull Request: https://github.com/wildfly/wildfly-core/pull/92
I am changing the title to make it more precise (from my point of view). Feel free to object and suggest a better one.
I have fixed the issue in the linked PR.
Thanks for the report!
> CLI: non-batchable commands appearing in control flow statements executed regardless of condition
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-3662
> URL: https://issues.jboss.org/browse/WFLY-3662
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.1.0.Final
> Reporter: Stanley Hillner
> Assignee: Alexey Loubyansky
> Priority: Critical
> Labels: cli, command, command-line, script
> Fix For: 9.0.0.Beta1
>
>
> The CLI control flows, such as if-then-else, are not working for CLI commands, such as echo or module. Using commands in control flows results in the strange behavior that these commands are executed in each case without respecting to what the if-statement evaluated.
> I am trying to customize a fresh wildfly server with some modules and settings for our development process. I decided to add modules using a CLI script that gets executed by maven, but when the script declares the following the module command in the 'then' block is executed in each case:
> {noformat}
> if (outcome == failed) of /core-service=module-loading:list-resource-loader-paths(module=oracle.jdbcaq)
> module add --name=oracle.jdbcaq ...
> end-if
> ...
> {noformat}
> I've also verified this behavior with another structure that just checks a property and echos something and both echos were executed:
> {noformat}
> /system-property=x:add(value=123)
> if (result == 123) of /system-property=x:read-attribute(name=value)
> echo "If block"
> /system-property=x:read-attribute(name=value)
> else
> echo "Else block"
> /system-property=x:read-attribute(name=value)
> end-if
> {noformat}
> The next thing is that if you just put echos into the if and else blocks, the CLI processor complains about an empty if-block. Try this one:
> {noformat}
> /system-property=x:add(value=123)
> if (result == 123) of /system-property=x:read-attribute(name=value)
> echo "If block"
> else
> echo "Else block"
> end-if
> {noformat}
> This behavior has also been observed by other users (see the forum reference) and for me it is critical to our setup since the only alternative would be copying modules manually to the modules folder. Furthermore, there might be other commands required for us to adapt the standalone configuration that need to be nested in an if-statement.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 8 months