May 2010 - arquillian-issues - Jboss List Archives

[JBoss JIRA] Created: (ARQ-68) Ability to apply configuration changes to the container

by Pete Muir (JIRA)

Ability to apply configuration changes to the container ------------------------------------------------------- Key: ARQ-68 URL: https://jira.jboss.org/jira/browse/ARQ-68 Project: Arquillian Issue Type: Feature Request Reporter: Pete Muir For example, we might want to adjust something in conf/* in JBoss AS or perhaps add an installed library to the server. Whilst this might not be advisable testing practice, it is sometimes necessary! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

2
6
0 / 0

[JBoss JIRA] Created: (ARQ-125) Prototype "ArquillianContext" Hook between test and the ARQ container

by Andrew Lee Rubinger (JIRA)

Prototype "ArquillianContext" Hook between test and the ARQ container --------------------------------------------------------------------- Key: ARQ-125 URL: https://jira.jboss.org/jira/browse/ARQ-125 Project: Arquillian Issue Type: Feature Request Reporter: Andrew Lee Rubinger Assignee: Andrew Lee Rubinger In many senses, Arquillian provides a component model for testing. While it's capable of providing services like injection, many times it's desirable for a client to get at the ARQ services programatically (as opposed to declaratively as is the case with compile-time metadata like annotations). So we should be able to: @Inject private ArquillianContext context; ...inside of the user test, and use this object to make container-specific requests of the container. These requests should be fielded by the same mechanism used during test enrichment. In fact, introducing this grammar now provides us the proper separation between enrichment (scanning test fields and injecting into them) and resolution (the process of determining the instance to be injected into some target). Taking this a step further we can now build a chain of resolvers which may be together composed; test enrichers would then delegate all resolution logic to the chain (now they're in a hierarchy). Do the prototyping within the OpenEJB container, then extract out and review as necessary. IRC log detailing some discussion: (10:44:36 AM) ALR@Freenode: aslak: Let's start here: http://pastebin.com/WG6YBEM0 (10:45:32 AM) ALR@Freenode: Think of this as you think of EJB's SessionContext (10:45:35 AM) aamonten left the room. (10:45:44 AM) ALR@Freenode: In EJB, bean impls sometimes need to talk to the container. (10:45:51 AM) ALR@Freenode: Here, tests need to talk to the container too. (10:45:56 AM) ALR@Freenode: And the Container is Arquillian. (10:46:12 AM) ALR@Freenode: Which may in turn delegate stuff to a backing container like JBossAS or GlassFish (10:47:02 AM) ALR@Freenode: So very simply we get, for instance an OpenEJB implementation: (10:47:03 AM) ALR@Freenode: http://pastebin.com/izMV5SaM (10:47:36 AM) ALR@Freenode: Here the test enricher, or even the test itself, can get the OpenEJB impl of the Arquillian context. (10:47:48 AM) ALR@Freenode: And this is the thing that resolves requested references. (10:47:56 AM) ALR@Freenode: The test enricher would no longer resolve anything. (10:47:57 AM) balunasj left the room (quit: Client Quit). (10:48:12 AM) ALR@Freenode: Just scan the test class for stuff that needs to be injected. (10:48:14 AM) balunasj [~balunasj@redhat/jboss/balunasj] entered the room. (10:48:28 AM) ALR@Freenode: So we extract the concerns in a typesafe, container-specific way. (10:48:42 AM) aslak: the new core has that 'kind' of context already (10:49:00 AM) ALR@Freenode: Now along comes my test. (10:49:08 AM) ALR@Freenode: aslak: That Context isn't quite it. (10:49:14 AM) aslak: and have plans for building some kind of 'create object' into it as well.. (10:49:17 AM) ALR@Freenode: That's a context for the testrunner (10:50:03 AM) ALR@Freenode: aslak: Usage from the test class is: (10:50:03 AM) ALR@Freenode: http://pastebin.com/kmkwMyX4 (10:50:13 AM) ALR@Freenode: We inject the ArquillianContext (10:50:22 AM) ALR@Freenode: Then the test can request stuff of the container programatically. (10:50:44 AM) ALR@Freenode: And using the same mechanism as done declaratively (==annotations/injection) during test enrichment (10:50:48 AM) ALR@Freenode: But gives the user control. (10:50:59 AM) ALR@Freenode: And can provide some more context to the process. (10:51:09 AM) aslak: sure, but why stop with injecting a context the user can use for lookup (10:51:10 AM) ALR@Freenode: So here I get a good naming context which does auth login. (10:51:34 AM) ALR@Freenode: I stopped because it got to be 3AM. :D (10:51:36 AM) aslak: that kinda goes against the idea of injection.. :) (10:51:49 AM) ALR@Freenode: aslak: It's a complement. (10:51:56 AM) ALR@Freenode: Injection is always preferred. (10:52:02 AM) ALR@Freenode: But you may not know at compile-time. (10:52:05 AM) ALR@Freenode: This is for runtime. (10:52:33 AM) aslak: ALR, if you keep the custom jndi properties out of it for now, this is what the enrichers should do (10:52:42 AM) aslak: that we solve it via the context in the background, sure (10:53:14 AM) ALR@Freenode: I think you're missing the overall goal. (10:53:18 AM) ALR@Freenode: To separate concerns. (10:53:24 AM) ALR@Freenode: And provide a context from test to Arquillian. (10:53:31 AM) ALR@Freenode: jndi.properties isn't a factor. (10:53:44 AM) ALR@Freenode: And also, I need *many* naming contexts with different auth properties. (10:53:53 AM) ALR@Freenode: So something on the ClassPath isn't an answer. (10:54:08 AM) ALR@Freenode: And the enrichers should not be in charge of resolving targets (10:54:16 AM) aslak: no, but the mdb spec us eannotated properties (10:54:17 AM) ALR@Freenode: This is why we commonly have "Resolvers" (10:54:41 AM) ALR@Freenode: Great, we do that too. (10:55:05 AM) ALR@Freenode: @Inject (10:55:05 AM) ALR@Freenode: @ArquillianProps({something,something}) (10:55:05 AM) ALR@Freenode: private Context context; (10:55:11 AM) aslak: yea (10:55:17 AM) ALR@Freenode: And the enricher's job is only: (10:55:22 AM) ALR@Freenode: Parse that shit (10:55:30 AM) ALR@Freenode: And send along to the ArquillianContext impl. (10:55:37 AM) ALR@Freenode: Not resolve anything. (10:55:46 AM) ALR@Freenode: Under that scheme we get to compose enrichers together (10:55:58 AM) ALR@Freenode: Backed by an appropriate ArquillianContext impl specific to each container (10:56:07 AM) aslak: sure sure.. EJBEnricher only find the fields with @EJB, sends the resolve for creation in the context (10:56:08 AM) ALR@Freenode: And the ArqContext can have many resolvers (10:56:18 AM) ALR@Freenode: aslak: Exactly. (10:56:26 AM) ALR@Freenode: Enrichers scan only. (10:56:29 AM) aslak: yea (10:56:37 AM) ALR@Freenode: Which means we can in turn make the enrichers much more generic. (10:56:40 AM) aslak: sounds like a stratigy (10:56:50 AM) ALR@Freenode: Woohoo! (10:57:05 AM) aslak: i still think we can use the existing context tho (10:57:25 AM) ALR@Freenode: Is the existing context container-specific? (10:57:34 AM) aslak: a container would bind it's resolvers in the ClasContext (10:57:34 AM) ALR@Freenode: It has too much support we don't want to give the usre. (10:57:38 AM) ALR@Freenode: fireEvent and such (10:58:01 AM) lightguard_jp [~lightguar(a)166-70-166-98.ip.xmission.com] entered the room. (10:58:04 AM) ALR@Freenode: (ArquillianContext here would go into an Arq API package) (10:58:14 AM) aslak: hmm (10:58:21 AM) ALR@Freenode: Which besides annotations is I think the only Arq API thus far. (10:58:30 AM) aslak: yea (10:58:41 AM) aslak: but why expose it (10:58:46 AM) ALR@Freenode: aslak: To the user? asgeirf__ aslak (10:58:49 AM) aslak: yea (10:58:56 AM) ALR@Freenode: aslak: Just as my last example has (10:59:06 AM) ALR@Freenode: aslak: So we have a hook to ARQ. (10:59:13 AM) ALR@Freenode: And can programatically get stuff. (10:59:20 AM) ALR@Freenode: With runtime properties. (10:59:33 AM) ALR@Freenode: Else we're chained a bit to compile-time stuff. (10:59:46 AM) ALR@Freenode: It's like we say: (11:00:00 AM) ALR@Freenode: Intelligent defaults and simplicity. But option to get under the covers a bit. (11:00:21 AM) ALR@Freenode: We might have other things we later want to add to ArquillianContext too. (11:00:28 AM) aslak: ok, i can relate it to injecting a beanmanager.. :) (11:00:30 AM) ALR@Freenode: Like...accessing the container configuration? (11:01:19 AM) ALR@Freenode: Yes, exactly. SessionContext, BeanManager. (11:01:34 AM) ALR@Freenode: Arquillian is a component model for tests. (11:01:43 AM) ALR@Freenode: As such needs a channel to talk to the host. (11:02:05 AM) ALR@Freenode: And we get to benefit from the design of successful models elsewhere. (11:03:23 AM) aslak: so, we start with a simple Class->Resolver mapper as the ArquillianContext (11:03:40 AM) ALR@Freenode: aslak: Let me hack some things in the OpenEJB impl. (11:03:59 AM) ALR@Freenode: I'm thinking maybe a chain of eligible resolvers. (11:04:03 AM) ALR@Freenode: Under the hood. (11:04:19 AM) aslak: like El (11:04:26 AM) ALR@Freenode: El? (11:04:33 AM) aslak: The EL Factory (11:04:38 AM) ALR@Freenode: Oh right. (11:04:39 AM) aslak: or no tthe factory, the el context (11:04:48 AM) ALR@Freenode: Or anything that needs pluggable resolution :) (11:04:55 AM) aslak: :) (11:05:58 AM) aslak: i'm not sure this should be fully controlled by the container tho. (11:06:16 AM) aslak: the container will add it's set of Resolvers, but it's useful for other places as well (11:07:34 AM) aslak: it should be bound in the normal Context at some level.. (11:07:39 AM) ALR@Freenode: aslak: Anyway let me see what I can throw in place. Then we'll find proper homes for everything. asgeirf__ aslak (11:07:46 AM) aslak: sure (11:07:55 AM) ALR@Freenode: aslak: TBH I think that normal Context needs some work. (11:08:16 AM) ALR@Freenode: The docs issue you know, but it encompasses even management together with an object registry. (11:08:24 AM) ALR@Freenode: And its purpose is for the test runner. (11:08:35 AM) ALR@Freenode: Not for a channel between client and Arquillian (11:09:06 AM) ALR@Freenode: s/even/event (11:09:37 AM) aslak: if you have any good names.. lemme know.. :) (11:10:59 AM) ALR@Freenode: Well, it's a context no doubt. (11:11:16 AM) ALR@Freenode: But more I want to understand its intent. (11:11:39 AM) ALR@Freenode: What does it do, aside from being the object we pass around from enricher to runner? (11:11:58 AM) ALR@Freenode: TestContext (11:11:58 AM) ALR@Freenode: ? (11:12:11 AM) aslak: Session/Class/Test-Context (11:12:51 AM) aslak: it's a chain of context that says something about the life of the obejct bound to it (11:13:00 AM) aslak: s/Session/Suite sorry (11:13:59 AM) aslak: it can store event handlers for specific events, and it can trigger(fire events) those handlers (11:15:12 AM) aslak: it also acts as a 'cumminication' channel between the handlers/enrichers/containers (11:16:36 AM) ALR@Freenode: Yep. (11:16:46 AM) ALR@Freenode: So it's the test "session" (11:17:00 AM) ALR@Freenode: Which starts and ends alongside Suite lifecycle. (11:17:40 AM) aslak: as a scenario.. when @BeforeSuite is triggered, a SuiteContext is build based on a Profile. the ProfileBuilder will register a set of eventhandlers. when th eevent comes in to the session context, it will trigger the handlers, ie the DeployableContianer creator. the creator will then bind the DeployableContainer back to the context (11:19:01 AM) aslak: then when @BeforeClass is triggered, a ClassContext with a ref to the parent SuiteContext is built and fired all the BeforeClass handlers.. one of which is the deployer which will get the DeployableContainer bound by the creator (11:19:53 AM) aslak: session in a sens sure (11:21:14 AM) ALR@Freenode: Yep. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
6
0 / 0

