October 2010 - arquillian-issues - Jboss List Archives

[JBoss JIRA] Created: (ARQ-66) provide a mechanism for adding library JARs (test dependencies) to the deployment

by Dan Allen (JIRA)

provide a mechanism for adding library JARs (test dependencies) to the deployment --------------------------------------------------------------------------------- Key: ARQ-66 URL: https://jira.jboss.org/jira/browse/ARQ-66 Project: Arquillian Issue Type: Feature Request Components: Core Reporter: Dan Allen Assignee: Pete Muir Fix For: 1.0.0-alpha-1 The requirement to add extra JARs into the deployment is going to surface fairly early on in the adoption of Arquillian. In our examples, we are sticking to APIs in Java EE, but most projects have third-party JARs on which the application depends. Common examples are a logging framework, Apache Commons libraries, Google Collections, Hibernate Search...anything not available in the container. We might need to update the @Deployment signature to support: @Deployment static Set<Archive<?>> x(); Or maybe a seperate @DeploymentDependencies (this could be defined in e.g. a super class) @DeploymentDependencies static Set<Archive<?>> x() We are also going to need to consider providing APIs for resolving Maven dependencies (groupId, artifactId, version) or resolving test dependencies from the Maven pom. We need to be flexible. -- 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

3
10
0 / 0

[JBoss JIRA] Created: (ARQ-244) Create a DeployableContainer integration for Google App Engine

by Aslak Knutsen (JIRA)

Create a DeployableContainer integration for Google App Engine -------------------------------------------------------------- Key: ARQ-244 URL: https://jira.jboss.org/browse/ARQ-244 Project: Arquillian Issue Type: Feature Request Components: GAE Containers Reporter: Aslak Knutsen Assignee: Ales Justin Priority: Optional Fix For: 1.0.0.Beta1 Arquillian should support start/stop/deploy and undeploy to a Google App Engine container. -- 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

2
2
0 / 0

[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

2
6
0 / 0

[JBoss JIRA] Created: (ARQ-280) Weld SE should support 'deploy full classpath' in Configuration

by Aslak Knutsen (JIRA)

Weld SE should support 'deploy full classpath' in Configuration --------------------------------------------------------------- Key: ARQ-280 URL: https://jira.jboss.org/browse/ARQ-280 Project: Arquillian Issue Type: Feature Request Components: Weld Containers Reporter: Aslak Knutsen Fix For: 1.0.0.CR1 So behave like Weld SE, the Weld SE container should have a configurable option to deploy full classpath like Weld SE does. -- 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

1
2
0 / 0

[JBoss JIRA] Created: (ARQ-311) Add runtime ConfigurationException for use in DeployableContainer#setup()

by Dan Allen (JIRA)

Add runtime ConfigurationException for use in DeployableContainer#setup() ------------------------------------------------------------------------- Key: ARQ-311 URL: https://jira.jboss.org/browse/ARQ-311 Project: Arquillian Issue Type: Feature Request Components: Deployable Containers SPI Affects Versions: 1.0.0.Alpha4 Reporter: Dan Allen Priority: Minor When setting up a container, the routine may determine that setup cannot be completed successfully. Provide a ConfigurationException that indicates, with proper semantics, that the container cannot be setup. -- 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

3
7
0 / 0

[JBoss JIRA] Created: (ARQ-325) Create build job to publish nightly snapshot of docs

by Dan Allen (JIRA)

Create build job to publish nightly snapshot of docs ---------------------------------------------------- Key: ARQ-325 URL: https://jira.jboss.org/browse/ARQ-325 Project: Arquillian Issue Type: Feature Request Components: Build Infrastructure Affects Versions: 1.0.0.Alpha4 Reporter: Dan Allen Assignee: Dan Allen Priority: Minor Fix For: 1.0.0.Beta1 Create a Hudson build job to publish a snapshot of the reference guide and API docs to docs.jboss.org/arquillian -- 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

2
2
0 / 0

[JBoss JIRA] Created: (ARQ-285) integrate arquillian with compute clouds

by Adrian Cole (JIRA)

integrate arquillian with compute clouds ---------------------------------------- Key: ARQ-285 URL: https://jira.jboss.org/browse/ARQ-285 Project: Arquillian Issue Type: Feature Request Reporter: Adrian Cole It would be useful to integrate arquillian with compute cloud provisioning apis such as EC2 and Rackspace. In doing so, one can test on a specific set of operating systems, larger and smaller sizes, and also ensure they know how to build the configuration from scratch. One implementation idea: BeforeStart = Run Node with Start Server Shell command AfterStop = Destroy Node jclouds could provide the mechanism to run/destroy/query independent of cloud provider -- 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

2
5
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

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

3
11
0 / 0

[JBoss JIRA] Created: (ARQ-225) Add support for performance regression on test methods

by St?le Pedersen (JIRA)

Add support for performance regression on test methods ------------------------------------------------------- Key: ARQ-225 URL: https://jira.jboss.org/browse/ARQ-225 Project: Arquillian Issue Type: Feature Request Components: Extension - Performance Reporter: St?le Pedersen Assignee: St?le Pedersen Fix For: 1.0.0.Alpha4 -- 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

2
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues October 2010