[JBoss JIRA] (ARQ-1327) arquillian-jacoco: Wrong asm library (3.1.1) dependency
by Tobias Seppenhauser (JIRA)
Tobias Seppenhauser created ARQ-1327:
----------------------------------------
Summary: arquillian-jacoco: Wrong asm library (3.1.1) dependency
Key: ARQ-1327
URL: https://issues.jboss.org/browse/ARQ-1327
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Extension - Jacoco
Affects Versions: jacoco_1.0.0.Alpha5
Reporter: Tobias Seppenhauser
In its pom.xml the _arquillian-jacoco_ extension is requiring the _asm_ library in version 3.1.1
http://search.maven.org/remotecontent?filepath=org/jboss/arquillian/exten...
The _Jacoco_ libraries itself don't require a certain version of the _asm_ library.
http://search.maven.org/remotecontent?filepath=org/jacoco/org.jacoco.core...
But the problem is, that trying to run a coverage test with _arquillian-jacoco_ and using _asm_ in version 3.1.1 is leading to an {{IncompatibleClassChangeError}}.
The class {{org.jacoco.core.internal.flow.ClassProbesVisitor}} is extending {{org.objectweb.asm.ClassVisitor}}, which is an interface in 3.1.1 and an abstract class in the latest version (4.1).
{code}
public abstract class ClassProbesVisitor extends ClassVisitor {
...
}
{code}
So, in my opion the asm-depencency should be changed to 4.1 to avoid this error.
--
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
12 years, 7 months
[JBoss JIRA] (ARQ-1325) Warp: replace piggy-backing on request/response with direct test->filter communication
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1325?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1325:
----------------------------
Assignee: (was: Lukáš Fryč)
> Warp: replace piggy-backing on request/response with direct test->filter communication
> --------------------------------------------------------------------------------------
>
> Key: ARQ-1325
> URL: https://issues.jboss.org/browse/ARQ-1325
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Reporter: Lukáš Fryč
> Fix For: warp_1.0.0.Beta1
>
>
> We can do similar processing as we did with CommandService here:
> https://github.com/arquillian/arquillian-extension-warp/blob/aa0745237f5d...
> The CommandService communicates with the WarpFilter asynchronously and its requests are not processed directly, they delegates to the request-serving routine.
> ----
> This way, Warp could:
> 0. request is issued against proxy
> 1. catch the request on the proxy
> 2. register the RequestPayload (with Inspection) in the registry via the WarpFilter (under generated request-specific UUID)
> 3. proxy passes request to WarpFilter with a request header which contains UUID
> 4. WarpFilter associates Inspection from the registry with given request
> 5. Warp proceeds with a request inspection
> 6. response is commited and sent back to the proxy (with given UUID as response header)
> 7. proxy catches the response and obtains ResponsePayload (with Inspection result) from the WarpFilter (using UUID)
> 8. proxy processes the ResponsePayload and passes the request to the client
> 9. the client processes response
> This would avoid a need for piggy-backing on request/response, so it will also eliminate need for response-wrapping (NonWritingResponse).
--
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
12 years, 7 months
[JBoss JIRA] (ARQ-1325) Warp: replace piggy-backing on request/response with direct test->filter communication
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1325?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1325:
----------------------------
Priority: Critical (was: Major)
> Warp: replace piggy-backing on request/response with direct test->filter communication
> --------------------------------------------------------------------------------------
>
> Key: ARQ-1325
> URL: https://issues.jboss.org/browse/ARQ-1325
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Reporter: Lukáš Fryč
> Priority: Critical
> Fix For: warp_1.0.0.Beta1
>
>
> We can do similar processing as we did with CommandService here:
> https://github.com/arquillian/arquillian-extension-warp/blob/aa0745237f5d...
> The CommandService communicates with the WarpFilter asynchronously and its requests are not processed directly, they delegates to the request-serving routine.
> ----
> This way, Warp could:
> 0. request is issued against proxy
> 1. catch the request on the proxy
> 2. register the RequestPayload (with Inspection) in the registry via the WarpFilter (under generated request-specific UUID)
> 3. proxy passes request to WarpFilter with a request header which contains UUID
> 4. WarpFilter associates Inspection from the registry with given request
> 5. Warp proceeds with a request inspection
> 6. response is commited and sent back to the proxy (with given UUID as response header)
> 7. proxy catches the response and obtains ResponsePayload (with Inspection result) from the WarpFilter (using UUID)
> 8. proxy processes the ResponsePayload and passes the request to the client
> 9. the client processes response
> This would avoid a need for piggy-backing on request/response, so it will also eliminate need for response-wrapping (NonWritingResponse).
--
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
12 years, 7 months
[JBoss JIRA] (ARQ-1319) Warp: Jacoco support
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on ARQ-1319 at 3/4/13 4:12 AM:
---------------------------------------------------------
I would consider it good approach, however the thing is that Warp currently misuses the Arquillian Manager - it should reuse it through whole test lifecycle and fire AfterSuite on the end of the test (ARQ-934).
Also, I have idea to avoid wrapping response (NonWritingResponse) at all: ARQ-1325
But as it appears to me, the CommandEventBus (and client test itself) should not finish before it has chance to process all Commands from server - it should wait from all server processing and all AfterSuite.
The ARQ-1325 and this issue could actually share implementation - the idea is allow bi-directional Command execution: test can execute command on server (e.g. "register the inspection", "execute AfterSuite"), on the other hand command service still can communicate to the client - I have this idea for quite long time: ARQ-1005
was (Author: lfryc):
I would consider it good approach, however the thing is that Warp currently misuses the Arquillian Manager - it should reuse it through whole test lifecycle and fire AfterSuite on the end of the test (ARQ-934).
Also, I have idea to avoid wrapping response (NonWritingResponse) at all: ARQ-1325
But as it appears to me, the CommandEventBus (and client test itself) should not finish before it has chance to process all Commands from server - it should wait from all server processing and all AfterSuite.
The ARQ-1325 and this issue could actually share implementation - the idea is allow bi-directional Command execution: test can execute command on server (e.g. "register the inspection", "execute AfterSuite"), on the other hand command service still can communicate to the client.
> 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
12 years, 7 months
[JBoss JIRA] (ARQ-1319) Warp: Jacoco support
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1319?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on ARQ-1319:
---------------------------------
I would consider it good approach, however the thing is that Warp currently misuses the Arquillian Manager - it should reuse it through whole test lifecycle and fire AfterSuite on the end of the test (ARQ-934).
Also, I have idea to avoid wrapping response (NonWritingResponse) at all: ARQ-1325
But as it appears to me, the CommandEventBus (and client test itself) should not finish before it has chance to process all Commands from server - it should wait from all server processing and all AfterSuite.
The ARQ-1325 and this issue could actually share implementation - the idea is allow bi-directional Command execution: test can execute command on server (e.g. "register the inspection", "execute AfterSuite"), on the other hand command service still can communicate to the client.
> 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
12 years, 7 months
[JBoss JIRA] (ARQ-1325) Warp: replace piggy-backing on request/response with direct test->filter communication
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1325?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on ARQ-1325:
---------------------------------
We would need to setup tests for communication with multiple servlet containers in one Warp test.
The logic for establishing connection can be reused from CommandEventBus.
> Warp: replace piggy-backing on request/response with direct test->filter communication
> --------------------------------------------------------------------------------------
>
> Key: ARQ-1325
> URL: https://issues.jboss.org/browse/ARQ-1325
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Fix For: warp_1.0.0.Beta1
>
>
> We can do similar processing as we did with CommandService here:
> https://github.com/arquillian/arquillian-extension-warp/blob/aa0745237f5d...
> The CommandService communicates with the WarpFilter asynchronously and its requests are not processed directly, they delegates to the request-serving routine.
> ----
> This way, Warp could:
> 0. request is issued against proxy
> 1. catch the request on the proxy
> 2. register the RequestPayload (with Inspection) in the registry via the WarpFilter (under generated request-specific UUID)
> 3. proxy passes request to WarpFilter with a request header which contains UUID
> 4. WarpFilter associates Inspection from the registry with given request
> 5. Warp proceeds with a request inspection
> 6. response is commited and sent back to the proxy (with given UUID as response header)
> 7. proxy catches the response and obtains ResponsePayload (with Inspection result) from the WarpFilter (using UUID)
> 8. proxy processes the ResponsePayload and passes the request to the client
> 9. the client processes response
> This would avoid a need for piggy-backing on request/response, so it will also eliminate need for response-wrapping (NonWritingResponse).
--
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
12 years, 7 months
[JBoss JIRA] (ARQ-1325) Warp: replace piggy-backing on request/response with direct test->filter communication
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1325?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1325:
----------------------------
Description:
We can do similar processing as we did with CommandService here:
https://github.com/arquillian/arquillian-extension-warp/blob/aa0745237f5d...
The CommandService communicates with the WarpFilter asynchronously and its requests are not processed directly, they delegates to the request-serving routine.
----
This way, Warp could:
0. request is issued against proxy
1. catch the request on the proxy
2. register the RequestPayload (with Inspection) in the registry via the WarpFilter (under generated request-specific UUID)
3. proxy passes request to WarpFilter with a request header which contains UUID
4. WarpFilter associates Inspection from the registry with given request
5. Warp proceeds with a request inspection
6. response is commited and sent back to the proxy (with given UUID as response header)
7. proxy catches the response and obtains ResponsePayload (with Inspection result) from the WarpFilter (using UUID)
8. proxy processes the ResponsePayload and passes the request to the client
9. the client processes response
This would avoid a need for piggy-backing on request/response, so it will also eliminate need for response-wrapping (NonWritingResponse).
> Warp: replace piggy-backing on request/response with direct test->filter communication
> --------------------------------------------------------------------------------------
>
> Key: ARQ-1325
> URL: https://issues.jboss.org/browse/ARQ-1325
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
> Fix For: warp_1.0.0.Beta1
>
>
> We can do similar processing as we did with CommandService here:
> https://github.com/arquillian/arquillian-extension-warp/blob/aa0745237f5d...
> The CommandService communicates with the WarpFilter asynchronously and its requests are not processed directly, they delegates to the request-serving routine.
> ----
> This way, Warp could:
> 0. request is issued against proxy
> 1. catch the request on the proxy
> 2. register the RequestPayload (with Inspection) in the registry via the WarpFilter (under generated request-specific UUID)
> 3. proxy passes request to WarpFilter with a request header which contains UUID
> 4. WarpFilter associates Inspection from the registry with given request
> 5. Warp proceeds with a request inspection
> 6. response is commited and sent back to the proxy (with given UUID as response header)
> 7. proxy catches the response and obtains ResponsePayload (with Inspection result) from the WarpFilter (using UUID)
> 8. proxy processes the ResponsePayload and passes the request to the client
> 9. the client processes response
> This would avoid a need for piggy-backing on request/response, so it will also eliminate need for response-wrapping (NonWritingResponse).
--
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
12 years, 7 months
[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č commented on ARQ-1324:
---------------------------------
One of the solutions might be attaching request payload as multi-part request.
----
But I would opt for eliminating the proxy and piggy-backing on request/response: ARQ-1325
> 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
12 years, 7 months