[JBoss JIRA] (ARQ-1290) Warp: support Servlets 2.5
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1290?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč resolved ARQ-1290.
-----------------------------
Assignee: Lukáš Fryč
Fix Version/s: (was: warp_1.0.0.Beta1)
Resolution: Duplicate Issue
> Warp: support Servlets 2.5
> --------------------------
>
> Key: ARQ-1290
> URL: https://issues.jboss.org/browse/ARQ-1290
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha2
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
>
> Warp currently uses {{@WebFilter}} and thus it is supported only when using Servlets 3.0 protocol.
> Additionally with ARQ-1027, the usage of {{web-fragment.xml}} was introduced.
> Warp should detect what protocol is used (2.5 or 3.0) and in case of 2.5, the {{web.xml}} enrichment will be used instead.
--
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-1286) Support Warp on Java EE 5 (Servlets 2.5) compliant containers
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1286?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on ARQ-1286:
---------------------------------
Warp currently uses {{@WebFilter}} and thus it is supported only when using Servlets 3.0 protocol.
Additionally with ARQ-1027, the usage of {{web-fragment.xml}} was introduced.
Warp should detect what protocol is used (2.5 or 3.0) and in case of 2.5, the {{web.xml}} enrichment will be used instead.
> Support Warp on Java EE 5 (Servlets 2.5) compliant containers
> -------------------------------------------------------------
>
> Key: ARQ-1286
> URL: https://issues.jboss.org/browse/ARQ-1286
> 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
>
>
> Warp is currently focused on Java EE 6 and higher, since it uses {{@WebFilter}} annotation to intercept incoming requests.
> We may decide to support Servlets 2.5 containers as well in case there is enough interest (please vote if you are interested).
--
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-1291) Warp: single request execution does enrich only first request
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1291?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1291:
----------------------------
Priority: Blocker (was: Major)
> Warp: single request execution does enrich only first request
> -------------------------------------------------------------
>
> Key: ARQ-1291
> URL: https://issues.jboss.org/browse/ARQ-1291
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha2
> Reporter: Lukáš Fryč
> Priority: Blocker
>
> When single-request execution API is used
> {code}
> Warp.initiate(Activity)
> .inspect(Inspection);
> {code}
> then the default filter is applied which says that only first request can be enriched,
> and thus when user-provided filter selects second or further request, nothing will be enriched.
> In fact it should work in the way that first user-selected request is enriched.
--
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-1291) Warp: single request execution does enrich only first request
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1291?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč updated ARQ-1291:
----------------------------
Fix Version/s: warp_1.0.0.Beta1
> Warp: single request execution does enrich only first request
> -------------------------------------------------------------
>
> Key: ARQ-1291
> URL: https://issues.jboss.org/browse/ARQ-1291
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha2
> Reporter: Lukáš Fryč
> Priority: Blocker
> Fix For: warp_1.0.0.Beta1
>
>
> When single-request execution API is used
> {code}
> Warp.initiate(Activity)
> .inspect(Inspection);
> {code}
> then the default filter is applied which says that only first request can be enriched,
> and thus when user-provided filter selects second or further request, nothing will be enriched.
> In fact it should work in the way that first user-selected request is enriched.
--
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-1303) Add Spring StaticApplicationContext
by omid pourhadi (JIRA)
[ https://issues.jboss.org/browse/ARQ-1303?page=com.atlassian.jira.plugin.s... ]
omid pourhadi commented on ARQ-1303:
------------------------------------
You don't need to lookup the bean, we can provide a feature to autowire beans in a test class by using reflection. please take a look at AbstractSpringInjectionEnricher.java registerBean method. in my point of view, it might be better to keep away the developer from complexity of creating spring context and let Arquillian take care of it so having a prepared context and controlling it by annotation is more convenient than creating it.
second approach sounds cool but you only will be able to use it in Spring 3.x and it does not work with static application context.
another problem that thanks to Arquillian it is solved now is to use your test context in server. it is really cumbersome specially if you are using Grizzly (jersey) but it is not our concern in this case.
WDYT ?
> Add Spring StaticApplicationContext
> -----------------------------------
>
> Key: ARQ-1303
> URL: https://issues.jboss.org/browse/ARQ-1303
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Spring
> Reporter: omid pourhadi
> Assignee: Marius Bogoevici
> Priority: Minor
> Original Estimate: 1 week, 1 day
> Remaining Estimate: 1 week, 1 day
>
> It is a common way that developers programmatically register beans into context specially in testing rather than reading bean definitions from external configuration sources, in this case, you need to use StaticApplicationContext.
> As far as my experience concerned, there are some circumstances that you need to have populated context when you are testing
> 1. for registering mock objects into context
> let's assume we inject a DAO into a service and we want to mock DAO then test our service
> {code:title=Bar.java|borderStyle=solid}
> public class MockTest(){
> @Mock
> Dao dao;
> public void testMethod(){
> ctx.getBeanFactory().registerSingleton(dao.getClass().getName(), dao);
> }
> }
> {code}
> 2. for specifying classes not packages
> sometimes you need to create a spring context by only some specific classes from different packages not the whole packages.
> It might be good idea to have an annotation ClassToScan({}) to define whcih classes, you want to scan
--
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-1303) Add Spring StaticApplicationContext
by Jakub Narloch (JIRA)
[ https://issues.jboss.org/browse/ARQ-1303?page=com.atlassian.jira.plugin.s... ]
Jakub Narloch commented on ARQ-1303:
------------------------------------
Does this make sense?
> Add Spring StaticApplicationContext
> -----------------------------------
>
> Key: ARQ-1303
> URL: https://issues.jboss.org/browse/ARQ-1303
> Project: Arquillian
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Extension - Spring
> Reporter: omid pourhadi
> Assignee: Marius Bogoevici
> Priority: Minor
> Original Estimate: 1 week, 1 day
> Remaining Estimate: 1 week, 1 day
>
> It is a common way that developers programmatically register beans into context specially in testing rather than reading bean definitions from external configuration sources, in this case, you need to use StaticApplicationContext.
> As far as my experience concerned, there are some circumstances that you need to have populated context when you are testing
> 1. for registering mock objects into context
> let's assume we inject a DAO into a service and we want to mock DAO then test our service
> {code:title=Bar.java|borderStyle=solid}
> public class MockTest(){
> @Mock
> Dao dao;
> public void testMethod(){
> ctx.getBeanFactory().registerSingleton(dao.getClass().getName(), dao);
> }
> }
> {code}
> 2. for specifying classes not packages
> sometimes you need to create a spring context by only some specific classes from different packages not the whole packages.
> It might be good idea to have an annotation ClassToScan({}) to define whcih classes, you want to scan
--
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