You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Bartosz Kowalewski <ko...@gmail.com> on 2010/05/21 02:00:53 UTC
The blueprint-itests project and approaches to using Pax Exam
Hi All,
I'm rather new to Apache Aries (at least I haven't played with the
source code a lot). However, today I had an opportunity to dig in,
because I needed ARIES-9 to be fixed. As a part of the fix that I
provided I also created a new Pax Exam test for blueprint-core. I
learned that all tests that are available in blueprint-itests project
use a shared test bundle (blueprint-sample) with a single file that
contains Blueprint definitions. This means that with every test run
all definitions from this sample Blueprint bundle are processed and we
get lots of components. Each test case uses only a subset of these
components. I'm wondering if you ever thought of refactoring these
tests, so that each test class would use its own sample blueprint
bundle? I know that using tens of test/sample Maven projects would not
be acceptable :). I was rather thinking of using swissbox tinybundles
and generating the sample bundles with Blueprint definitions at
runtime. Here's an example of similar code that I created for Spring
powered bundles some time ago:
protected Option generateBundle(String symbolicName,
Class<?>[] classesToAdd, String[] importedPackages,
String[] exportedPackages, InputStream springContextContents)
{
// Note: we do not check if parameters are not null; NPEs will be thrown
TinyBundle generatedBundle = newBundle();
if (classesToAdd != null)
{
for (Class<?> clazz : classesToAdd)
{
generatedBundle.add(clazz);
}
}
generatedBundle.add("META-INF/spring/generated-" + symbolicName
+ ".xml", springContextContents);
generatedBundle.set(Constants.BUNDLE_NAME, symbolicName);
generatedBundle.set(Constants.BUNDLE_SYMBOLICNAME, symbolicName);
//generatedBundle.set(Constants.DYNAMICIMPORT_PACKAGE, "*");
StringBuilder sb = new StringBuilder();
if (importedPackages.length > 0)
{
sb.append(importedPackages[0]);
}
for (int i = 1; i < importedPackages.length; i++)
{
sb.append("," + importedPackages[i]);
}
generatedBundle.set(Constants.IMPORT_PACKAGE, sb.toString());
sb.setLength(0);
if (exportedPackages.length > 0)
{
sb.append(exportedPackages[0]);
}
for (int i = 1; i < exportedPackages.length; i++)
{
sb.append("," + exportedPackages[i]);
}
generatedBundle.set(Constants.EXPORT_PACKAGE, sb.toString());
// replace Spring specific names with constants?
generatedBundle.set("Spring-Context",
"*;publish-context:=true;create-asynchronously:=false");
return provision(generatedBundle.build(withBnd()));
}
A similar approach can be used to generate Blueprint bundles. Such a
generated bundle can then be passed to Pax Exam.
There's one significant drawback the approach taht I'm proposing. You
also need to customize the Pax Exam test probe (again using Tiny
Bundles :) ) and remove the resources and classes that you want only
to be available in the generated sample Blueprint (or Spring powered)
bundle. By default these resources would also be used by Pax Exam when
creating the test probe.
Thanks,
Bartek
Re: The blueprint-itests project and approaches to using Pax Exam
Posted by Lin Sun <li...@gmail.com>.
Hi Bartek,
No prob, thanks a bunch in thinking of how to improve the Aries project.
Lin
On Fri, May 21, 2010 at 6:21 PM, Bartosz Kowalewski
<ko...@gmail.com> wrote:
> Hi Lin,
>
> Thanks a lot for this pointer. I previously only took a look at
> Blueprint and the integration tests that are defined there. That is
> why I missed this nice fixture which is used in other itests projects.
> My fault :).
>
> Best regards,
> Bartek
>
> 2010/5/21 Lin Sun <li...@gmail.com>:
>> Hi Bartek,
>>
>> Thanks. I think we have something similar in our unittest already, it
>> is called ArchiveFixture which you can use to construct your archive
>> you want.
>>
>> For example, see the BasicAppManagerTest in
>> org.apache.aries.application.runtime.itests.
>>
>> Lin
>>
>> On Thu, May 20, 2010 at 8:00 PM, Bartosz Kowalewski
>> <ko...@gmail.com> wrote:
>>> Hi All,
>>>
>>> I'm rather new to Apache Aries (at least I haven't played with the
>>> source code a lot). However, today I had an opportunity to dig in,
>>> because I needed ARIES-9 to be fixed. As a part of the fix that I
>>> provided I also created a new Pax Exam test for blueprint-core. I
>>> learned that all tests that are available in blueprint-itests project
>>> use a shared test bundle (blueprint-sample) with a single file that
>>> contains Blueprint definitions. This means that with every test run
>>> all definitions from this sample Blueprint bundle are processed and we
>>> get lots of components. Each test case uses only a subset of these
>>> components. I'm wondering if you ever thought of refactoring these
>>> tests, so that each test class would use its own sample blueprint
>>> bundle? I know that using tens of test/sample Maven projects would not
>>> be acceptable :). I was rather thinking of using swissbox tinybundles
>>> and generating the sample bundles with Blueprint definitions at
>>> runtime. Here's an example of similar code that I created for Spring
>>> powered bundles some time ago:
>>>
>>> protected Option generateBundle(String symbolicName,
>>> Class<?>[] classesToAdd, String[] importedPackages,
>>> String[] exportedPackages, InputStream springContextContents)
>>> {
>>> // Note: we do not check if parameters are not null; NPEs will be thrown
>>>
>>> TinyBundle generatedBundle = newBundle();
>>> if (classesToAdd != null)
>>> {
>>> for (Class<?> clazz : classesToAdd)
>>> {
>>> generatedBundle.add(clazz);
>>> }
>>> }
>>>
>>> generatedBundle.add("META-INF/spring/generated-" + symbolicName
>>> + ".xml", springContextContents);
>>> generatedBundle.set(Constants.BUNDLE_NAME, symbolicName);
>>> generatedBundle.set(Constants.BUNDLE_SYMBOLICNAME, symbolicName);
>>>
>>> //generatedBundle.set(Constants.DYNAMICIMPORT_PACKAGE, "*");
>>>
>>> StringBuilder sb = new StringBuilder();
>>> if (importedPackages.length > 0)
>>> {
>>> sb.append(importedPackages[0]);
>>> }
>>> for (int i = 1; i < importedPackages.length; i++)
>>> {
>>> sb.append("," + importedPackages[i]);
>>> }
>>> generatedBundle.set(Constants.IMPORT_PACKAGE, sb.toString());
>>>
>>> sb.setLength(0);
>>> if (exportedPackages.length > 0)
>>> {
>>> sb.append(exportedPackages[0]);
>>> }
>>> for (int i = 1; i < exportedPackages.length; i++)
>>> {
>>> sb.append("," + exportedPackages[i]);
>>> }
>>> generatedBundle.set(Constants.EXPORT_PACKAGE, sb.toString());
>>>
>>> // replace Spring specific names with constants?
>>> generatedBundle.set("Spring-Context",
>>> "*;publish-context:=true;create-asynchronously:=false");
>>>
>>> return provision(generatedBundle.build(withBnd()));
>>> }
>>>
>>> A similar approach can be used to generate Blueprint bundles. Such a
>>> generated bundle can then be passed to Pax Exam.
>>>
>>> There's one significant drawback the approach taht I'm proposing. You
>>> also need to customize the Pax Exam test probe (again using Tiny
>>> Bundles :) ) and remove the resources and classes that you want only
>>> to be available in the generated sample Blueprint (or Spring powered)
>>> bundle. By default these resources would also be used by Pax Exam when
>>> creating the test probe.
>>>
>>> Thanks,
>>> Bartek
>>>
>>
>
Re: The blueprint-itests project and approaches to using Pax Exam
Posted by Bartosz Kowalewski <ko...@gmail.com>.
Hi Lin,
Thanks a lot for this pointer. I previously only took a look at
Blueprint and the integration tests that are defined there. That is
why I missed this nice fixture which is used in other itests projects.
My fault :).
Best regards,
Bartek
2010/5/21 Lin Sun <li...@gmail.com>:
> Hi Bartek,
>
> Thanks. I think we have something similar in our unittest already, it
> is called ArchiveFixture which you can use to construct your archive
> you want.
>
> For example, see the BasicAppManagerTest in
> org.apache.aries.application.runtime.itests.
>
> Lin
>
> On Thu, May 20, 2010 at 8:00 PM, Bartosz Kowalewski
> <ko...@gmail.com> wrote:
>> Hi All,
>>
>> I'm rather new to Apache Aries (at least I haven't played with the
>> source code a lot). However, today I had an opportunity to dig in,
>> because I needed ARIES-9 to be fixed. As a part of the fix that I
>> provided I also created a new Pax Exam test for blueprint-core. I
>> learned that all tests that are available in blueprint-itests project
>> use a shared test bundle (blueprint-sample) with a single file that
>> contains Blueprint definitions. This means that with every test run
>> all definitions from this sample Blueprint bundle are processed and we
>> get lots of components. Each test case uses only a subset of these
>> components. I'm wondering if you ever thought of refactoring these
>> tests, so that each test class would use its own sample blueprint
>> bundle? I know that using tens of test/sample Maven projects would not
>> be acceptable :). I was rather thinking of using swissbox tinybundles
>> and generating the sample bundles with Blueprint definitions at
>> runtime. Here's an example of similar code that I created for Spring
>> powered bundles some time ago:
>>
>> protected Option generateBundle(String symbolicName,
>> Class<?>[] classesToAdd, String[] importedPackages,
>> String[] exportedPackages, InputStream springContextContents)
>> {
>> // Note: we do not check if parameters are not null; NPEs will be thrown
>>
>> TinyBundle generatedBundle = newBundle();
>> if (classesToAdd != null)
>> {
>> for (Class<?> clazz : classesToAdd)
>> {
>> generatedBundle.add(clazz);
>> }
>> }
>>
>> generatedBundle.add("META-INF/spring/generated-" + symbolicName
>> + ".xml", springContextContents);
>> generatedBundle.set(Constants.BUNDLE_NAME, symbolicName);
>> generatedBundle.set(Constants.BUNDLE_SYMBOLICNAME, symbolicName);
>>
>> //generatedBundle.set(Constants.DYNAMICIMPORT_PACKAGE, "*");
>>
>> StringBuilder sb = new StringBuilder();
>> if (importedPackages.length > 0)
>> {
>> sb.append(importedPackages[0]);
>> }
>> for (int i = 1; i < importedPackages.length; i++)
>> {
>> sb.append("," + importedPackages[i]);
>> }
>> generatedBundle.set(Constants.IMPORT_PACKAGE, sb.toString());
>>
>> sb.setLength(0);
>> if (exportedPackages.length > 0)
>> {
>> sb.append(exportedPackages[0]);
>> }
>> for (int i = 1; i < exportedPackages.length; i++)
>> {
>> sb.append("," + exportedPackages[i]);
>> }
>> generatedBundle.set(Constants.EXPORT_PACKAGE, sb.toString());
>>
>> // replace Spring specific names with constants?
>> generatedBundle.set("Spring-Context",
>> "*;publish-context:=true;create-asynchronously:=false");
>>
>> return provision(generatedBundle.build(withBnd()));
>> }
>>
>> A similar approach can be used to generate Blueprint bundles. Such a
>> generated bundle can then be passed to Pax Exam.
>>
>> There's one significant drawback the approach taht I'm proposing. You
>> also need to customize the Pax Exam test probe (again using Tiny
>> Bundles :) ) and remove the resources and classes that you want only
>> to be available in the generated sample Blueprint (or Spring powered)
>> bundle. By default these resources would also be used by Pax Exam when
>> creating the test probe.
>>
>> Thanks,
>> Bartek
>>
>
Re: The blueprint-itests project and approaches to using Pax Exam
Posted by Lin Sun <li...@gmail.com>.
Hi Bartek,
Thanks. I think we have something similar in our unittest already, it
is called ArchiveFixture which you can use to construct your archive
you want.
For example, see the BasicAppManagerTest in
org.apache.aries.application.runtime.itests.
Lin
On Thu, May 20, 2010 at 8:00 PM, Bartosz Kowalewski
<ko...@gmail.com> wrote:
> Hi All,
>
> I'm rather new to Apache Aries (at least I haven't played with the
> source code a lot). However, today I had an opportunity to dig in,
> because I needed ARIES-9 to be fixed. As a part of the fix that I
> provided I also created a new Pax Exam test for blueprint-core. I
> learned that all tests that are available in blueprint-itests project
> use a shared test bundle (blueprint-sample) with a single file that
> contains Blueprint definitions. This means that with every test run
> all definitions from this sample Blueprint bundle are processed and we
> get lots of components. Each test case uses only a subset of these
> components. I'm wondering if you ever thought of refactoring these
> tests, so that each test class would use its own sample blueprint
> bundle? I know that using tens of test/sample Maven projects would not
> be acceptable :). I was rather thinking of using swissbox tinybundles
> and generating the sample bundles with Blueprint definitions at
> runtime. Here's an example of similar code that I created for Spring
> powered bundles some time ago:
>
> protected Option generateBundle(String symbolicName,
> Class<?>[] classesToAdd, String[] importedPackages,
> String[] exportedPackages, InputStream springContextContents)
> {
> // Note: we do not check if parameters are not null; NPEs will be thrown
>
> TinyBundle generatedBundle = newBundle();
> if (classesToAdd != null)
> {
> for (Class<?> clazz : classesToAdd)
> {
> generatedBundle.add(clazz);
> }
> }
>
> generatedBundle.add("META-INF/spring/generated-" + symbolicName
> + ".xml", springContextContents);
> generatedBundle.set(Constants.BUNDLE_NAME, symbolicName);
> generatedBundle.set(Constants.BUNDLE_SYMBOLICNAME, symbolicName);
>
> //generatedBundle.set(Constants.DYNAMICIMPORT_PACKAGE, "*");
>
> StringBuilder sb = new StringBuilder();
> if (importedPackages.length > 0)
> {
> sb.append(importedPackages[0]);
> }
> for (int i = 1; i < importedPackages.length; i++)
> {
> sb.append("," + importedPackages[i]);
> }
> generatedBundle.set(Constants.IMPORT_PACKAGE, sb.toString());
>
> sb.setLength(0);
> if (exportedPackages.length > 0)
> {
> sb.append(exportedPackages[0]);
> }
> for (int i = 1; i < exportedPackages.length; i++)
> {
> sb.append("," + exportedPackages[i]);
> }
> generatedBundle.set(Constants.EXPORT_PACKAGE, sb.toString());
>
> // replace Spring specific names with constants?
> generatedBundle.set("Spring-Context",
> "*;publish-context:=true;create-asynchronously:=false");
>
> return provision(generatedBundle.build(withBnd()));
> }
>
> A similar approach can be used to generate Blueprint bundles. Such a
> generated bundle can then be passed to Pax Exam.
>
> There's one significant drawback the approach taht I'm proposing. You
> also need to customize the Pax Exam test probe (again using Tiny
> Bundles :) ) and remove the resources and classes that you want only
> to be available in the generated sample Blueprint (or Spring powered)
> bundle. By default these resources would also be used by Pax Exam when
> creating the test probe.
>
> Thanks,
> Bartek
>