[JBoss JIRA] (ARQ-1324) Warp HTTP request header size beyond reasonable limits
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1324?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1324:
----------------------------
Fix Version/s: warp_1.0.0.Beta1
> Warp HTTP request header size beyond reasonable limits
> ------------------------------------------------------
>
> Key: ARQ-1324
> URL: https://issues.jboss.org/browse/ARQ-1324
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha2
> Environment: JBoss AS 7.1.1.Final
> Reporter: Marek Schmidt
> Assignee: Lukáš Fryč
> Priority: Critical
> Fix For: warp_1.0.0.Beta1
>
>
> HTTP servers usually limit HTTP header size of the requests (e.g. 8192 bytes for AS7) and refuse to accept requests with larger headers with "Invalid request" errors. Such limit is easily exceeded by a non-trivial Inspection object.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ARQ-1324) Warp HTTP request header size beyond reasonable limits
by Marek Schmidt (JIRA)
Marek Schmidt created ARQ-1324:
----------------------------------
Summary: Warp HTTP request header size beyond reasonable limits
Key: ARQ-1324
URL: https://issues.jboss.org/browse/ARQ-1324
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Extension - Warp
Affects Versions: warp_1.0.0.Alpha2
Environment: JBoss AS 7.1.1.Final
Reporter: Marek Schmidt
Assignee: Lukáš Fryč
Priority: Critical
HTTP servers usually limit HTTP header size of the requests (e.g. 8192 bytes for AS7) and refuse to accept requests with larger headers with "Invalid request" errors. Such limit is easily exceeded by a non-trivial Inspection object.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ARQ-1319) Warp: Jacoco support
by Aris Tzoumas (JIRA)
[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ]
Aris Tzoumas edited comment on ARQ-1319 at 3/3/13 2:38 PM:
-----------------------------------------------------------
It is possible to decouple response's writing and closing from {{WarpFilter}} {{doFilterWarp}} method, but this means that I should have to do the following changes:
* Make {{RequestContextHandler}} observe {{BeforeSuite}} & {{AfterSuite}} instead of {{BeforeRequest}} & {{AfterRequest}} events. This way requestContext will be active throughout Arquillian's event lifecycle.
* Add two observer methods on {{HttpRequestProcessor}}. The first one will observe {{BeforeSuite}} event (with precedence 100) and replace {{HttpServletResponse}} with a {{NonWritingResponse}}. The second one will observe {{AfterSuite}} event (with precedence -100) and will write and close the {{ServletOutputStream}}.
Do you think that this is a good approach?
was (Author: atzoum):
It is possible to decouple response's writing and closing from {{WarpFilter}} {{doFilterWarp}} method, but this means that I should have to do the following changes:
* Make {{RequestContextHandler}} observe {{BeforeSuite}} & {{AfterSuite}} instead of {{BeforeRequest}} & {{AfterRequest}} events. This way requestContext will be active throughout Arquillian's event lifecycle.
* Add two observer methods on {{HttpRequestProcessor}}. The first one will observe {{BeforeSuite}} event (with precedence 100)and replace {{HttpServletResponse}} with a {{NonWritingResponse}}. The second one will observe {{AfterSuite}} event (with precedence -100) and will write and close the {{ServletOutputStream}}.
Do you think that this is a good approach?
> Warp: Jacoco support
> --------------------
>
> Key: ARQ-1319
> URL: https://issues.jboss.org/browse/ARQ-1319
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Reporter: Lukáš Fryč
> Fix For: warp_1.0.0.Beta1
>
> Attachments: ftest-coverage.jpg, jacoco.jpg, warp-jacoco.png
>
>
> The support for CommandService was committed in ARQ-1027, which enabled us to run {{arquillian-extension-jacoco}}.
> However as report from the Warp's build shows, the reporting isn't successful - report doesn't seem to contain any hits.
> We need to investigate and once ready, we should use [{{check}}|http://www.eclemma.org/jacoco/trunk/doc/check-mojo.html] goal to be sure that coverage is reported successfully from Warp's tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ARQ-1319) Warp: Jacoco support
by Aris Tzoumas (JIRA)
[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ]
Aris Tzoumas commented on ARQ-1319:
-----------------------------------
It is possible to decouple response's writing and closing from {{WarpFilter}} {{doFilterWarp}} method, but this means that I should have to do the following changes:
* Make {{RequestContextHandler}} observe {{BeforeSuite}} & {{AfterSuite}} instead of {{BeforeRequest}} & {{AfterRequest}} events. This way requestContext will be active throughout Arquillian's event lifecycle.
* Add two observer methods on {{HttpRequestProcessor}}. The first one will observe {{BeforeSuite}} event (with precedence 100)and replace {{HttpServletResponse}} with a {{NonWritingResponse}}. The second one will observe {{AfterSuite}} event (with precedence -100) and will write and close the {{ServletOutputStream}}.
Do you think that this is a good approach?
> Warp: Jacoco support
> --------------------
>
> Key: ARQ-1319
> URL: https://issues.jboss.org/browse/ARQ-1319
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Reporter: Lukáš Fryč
> Fix For: warp_1.0.0.Beta1
>
> Attachments: ftest-coverage.jpg, jacoco.jpg, warp-jacoco.png
>
>
> The support for CommandService was committed in ARQ-1027, which enabled us to run {{arquillian-extension-jacoco}}.
> However as report from the Warp's build shows, the reporting isn't successful - report doesn't seem to contain any hits.
> We need to investigate and once ready, we should use [{{check}}|http://www.eclemma.org/jacoco/trunk/doc/check-mojo.html] goal to be sure that coverage is reported successfully from Warp's tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ARQ-1319) Warp: Jacoco support
by Aris Tzoumas (JIRA)
[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ]
Aris Tzoumas edited comment on ARQ-1319 at 3/3/13 2:21 PM:
-----------------------------------------------------------
Well Lukáš, you just found a *Bug* in {{CommandEventBus}}...
The case is that the Container may send a {{CoverageDataCommand}} to the client *after* a response has already been sent to the client ({{ServletResponse}} {{OutputStream}} is closed). As a result, client's CommandEventBus may have already been closed (the {{After}} event has fired on client side) and thus it doesn't receive the coverage command.
Actually, there is a race condition between the timer thread on {{CommandEventBus}} and the {{@After}} event that cancels the timer. Sometimes the {{TimerTask}} manages to process the command, sometimes it doesn't. That's why I was getting inconsistent coverage reports from Jacoco's reporting task when testing.
There are two possible solutions to this problem:
* Add a 100ms delay to {{CommandEventBus}} shutdown process, so that the TimerTask has time to process the last Command from the container (...if it does send one).
* Make sure that all container commands happen before the {{After}} event fires on client.
Although the first solution may be easier to implement, the second one is the right thing to do.
That's why I have prepared the following two commits:
* https://github.com/atzoum/arquillian-extension-warp/commit/6d284459402ebf...
This one closes the {{HttpServletResponse}} only afterwards {{Manager}} shuts down. So, {{CommandEventBus}} stays open for as long it is needed. You may need to review this one, since you have a better understanding of Warp's internals. I basically create a {{NonWritingResponse}} at the beginning of {{WarpFilter}}'s processing, which actually gets written and closed only at the end of the processing.
* https://github.com/atzoum/arquillian-extension-warp/commit/0fa31972597c0b...
This one is an updated Test that should fail if the HTTP Response gets committed before {{AfterSuite}} event is called in the container.
The above two commits are inside my branch:
https://github.com/atzoum/arquillian-extension-warp/tree/race-condition
This branch runs all tests successfully and behaves as expected.
I am also attaching a screenshot with a correct coverage report on {{ftest}} project (https://issues.jboss.org/secure/attachment/12361047/ftest-coverage.jpg).
If you want to add arquillian coverage on *{{jsf-ftest}}*, please don't forget to add the following dependencies on {{pom.xml}}
{noformat}
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<scope>test</scope>
</dependency>
{noformat}
was (Author: atzoum):
Well Lukáš, you just found a *Bug* in {{CommandEventBus}}...
The case is that the Container may send a {{CoverageDataCommand}} to the client *after* a response has already been sent to the client ({{ServletResponce}} {{OutputStream}} is closed). As a result, client's CommandEventBus may have already been closed (the {{After}} event has fired on client side) and thus it doesn't receive the coverage command.
Actually, there is a race condition between the timer thread on {{CommandEventBus}} and the {{@After}} event that cancels the timer. Sometimes the {{TimerTask}} manages to process the command, sometimes it doesn't. That's why I was getting inconsistent coverage reports from Jacoco's reporting task when testing.
There are two possible solutions to this problem:
* Add a 100ms delay to {{CommandEventBus}} shutdown process, so that the TimerTask has time to process the last Command from the container (...if it does send one).
* Make sure that all container commands happen before the {{After}} event fires on client.
Although the first solution may be easier to implement, the second one is the right thing to do.
That's why I have prepared the following two commits:
* https://github.com/atzoum/arquillian-extension-warp/commit/6d284459402ebf...
This one closes the {{HttpServletResponse}} only afterwards {{Manager}} shuts down. So, {{CommandEventBus}} stays open for as long it is needed. You may need to review this one, since you have a better understanding of Warp's internals. I basically create a {{NonWritingResponse}} at the beginning of {{WarpFilter}}'s processing, which actually gets written and closed only at the end of the processing.
* https://github.com/atzoum/arquillian-extension-warp/commit/0fa31972597c0b...
This one is an updated Test that should fail if the HTTP Response gets committed before {{AfterSuite}} event is called in the container.
The above two commits are inside my branch:
https://github.com/atzoum/arquillian-extension-warp/tree/race-condition
This branch runs all tests successfully and behaves as expected.
I am also attaching a screenshot with a correct coverage report on {{ftest}} project (https://issues.jboss.org/secure/attachment/12361047/ftest-coverage.jpg).
If you want to add arquillian coverage on *{{jsf-ftest}}*, please don't forget to add the following dependencies on {{pom.xml}}
{noformat}
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<scope>test</scope>
</dependency>
{noformat}
> Warp: Jacoco support
> --------------------
>
> Key: ARQ-1319
> URL: https://issues.jboss.org/browse/ARQ-1319
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Reporter: Lukáš Fryč
> Fix For: warp_1.0.0.Beta1
>
> Attachments: ftest-coverage.jpg, jacoco.jpg, warp-jacoco.png
>
>
> The support for CommandService was committed in ARQ-1027, which enabled us to run {{arquillian-extension-jacoco}}.
> However as report from the Warp's build shows, the reporting isn't successful - report doesn't seem to contain any hits.
> We need to investigate and once ready, we should use [{{check}}|http://www.eclemma.org/jacoco/trunk/doc/check-mojo.html] goal to be sure that coverage is reported successfully from Warp's tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
[JBoss JIRA] (ARQ-1319) Warp: Jacoco support
by Aris Tzoumas (JIRA)
[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ]
Aris Tzoumas edited comment on ARQ-1319 at 3/3/13 2:21 PM:
-----------------------------------------------------------
Well Lukáš, you just found a *Bug* in {{CommandEventBus}}...
The case is that the Container may send a {{CoverageDataCommand}} to the client *after* a response has already been sent to the client ({{ServletResponce}} {{OutputStream}} is closed). As a result, client's CommandEventBus may have already been closed (the {{After}} event has fired on client side) and thus it doesn't receive the coverage command.
Actually, there is a race condition between the timer thread on {{CommandEventBus}} and the {{@After}} event that cancels the timer. Sometimes the {{TimerTask}} manages to process the command, sometimes it doesn't. That's why I was getting inconsistent coverage reports from Jacoco's reporting task when testing.
There are two possible solutions to this problem:
* Add a 100ms delay to {{CommandEventBus}} shutdown process, so that the TimerTask has time to process the last Command from the container (...if it does send one).
* Make sure that all container commands happen before the {{After}} event fires on client.
Although the first solution may be easier to implement, the second one is the right thing to do.
That's why I have prepared the following two commits:
* https://github.com/atzoum/arquillian-extension-warp/commit/6d284459402ebf...
This one closes the {{HttpServletResponse}} only afterwards {{Manager}} shuts down. So, {{CommandEventBus}} stays open for as long it is needed. You may need to review this one, since you have a better understanding of Warp's internals. I basically create a {{NonWritingResponse}} at the beginning of {{WarpFilter}}'s processing, which actually gets written and closed only at the end of the processing.
* https://github.com/atzoum/arquillian-extension-warp/commit/0fa31972597c0b...
This one is an updated Test that should fail if the HTTP Response gets committed before {{AfterSuite}} event is called in the container.
The above two commits are inside my branch:
https://github.com/atzoum/arquillian-extension-warp/tree/race-condition
This branch runs all tests successfully and behaves as expected.
I am also attaching a screenshot with a correct coverage report on {{ftest}} project (https://issues.jboss.org/secure/attachment/12361047/ftest-coverage.jpg).
If you want to add arquillian coverage on *{{jsf-ftest}}*, please don't forget to add the following dependencies on {{pom.xml}}
{noformat}
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<scope>test</scope>
</dependency>
{noformat}
was (Author: atzoum):
Well Lukáš, you just found a *Bug* in {{CommandEventBus}}...
The case is that the Container may send a {{CoverageDataCommand}} to the client *after* a response has already been sent to the client ({{OutputStream}} is closed). As a result, client's CommandEventBus may have already been closed ({{After}} event has fired on client) and thus it doesn't receive the coverage command.
Actually, there is a race condition between the timer on {{CommandEventBus}} and the {{@After}} event that cancels the timer. Sometimes the {{TimerTask}} manages to process the command, sometimes it doesn't. That's why I was getting inconsistent coverage reports from Jacoco's reporting task.
There are two possible solutions to this problem:
* Add a delay to {{CommandEventBus}} shutdown, so that it has time to process the last Command from the container (should it ever send one).
* Make all container commands happen before {{After}} event fires on client.
Although the first solution may be easier to implement, the second one is the way we should go.
That's why I have prepared the following two commits:
* https://github.com/atzoum/arquillian-extension-warp/commit/6d284459402ebf...
This one closes the response afterwards {{Manager}}'s shudown, so {{CommandEventBus}} stays open for as long it is needed. You may need to review this one, since you have a better understanding of Warp's internals. I basically create a {{NonWritingResponse}} at the beginning of {{WarpFilter}}'s processing, which gets written and closed at the end of the processing.
* https://github.com/atzoum/arquillian-extension-warp/commit/0fa31972597c0b...
This one is an updated Test that should fail if the HTTP Response gets committed before {{AfterSuite}} event is called in the container.
The above two commits are inside my branch:
https://github.com/atzoum/arquillian-extension-warp/tree/race-condition
This branch runs all tests successfully and behaves as expected.
I am also attaching a screenshot with a correct coverage report on {{ftest}} project (https://issues.jboss.org/secure/attachment/12361047/ftest-coverage.jpg).
If you want to add arquillian coverage on *{{jsf-ftest}}*, please don't forget to add the following dependencies on {{pom.xml}}
{noformat}
<dependency>
<groupId>org.jboss.arquillian.extension</groupId>
<artifactId>arquillian-jacoco</artifactId>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jacoco</groupId>
<artifactId>org.jacoco.core</artifactId>
<scope>test</scope>
</dependency>
{noformat}
> Warp: Jacoco support
> --------------------
>
> Key: ARQ-1319
> URL: https://issues.jboss.org/browse/ARQ-1319
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Reporter: Lukáš Fryč
> Fix For: warp_1.0.0.Beta1
>
> Attachments: ftest-coverage.jpg, jacoco.jpg, warp-jacoco.png
>
>
> The support for CommandService was committed in ARQ-1027, which enabled us to run {{arquillian-extension-jacoco}}.
> However as report from the Warp's build shows, the reporting isn't successful - report doesn't seem to contain any hits.
> We need to investigate and once ready, we should use [{{check}}|http://www.eclemma.org/jacoco/trunk/doc/check-mojo.html] goal to be sure that coverage is reported successfully from Warp's tests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
11 years, 10 months
