[JBoss JIRA] (JBWEB-301) When custom error pages are used in web.xml wrong status codes are returned
by Troy Longo (JIRA)
[ https://issues.jboss.org/browse/JBWEB-301?page=com.atlassian.jira.plugin.... ]
Troy Longo edited comment on JBWEB-301 at 7/25/14 2:24 PM:
-----------------------------------------------------------
This reproducible in Jboss EAP 6.2.4 also
was (Author: tclongo):
This reproducible in 6.2.4 also
> 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.0
> 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, 11 months
[JBoss JIRA] (JBWEB-301) When custom error pages are used in web.xml wrong status codes are returned
by Troy Longo (JIRA)
[ https://issues.jboss.org/browse/JBWEB-301?page=com.atlassian.jira.plugin.... ]
Troy Longo updated JBWEB-301:
-----------------------------
Environment:
JBoss EAP 6.1.1
Red Hat Linux 6.1
CamelServlet 2.13.0
was:
JBoss EAP 6.1.0
Red Hat Linux 6.1
CamelServlet 2.13.0
> 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, 11 months
[JBoss JIRA] (JBWEB-301) When custom error pages are used in web.xml wrong status codes are returned
by Troy Longo (JIRA)
[ https://issues.jboss.org/browse/JBWEB-301?page=com.atlassian.jira.plugin.... ]
Troy Longo commented on JBWEB-301:
----------------------------------
This reproducible in 6.2.4 also
> 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.0
> 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, 11 months
[JBoss JIRA] (JBJCA-1198) Use-strict-min shouldn't be considered for non-prefill pools
by Jesper Pedersen (JIRA)
Jesper Pedersen created JBJCA-1198:
--------------------------------------
Summary: Use-strict-min shouldn't be considered for non-prefill pools
Key: JBJCA-1198
URL: https://issues.jboss.org/browse/JBJCA-1198
Project: IronJacamar
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Core
Affects Versions: 1.2.0.Beta3, 1.1.6.Final, 1.0.26.Final
Reporter: Jesper Pedersen
Assignee: Jesper Pedersen
Priority: Critical
Fix For: 1.0.27.Final, 1.1.7.Final, 1.2.0.Beta4
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3663) WildFly should manage JGroups and Infinispan thread pools by default
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-3663?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-3663:
------------------------------------
There is already a JIRA for that: https://issues.jboss.org/browse/WFLY-497
I'll add the missing dependency.
> WildFly should manage JGroups and Infinispan thread pools by default
> --------------------------------------------------------------------
>
> Key: WFLY-3663
> URL: https://issues.jboss.org/browse/WFLY-3663
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Clustering
> Affects Versions: 8.1.0.Final
> Reporter: Paul Ferraro
> Assignee: Paul Ferraro
> Fix For: 9.0.0.Beta1
>
>
> In our default configuration, both JGroups and Infinispan manage their own thread pools. Unfortunately, both projects do not handle thread pool lifecycle so well. Both projects use ExecutorService.shutdownNow() to end their thread pool lifecycles. This means that a channel or cache can stop, but still leave active threads running (albeit interrupted). We should have services that manage the lifecycle of our thread pools which ensure that all threads have terminated during Service.stop().
> This causes occasional OOMs in the Windows CI testsuite runs, due to too many threads lying around.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-495) kie maven plugin, packaging kjar, test resources file not resolved
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-495?page=com.atlassian.jira.plugin... ]
Petr Široký reassigned DROOLS-495:
----------------------------------
Assignee: Petr Široký (was: Mark Proctor)
> kie maven plugin, packaging kjar, test resources file not resolved
> ------------------------------------------------------------------
>
> Key: DROOLS-495
> URL: https://issues.jboss.org/browse/DROOLS-495
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta3, 6.1.0.CR2
> Reporter: Matteo Mortari
> Assignee: Petr Široký
> Attachments: 20140521.drools6test.testresources.zip
>
>
> I understand the idiomatic way for a drools Kie rule Maven project to be built, as shown in the [example|https://github.com/droolsjbpm/drools/blob/master/kie-maven-plugin...], is to include in the pom:
> * Kie Maven plugin
> * set packaging to {{kjar}}
> However, normally the file resources available under
> {noformat}
> src/
> test/
> resources/
> aresource.txt
> {noformat}
> should be available while running {{mvn test}}
> However I noticed if packaging is set to {{kjar}}, this fails. It is working as expected if instead the packaging is set to the standard {{jar}}
> Consider the following attached example project to replicate the issue. It contains the 'aresource.txt' file in the standard Maven layout directory {{src/test/resources}} as shown above. However the following simple test fails:
> {code:title=AppTest.java|borderStyle=solid}
> @Test
> public void testFindTheFile() {
> URL resource = getClass().getResource("/aresource.txt");
> assertNotNull(resource);
> }
> {code}
> Setting instead the project packaging to the standard {{jar}} instead, pass the test, and in fact it can be noticed the 'aresource.txt' file is available under {{target/test-classes}} directory.
> Extract of the pom failing the test due to packaging set to {{kjar}}
> {code:xml|title=pom.xml}
> <project ...>
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.acme</groupId>
> <artifactId>drools6test.testresources</artifactId>
> <version>0.0.1-SNAPSHOT</version>
>
> <packaging>kjar</packaging>
>
> <!-- ... -->
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-bom</artifactId>
> <type>pom</type>
> <version>6.1.0.Beta3</version>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> <!-- ... -->
> <build>
> <finalName>drools6test.testresources</finalName>
> <plugins>
> <plugin>
> <groupId>org.kie</groupId>
> <artifactId>kie-maven-plugin</artifactId>
> <version>6.1.0.Beta3</version>
> <extensions>true</extensions>
> </plugin>
> </plugins>
> </project>
> {code}
> Thank you in advance for your feedback accordingly;
> Ciao
> Matteo
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (DROOLS-495) kie maven plugin, packaging kjar, test resources file not resolved
by Petr Široký (JIRA)
[ https://issues.jboss.org/browse/DROOLS-495?page=com.atlassian.jira.plugin... ]
Petr Široký commented on DROOLS-495:
------------------------------------
Hello,
I believe the root cause is here: https://github.com/droolsjbpm/drools/blob/master/kie-maven-plugin/src/mai.... The file lists the phases that should be executed during the build and I think the _process-test-resources_ (which copies the test resources into target/test-classes) is missing. I will create a PR with the change once I test the changes locally.
In the meantime you can use the following workaround (defining the _resources:testResources_ manually in pom.xml):
{code:xml}
<build>
....
<plugins>
....
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-resources-plugin</artifactId>
<executions>
<execution>
<id>copy-test-resources</id>
<phase>process-test-resources</phase>
<goals>
<goal>testResources</goal>
</goals>
</execution>
</executions>
</plugin>
...
</plugins>
...
</build>
{code}
> kie maven plugin, packaging kjar, test resources file not resolved
> ------------------------------------------------------------------
>
> Key: DROOLS-495
> URL: https://issues.jboss.org/browse/DROOLS-495
> Project: Drools
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 6.1.0.Beta3, 6.1.0.CR2
> Reporter: Matteo Mortari
> Assignee: Mark Proctor
> Attachments: 20140521.drools6test.testresources.zip
>
>
> I understand the idiomatic way for a drools Kie rule Maven project to be built, as shown in the [example|https://github.com/droolsjbpm/drools/blob/master/kie-maven-plugin...], is to include in the pom:
> * Kie Maven plugin
> * set packaging to {{kjar}}
> However, normally the file resources available under
> {noformat}
> src/
> test/
> resources/
> aresource.txt
> {noformat}
> should be available while running {{mvn test}}
> However I noticed if packaging is set to {{kjar}}, this fails. It is working as expected if instead the packaging is set to the standard {{jar}}
> Consider the following attached example project to replicate the issue. It contains the 'aresource.txt' file in the standard Maven layout directory {{src/test/resources}} as shown above. However the following simple test fails:
> {code:title=AppTest.java|borderStyle=solid}
> @Test
> public void testFindTheFile() {
> URL resource = getClass().getResource("/aresource.txt");
> assertNotNull(resource);
> }
> {code}
> Setting instead the project packaging to the standard {{jar}} instead, pass the test, and in fact it can be noticed the 'aresource.txt' file is available under {{target/test-classes}} directory.
> Extract of the pom failing the test due to packaging set to {{kjar}}
> {code:xml|title=pom.xml}
> <project ...>
> <modelVersion>4.0.0</modelVersion>
> <groupId>com.acme</groupId>
> <artifactId>drools6test.testresources</artifactId>
> <version>0.0.1-SNAPSHOT</version>
>
> <packaging>kjar</packaging>
>
> <!-- ... -->
>
> <dependencyManagement>
> <dependencies>
> <dependency>
> <groupId>org.drools</groupId>
> <artifactId>drools-bom</artifactId>
> <type>pom</type>
> <version>6.1.0.Beta3</version>
> <scope>import</scope>
> </dependency>
> </dependencies>
> </dependencyManagement>
>
> <!-- ... -->
> <build>
> <finalName>drools6test.testresources</finalName>
> <plugins>
> <plugin>
> <groupId>org.kie</groupId>
> <artifactId>kie-maven-plugin</artifactId>
> <version>6.1.0.Beta3</version>
> <extensions>true</extensions>
> </plugin>
> </plugins>
> </project>
> {code}
> Thank you in advance for your feedback accordingly;
> Ciao
> Matteo
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (JGRP-1863) Excessive dropped messages due to missing physical address
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1863?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-1863:
------------------------------------
OK - this was definitely an issue on my end. Sorry about that.
> Excessive dropped messages due to missing physical address
> ----------------------------------------------------------
>
> Key: JGRP-1863
> URL: https://issues.jboss.org/browse/JGRP-1863
> Project: JGroups
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.5
> Reporter: Paul Ferraro
> Assignee: Bela Ban
> Priority: Blocker
> Fix For: 3.5
>
>
> When running the x-site replication tests (and only those tests - the others run fine) from the clustering testsuite in WildFly against JGroups 3.5, I encounter failures due to:
> {noformat}
> 12:15:48,537 WARN [org.infinispan.xsite.BackupSenderImpl] (default task-1) ISPN000202: Problems backing up data for cache dist to site SFO: org.infinispan.util.concurrent.TimeoutException: Timed out after 10 seconds waiting for a response from SFO (sync, timeout=10000)
> {noformat}
> The logs preceding this indicate the cause of the timeout:
> {noformat}
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> 12:15:38,536 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,506 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(SFO), dropping message
> 12:15:39,507 WARN [org.jgroups.protocols.UDP] (TransferQueueBundler,shared=udp) JGRP000032: null: no physical address for SiteMaster(NYC), dropping message
> {noformat}
> These messages repeat about 100 or so times over a period of 10 seconds.
> A little investigation reveals that the process for fetching physical addresses for a given logical destination address has changed. In 3.4, a given call to sendToSingleMember(...) would attempt to lookup the physical address by sending a Event.GET_PHYSICAL_ADDRESS up the stack and wait a predetermined period for a response. Any concurrent calls to sendToSingleMember(...) would also wait, but only one thread in a given time period would ever send the Event.GET_PHYSICAL_ADDRESS event up the stack.
> In 3.5 the process is different. In org.jgroups.protocols.TP, the FIND_MBRS event is used to lookup the phsyical addresses, instead of directly sending up a GET_PHYSICAL_ADDRESS event. However, looking at the implementation of the FIND_MBRS event handling within org.jgroups.protocols.Discovery, I see that this triggers a asynchronous GET_MBRS_REQ message. Since this message is sent asynchronously, this means that the response from the original FIND_MBRS event will most certainly be empty. Thus the thread that initiated the FIND_MBRS will most certainly log the PhysicalAddrMissing warning, as will any concurrent/subsequent calls to sendToSingleMember(...) for the same destination until that asynchronous processing completes. This is a departure from the logic in 3.4, where the thread initiating the physical address lookup would wait for some time for the address cache to be updated. I should think that the PhysicalAddrMissing warnings should stop once the original GET_MBRS_REQ message is handled, but that doesn't seem to be happening (hence the 100 or so sequential warning messages over a period of 10 seconds preceding the timeout log message from infinispan).
> Curiously, I see a org.jgroups.protocols.TP.setPingData(...) method, which seems to be responsible for populating the physical address cache from the FIND_MBRS event results from org.jgroups.protocols.Discovery - however, this method doesn't seem to be referenced anywhere. Might that be the source of the problem?
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months
[JBoss JIRA] (WFLY-3657) JAXWS handlers do not support injection
by Alessio Soldano (JIRA)
[ https://issues.jboss.org/browse/WFLY-3657?page=com.atlassian.jira.plugin.... ]
Alessio Soldano commented on WFLY-3657:
---------------------------------------
Sorry, I didn't have time yet to figure out where the bug actually is, however it comes from the @HandlerChain not being specified on the service endpoint implementation class (but on the service endpoint interface). I need to verify if the specs actually say something on this, but it's likely a bug. You can workaround the problem by adding @HandlerChain(file = "MessagingServicePortType_handler.xml") in your MessagingServiceEndpointImpl .
> JAXWS handlers do not support injection
> ---------------------------------------
>
> Key: WFLY-3657
> URL: https://issues.jboss.org/browse/WFLY-3657
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Web Services
> Affects Versions: 8.1.0.Final
> Environment: Ubuntu 12.04
> JDK 1.8.0_11
> Reporter: Thomas Kriechbaum
> Assignee: Alessio Soldano
> Attachments: jaxws-handler-war.zip, wildfly-test-soapui-project.xml
>
>
> According to the JavaEE spec JAXWS-handlers should support injection (@Inject, @EJB), @PostConstruct and @PreDestroy.
> In my test case (top-down approach, handler class is defined within *_handler.xml) @PostCunstruct works, but managed beans (CDI, EJB) are not injected via @Inject or @EJB.
> Possible workaround for EJBs: manual JNDI-lookup within @PostConstruct method. For CDI-managed beans you have to lookup the BeanManager and load the desired bean yourself.
> It seems, that this issue should have been addressed by WFLY-2362. But it is still does not work.
--
This message was sent by Atlassian JIRA
(v6.2.6#6264)
11 years, 11 months