[JBoss JIRA] Created: (ARQ-30) @Deployment should have some intelligent defaults

by Aslak (JIRA)

@Deployment should have some intelligent defaults ------------------------------------------------- Key: ARQ-30 URL: https://jira.jboss.org/jira/browse/ARQ-30 Project: Arquillian Issue Type: Task Reporter: Aslak The API @Deployment should have some smart auto packaging options to help package the test - Add The TestCase itself - Add the TestCase package recursively - Add Resources in TestCase package ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

3
11
0 / 0

[JBoss JIRA] Created: (ARQ-109) RunMode Local should support TestEnrichment

by Aslak Knutsen (JIRA)

RunMode Local should support TestEnrichment ------------------------------------------- Key: ARQ-109 URL: https://jira.jboss.org/jira/browse/ARQ-109 Project: Arquillian Issue Type: Task Components: Runtime Enricher SPI Reporter: Aslak Knutsen Currently when in RunMode local no enrichment is done. We can still enrich: @Resources for remote exposed object @EJB with Remote interface -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 8 months

1
3
0 / 0

[JBoss JIRA] Created: (ARQ-55) TestNG @Test(dependsOnMethods="") does not work when running inside the container

by Aslak Knutsen (JIRA)

TestNG @Test(dependsOnMethods="") does not work when running inside the container --------------------------------------------------------------------------------- Key: ARQ-55 URL: https://jira.jboss.org/jira/browse/ARQ-55 Project: Arquillian Issue Type: Bug Components: TestNG Reporter: Aslak Knutsen "methodX is not allowed to depend on methodY" The way Arquillian invokes the remote container it creates a new 'suite' pr TestCase pr test method. Since only one test method is invoked pr suite, TestNGs dependsOnMethods fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
3
0 / 0

