[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:
----------------------------------
The deployment failure? It occurs immediately upon attempting to deploy the given ear.
Immediately upon this failure, the deployment scanner undeploys the unrelated war -- and removes it from the standalone-full.xml file.
> 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, 9 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 updated WFLY-3726:
-----------------------------------
Assignee: Emmanuel Hugonnet (was: Brian Stansberry)
> 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, 9 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:
----------------------------------------
When does this failure occur? At boot, or later?
> 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: Brian Stansberry
>
> 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, 9 months
[JBoss JIRA] (WFLY-3725) Unable to deploy dynamic, programmatic JSR-356 Endpoints
by Jim Crossley (JIRA)
[ https://issues.jboss.org/browse/WFLY-3725?page=com.atlassian.jira.plugin.... ]
Jim Crossley closed WFLY-3725.
------------------------------
Resolution: Rejected
Sorry, Stuart, my bad. I was making an incorrect assumption about how the path passed to ServerEndpointConfig.create() is resolved.
> Unable to deploy dynamic, programmatic JSR-356 Endpoints
> ---------------------------------------------------------
>
> Key: WFLY-3725
> URL: https://issues.jboss.org/browse/WFLY-3725
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final
> Reporter: Jim Crossley
> Assignee: Stuart Douglas
>
> I'm following the example here: https://github.com/undertow-io/undertow/blob/ceb019c91bd5ff5f219093298be9...
> I'm dynamically creating a Servlet instance and deploying it using the the ServletContext's addServlet method. The servlet init's method is similar to the above test case, obtaining a ServerContainer and calling its addEndpoint method with a ServerEndpointConfig$Configurator.
> Everything works fine in standalone Undertow 1.0.15.Final, but in WildFly 8.1, I see the following:
> [io.undertow.websockets.jsr] (MSC service thread 1-1) UT026005: Adding programmatic server endpoint class immutant.web.internal.servlet.proxy$javax.websocket.Endpoint$ff19274a for path /
> And then my configurator never gets called when I attempt to connect. It's as if the upgrade is never attempted, i.e. like the request protocol is 'http://' instead of 'ws://' but I know it's 'ws://' because the same client works fine against Undertow standalone.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (WFLY-3726) Filesystem deployment scanner deployment failure removes unrelated deployments
by Jess Holle (JIRA)
Jess Holle created WFLY-3726:
--------------------------------
Summary: 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: Brian Stansberry
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, 9 months
[JBoss JIRA] (JGRP-1870) Convert manual and tutorial to Asciidoc
by Bela Ban (JIRA)
Bela Ban created JGRP-1870:
------------------------------
Summary: Convert manual and tutorial to Asciidoc
Key: JGRP-1870
URL: https://issues.jboss.org/browse/JGRP-1870
Project: JGroups
Issue Type: Task
Security Level: Public (Everyone can see)
Reporter: Bela Ban
Assignee: Bela Ban
Fix For: 3.6
# Convert the Docbook based documentation (manual & tutorial) to Asciidoc
# Move the documentation to github.io: advantage would be to make changing docs simpler; e.g. anyone with permission would be able to make a change in the doc online (directly on github.io) or via PR. OPTIONAL and TBD
# Move the web page to github.io (optional, later)
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBWEB-301) When custom error pages are used in web.xml wrong status codes are returned
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/JBWEB-301?page=com.atlassian.jira.plugin.... ]
Aaron Ogburn commented on JBWEB-301:
------------------------------------
Let me note what happens specifically with DELETE/PUT and PATCH requests First, here's what occurs with DELETE/PUT requests:
1) filter sends 405
2) StandardHostValve tries to serve custom error page, forwarding to custom 405 page.
3) Static 405 error page is served by org.apache.catalina.servlets.DefaultServlet. It is still serving the original method for the forwarded error page request (DELETE or PUT). DefaultServlet provides 403 in its doPut/doDelete implementations. So the put/delete to the static page gets a 403 in the end from the custom error page.
And now for PATCH requests:
1) filter sends 405
2) StandardHostValve tries to serve custom error page, forwarding to custom 405 page.
3) Static 405 error page is served by org.apache.catalina.servlets.DefaultServlet. It is still serving the original method for the forwarded error page request (PATCH). DefaultServlet extends javax.servlet.http.HttpServlet and does not override the HttpServlet.service method. HttpServlet.service does not recognize the PATCH request method, and so it provides a 501/method not implemented response.
So in both cases, JBoss forwards the request to the custom error page, and the result of that forwarded request sets the end response code, overriding what your filter set. Note the following portion from the servlet spec (JSR 315, Section 10.9.1):
...
If the location of the error handler is a servlet or a JSP page:
* The original unwrapped request and response objects created by the container are passed to the servlet or JSP page.
* The request path and attributes are set as if a RequestDispatcher.forward to the error resource had been performed.
...
So we should expect the request to be forwarded to the error pages, which are handled by the DefaultServlet, and we should expect the end custom error page response from the DefaultServlet to override the filter's set 405. It looks like everything is working as intended here and there is no actual bug, although the end result is not your desired result. Your complaint would actually be against the servlet spec itself and not JBossWeb, which is just following the spec.
> When custom error pages are used in web.xml wrong status codes are returned
> ---------------------------------------------------------------------------
>
> Key: JBWEB-301
> URL: https://issues.jboss.org/browse/JBWEB-301
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.2.1.GA
> Environment: JBoss EAP 6.1.1
> Red Hat Linux 6.1
> CamelServlet 2.13.0
> Reporter: Troy Longo
> Assignee: Remy Maucherat
>
> I have the following code in my ServletFilter
> if(request instanceof HttpServletRequest)
> {
> isHttpRequest = true;
>
> if(!(((HttpServletRequest)request).getMethod().equals("POST")))
> {
> ((HttpServletResponse)response).sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED);
> return;
> }
> }
> When I send a GET request, everything works fine and I am receive a response with a 405 status code. However when I send a PUT or DELETE, I receive a 403 and 501 status code respectively. I have debugged through my code and verified that I am hitting the same line above in my code. What I noticed is that this code was working nicely until I added some custom error pages into my web.xml. My web xml error page definitions are as follows. Removing these custom error pages from the web.xml cause the code to work as expected.
> <!--<error-page>
> <error-code>500</error-code>
> <location>/WEB-INF/500Error.html</location>
> </error-page>
> <error-page>
> <error-code>404</error-code>
> <location>/WEB-INF/404Error.html</location>
> </error-page>
> <error-page>
> <error-code>413</error-code>
> <location>/WEB-INF/413Error.html</location>
> </error-page>
> <error-page>
> <error-code>405</error-code>
> <location>/WEB-INF/405Error.html</location>
> </error-page>-->
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months
[JBoss JIRA] (JBWEB-301) When custom error pages are used in web.xml wrong status codes are returned
by Aaron Ogburn (JIRA)
[ https://issues.jboss.org/browse/JBWEB-301?page=com.atlassian.jira.plugin.... ]
Aaron Ogburn updated JBWEB-301:
-------------------------------
> When custom error pages are used in web.xml wrong status codes are returned
> ---------------------------------------------------------------------------
>
> Key: JBWEB-301
> URL: https://issues.jboss.org/browse/JBWEB-301
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: JBossWeb-7.2.1.GA
> Environment: JBoss EAP 6.1.1
> Red Hat Linux 6.1
> CamelServlet 2.13.0
> Reporter: Troy Longo
> Assignee: Remy Maucherat
>
> I have the following code in my ServletFilter
> if(request instanceof HttpServletRequest)
> {
> isHttpRequest = true;
>
> if(!(((HttpServletRequest)request).getMethod().equals("POST")))
> {
> ((HttpServletResponse)response).sendError(HttpServletResponse.SC_METHOD_NOT_ALLOWED);
> return;
> }
> }
> When I send a GET request, everything works fine and I am receive a response with a 405 status code. However when I send a PUT or DELETE, I receive a 403 and 501 status code respectively. I have debugged through my code and verified that I am hitting the same line above in my code. What I noticed is that this code was working nicely until I added some custom error pages into my web.xml. My web xml error page definitions are as follows. Removing these custom error pages from the web.xml cause the code to work as expected.
> <!--<error-page>
> <error-code>500</error-code>
> <location>/WEB-INF/500Error.html</location>
> </error-page>
> <error-page>
> <error-code>404</error-code>
> <location>/WEB-INF/404Error.html</location>
> </error-page>
> <error-page>
> <error-code>413</error-code>
> <location>/WEB-INF/413Error.html</location>
> </error-page>
> <error-page>
> <error-code>405</error-code>
> <location>/WEB-INF/405Error.html</location>
> </error-page>-->
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 9 months