|
|
|
 |
|
Sort Order:
These tests should be moved to test.jca.jdo, since they are meant for ejb environment, (maybe we need to rename test.jca.jdo to test.jee.jdo, or test.ejb.jdo). Currently they use JCA, but nothing disallows having other ejbs using JTA without JCA..
I dont think we need to use this cargo stuff. we can easily download jboss and deploy the test ear application. I'm reopening and assigning to you the convergence of test.jca.jdo and test.appservers.
And how do you want to automatedly start jboss and shut it down, e.g. for continuous integration?
And why exactly do you want to do any further manual work for downloading, installing, starting, deploying, running tests via junitee and stopping the server, when this is all done for you in test.appservers without any manual intervention required?? simply because an application server deployment has proprietary characteristics and if you try to generalise it you spend more time trying to adapt and maintain your build scripts to all servers than if you do on ad-hoc basis.
I'm fine to deploy and ear application to different servers, even for jboss, manually (or with proprietary app server scripts) and run tests that can be launched as a jsp page. Abstracting from proprietary characteristics of applcation servers, that's *exactly* what cargo is for. If you look at the pom.xml, you may notice that the only jboss-specific thing is copying of a single datasource configuration file. Other servers won't make a difference.
The new test project test.appservers provides what this ticket asked for. Anything else is up to you, in a different ticket. Well, there is already a test project for application servers, and there is also a conflict of interest in this issue since you raised it and resolved the way you believe it should be without any consultation.
We have a minimum criteria in this project, and creating whatever project you like is not in our goals. if you dont understand the tests organization, then you should ask before starting to contribute. In your interest all j2ee must be converged into test.jca.jdo otherwise I will rollback these changes as I dont agree with multiplying projects. Comment from someone who doesn't use JTA/JCA/J2EE :-)
There are various environments needing testing. We have, at least, the following 1. J2EE + JCA 2. J2EE + JTA 3. OSGi 4. J2SE + local-tx 5. J2SE + JTA We need tests for all of these. We would like tests for all of these to use the same mechanism for testing (if possible). test.jca.jdo is number 1 on the list I think (never used it but the README implies JCA usage). test.jdo.jta is number 5 test.appservers is number 2 ? not been following this and not an expert on that platform so am guessing. If thats the case then the only overlap with test.jca.jdo is that they both utilise J2EE. Yes ? or no? What I would like to see is :- 1. a unified approach. This doesn't necessarily mean merging tests but it certainly should mean we have some common strategy for covering all of these 5 areas, and all tests should be working towards this strategy. "test.appservers" is at the very least inappropriately named so maybe should be "test.j2ee.jdo.jta". 2. easy to use for anyone (even me!) so I'd expect to see the same build files and process(es) under all. Doesn't mean that they all should be M2 and only M2 ... since I use M1 (currently) and Erik uses Ant. But if a new suite is provided then it needs to be accessible for others. test.appservers is number 2, yes.
test.jdo.jta relies on the J2EE spec, even though it is not a complete J2EE appserver that is being used here. Instead, it ties together parts of an appserver to provide the required container environment. My guess is that this was done because at that time it was easier to do than to set up a complete application server. So from my point of view, test.jdo.jta is number 2 as well. In the code I have not yet committed, I tie in the GeneralTest class from test.jdo.jta as a m2 dependency, so it gets run by issuing "mvn integration-test" in test.appservers (you can tell junitee in "smart" mode to look for test classes in any jars in WEB-INF/lib). I see the point of merging J2EE tests into a single project. The only question really is your requirement "2.": how do we run the tests? Funny enough, but the 3 existing test projects employ 3 different methods of running the tests: test.jdo.jca: ant test.jdo.jta: maven1 test.appservers: maven2 Since in the long run we want to move from maven1 to maven2, I'd like to further concentrate on maven2. Anybody can run it who has maven2 installed, and, most of all, "mvn integration-test" is all that needs to be issued on the command-line. we just need to follow this cardinality:
1. J2EE (JCA+JTA) - 1 project 2. OSGi - 1 project (at the moment there is none) 4. J2SE (datastore,general,etc) - 1 project per scenario RDBMS 5. J2SE (JTA) - 1 project 6. J2SE (db4o,xml,etc) - 1 project per datastore The deliverable of the J2EE project must be an EAR that you can deploy to any server manually. You run the tests via a JSP page where you can check visually the results. No need to use complicated components (cargo,junitee) to automate this. kiss approach and focus on functional tests. Ant scripts relies on m2, so they are not exclusive, but complementary. (this is not the case for ant and m1 or m1 and m2 which have different config files) You can still visually check the result with cargo and junitee, just tell cargo to wait and then invoke the URL configured for junitee on the server.
An EAR is required only for JCA, for JTA a WAR is just fine. If we want to merge things in a single test.j2ee project, we can create maven2 profiles that will deploy and test one or the other. We need to have two different ways of running the tests here anyway, since the same execution cannot use both JCA and JTA only. As I said before, automated running of the tests is a requirement for continuous integration, and continuous integration is essential for reliable software. Yes you can have both JCA and JTA tests in the same ear and run it one shot.
I don't see the point of having multiple war/ear files. There need to be different persistence properties in the classpath?
|
||||||||||||||||||||||||||||||||
Improvement
Reopened
Major
Provide integration tests with application servers
It is possible to add other application servers, provided they are support by cargo (see README.txt).