[JBoss JIRA] Created: (ARQ-124) Move jndi.properties out as Configuration

by Aslak Knutsen (JIRA)

Move jndi.properties out as Configuration ----------------------------------------- Key: ARQ-124 URL: https://jira.jboss.org/jira/browse/ARQ-124 Project: Arquillian Issue Type: Task Components: Configuration, Documentation Affects Versions: 1.0.0.Alpha1, 1.0.0.Alpha2 Reporter: Aslak Knutsen When using multiple containers in the same project they might require different jndi.properties files. Since jndi.properties are sucked in by the InitialContext automagically, multiple resource folders has to be used to control which jndi.properties file is the active. Remove the need for jndi.properties by extending the Configuration module to support jndi properties pr container. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
6
0 / 0

[JBoss JIRA] Created: (ARQ-153) Protocol configuration element should be separate from Container

by Aslak Knutsen (JIRA)

Protocol configuration element should be separate from Container ---------------------------------------------------------------- Key: ARQ-153 URL: https://jira.jboss.org/browse/ARQ-153 Project: Arquillian Issue Type: Feature Request Components: Configuration Affects Versions: 1.0.0.Alpha2 Reporter: Aslak Knutsen A Contianer should be able to run with any of the support Protocols for communication with TestCase running inside the container. This needs to be configurable in a common way. Currently Servlet Protocol configuration is stuck in the specific Containers who use it, this needs to be extracted. e.g. {code:XML} <arquillian xmlns="http://jboss.com/arquillian" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jboss="urn:arq:org.jboss.arquillian.jbossas.remote60" xmlns:servlet="urn:arq:org.jboss.arquillian.protocol.servlet" xmlns:jmx="urn:arq:org.jboss.arquillian.protocol.jmx" xmlns:jndi="urn:arq:org.jboss.arquillian.jndi"> <jboss:container id="jbossTest"> <localDeploymentBindAddress>my.domain</localDeploymentBindAddress> <servlet:protocol> <remoteServerAddress>remote.server</remoteServerAddress> <remoteServerHttpPort>8181</remoteServerHttpPort> </servlet:protocol> <jndi:protocol>  <javaNamingProviderUrl>jnp://remote.server:1099</javaNamingProviderUrl> <javaNamingFactoryInitial>org.jnp.interfaces.NamingContextFactory</javaNamingFactoryInitial> <javaNamingFactoryUrlPkgs>org.jboss.naming\:org.jnp.interfaces</javaNamingFactoryUrlPkgs> </jndi:protocol> </jboss:container> <jboss:container id="jbossStage"> <localDeploymentBindAddress>my.domain</localDeploymentBindAddress> <jmx:protocol> <serviceUrl>service:jmx:rmi:///jndi/rmi://localhost:1099/</serviceUrl> </jmx:protocol> <jndi:protocol> <javaNamingProviderUrl>jnp://remote.server:1099</javaNamingProviderUrl> <javaNamingFactoryInitial>org.jnp.interfaces.NamingContextFactory</javaNamingFactoryInitial> <javaNamingFactoryUrlPkgs>org.jboss.naming\:org.jnp.interfaces</javaNamingFactoryUrlPkgs> </jndi:protocol> </jboss:container> </arquillian> {code} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

