[arquillian-issues] [JBoss JIRA] Updated: (ARQ-125) Prototype "ArquillianContext" Hook between test and the ARQ container
Aslak Knutsen (JIRA)
jira-events at lists.jboss.org
Mon May 9 08:20:23 EDT 2011
[ https://issues.jboss.org/browse/ARQ-125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Aslak Knutsen updated ARQ-125:
------------------------------
Fix Version/s: 1.1.0.CR1
(was: 1.0.0.Beta1)
> Prototype "ArquillianContext" Hook between test and the ARQ container
> ---------------------------------------------------------------------
>
> Key: ARQ-125
> URL: https://issues.jboss.org/browse/ARQ-125
> Project: Arquillian
> Issue Type: Feature Request
> Reporter: Andrew Rubinger
> Assignee: Andrew Rubinger
> Fix For: 1.1.0.CR1
>
>
> 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. This is in many ways analagous to:
> @Resource private SessionContext context;
> ...within EJB, where a bean instance gets a hook to 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 at Freenode: aslak: Let's start here: http://pastebin.com/WG6YBEM0
> (10:45:32 AM) ALR at Freenode: Think of this as you think of EJB's SessionContext
> (10:45:35 AM) aamonten left the room.
> (10:45:44 AM) ALR at Freenode: In EJB, bean impls sometimes need to talk to the container.
> (10:45:51 AM) ALR at Freenode: Here, tests need to talk to the container too.
> (10:45:56 AM) ALR at Freenode: And the Container is Arquillian.
> (10:46:12 AM) ALR at Freenode: Which may in turn delegate stuff to a backing container like JBossAS or GlassFish
> (10:47:02 AM) ALR at Freenode: So very simply we get, for instance an OpenEJB implementation:
> (10:47:03 AM) ALR at Freenode: http://pastebin.com/izMV5SaM
> (10:47:36 AM) ALR at Freenode: Here the test enricher, or even the test itself, can get the OpenEJB impl of the Arquillian context.
> (10:47:48 AM) ALR at Freenode: And this is the thing that resolves requested references.
> (10:47:56 AM) ALR at 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 at Freenode: Just scan the test class for stuff that needs to be injected.
> (10:48:14 AM) balunasj [~balunasj at redhat/jboss/balunasj] entered the room.
> (10:48:28 AM) ALR at 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 at Freenode: Now along comes my test.
> (10:49:08 AM) ALR at 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 at Freenode: That's a context for the testrunner
> (10:50:03 AM) ALR at Freenode: aslak: Usage from the test class is:
> (10:50:03 AM) ALR at Freenode: http://pastebin.com/kmkwMyX4
> (10:50:13 AM) ALR at Freenode: We inject the ArquillianContext
> (10:50:22 AM) ALR at Freenode: Then the test can request stuff of the container programatically.
> (10:50:44 AM) ALR at Freenode: And using the same mechanism as done declaratively (==annotations/injection) during test enrichment
> (10:50:48 AM) ALR at Freenode: But gives the user control.
> (10:50:59 AM) ALR at 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 at Freenode: So here I get a good naming context which does auth login.
> (10:51:34 AM) ALR at 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 at Freenode: aslak: It's a complement.
> (10:51:56 AM) ALR at Freenode: Injection is always preferred.
> (10:52:02 AM) ALR at Freenode: But you may not know at compile-time.
> (10:52:05 AM) ALR at 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 at Freenode: I think you're missing the overall goal.
> (10:53:18 AM) ALR at Freenode: To separate concerns.
> (10:53:24 AM) ALR at Freenode: And provide a context from test to Arquillian.
> (10:53:31 AM) ALR at Freenode: jndi.properties isn't a factor.
> (10:53:44 AM) ALR at Freenode: And also, I need *many* naming contexts with different auth properties.
> (10:53:53 AM) ALR at Freenode: So something on the ClassPath isn't an answer.
> (10:54:08 AM) ALR at 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 at Freenode: This is why we commonly have "Resolvers"
> (10:54:41 AM) ALR at Freenode: Great, we do that too.
> (10:55:05 AM) ALR at Freenode: @Inject
> (10:55:05 AM) ALR at Freenode: @ArquillianProps({something,something})
> (10:55:05 AM) ALR at Freenode: private Context context;
> (10:55:11 AM) aslak: yea
> (10:55:17 AM) ALR at Freenode: And the enricher's job is only:
> (10:55:22 AM) ALR at Freenode: Parse that shit
> (10:55:30 AM) ALR at Freenode: And send along to the ArquillianContext impl.
> (10:55:37 AM) ALR at Freenode: Not resolve anything.
> (10:55:46 AM) ALR at Freenode: Under that scheme we get to compose enrichers together
> (10:55:58 AM) ALR at 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 at Freenode: And the ArqContext can have many resolvers
> (10:56:18 AM) ALR at Freenode: aslak: Exactly.
> (10:56:26 AM) ALR at Freenode: Enrichers scan only.
> (10:56:29 AM) aslak: yea
> (10:56:37 AM) ALR at 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 at Freenode: Woohoo!
> (10:57:05 AM) aslak: i still think we can use the existing context tho
> (10:57:25 AM) ALR at 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 at Freenode: It has too much support we don't want to give the usre.
> (10:57:38 AM) ALR at Freenode: fireEvent and such
> (10:58:01 AM) lightguard_jp [~lightguar at 166-70-166-98.ip.xmission.com] entered the room.
> (10:58:04 AM) ALR at Freenode: (ArquillianContext here would go into an Arq API package)
> (10:58:14 AM) aslak: hmm
> (10:58:21 AM) ALR at 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 at Freenode: aslak: To the user?
> asgeirf__ aslak
> (10:58:49 AM) aslak: yea
> (10:58:56 AM) ALR at Freenode: aslak: Just as my last example has
> (10:59:06 AM) ALR at Freenode: aslak: So we have a hook to ARQ.
> (10:59:13 AM) ALR at Freenode: And can programatically get stuff.
> (10:59:20 AM) ALR at Freenode: With runtime properties.
> (10:59:33 AM) ALR at Freenode: Else we're chained a bit to compile-time stuff.
> (10:59:46 AM) ALR at Freenode: It's like we say:
> (11:00:00 AM) ALR at Freenode: Intelligent defaults and simplicity. But option to get under the covers a bit.
> (11:00:21 AM) ALR at 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 at Freenode: Like...accessing the container configuration?
> (11:01:19 AM) ALR at Freenode: Yes, exactly. SessionContext, BeanManager.
> (11:01:34 AM) ALR at Freenode: Arquillian is a component model for tests.
> (11:01:43 AM) ALR at Freenode: As such needs a channel to talk to the host.
> (11:02:05 AM) ALR at 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 at Freenode: aslak: Let me hack some things in the OpenEJB impl.
> (11:03:59 AM) ALR at Freenode: I'm thinking maybe a chain of eligible resolvers.
> (11:04:03 AM) ALR at Freenode: Under the hood.
> (11:04:19 AM) aslak: like El
> (11:04:26 AM) ALR at Freenode: El?
> (11:04:33 AM) aslak: The EL Factory
> (11:04:38 AM) ALR at Freenode: Oh right.
> (11:04:39 AM) aslak: or no tthe factory, the el context
> (11:04:48 AM) ALR at 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 at 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 at Freenode: aslak: TBH I think that normal Context needs some work.
> (11:08:16 AM) ALR at Freenode: The docs issue you know, but it encompasses even management together with an object registry.
> (11:08:24 AM) ALR at Freenode: And its purpose is for the test runner.
> (11:08:35 AM) ALR at Freenode: Not for a channel between client and Arquillian
> (11:09:06 AM) ALR at Freenode: s/even/event
> (11:09:37 AM) aslak: if you have any good names.. lemme know.. :)
> (11:10:59 AM) ALR at Freenode: Well, it's a context no doubt.
> (11:11:16 AM) ALR at Freenode: But more I want to understand its intent.
> (11:11:39 AM) ALR at Freenode: What does it do, aside from being the object we pass around from enricher to runner?
> (11:11:58 AM) ALR at Freenode: TestContext
> (11:11:58 AM) ALR at 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 at Freenode: Yep.
> (11:16:46 AM) ALR at Freenode: So it's the test "session"
> (11:17:00 AM) ALR at 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 at Freenode: Yep.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the arquillian-issues
mailing list