(02:20:53 PM) ***aslak checking were we left off
(02:21:33 PM) aslak: ALR, you wanna do the introduction..
(02:21:55 PM) ALR@Freenode: aslak: I think you should drive this.
(02:22:04 PM) ALR@Freenode: aslak: I'm a bit behind on Arquillian
(02:22:45 PM) aslak: i guess we start where we started last time
(02:22:52 PM) aslak: (02:05:44 PM) ALR@Freenode: OK, welcome all to round two of the Arquillian Design Kickoff
(02:22:52 PM) aslak: (02:05:53 PM) ALR@Freenode: Last meeting's notes can be found:
(02:22:54 PM) aslak: http://community.jboss.org/wiki/ArquillianMeetingLog20100218
(02:23:02 PM) aslak: (02:06:38 PM) ALR@Freenode: We left off on the topic of the User Configuration API
(02:23:02 PM) aslak: (02:07:01 PM) ALR@Freenode: A way for declarative container-specific properties to be passed along.
(02:23:07 PM) aslak: two/tree
(02:23:18 PM) aslak: hehe
(02:23:21 PM) ALR@Freenode: Haha
(02:23:32 PM) ALR@Freenode: I'm a visionary ahead of my time.
(02:23:56 PM) aslak:
(02:24:49 PM) aslak: so basically, we need to be able to configure the whole shebang
(02:25:01 PM) ALR@Freenode: Yep.
(02:25:23 PM) ALR@Freenode: I point to the way MDBs are configured as an analogy
(02:25:25 PM) aslak: we have arquillian core config, container config
(02:25:37 PM) ALR@Freenode: Because MDBs are listeners, coming in from any JCA-compliant resource adaptor
(02:25:45 PM) ALR@Freenode: You need to be able to configure the adaptor.
(02:25:49 PM) ALR@Freenode: This is similar
(02:26:03 PM) ALR@Freenode: Arquillian is JCA in this case
(02:26:08 PM) ALR@Freenode: And the Containers are the adaptors
(02:26:31 PM) ALR@Freenode: It's activation config properties (String/String) name/value pairs in the MDB case.
(02:26:50 PM) ALR@Freenode: So a question I have is: can we do something more typesafe, with a configuration object per container?
(02:26:54 PM) ALR@Freenode: Or stick w/ props?
(02:27:31 PM) aslak: we can at least make it type safe on the reader side
(02:27:33 PM) germanescobar: I would like something more typesafe ... at least for the general configuration
(02:28:51 PM) aslak: ALR, but where do you propose we put the mdb style attributes ?
(02:29:08 PM) aslak: pr testcase ?
(02:29:14 PM) ALR@Freenode: aslak: I think it'd go on the class, yeah.
(02:29:22 PM) ALR@Freenode: Alongside where we say "Use Container X"
(02:30:26 PM) aslak: yea, it's at a level that doesn't really make much sense to me.. you have one test case wanting contianer x and another container y and a third container x with port n
(02:31:06 PM) ALR@Freenode: You mean on the class it doesn't make sense to you?
(02:31:16 PM) aslak: yea
(02:31:27 PM) germanescobar: aslak, at testsuite level?
(02:31:33 PM) aslak: germanescobar, yea
(02:31:39 PM) pmuir [~pmuir@redhat/jboss/pmuir] entered the room.
(02:31:47 PM) ALR@Freenode: TestSuite == Class in JUnit by default
(02:31:49 PM) aslak: ALR, a test class could have some config.. ie like needsRestart
(02:32:09 PM) aslak: heya pmuir
(02:32:19 PM) pmuir: hey
(02:32:31 PM) aslak: but i don't like the idea of hardcoding the container to the testcase
(02:33:05 PM) aslak: it defetes some of the point with 'standalone/embedded' containers vs full etc
(02:33:20 PM) aslak: defeats
(02:33:46 PM) ALR@Freenode: aslak: That's where inheritance comes in IMO
(02:33:51 PM) ALR@Freenode: Base test class with all the logic
(02:33:56 PM) ALR@Freenode: And extensions per container
(02:34:18 PM) ALR@Freenode: It's how I do it in EJB3 for example. Rarely am I annotating/hardcoding stuff alongside the logic.
(02:34:19 PM) aslak: ? you can run the same test in multiple containers
(02:34:22 PM) pmuir: ALR: seems a bit heavy
(02:34:33 PM) germanescobar: aslak, but most of the time you will be configuring hostname and port for a specific container
(02:34:40 PM) ALR@Freenode: It's just the age-old question: What's configuration, and what's wiring?
(02:34:57 PM) ALR@Freenode: I think 80% of the time at least, folks will have a specific target container in mind.
(02:35:02 PM) lightguard_jp: aslak, ALR, I'm here, we had an interview we were doing.
(02:35:03 PM) ALR@Freenode: If they don't, there's inheritance
(02:35:19 PM) ALR@Freenode: Definitely open to other suggestions.
(02:35:27 PM) ALR@Freenode: These just jump out at me first.
(02:35:44 PM) pmuir: ALR: we need a way to configure this outside of Java code
(02:36:12 PM) ALR@Freenode: I like Java. So fast for prototyping, less switching.
(02:37:52 PM) pmuir: ALR: so do I
(02:38:08 PM) pmuir: but we have a concrete use case with the CDI TCK where we need to switch it without any Java codd
(02:38:10 PM) pmuir: e
(02:38:18 PM) ALR@Freenode: OKee.
(02:38:21 PM) pmuir: we also need that for the Seam test suite
(02:38:30 PM) ALR@Freenode: How do overrides sit with you?
(02:38:30 PM) aslak: pmuir, what's the use case?
(02:38:52 PM) pmuir: aslak: use the TCK with multiple containers
(02:38:56 PM) aslak: pmuir, never mind.. diff containers running the test
(02:38:57 PM) pmuir: how do you mean overrides?
(02:38:59 PM) aslak: hehe right..
(02:39:13 PM) ALR@Freenode: non-Java config overrides annotations.
(02:39:17 PM) ALR@Freenode: Basically the EJB3 model
(02:39:22 PM) ALR@Freenode: Partial XML descriptors and such.
(02:39:46 PM) aslak: i'm not sure about the idea of switching contianers midd run
(02:39:56 PM) ALR@Freenode: Mid run?
(02:40:01 PM) lightguard_jp: I think that's probably the most standard approach (annotations w/ xml override).
(02:40:05 PM) ALR@Freenode: I thought this was just so the TCK could be used for all implementors
(02:40:19 PM) ALR@Freenode: So the vendor configures stuff in their porting layer
(02:40:23 PM) pmuir: ALR: never really liked that style of XML config
(02:40:24 PM) aslak: ALR, yea, with config pr test case
(02:40:28 PM) pmuir: it's seems fugly to me
(02:40:40 PM) ALR@Freenode: Again, open to ideas.
(02:40:44 PM) lightguard_jp: If we have to switch mid run, things get complicated
(02:41:02 PM) aslak: complicated and we run out of memory real wick
(02:41:07 PM) aslak: wuick
(02:41:09 PM) aslak: quick
(02:41:11 PM) pmuir: do we have any config atm, apart from service providers?
(02:41:25 PM) aslak: we don'teven have that..
(02:41:37 PM) pmuir: though if we are talking XML, I would prefer a schema based XML config
(02:41:47 PM) aslak: not 100% true.. jndi.properties is unsed by remote containers
(02:41:49 PM) lightguard_jp: pmuir: Definately.
(02:42:29 PM) aslak: unused/used
(02:42:36 PM) pmuir: in which case it can be sth like
(02:42:50 PM) pmuir: <config:container id="GlassFish" />
(02:43:05 PM) lightguard_jp: Are we thinking configurations at a super class that's extended, like SeamTest or do we have other options?
(02:43:09 PM) pmuir: well <arq:container id="GlassFish" /> is better
(02:43:58 PM) lightguard_jp: For TestNG with SeamTest it's a pain if you're using groups, you have to create your own superclass that does the same as SeamTest (which isn't much) but it's cumbersome.
(02:44:13 PM) lightguard_jp: I don't think the same thing applies to JUnit though, they don't do groups the same way.
(02:44:15 PM) pmuir: I guess we are providing some SPI (service providers based) to allow plugins (containers) to register themselves
(02:44:24 PM) lightguard_jp: I like that idea.
(02:44:39 PM) pmuir: lightguard_jp: lets make sure we get that right in Arqullian/TestNG :-)
(02:44:46 PM) pmuir: and then each container can have an id
(02:44:46 PM) lightguard_jp:
(02:44:48 PM) aslak: atm arquillian finds the containers and fail on multiple..
(02:45:01 PM) aslak: but it can of course find all and look for their ids to match configuration
(02:45:04 PM) pmuir: right, but we need to change that, as ALR wants to configure multiple containers per suite
(02:45:07 PM) pmuir: which is useful
(02:45:13 PM) pmuir: and then we have
(02:45:22 PM) pmuir: if (one container) then
(02:45:24 PM) pmuir: use that
(02:45:43 PM) pmuir: if (multiple containers AND config specified with annotation) then
(02:45:44 PM) pmuir: use that
(02:45:46 PM) pmuir: else
(02:45:58 PM) ALR@Freenode: What do we mean by "suite"?
(02:46:03 PM) pmuir: if (multiple containers AND xml config)
(02:46:04 PM) pmuir: use that
(02:46:05 PM) pmuir: else
(02:46:06 PM) pmuir: fail
(02:46:09 PM) pmuir: fi
(02:46:19 PM) pmuir: testng definition of suite
(02:46:30 PM) ALR@Freenode: k, what's that, I'm a JUnit guy
(02:46:35 PM) ALR@Freenode: Suite == Class for me.
(02:46:42 PM) aslak: Suite == Class...
(02:46:48 PM) lightguard_jp: That doesn't really come over to the JUnit side, does it?
(02:46:50 PM) ALR@Freenode: So I more want multiple containers to be able to be executed per module
(02:47:01 PM) lightguard_jp: There's no grouping of tests outside the class in JUnit, is there?
(02:47:02 PM) pmuir: http://testng.org/doc/documentation-main.html#introduction
(02:47:23 PM) aslak: lightguard_jp, it does.. junit doesn't know of a suite, but it knows of running multiple test classes
(02:47:24 PM) ALR@Freenode: And I'd be happy with extending test bases to add contaniner-specific stuff BTW
(02:48:01 PM) pmuir: in general, I would say method == test method, class == test case, group of test cases == suite
(02:48:18 PM) aslak: lightguard_jp, there is in the latest junit v. Category http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.html
(02:48:35 PM) lightguard_jp: Which JUnit are we targeting thin?
(02:48:40 PM) lightguard_jp: s/in/en
(02:48:55 PM) aslak: 4.6 as of now
(02:49:06 PM) ALR@Freenode: Or maybe even, if configuration was not part of the Java code
(02:49:10 PM) ALR@Freenode: Then you'd have one test class
(02:49:14 PM) ALR@Freenode: And N Maven profiles
(02:49:16 PM) lightguard_jp: Would going up to 4.8 make things easier or more uniform for us?
(02:49:31 PM) ALR@Freenode: So the thing would run N times, each with a different container config. That fits my case I think.
(02:49:31 PM) pmuir: btw my definition is backed by the fount of all knowledge
(02:49:32 PM) pmuir: http://en.wikipedia.org/wiki/Test_suite
(02:49:40 PM) ALR@Freenode: Though it'd mess up surefire reporting
(02:49:53 PM) aslak: ALR, hehe. isn't that what we have now.. ?
(02:50:15 PM) ALR@Freenode: aslak: Well, no, it runs once. And there's the reporting element.
(02:50:18 PM) lightguard_jp: Are we going to stay build tool egnostic? So you should be able to do this multiple container stuff with ant, builder, maven, gradle, etc?
(02:50:18 PM) pmuir: ALR: right, that is the way we do it now
(02:50:27 PM) pmuir: lightguard_jp: yes, that is a core requirement
(02:50:31 PM) aslak: ALR, it doesn't mess it up.. they are different runs testing different things against different enviroments.. you don't want to merge those reports
(02:50:35 PM) lightguard_jp: Good
(02:50:51 PM) ALR@Freenode: aslak: I don't want to merge them, I want disparate reports.
(02:51:04 PM) ALR@Freenode: But when running I'm seeing the same *.xml files at the end
(02:51:08 PM) ALR@Freenode: Not one-per.
(02:51:12 PM) ALR@Freenode: Or am I wrong?
(02:51:17 PM) aslak: ALR, you configure that in the profile
(02:51:20 PM) pmuir: i personally would prefer keeping container config out of code if I were designing a test suite using this
(02:51:36 PM) lightguard_jp: pmuir: I agree
(02:51:54 PM) aslak: pmuir, hehe.. arn't you ?
(02:51:56 PM) lightguard_jp: Not sure if XML is the best, but keeping it out of code (or at least an option to) IMO is best.
(02:52:01 PM) pmuir: but I can see it is useful for rapid prototyping / demos
(02:52:03 PM) pmuir: :-)
(02:52:10 PM) lightguard_jp: pmuir: Exactly
(02:52:23 PM) pmuir: so my algorithm does solve all these use cases right?
(02:52:31 PM) pmuir: aslak: well yes :-)
(02:53:23 PM) aslak: i think we have can have test class relates config pr test class in java code, but keep container / arquillian config outside
(02:53:36 PM) pmuir: btw I regard the multiple container use case as key (because we need it ourselves for developing frameworks!) but probably not something *most* users will need
(02:53:49 PM) pmuir: aslak: pardo
(02:53:50 PM) pmuir: n
(02:55:18 PM) aslak: i think we have a little of both.. i'm sure there are 'test class level' configuration that we can support in java on the class, but all arquillian /container configuration we keep outside
(02:55:37 PM) aslak: only something like forceRestart springs to mind, but..
(02:55:39 PM) pmuir: aslak: sure, I think that is a good way to do it
(02:55:46 PM) pmuir: for example, someone was talking about configuring ports
(02:56:16 PM) pmuir: that is probably better in Java (as you are configuring what to do if a particular container is used) but *which* container is used I would think belongs in XML
(02:56:25 PM) lightguard_jp: Would that still allow for the rapid prototyping or would it be required to have the external configuration as well?
(02:57:07 PM) aslak: pmuir, but how do you deal with multiple test cases defining different ports ? keep on to the first one? fail when you find another one?
(02:57:11 PM) pmuir: question: in a rapid prototyping situation, will you need to test in multiple containers?
(02:57:18 PM) pmuir: aslak: common superclass?
(02:57:52 PM) aslak: pmuir, sure, in a perfect world.. we can't garantee the user will do that
(02:57:59 PM) ALR@Freenode: We can recommend it.
(02:58:08 PM) ALR@Freenode: Or they can go the non-code route.
(02:58:16 PM) lightguard_jp: pmuir: I wouldn't think so, you'd have a targeted container that you're prototyping against.
(02:58:28 PM) pmuir: exactly, if we have a design pattern that solves a use case that is ok
(02:58:31 PM) aslak: the question still stands.. what do we do when they don't listen to us.. hehe
(02:58:33 PM) pmuir: lightguard_jp: so then it's the demo use case...
(02:58:47 PM) ALR@Freenode: pmuir: But I don't think configuration like ports should go separate from where we say the target container is.
(02:58:47 PM) pmuir: throw the toys out the pram
(02:58:52 PM) lightguard_jp: pmuir: I say yes.
(02:58:58 PM) ALR@Freenode: Unless the user chooses that way by combining metadata in two locations.
(02:59:01 PM) pmuir: well, this depends what ports we are talking about?
(02:59:09 PM) ALR@Freenode: Honestly this whole thing to me reads a lot like EJB3.
(02:59:20 PM) ALR@Freenode: You've got annotations if you want; they're easy.
(02:59:28 PM) ALR@Freenode: And XML if you want to override or decouple.
(02:59:49 PM) aslak: ALR, i don't think they should override.. they are different sets of config
(03:00:01 PM) ALR@Freenode: Are they?
(03:00:14 PM) aslak: ALR, at least i would wan't to keep it like that
(03:00:17 PM) ALR@Freenode: I find it confusing to separate config in more than one area unless it's necessary
(03:00:59 PM) aslak: configuration related to your test class is in your test case, configuration related to your test suite is in properties/xml somewhere
(03:01:08 PM) aslak: case/class
(03:01:38 PM) lightguard_jp: ALR: I guess at the code level we'd probably have to specify which container you're using for each test suite, little redundant, but probably no easy way around it, save an external config.
(03:02:05 PM) aslak: ALR, it fits your mdb example perfectly.. except MDB == test class, arquillian == app server
(03:02:18 PM) ALR@Freenode: aslak: What's an example of a test cnfig?
(03:02:36 PM) pmuir: ALR: aslak: I want to know this too :-)
(03:02:41 PM) lightguard_jp: Datasource?
(03:02:53 PM) ALR@Freenode: That's a deployment.
(03:03:04 PM) aslak: @Deployment, forceRestart ?
(03:03:29 PM) lightguard_jp: That might be it.
(03:03:36 PM) ALR@Freenode: forceRestart sounds like a container config to me too.
(03:03:39 PM) aslak: ok, i don't have any good test class level config use case at all..
(03:03:46 PM) ALR@Freenode: And deployments aren't configs
(03:03:50 PM) lightguard_jp: I can't think of anything I'd want to change at the container level per class or per test.
(03:03:53 PM) pmuir: yes, I can't see any
(03:04:09 PM) ALR@Freenode: Nor I. Cool, so just container config then.
(03:04:17 PM) ALR@Freenode: The *only* thing I can see:
(03:04:22 PM) aslak: i'm sure i'll find one..
(03:04:35 PM) ALR@Freenode: If you configure your container to bind to a specific port, you want the test to know which port.
(03:04:38 PM) aslak: if we can accept use case.. and not a good one..
(03:04:44 PM) ALR@Freenode: So it's still container config, but the test needs to know it.
(03:05:08 PM) ALR@Freenode: A static variable used in both the test and annotation on the class for container config can be share
(03:05:10 PM) ALR@Freenode: *shared
(03:05:15 PM) pmuir: that implies to me that what we need is a way for a test to be able to read the current container configuration?
(03:05:22 PM) ALR@Freenode: Yep.
(03:05:38 PM) ALR@Freenode: If it got injected that'd be fine
(03:05:49 PM) pmuir: that can be as simple as allowing a type safe configuration object to be injected?
(03:05:50 PM) pmuir: snap
(03:05:55 PM) ALR@Freenode: And then we enter the question of typesafety etc
(03:05:57 PM) ALR@Freenode: Yep
(03:06:09 PM) aslak: that's doable.. a ClientSideTestEnricher spi
(03:07:16 PM) aslak: or maybe even just use the same.. TestEnricher.. it should be able to run on both client and container side..
(03:07:27 PM) aslak: on/in
(03:07:40 PM) pmuir: aslak: yup
(03:07:44 PM) ALR@Freenode: pmuir: Problem is:
(03:07:49 PM) ALR@Freenode: Typesafe per container?
(03:07:59 PM) ALR@Freenode: Because then the test has container-specific stuff in it
(03:08:10 PM) ALR@Freenode: And configs will vary depending upon the type of container
(03:08:41 PM) pmuir: I was thinking typesafe as in a generic map
(03:09:19 PM) lightguard_jp: Probably the best we've got unless we go with the SPI idea like what aslak was saying.
(03:09:30 PM) aslak: in some cases we can get around it with a Requester API as Dan spoke about..
(03:09:47 PM) aslak: trying to hide the impl details in the background
(03:10:24 PM) aslak: maybe we should try to foresee what the user actually wants instead of just handing him the raw config ?
(03:10:47 PM) aslak: if i want to lookup a ejb remote, i wan't the jndi name and a initial contxt
(03:11:01 PM) aslak: if i want to do a http request i want the url to my resource
(03:11:28 PM) lightguard_jp: You'd need the same kinds of things as what you have in a real deployment.
(03:11:28 PM) aslak: and not.. new URL(config.address + :"" + container.port + "/" + containre.context ? ".....)
(03:11:51 PM) lightguard_jp: URLs, JNDI, managed objects (FacesContext for example).
(03:12:41 PM) aslak: i'm sure we can some up with some exiting spi here as well..
(03:12:43 PM) aslak:
(03:14:48 PM) aslak: @ArquillainResource InitialContext, @ArquillainResource FacesContext, @ArquillainResource(MyServlet.class) URL
(03:16:09 PM) aslak: we should probably call it Arquillian instead, but.. you get the picture..
(03:16:23 PM) lightguard_jp: Not bad, I like it.
(03:17:08 PM) lightguard_jp: Do we want to go down the injection road or just have a class called ArquillianResource and a getResource(Type) or similar?
(03:19:08 PM) pmuir: aslak: sounds like a good thing for alpha > 1 ;-)
(03:19:55 PM) aslak:
(03:20:17 PM) aslak: easy as a cup cake..
(03:21:27 PM) aslak: lightguard_jp, it can be both i guess
(03:21:35 PM) pmuir: So is this the end of the first round of design discussions?
(03:22:29 PM) aslak: unless anyone else have anything i think so..
(03:22:45 PM) germanescobar: catching up ... couple of questions ...
(03:23:08 PM) aslak: we have some naming + libraries in the deployment issues still open but..
(03:23:34 PM) germanescobar: so, where do you end up configuring things like port and hostname of a JBoss 6 for example?
(03:24:03 PM) aslak: pmuir, ohh, while on topic.. i havn't chcked yet, but how do you handle the war deployment in test-harness.. the user has to add the estrunner servlet to his web.xml ?
(03:24:24 PM) aslak: germanescobar, file / enviroment
(03:25:05 PM) germanescobar: no option for java code?
(03:27:01 PM) aslak: don't really see any where to put it
(03:27:30 PM) germanescobar: I would like to have the option to change that using the Java code .... and point all my test classes to a configuration class for example ... so, I have the same configuration on all of my test classes ...
(03:27:51 PM) aslak: germanescobar, the problem is it's hard to enforce..
(03:28:11 PM) aslak: hard to enforce you actually point all your test classes to the same configuration i mean
(03:28:34 PM) pmuir: aslak: provide a "default" web.xml which gets used if not overridden that specifies it
(03:28:39 PM) pmuir: otherwise they must include it
(03:28:51 PM) pmuir: BUT with servlet 3, this can be done better with a fragment
(03:28:55 PM) aslak: pmuir, right.. thought so..
(03:29:08 PM) pmuir: so IMO we add the fragment and advise using Servlet 3
(03:29:11 PM) aslak: pmuir, yea, in a ee 6 container, but..
(03:29:14 PM) pmuir: otherwise we say you must add it
(03:29:24 PM) pmuir: well, that pushes problem to the user ;-)
(03:29:52 PM) aslak:
(03:30:27 PM) pmuir: i assume we don't always require hostname/port of AS right?
(03:30:34 PM) pmuir: we have some defaults which can be overrideen?
(03:30:41 PM) aslak: right
(03:31:01 PM) aslak: i would want to go with sensable defaults on everything..
(03:31:08 PM) pmuir: IMO then germanescobar's point is good for 1.1 not 1.0 :-)
(03:31:10 PM) lightguard_jp: Is configuration something we're going to make the containers implement for us then?
(03:31:41 PM) aslak: lightguard_jp, ?
(03:32:31 PM) lightguard_jp: We're saying you configure the container in an xml file, but we don't know or have all the configurations for GF or Jetty or whatever.
(03:32:44 PM) lightguard_jp: So is it an SPI that we'll expose to them?
(03:34:59 PM) aslak: DeployableContainer.start(GlassFishConfiguration extends ContainerConfiguration) , we provide a way of reading in GlassfishConfiguration from propeties/xml/environment .. ?
(03:35:54 PM) lightguard_jp: I agree with pmuir about having an XSD and that's difficult to ship with unless we have / know it
(03:36:22 PM) pmuir: not necessarily, the container plugin can publish the xsd...
(03:36:33 PM) pmuir: thats the beauty of schema, it's extensible
(03:36:58 PM) aslak: containers define their own configuraiton.. in the end they have to do the work of supporting the config anyway..
(03:37:05 PM) aslak: pmuir, exactly..
(03:37:32 PM) lightguard_jp: I'm good with that
(03:37:40 PM) germanescobar: ok, I like that ... so there will be no global configuration ... each container "exposes" its configuration options ...
(03:37:44 PM) aslak: we can provide a base of, bind address / port, but jboss provides profile name
(03:38:17 PM) pmuir: germanescobar: there will be a "core" configuration as well
(03:38:26 PM) aslak: germanescobar, i think the other way around.. there is a global config, but if you want to configure GlassFish you include their scahem in your global config
(03:38:27 PM) pmuir: which configures Arq itself
(03:39:14 PM) germanescobar: pmuir, what do you need to configure for the core?
(03:39:28 PM) pmuir: the container to use
(03:41:16 PM) germanescobar: pmuir, any other option besides the container to use?
(03:41:23 PM) pmuir: atm, not afaik
(03:41:24 PM) pmuir: aslak?
(03:42:04 PM) aslak: germanescobar, host port profiles memory
(03:42:29 PM) germanescobar: aslak, but you don't always need host and port ...
(03:42:39 PM) aslak: TestEnrichers / DeploymentAppenders, DeploymentPakcager..
(03:42:55 PM) germanescobar: I would leave that to each container to decide ...
(03:43:16 PM) aslak: germanescobar, no you shouldn't need any config at all.. a dep on the contianer jar should be enought, but if you want to use multiple containers in same classpath etc you need to configure
(03:43:16 PM) germanescobar: besides, I guess each container will have its own defaults ...
(03:43:37 PM) pmuir: yes, I agree with germanescobar those things seem more a container config
(03:43:43 PM) germanescobar: aslak, right ...
(03:44:07 PM) aslak: this ish.. http://shrinkwrap.pastebin.com/t6DtuVqh
(03:46:20 PM) pmuir: personally I think bind should be per container
(03:46:27 PM) germanescobar: I like it ... the only thing is that <bind ... is generic, I would leave it <jboss:bind ...
(03:46:49 PM) aslak: yea yea.. details..
(03:47:29 PM) germanescobar: yeah, but that will do it ...
(03:47:30 PM) pmuir: and also it shouldn't be nested in the container
(03:47:36 PM) pmuir: as container id="JBoss"
(03:47:41 PM) pmuir: is an instructions "Use JBoss"
(03:47:52 PM) pmuir: when the others are about configuring the jboss instance
(03:48:54 PM) pmuir: ok, as we have 10m left,
(03:48:55 PM) lightguard_jp: Would we have multiple container configs in the same file?
(03:49:07 PM) pmuir: and I think we have covered everything we want to
(03:49:09 PM) aslak: pmuir, like tihds: http://shrinkwrap.pastebin.com/xn8hsSxi
(03:49:09 PM) aslak: ?
(03:49:39 PM) pmuir: yes, more like that
(03:49:42 PM) aslak: i was thinking multiple container config in same xm lfile and a run time params sying which to use.. ?
(03:50:01 PM) germanescobar: lightguard_jp, I think we should support that. However, how do we choose only one for running the tests?
(03:50:05 PM) aslak: mvn test -Darquillian.contianer.id=JBoss
(03:50:07 PM) pmuir: support <container id="${container}" />?
(03:50:22 PM) lightguard_jp: Combination of both?
(03:50:46 PM) pmuir: anyway, back to adminstrivia for me
(03:51:00 PM) lightguard_jp: pmuir: Have fun
(03:51:02 PM) pmuir: I want to make sure we are clear what we still need to do for alpha 1 (we neeed to get a release out)
(03:51:18 PM) pmuir: and also set a target date
(03:51:29 PM) pmuir: aslak: is JIRA up to date for this?
(03:51:48 PM) aslak: not issues to include for alpha-1 no..
(03:51:51 PM) pmuir: ok
(03:52:06 PM) pmuir: so first order IMO is to get all the tasks to do into JIRA
(03:52:14 PM) pmuir: then we can all review and make sure we are happy
(03:52:18 PM) pmuir: then we can set a target date
(03:52:33 PM) pmuir: aslak: I'm really tired tonight, but perhaps we can work on the JIRA tomorrow morning?
(03:52:43 PM) aslak: sure
(03:52:50 PM) pmuir: ok cool
(03:52:55 PM) pmuir: i;ll drop off then
(03:52:59 PM) pmuir: night guys
(03:53:00 PM) pmuir left the room (quit: Quit: Leaving).
(03:53:04 PM) aslak: i'll look through the log and create some..
(03:53:24 PM) aslak: ALR, stop log..
(02:21:33 PM) aslak: ALR, you wanna do the introduction..
(02:21:55 PM) ALR@Freenode: aslak: I think you should drive this.
(02:22:04 PM) ALR@Freenode: aslak: I'm a bit behind on Arquillian
(02:22:45 PM) aslak: i guess we start where we started last time
(02:22:52 PM) aslak: (02:05:44 PM) ALR@Freenode: OK, welcome all to round two of the Arquillian Design Kickoff
(02:22:52 PM) aslak: (02:05:53 PM) ALR@Freenode: Last meeting's notes can be found:
(02:22:54 PM) aslak: http://community.jboss.org/wiki/ArquillianMeetingLog20100218
(02:23:02 PM) aslak: (02:06:38 PM) ALR@Freenode: We left off on the topic of the User Configuration API
(02:23:02 PM) aslak: (02:07:01 PM) ALR@Freenode: A way for declarative container-specific properties to be passed along.
(02:23:07 PM) aslak: two/tree
(02:23:18 PM) aslak: hehe
(02:23:21 PM) ALR@Freenode: Haha
(02:23:32 PM) ALR@Freenode: I'm a visionary ahead of my time.
(02:23:56 PM) aslak:
(02:24:49 PM) aslak: so basically, we need to be able to configure the whole shebang
(02:25:01 PM) ALR@Freenode: Yep.
(02:25:23 PM) ALR@Freenode: I point to the way MDBs are configured as an analogy
(02:25:25 PM) aslak: we have arquillian core config, container config
(02:25:37 PM) ALR@Freenode: Because MDBs are listeners, coming in from any JCA-compliant resource adaptor
(02:25:45 PM) ALR@Freenode: You need to be able to configure the adaptor.
(02:25:49 PM) ALR@Freenode: This is similar
(02:26:03 PM) ALR@Freenode: Arquillian is JCA in this case
(02:26:08 PM) ALR@Freenode: And the Containers are the adaptors
(02:26:31 PM) ALR@Freenode: It's activation config properties (String/String) name/value pairs in the MDB case.
(02:26:50 PM) ALR@Freenode: So a question I have is: can we do something more typesafe, with a configuration object per container?
(02:26:54 PM) ALR@Freenode: Or stick w/ props?
(02:27:31 PM) aslak: we can at least make it type safe on the reader side
(02:27:33 PM) germanescobar: I would like something more typesafe ... at least for the general configuration
(02:28:51 PM) aslak: ALR, but where do you propose we put the mdb style attributes ?
(02:29:08 PM) aslak: pr testcase ?
(02:29:14 PM) ALR@Freenode: aslak: I think it'd go on the class, yeah.
(02:29:22 PM) ALR@Freenode: Alongside where we say "Use Container X"
(02:30:26 PM) aslak: yea, it's at a level that doesn't really make much sense to me.. you have one test case wanting contianer x and another container y and a third container x with port n
(02:31:06 PM) ALR@Freenode: You mean on the class it doesn't make sense to you?
(02:31:16 PM) aslak: yea
(02:31:27 PM) germanescobar: aslak, at testsuite level?
(02:31:33 PM) aslak: germanescobar, yea
(02:31:39 PM) pmuir [~pmuir@redhat/jboss/pmuir] entered the room.
(02:31:47 PM) ALR@Freenode: TestSuite == Class in JUnit by default
(02:31:49 PM) aslak: ALR, a test class could have some config.. ie like needsRestart
(02:32:09 PM) aslak: heya pmuir
(02:32:19 PM) pmuir: hey
(02:32:31 PM) aslak: but i don't like the idea of hardcoding the container to the testcase
(02:33:05 PM) aslak: it defetes some of the point with 'standalone/embedded' containers vs full etc
(02:33:20 PM) aslak: defeats
(02:33:46 PM) ALR@Freenode: aslak: That's where inheritance comes in IMO
(02:33:51 PM) ALR@Freenode: Base test class with all the logic
(02:33:56 PM) ALR@Freenode: And extensions per container
(02:34:18 PM) ALR@Freenode: It's how I do it in EJB3 for example. Rarely am I annotating/hardcoding stuff alongside the logic.
(02:34:19 PM) aslak: ? you can run the same test in multiple containers
(02:34:22 PM) pmuir: ALR: seems a bit heavy
(02:34:33 PM) germanescobar: aslak, but most of the time you will be configuring hostname and port for a specific container
(02:34:40 PM) ALR@Freenode: It's just the age-old question: What's configuration, and what's wiring?
(02:34:57 PM) ALR@Freenode: I think 80% of the time at least, folks will have a specific target container in mind.
(02:35:02 PM) lightguard_jp: aslak, ALR, I'm here, we had an interview we were doing.
(02:35:03 PM) ALR@Freenode: If they don't, there's inheritance
(02:35:19 PM) ALR@Freenode: Definitely open to other suggestions.
(02:35:27 PM) ALR@Freenode: These just jump out at me first.
(02:35:44 PM) pmuir: ALR: we need a way to configure this outside of Java code
(02:36:12 PM) ALR@Freenode: I like Java. So fast for prototyping, less switching.
(02:37:52 PM) pmuir: ALR: so do I
(02:38:08 PM) pmuir: but we have a concrete use case with the CDI TCK where we need to switch it without any Java codd
(02:38:10 PM) pmuir: e
(02:38:18 PM) ALR@Freenode: OKee.
(02:38:21 PM) pmuir: we also need that for the Seam test suite
(02:38:30 PM) ALR@Freenode: How do overrides sit with you?
(02:38:30 PM) aslak: pmuir, what's the use case?
(02:38:52 PM) pmuir: aslak: use the TCK with multiple containers
(02:38:56 PM) aslak: pmuir, never mind.. diff containers running the test
(02:38:57 PM) pmuir: how do you mean overrides?
(02:38:59 PM) aslak: hehe right..
(02:39:13 PM) ALR@Freenode: non-Java config overrides annotations.
(02:39:17 PM) ALR@Freenode: Basically the EJB3 model
(02:39:22 PM) ALR@Freenode: Partial XML descriptors and such.
(02:39:46 PM) aslak: i'm not sure about the idea of switching contianers midd run
(02:39:56 PM) ALR@Freenode: Mid run?
(02:40:01 PM) lightguard_jp: I think that's probably the most standard approach (annotations w/ xml override).
(02:40:05 PM) ALR@Freenode: I thought this was just so the TCK could be used for all implementors
(02:40:19 PM) ALR@Freenode: So the vendor configures stuff in their porting layer
(02:40:23 PM) pmuir: ALR: never really liked that style of XML config
(02:40:24 PM) aslak: ALR, yea, with config pr test case
(02:40:28 PM) pmuir: it's seems fugly to me
(02:40:40 PM) ALR@Freenode: Again, open to ideas.
(02:40:44 PM) lightguard_jp: If we have to switch mid run, things get complicated
(02:41:02 PM) aslak: complicated and we run out of memory real wick
(02:41:07 PM) aslak: wuick
(02:41:09 PM) aslak: quick
(02:41:11 PM) pmuir: do we have any config atm, apart from service providers?
(02:41:25 PM) aslak: we don'teven have that..
(02:41:37 PM) pmuir: though if we are talking XML, I would prefer a schema based XML config
(02:41:47 PM) aslak: not 100% true.. jndi.properties is unsed by remote containers
(02:41:49 PM) lightguard_jp: pmuir: Definately.
(02:42:29 PM) aslak: unused/used
(02:42:36 PM) pmuir: in which case it can be sth like
(02:42:50 PM) pmuir: <config:container id="GlassFish" />
(02:43:05 PM) lightguard_jp: Are we thinking configurations at a super class that's extended, like SeamTest or do we have other options?
(02:43:09 PM) pmuir: well <arq:container id="GlassFish" /> is better
(02:43:58 PM) lightguard_jp: For TestNG with SeamTest it's a pain if you're using groups, you have to create your own superclass that does the same as SeamTest (which isn't much) but it's cumbersome.
(02:44:13 PM) lightguard_jp: I don't think the same thing applies to JUnit though, they don't do groups the same way.
(02:44:15 PM) pmuir: I guess we are providing some SPI (service providers based) to allow plugins (containers) to register themselves
(02:44:24 PM) lightguard_jp: I like that idea.
(02:44:39 PM) pmuir: lightguard_jp: lets make sure we get that right in Arqullian/TestNG :-)
(02:44:46 PM) pmuir: and then each container can have an id
(02:44:46 PM) lightguard_jp:
(02:44:48 PM) aslak: atm arquillian finds the containers and fail on multiple..
(02:45:01 PM) aslak: but it can of course find all and look for their ids to match configuration
(02:45:04 PM) pmuir: right, but we need to change that, as ALR wants to configure multiple containers per suite
(02:45:07 PM) pmuir: which is useful
(02:45:13 PM) pmuir: and then we have
(02:45:22 PM) pmuir: if (one container) then
(02:45:24 PM) pmuir: use that
(02:45:43 PM) pmuir: if (multiple containers AND config specified with annotation) then
(02:45:44 PM) pmuir: use that
(02:45:46 PM) pmuir: else
(02:45:58 PM) ALR@Freenode: What do we mean by "suite"?
(02:46:03 PM) pmuir: if (multiple containers AND xml config)
(02:46:04 PM) pmuir: use that
(02:46:05 PM) pmuir: else
(02:46:06 PM) pmuir: fail
(02:46:09 PM) pmuir: fi
(02:46:19 PM) pmuir: testng definition of suite
(02:46:30 PM) ALR@Freenode: k, what's that, I'm a JUnit guy
(02:46:35 PM) ALR@Freenode: Suite == Class for me.
(02:46:42 PM) aslak: Suite == Class...
(02:46:48 PM) lightguard_jp: That doesn't really come over to the JUnit side, does it?
(02:46:50 PM) ALR@Freenode: So I more want multiple containers to be able to be executed per module
(02:47:01 PM) lightguard_jp: There's no grouping of tests outside the class in JUnit, is there?
(02:47:02 PM) pmuir: http://testng.org/doc/documentation-main.html#introduction
(02:47:23 PM) aslak: lightguard_jp, it does.. junit doesn't know of a suite, but it knows of running multiple test classes
(02:47:24 PM) ALR@Freenode: And I'd be happy with extending test bases to add contaniner-specific stuff BTW
(02:48:01 PM) pmuir: in general, I would say method == test method, class == test case, group of test cases == suite
(02:48:18 PM) aslak: lightguard_jp, there is in the latest junit v. Category http://kentbeck.github.com/junit/doc/ReleaseNotes4.8.html
(02:48:35 PM) lightguard_jp: Which JUnit are we targeting thin?
(02:48:40 PM) lightguard_jp: s/in/en
(02:48:55 PM) aslak: 4.6 as of now
(02:49:06 PM) ALR@Freenode: Or maybe even, if configuration was not part of the Java code
(02:49:10 PM) ALR@Freenode: Then you'd have one test class
(02:49:14 PM) ALR@Freenode: And N Maven profiles
(02:49:16 PM) lightguard_jp: Would going up to 4.8 make things easier or more uniform for us?
(02:49:31 PM) ALR@Freenode: So the thing would run N times, each with a different container config. That fits my case I think.
(02:49:31 PM) pmuir: btw my definition is backed by the fount of all knowledge
(02:49:32 PM) pmuir: http://en.wikipedia.org/wiki/Test_suite
(02:49:40 PM) ALR@Freenode: Though it'd mess up surefire reporting
(02:49:53 PM) aslak: ALR, hehe. isn't that what we have now.. ?
(02:50:15 PM) ALR@Freenode: aslak: Well, no, it runs once. And there's the reporting element.
(02:50:18 PM) lightguard_jp: Are we going to stay build tool egnostic? So you should be able to do this multiple container stuff with ant, builder, maven, gradle, etc?
(02:50:18 PM) pmuir: ALR: right, that is the way we do it now
(02:50:27 PM) pmuir: lightguard_jp: yes, that is a core requirement
(02:50:31 PM) aslak: ALR, it doesn't mess it up.. they are different runs testing different things against different enviroments.. you don't want to merge those reports
(02:50:35 PM) lightguard_jp: Good
(02:50:51 PM) ALR@Freenode: aslak: I don't want to merge them, I want disparate reports.
(02:51:04 PM) ALR@Freenode: But when running I'm seeing the same *.xml files at the end
(02:51:08 PM) ALR@Freenode: Not one-per.
(02:51:12 PM) ALR@Freenode: Or am I wrong?
(02:51:17 PM) aslak: ALR, you configure that in the profile
(02:51:20 PM) pmuir: i personally would prefer keeping container config out of code if I were designing a test suite using this
(02:51:36 PM) lightguard_jp: pmuir: I agree
(02:51:54 PM) aslak: pmuir, hehe.. arn't you ?
(02:51:56 PM) lightguard_jp: Not sure if XML is the best, but keeping it out of code (or at least an option to) IMO is best.
(02:52:01 PM) pmuir: but I can see it is useful for rapid prototyping / demos
(02:52:03 PM) pmuir: :-)
(02:52:10 PM) lightguard_jp: pmuir: Exactly
(02:52:23 PM) pmuir: so my algorithm does solve all these use cases right?
(02:52:31 PM) pmuir: aslak: well yes :-)
(02:53:23 PM) aslak: i think we have can have test class relates config pr test class in java code, but keep container / arquillian config outside
(02:53:36 PM) pmuir: btw I regard the multiple container use case as key (because we need it ourselves for developing frameworks!) but probably not something *most* users will need
(02:53:49 PM) pmuir: aslak: pardo
(02:53:50 PM) pmuir: n
(02:55:18 PM) aslak: i think we have a little of both.. i'm sure there are 'test class level' configuration that we can support in java on the class, but all arquillian /container configuration we keep outside
(02:55:37 PM) aslak: only something like forceRestart springs to mind, but..
(02:55:39 PM) pmuir: aslak: sure, I think that is a good way to do it
(02:55:46 PM) pmuir: for example, someone was talking about configuring ports
(02:56:16 PM) pmuir: that is probably better in Java (as you are configuring what to do if a particular container is used) but *which* container is used I would think belongs in XML
(02:56:25 PM) lightguard_jp: Would that still allow for the rapid prototyping or would it be required to have the external configuration as well?
(02:57:07 PM) aslak: pmuir, but how do you deal with multiple test cases defining different ports ? keep on to the first one? fail when you find another one?
(02:57:11 PM) pmuir: question: in a rapid prototyping situation, will you need to test in multiple containers?
(02:57:18 PM) pmuir: aslak: common superclass?
(02:57:52 PM) aslak: pmuir, sure, in a perfect world.. we can't garantee the user will do that
(02:57:59 PM) ALR@Freenode: We can recommend it.
(02:58:08 PM) ALR@Freenode: Or they can go the non-code route.
(02:58:16 PM) lightguard_jp: pmuir: I wouldn't think so, you'd have a targeted container that you're prototyping against.
(02:58:28 PM) pmuir: exactly, if we have a design pattern that solves a use case that is ok
(02:58:31 PM) aslak: the question still stands.. what do we do when they don't listen to us.. hehe
(02:58:33 PM) pmuir: lightguard_jp: so then it's the demo use case...
(02:58:47 PM) ALR@Freenode: pmuir: But I don't think configuration like ports should go separate from where we say the target container is.
(02:58:47 PM) pmuir: throw the toys out the pram
(02:58:52 PM) lightguard_jp: pmuir: I say yes.
(02:58:58 PM) ALR@Freenode: Unless the user chooses that way by combining metadata in two locations.
(02:59:01 PM) pmuir: well, this depends what ports we are talking about?
(02:59:09 PM) ALR@Freenode: Honestly this whole thing to me reads a lot like EJB3.
(02:59:20 PM) ALR@Freenode: You've got annotations if you want; they're easy.
(02:59:28 PM) ALR@Freenode: And XML if you want to override or decouple.
(02:59:49 PM) aslak: ALR, i don't think they should override.. they are different sets of config
(03:00:01 PM) ALR@Freenode: Are they?
(03:00:14 PM) aslak: ALR, at least i would wan't to keep it like that
(03:00:17 PM) ALR@Freenode: I find it confusing to separate config in more than one area unless it's necessary
(03:00:59 PM) aslak: configuration related to your test class is in your test case, configuration related to your test suite is in properties/xml somewhere
(03:01:08 PM) aslak: case/class
(03:01:38 PM) lightguard_jp: ALR: I guess at the code level we'd probably have to specify which container you're using for each test suite, little redundant, but probably no easy way around it, save an external config.
(03:02:05 PM) aslak: ALR, it fits your mdb example perfectly.. except MDB == test class, arquillian == app server
(03:02:18 PM) ALR@Freenode: aslak: What's an example of a test cnfig?
(03:02:36 PM) pmuir: ALR: aslak: I want to know this too :-)
(03:02:41 PM) lightguard_jp: Datasource?
(03:02:53 PM) ALR@Freenode: That's a deployment.
(03:03:04 PM) aslak: @Deployment, forceRestart ?
(03:03:29 PM) lightguard_jp: That might be it.
(03:03:36 PM) ALR@Freenode: forceRestart sounds like a container config to me too.
(03:03:39 PM) aslak: ok, i don't have any good test class level config use case at all..
(03:03:46 PM) ALR@Freenode: And deployments aren't configs
(03:03:50 PM) lightguard_jp: I can't think of anything I'd want to change at the container level per class or per test.
(03:03:53 PM) pmuir: yes, I can't see any
(03:04:09 PM) ALR@Freenode: Nor I. Cool, so just container config then.
(03:04:17 PM) ALR@Freenode: The *only* thing I can see:
(03:04:22 PM) aslak: i'm sure i'll find one..
(03:04:35 PM) ALR@Freenode: If you configure your container to bind to a specific port, you want the test to know which port.
(03:04:38 PM) aslak: if we can accept use case.. and not a good one..
(03:04:44 PM) ALR@Freenode: So it's still container config, but the test needs to know it.
(03:05:08 PM) ALR@Freenode: A static variable used in both the test and annotation on the class for container config can be share
(03:05:10 PM) ALR@Freenode: *shared
(03:05:15 PM) pmuir: that implies to me that what we need is a way for a test to be able to read the current container configuration?
(03:05:22 PM) ALR@Freenode: Yep.
(03:05:38 PM) ALR@Freenode: If it got injected that'd be fine
(03:05:49 PM) pmuir: that can be as simple as allowing a type safe configuration object to be injected?
(03:05:50 PM) pmuir: snap
(03:05:55 PM) ALR@Freenode: And then we enter the question of typesafety etc
(03:05:57 PM) ALR@Freenode: Yep
(03:06:09 PM) aslak: that's doable.. a ClientSideTestEnricher spi
(03:07:16 PM) aslak: or maybe even just use the same.. TestEnricher.. it should be able to run on both client and container side..
(03:07:27 PM) aslak: on/in
(03:07:40 PM) pmuir: aslak: yup
(03:07:44 PM) ALR@Freenode: pmuir: Problem is:
(03:07:49 PM) ALR@Freenode: Typesafe per container?
(03:07:59 PM) ALR@Freenode: Because then the test has container-specific stuff in it
(03:08:10 PM) ALR@Freenode: And configs will vary depending upon the type of container
(03:08:41 PM) pmuir: I was thinking typesafe as in a generic map
(03:09:19 PM) lightguard_jp: Probably the best we've got unless we go with the SPI idea like what aslak was saying.
(03:09:30 PM) aslak: in some cases we can get around it with a Requester API as Dan spoke about..
(03:09:47 PM) aslak: trying to hide the impl details in the background
(03:10:24 PM) aslak: maybe we should try to foresee what the user actually wants instead of just handing him the raw config ?
(03:10:47 PM) aslak: if i want to lookup a ejb remote, i wan't the jndi name and a initial contxt
(03:11:01 PM) aslak: if i want to do a http request i want the url to my resource
(03:11:28 PM) lightguard_jp: You'd need the same kinds of things as what you have in a real deployment.
(03:11:28 PM) aslak: and not.. new URL(config.address + :"" + container.port + "/" + containre.context ? ".....)
(03:11:51 PM) lightguard_jp: URLs, JNDI, managed objects (FacesContext for example).
(03:12:41 PM) aslak: i'm sure we can some up with some exiting spi here as well..
(03:12:43 PM) aslak:
(03:14:48 PM) aslak: @ArquillainResource InitialContext, @ArquillainResource FacesContext, @ArquillainResource(MyServlet.class) URL
(03:16:09 PM) aslak: we should probably call it Arquillian instead, but.. you get the picture..
(03:16:23 PM) lightguard_jp: Not bad, I like it.
(03:17:08 PM) lightguard_jp: Do we want to go down the injection road or just have a class called ArquillianResource and a getResource(Type) or similar?
(03:19:08 PM) pmuir: aslak: sounds like a good thing for alpha > 1 ;-)
(03:19:55 PM) aslak:
(03:20:17 PM) aslak: easy as a cup cake..
(03:21:27 PM) aslak: lightguard_jp, it can be both i guess
(03:21:35 PM) pmuir: So is this the end of the first round of design discussions?
(03:22:29 PM) aslak: unless anyone else have anything i think so..
(03:22:45 PM) germanescobar: catching up ... couple of questions ...
(03:23:08 PM) aslak: we have some naming + libraries in the deployment issues still open but..
(03:23:34 PM) germanescobar: so, where do you end up configuring things like port and hostname of a JBoss 6 for example?
(03:24:03 PM) aslak: pmuir, ohh, while on topic.. i havn't chcked yet, but how do you handle the war deployment in test-harness.. the user has to add the estrunner servlet to his web.xml ?
(03:24:24 PM) aslak: germanescobar, file / enviroment
(03:25:05 PM) germanescobar: no option for java code?
(03:27:01 PM) aslak: don't really see any where to put it
(03:27:30 PM) germanescobar: I would like to have the option to change that using the Java code .... and point all my test classes to a configuration class for example ... so, I have the same configuration on all of my test classes ...
(03:27:51 PM) aslak: germanescobar, the problem is it's hard to enforce..
(03:28:11 PM) aslak: hard to enforce you actually point all your test classes to the same configuration i mean
(03:28:34 PM) pmuir: aslak: provide a "default" web.xml which gets used if not overridden that specifies it
(03:28:39 PM) pmuir: otherwise they must include it
(03:28:51 PM) pmuir: BUT with servlet 3, this can be done better with a fragment
(03:28:55 PM) aslak: pmuir, right.. thought so..
(03:29:08 PM) pmuir: so IMO we add the fragment and advise using Servlet 3
(03:29:11 PM) aslak: pmuir, yea, in a ee 6 container, but..
(03:29:14 PM) pmuir: otherwise we say you must add it
(03:29:24 PM) pmuir: well, that pushes problem to the user ;-)
(03:29:52 PM) aslak:
(03:30:27 PM) pmuir: i assume we don't always require hostname/port of AS right?
(03:30:34 PM) pmuir: we have some defaults which can be overrideen?
(03:30:41 PM) aslak: right
(03:31:01 PM) aslak: i would want to go with sensable defaults on everything..
(03:31:08 PM) pmuir: IMO then germanescobar's point is good for 1.1 not 1.0 :-)
(03:31:10 PM) lightguard_jp: Is configuration something we're going to make the containers implement for us then?
(03:31:41 PM) aslak: lightguard_jp, ?
(03:32:31 PM) lightguard_jp: We're saying you configure the container in an xml file, but we don't know or have all the configurations for GF or Jetty or whatever.
(03:32:44 PM) lightguard_jp: So is it an SPI that we'll expose to them?
(03:34:59 PM) aslak: DeployableContainer.start(GlassFishConfiguration extends ContainerConfiguration) , we provide a way of reading in GlassfishConfiguration from propeties/xml/environment .. ?
(03:35:54 PM) lightguard_jp: I agree with pmuir about having an XSD and that's difficult to ship with unless we have / know it
(03:36:22 PM) pmuir: not necessarily, the container plugin can publish the xsd...
(03:36:33 PM) pmuir: thats the beauty of schema, it's extensible
(03:36:58 PM) aslak: containers define their own configuraiton.. in the end they have to do the work of supporting the config anyway..
(03:37:05 PM) aslak: pmuir, exactly..
(03:37:32 PM) lightguard_jp: I'm good with that
(03:37:40 PM) germanescobar: ok, I like that ... so there will be no global configuration ... each container "exposes" its configuration options ...
(03:37:44 PM) aslak: we can provide a base of, bind address / port, but jboss provides profile name
(03:38:17 PM) pmuir: germanescobar: there will be a "core" configuration as well
(03:38:26 PM) aslak: germanescobar, i think the other way around.. there is a global config, but if you want to configure GlassFish you include their scahem in your global config
(03:38:27 PM) pmuir: which configures Arq itself
(03:39:14 PM) germanescobar: pmuir, what do you need to configure for the core?
(03:39:28 PM) pmuir: the container to use
(03:41:16 PM) germanescobar: pmuir, any other option besides the container to use?
(03:41:23 PM) pmuir: atm, not afaik
(03:41:24 PM) pmuir: aslak?
(03:42:04 PM) aslak: germanescobar, host port profiles memory
(03:42:29 PM) germanescobar: aslak, but you don't always need host and port ...
(03:42:39 PM) aslak: TestEnrichers / DeploymentAppenders, DeploymentPakcager..
(03:42:55 PM) germanescobar: I would leave that to each container to decide ...
(03:43:16 PM) aslak: germanescobar, no you shouldn't need any config at all.. a dep on the contianer jar should be enought, but if you want to use multiple containers in same classpath etc you need to configure
(03:43:16 PM) germanescobar: besides, I guess each container will have its own defaults ...
(03:43:37 PM) pmuir: yes, I agree with germanescobar those things seem more a container config
(03:43:43 PM) germanescobar: aslak, right ...
(03:44:07 PM) aslak: this ish.. http://shrinkwrap.pastebin.com/t6DtuVqh
(03:46:20 PM) pmuir: personally I think bind should be per container
(03:46:27 PM) germanescobar: I like it ... the only thing is that <bind ... is generic, I would leave it <jboss:bind ...
(03:46:49 PM) aslak: yea yea.. details..
(03:47:29 PM) germanescobar: yeah, but that will do it ...
(03:47:30 PM) pmuir: and also it shouldn't be nested in the container
(03:47:36 PM) pmuir: as container id="JBoss"
(03:47:41 PM) pmuir: is an instructions "Use JBoss"
(03:47:52 PM) pmuir: when the others are about configuring the jboss instance
(03:48:54 PM) pmuir: ok, as we have 10m left,
(03:48:55 PM) lightguard_jp: Would we have multiple container configs in the same file?
(03:49:07 PM) pmuir: and I think we have covered everything we want to
(03:49:09 PM) aslak: pmuir, like tihds: http://shrinkwrap.pastebin.com/xn8hsSxi
(03:49:09 PM) aslak: ?
(03:49:39 PM) pmuir: yes, more like that
(03:49:42 PM) aslak: i was thinking multiple container config in same xm lfile and a run time params sying which to use.. ?
(03:50:01 PM) germanescobar: lightguard_jp, I think we should support that. However, how do we choose only one for running the tests?
(03:50:05 PM) aslak: mvn test -Darquillian.contianer.id=JBoss
(03:50:07 PM) pmuir: support <container id="${container}" />?
(03:50:22 PM) lightguard_jp: Combination of both?
(03:50:46 PM) pmuir: anyway, back to adminstrivia for me
(03:51:00 PM) lightguard_jp: pmuir: Have fun
(03:51:02 PM) pmuir: I want to make sure we are clear what we still need to do for alpha 1 (we neeed to get a release out)
(03:51:18 PM) pmuir: and also set a target date
(03:51:29 PM) pmuir: aslak: is JIRA up to date for this?
(03:51:48 PM) aslak: not issues to include for alpha-1 no..
(03:51:51 PM) pmuir: ok
(03:52:06 PM) pmuir: so first order IMO is to get all the tasks to do into JIRA
(03:52:14 PM) pmuir: then we can all review and make sure we are happy
(03:52:18 PM) pmuir: then we can set a target date
(03:52:33 PM) pmuir: aslak: I'm really tired tonight, but perhaps we can work on the JIRA tomorrow morning?
(03:52:43 PM) aslak: sure
(03:52:50 PM) pmuir: ok cool
(03:52:55 PM) pmuir: i;ll drop off then
(03:52:59 PM) pmuir: night guys
(03:53:00 PM) pmuir left the room (quit: Quit: Leaving).
(03:53:04 PM) aslak: i'll look through the log and create some..
(03:53:24 PM) aslak: ALR, stop log..
Comments