3
10
0 / 0

[JBoss JIRA] Created: (ARQ-110) RunMode Local should reuse protocol-local

by Aslak Knutsen (JIRA)

RunMode Local should reuse protocol-local ----------------------------------------- Key: ARQ-110 URL: https://jira.jboss.org/jira/browse/ARQ-110 Project: Arquillian Issue Type: Task Reporter: Aslak Knutsen Currently the RunMode Local handler has it's own v. of the LocalMethodExecutor. The same code should be shared between the standalone containers(weld, openwebbeans, openejb...) options: - remove protocol-local and replace it with a class in impl? - remove protocol-local and replace it with a class in spi? - make impl depend on protocol-local ? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
6
0 / 0

[JBoss JIRA] Created: (ARQ-158) Replace method arguments with toString instead of Class

by Aslak Knutsen (JIRA)

Replace method arguments with toString instead of Class ------------------------------------------------------- Key: ARQ-158 URL: https://jira.jboss.org/browse/ARQ-158 Project: Arquillian Issue Type: Feature Request Components: Test Harness Integration Affects Versions: 1.0.0.Alpha2 Reporter: Aslak Knutsen When using Argument injection in TestNG, TestNG tries to write out the values as part of the Report after all contexts are closed. In Alpha-2 we replace all arguments with Class after the test is executed. Replace the arguments with toString instead, this way the user can control what is written. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

