Hi Bartek
Hi Zoe,
First of all, I think that it might be reasonable to switch from
embedded Derby DB to embedded in-memory Derby DB. The DB configuration
for the blog sample was recently changed and instead of an external DB
instance (initialized manually) an embedded one is used. This is okay
to get rid of the problem with inconsistent DB and client libraries
versions. However, when these apps are started to be used inside
integration tests, it might be a good idea to make the embedded Derby
DB an in-memory one. Such a change was recently done to the
transaction itests - for details see ARIES-326.
This will ensure that Derby will not leave its reasources (a blogDB
directory) in Pax Exam/Runner working dir. Of course there's one
drawback - when somebody starts using the blog sample from the
assembly, with every restart of the container all entries will be lost
as the DB will be recreated:).
I think we could live with that :-)
#1 I will attach a patch to ARIES-313. In summary it:
- Moves the JDBC version of this sample to an in-memory DB and tells
Derby to create this DB (the JPA version is not moved to the in-memory
DB, but I think that this chaneg should also happen)
- Adds a simple itest (based on your JPA one) that tests the jdbc
version of this sample
- Modifies the BlogPersistenceServiceImpl class, so that it setups all
the required tables through an init-method and drops them on shutdown.
The latter is not really required as this is an in-memory DB :). This
code needs clean-up and it's extremely simple.
Similarly to what is for example done in ActveMQ when setting up the
underlying DB, it uses hardcoded SQL statements. It even does not
check if these tables are already there. It assumes that it's not
possible that those tables are in place as an embedded DB is used.
#3 In Pax Exam tests for a different project I used:
rawPaxRunnerOption("--ee", "J2SE-1.5"),
bootDelegationPackages("sun.*", "com.sun.*",
"javax.transaction", "javax.transaction.*"),
systemPackages("com.sun.org.apache.xalan.internal.xsltc.trax",
"com.sun.org.apache.xerces.internal.dom",
"com.sun.org.apache.xerces.internal.jaxp",
"com.sun.org.apache.xerces.internal.xni"),
I don't remember why sun and com.sun packages were added, but there
was a reason to add them next to javax.transaction :). I'm also using
a shorter config for system packages. Similarly to you I found it
necessary to explicitly specify system packages and not to assume that
Pax Exam/Runner will know better what packages the given env needs.
Pax normally makes this decision on the basis of Java env that is used
when running the test. The J2SE profile + those 4 packages listed
above work for all of my usecases. When Pax decided what packages are
to be used, I had some issues with J2SE-6.0
You may want to take a look at it and see if any of these settings is
useful for you.
As for installing eba files from a maven repo, I'm rather new to Aries
Application, but as far as I know you need to pass an URL or a File
pointing to your eba file to the app manager, right? If so, it might
be possible to do it using Pax Url. I'm not 100% sure, but I think
that Pax Url exposes some services that could be used at runtime
(normally it is used by Pax Runner when seeting up the container). If
so these services could be retrieved inside a test method and used to
get an URL to a maven artifact, which could then be passed to app
manager. This is just a hypothesis and needs investigation.
I'll attach the above-mentioned diff to ARIES-313 within next few minutes.
Great! I saw from ARIES-313 that you found a solution to this. I checked
your more recent patch and committed it a couple of minutes ago.
I'll do something similar for the JPA test - I also still need to remove
(or at least comment out) debug from it. Really appreciate your help
with this,
Zoe
Thanks,
Bartek
2010/5/28 zoe slattery <[email protected]>:
Hi Lin
I have just committed a test (ARIES-313) which runs but almost certainly
needs some tidying up - it would be great if someone who know how to do this
properly could take a look.
I wanted to have a complete test for the blog sample. That is, start up the
sample, get the result from
http://localhost:8080/org.apache.aries.samples.blog.web/ViewBlog and check
the response. This turned out to be a lot harder than I'd thought it would
be. The problems were:
1) Had to get the sample to make its own database. Can do this with JPA (see
Aries 317) but have not figured out a way to do it with the JDBC version.
2) The services all take a while to register after the framework starts up.
So there is code in the test that waits until every service that the sample
uses is registered. There may be better ways to do this. I have left the
debug statements in the code for now.
3) Needed to use bootDelegationPackages to stop it getting in a mess with
javax.transaction. Fortunately someone had done this in the transactions
iTests already - so I just copied :-)
Apart from tidying the code there is still one problem. In the test I
install each of the four blog sample packages separately. It would be a
better test if I were able to install the blog eba from the maven
repository. I had a look at the application tests and they write their own
eba files in the tests and then read them back, so I'm not sure how to do
this. Any ideas?
Oh - and the other issue is that it takes 2 minutes or so to run - probably
don't want to do it as part of every build?
Zoe
Hi Zoe
There is the blueprint-itest out there in
trunk/blueprint/blueprint-itest, which uses pax exam to do the test.
It installed the required bundles to the equinox 3.5 and execute the
test. I'd envision we could do something similar for blog-itest.
Lin
On Fri, May 14, 2010 at 3:17 PM, zoe slattery
<[email protected]> wrote:
Agreed - see ARIES-313. I'm not sure how to write this kind of test
(which
is at least partly why there are none for the blog sample:-) ) - happy to
work with you to create some for the blog sample.
Zoe
+1 My thoughts exactly.
On 14 May 2010, at 18:52, Lin Sun wrote:
Hi
I understand we have great samples such as blog and ariesTrader, but I
am wondering if we have plans to create automated itests for them.
Seems a very useful thing to do to help us detect potential problems
at build time and I'd be willing help a bit on this if needed.
Thanks
Lin
