July 2010 - arquillian-issues - Jboss List Archives

[JBoss JIRA] Created: (ARQ-26) Create a archive repository service for containers not supporting ShrinkWrap directly

by Aslak (JIRA)

Create a archive repository service for containers not supporting ShrinkWrap directly ------------------------------------------------------------------------------------- Key: ARQ-26 URL: https://jira.jboss.org/jira/browse/ARQ-26 Project: Arquillian Issue Type: Task Reporter: Aslak Not all containers will support ShrinkWrap directly. Create a 'Service' or Abstract Deployable Container class to handle Archive<?> to URL mappings. ie, Remote Jboss instances need a http url to deploy. -- 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, 7 months

3
6
0 / 0

[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, 7 months

3
10
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, 7 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, 7 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, 7 months

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, 7 months

2
2
0 / 0

[JBoss JIRA] Created: (ARQ-177) create a Maven archetype for Arquillian (JUnit)

by Dan Allen (JIRA)

create a Maven archetype for Arquillian (JUnit) ----------------------------------------------- Key: ARQ-177 URL: https://jira.jboss.org/browse/ARQ-177 Project: Arquillian Issue Type: Feature Request Components: Build Infrastructure, Examples Affects Versions: 1.0.0.Alpha2 Reporter: Dan Allen Fix For: 1.0.0.Alpha3 Create a Maven archetype that makes it simple for users to get started with Arquillian (JUnit). The archetype should have profiles for various containers and some samples to demonstrate to the user that the setup works. We can then add a page to the Arquillian site that shows users how to use the archetype to get started. -- 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, 7 months

2
5
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-199) Add support to controll multiple framework instances

by Thomas Diesler (JIRA)

Add support to controll multiple framework instances ---------------------------------------------------- Key: ARQ-199 URL: https://jira.jboss.org/browse/ARQ-199 Project: Arquillian Issue Type: Feature Request Components: OSGi Containers Reporter: Thomas Diesler It would also be nice if it could support controlling multiple framework instances. As mentioned before, an OSGi Framework can be controlled using a standard interface: org.osgi.framework.launch.Framework extends Bundle. In some test scenarios (especially ones involving Distributed OSGi) you'd want to bring up multiple frameworks and run tests bundles in both of them. The unit test would then essentially orchestrate the whole thing and make assertions on behaviour in these two frameworks which can be obtained through the bundle context of either. -- 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, 8 months

2
5
0 / 0

[JBoss JIRA] Created: (ARQ-190) Remote OSGi bundle testing

by Thomas Diesler (JIRA)

Remote OSGi bundle testing -------------------------- Key: ARQ-190 URL: https://jira.jboss.org/browse/ARQ-190 Project: Arquillian Issue Type: Task Components: OSGi Integration Reporter: Thomas Diesler Assignee: Thomas Diesler Fix For: 1.0.0.Alpha3 Add remoteness to the jmx protocoll -- 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, 8 months

2
12
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

arquillian-issues July 2010