1
5
0 / 0

[JBoss JIRA] Created: (ARQ-152) Support multiple container configurations for same container type

by Aslak Knutsen (JIRA)

Support multiple container configurations for same container type ----------------------------------------------------------------- Key: ARQ-152 URL: https://jira.jboss.org/browse/ARQ-152 Project: Arquillian Issue Type: Feature Request Components: Configuration Reporter: Aslak Knutsen Configuration need to support multiple container configurations for the same container type with a runtime 'flag' for switching configuration. UseCase: Different configuration for test/stage servers. e.g. {code:XML} <arquillian xmlns="http://jboss.com/arquillian" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:jboss="urn:arq:org.jboss.arquillian.jbossas.remote60"> <jboss:container id="jbossTest"> <localDeploymentBindAddress>my.domain</localDeploymentBindAddress> <remoteServerAddress>remote.test.server</remoteServerAddress> <remoteServerHttpPort>8080</remoteServerHttpPort> </jboss:container> <jboss:container id="jbossStage"> <localDeploymentBindAddress>my.domain</localDeploymentBindAddress> <remoteServerAddress>remote.stage.server</remoteServerAddress> <remoteServerHttpPort>8181</remoteServerHttpPort> </jboss:container> </arquillian> {code} -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 years, 10 months

2
6
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues May 2010