You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Lin Sun <li...@gmail.com> on 2010/05/14 19:52:17 UTC
create itest for samples
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
Re: create itest for samples
Posted by zoe slattery <zo...@googlemail.com>.
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 <zo...@googlemail.com>:
>
>> 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
>>> <zo...@googlemail.com> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
>
Re: create itest for samples
Posted by Bartosz Kowalewski <ko...@gmail.com>.
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:).
#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.
Thanks,
Bartek
2010/5/28 zoe slattery <zo...@googlemail.com>:
> 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
>> <zo...@googlemail.com> 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
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>
Re: create itest for samples
Posted by zoe slattery <zo...@googlemail.com>.
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
> <zo...@googlemail.com> 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
>>>>
>>>>
>>>
>>>
>>
>
>
Re: create itest for samples
Posted by Lin Sun <li...@gmail.com>.
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
<zo...@googlemail.com> 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
>>>
>>
>>
>>
>
>
Re: create itest for samples
Posted by zoe slattery <zo...@googlemail.com>.
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
>>
>
>
>
Re: create itest for samples
Posted by Valentin Mahrwald <vm...@googlemail.com>.
+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