> Is a concrete example/ problem case a available at the svn? Here's the SMX testcase that I had in mind:
http://svn.apache.org/repos/asf/servicemix/smx4/features/trunk/examples/itests/tests/src/test/java/org/apache/servicemix/examples/CXFNMRIntegrationTest.java Note the logic in the getManifest() method to decorate the import- and export-packages lists with some extra entries. > What i could think of shortime is a "backdoor" option in exam to allow > hard coded bnd instructions for your probe. In this case you can do > all fancy things and we can see how to "really" do it. Yeah that would be cool. Cheers, Eoghan 2009/7/13 Toni Menzel <[email protected]>: > On 7/13/09, Eoghan Glynn <[email protected]> wrote: >> Thanks for the quick response, Toni. >> >> So just to clarify, the issue is that we need to tweak the import and >> export packages of the bundle context in which the test logic actually >> runs. >> >> This requirement comes about from the way CXF uses spring. Basically >> the upshot is that we need add some packages to the import and export >> packages, that wouldn't be obvious to a tool like BND. For example the >> way CXF loads its "extensions" from spring configs under META-INF/cxf >> means we have to add META-INF.cxf to the Import-Packages. > okay, i remember the cxf+spring combo (=dosgi).. :( > Is a concrete example/ problem case a available at the svn? > What i could think of shortime is a "backdoor" option in exam to allow > hard coded bnd instructions for your probe. In this case you can do > all fancy things and we can see how to "really" do it. > > As of TinyBundles, well, it allows you to construct any bundle of your choice. > I haven't explored the possibilities of the TinyBundles concept fully > myself. Back then i thought - and still do - that this can be a very > powerful addition to any testing framework where you need some very > special but exact bundles just for the matter of testing something. It > may be a very elegant solution to your case. Though, i have to get my > head arround this myself first ;) > > >> >> So would the "tiny bundle" idea actually address this requirement - >> specifically, would the Junit testcase logic run within the scope of >> this tiny bundle? >> >> Cheers, >> Eoghan >> >> 2009/7/13 Toni Menzel <[email protected]>: >>> On 7/13/09, Eoghan Glynn <[email protected]> wrote: >>>> Folks, >>>> >>>> I've been looking at cutting SMX4 features & NMR over to Karaf. >>>> >>>> One issue I've come across is that the features & NMR integration >>>> tests are based on the old SMX4 kernel AbstractIntegrationTest, which >>>> is itself a thin layer over spring-osgi-test framework. >>>> >>>> Now in Karaf-land, this AbstractIntegrationTest has been rebased on >>>> Pax-Exam. I'm new to Pax-Exam, so maybe I'm missing something, but I >>>> can't see an analogue for the flexibility that spring-osgi-test gives >>>> in terms of manipulating the manifest for the test bundle created >>>> on-the-fly. We need this mechanism in the feature case for example to >>>> ensure that a bunch of CXF packages are present on the Export-Packages >>>> list. >>> >>> Pax Exam's Test Bundles (we call them test probes) are - as of 1.0 - >>> fully auto mantained by pax exam. This means, you are not in control >>> of the manifest. >>> This has been stated often on mailinglists and is not really a >>> shortcoming but a definition of tests you can do with pax exam: You >>> test probe is just "orchestrating" the real bundles. This also ensures >>> you never come to the idea to really use the probe to contain real >>> logic you better want to have in a bundle you mantain yourself. >>> >>> Every bundle that is more than this orchestration (or see it as a test >>> starting point, the test activation bundle, if you want another >>> terminology) should be fully in your control. This means: treat that >>> as a real bundle. >>> >>> However, sometimes you really need "tiny bundles" that fill a gap, >>> that just exist to test a very certain concern - in cxf and can really >>> think of this very well. >>> Given this, you don't want to set up a full maven-bundle-plugin >>> project for each of those tiny bundles, .. well there is a project >>> called TinyBundles (http://wiki.ops4j.org/display/PAXSB/Tinybundles) >>> that i started for exactly this concern. >>> With this, you can create bundles (they don't have to be tiny..) on >>> the fly like so: >>> newBundle() >>> .addClass( MyFirstActivator.class ) >>> .addClass( HelloWorld.class ) >>> .addClass( HelloWorldImpl.class ) >>> .prepare( >>> withBnd() >>> .set( Constants.BUNDLE_SYMBOLICNAME, >>> "MyFirstTinyBundle" ) >>> .set( Constants.EXPORT_PACKAGE, >>> "org.ops4j.pax.tinybundles.demo" ) >>> .set( Constants.IMPORT_PACKAGE, >>> "org.ops4j.pax.tinybundles.demo" ) >>> .set( Constants.BUNDLE_ACTIVATOR, >>> MyFirstActivator.class.getName() ) >>> ).build( asStream() ); >>> >>> In this case, contents are pulled out of the current classpath (see >>> addClass) and the manifest is constructed by bnd with the ability to >>> set bnd directives. >>> >>> The output of this construct is an InputStream that you can use to >>> install inside your test. >>> This construct is very flexible and for sure needs more examples. >>> If this is something of interest i will add some asap. >>> Deployment Packages can be constructed like this too using >>> Tinybundles. But this has not been released yet (just in svn version). >>> >>> Let me know. >>> >>>> >>>> So I'm toying with the option of bringing the old kernel >>>> AbstractIntegrationTest stuff into features, while re-basing the NMR >>>> tests on the new Karaf Pax-Exam pattern. >>>> >>>> The NMR tests don't seem to need any jiggery-pokery on the manifest, >>>> so they should be OK to move across. Though the Karaf >>>> AbstractIntegrationTest isn't really set up for sharing, as its >>>> current stuck in the same module as some actual concrete tests. So >>>> this would probably need to be moved to a separate module if its going >>>> to be reused by the SMX codebases. In fact, it doesn't even seem to be >>>> built at the moment, as the itests module is excluded from the >>>> top-level pom[1]. >>>> >>>> Any thoughts or input on either of the above points? >>>> >>>> Of course, I'd be delighted if someone pipes up with an approach for >>>> manifest-manipulation with Pax-Exam, which would mean we could drop >>>> the whole spring-osgi-test thing. >>> Would love to see it ;) For sure, if there is *enough evidence* to add >>> a "manually change bnd instructions"-feature, we can simply add this >>> to exam. >>> >>>> >>>> Cheers, >>>> Eoghan >>>> >>>> [1] http://svn.apache.org/repos/asf/felix/trunk/karaf/pom.xml >>>> >>> >>> >>> -- >>> Toni Menzel >>> Independent Software Developer >>> Professional Profile: http://okidokiteam.com >>> [email protected] >>> http://www.ops4j.org - New Energy for OSS Communities - Open >>> Participation Software. >>> >> > > > -- > Toni Menzel > Independent Software Developer > Professional Profile: http://okidokiteam.com > [email protected] > http://www.ops4j.org - New Energy for OSS Communities - Open > Participation Software. >
