It must be possible to create a BundleArchive from within the OSGi Framework. i.e. A (test) Bundle can generate shrinkwrap bundles

The way we currently achieve this in our standalone Runtime is that the Arquillian injected OSGiContainer makes a decoupled (maybe even remote) JMX call to the test client. The Shrinkwrap bundle archive is created in the context of the client and the wrapped bytes are returned and installed in the Runtime.

In contrast to this approach, if you create the shrinkwrap archive in the context of a test bundle ( i.e. there is SW API access or an SW OSGi service) by definition the assets you wrap must be visible by the bundle that uses the SW API.

archive.addClasses(Foo.class);

Inevitably, Foo.class would be duplicated in the Framework. This might have unexpected, undesired or negative effects on testing Foo.

Lets have a few posts on the proposed API and a conceptual description of how this is supposed to work ...

ARQ now supports the notion of multiple target containers over multiple protocols with multiple deployments. It also extended the event model to send events back and forth from the container to the test client over the given protocol. So you can do thinks like ...

* deploy testable archiveA to containerA

* deploy plain archive to containerB

* make testA call back to test client and fetch archiveC

It seems that the logical approach would be to port the ARQ OSGi functionality to the latest ARQ first. If the event callback functionality should not work as expected then it should be fixed at the ARQ level.

Aslak, seemed to have looked and learned from the OSGi integration considerably. Much of what I did for OSGi is now generally available in ARQ and part of the overall test strategy.

This in particular caused issues for us in the past. I think we have a few options here:

follow the pattern we had in the past with a JMX callback

use some sort of other remote protocol to obtain the test archive

actually not make a remote callback from the test class and produce test archiveC in testA somehow.

I'm personally not a big fan of options 1 and 2 since they make the test hard to follow (IMHO) and require a remote communication back and forth between the test (running in an OSGi framework) and the test client (not running in OSGi). In addition to that were the actual technical problems in the recent past that were holding us back in 1.

I'd be much more in favour of option 3 since it makes the test easier to follow and understand, so I started experimenting with this.

For this, you first need Shrinkwrap to be usable from inside OSGi. This is possibly generally useful outside of this context too, and I think I've got most of this done now (SHRINKWRAP-242) (btw this doesn't include the API change as suggested in SHRINKWRAP-139).

Then you do have the disadvantage that you can't make calls any more such as

{code}archive.addClasses(Foo.class){code}

as the "Foo.class" object is not available to the classloader. Instead you'd have to do something like

{code}URL url = ... // get url to org/acme/foo/Foo.class resource

archive.addResource(url){code}

While this may seem like an inconvenience I think it's ok and possibly outweighs the complexity introduced by options 1 and 2. You can wrap those calls in a method in your test to get back to a simple addToArchive(archive, "org.acme.foo.Foo") or something like that.

Thomas Diesler wrote:

Aslak, seemed to have looked and learned from the OSGi integration considerably. Much of what I did for OSGi is now generally available in ARQ and part of the overall test strategy.

Ok - what I currently have works on the jbosgi branch of ARQ with one of our performance tests - I'll look into starting from ARQ master next.

At the end of the day you will probably find that it is nonsense to assemble the shrinkwrap archives in the target container. Especially if you have a variety of target containers at various locations and a variety of test deployments not all of which will be osgi bundles. Especially in AS7 were class/resource visibility is very strictly controlled you would have to use a thing that has very little to do with the fundaments of shrinkwarp.

Any deployment that makes it into AS7 comes via the ServerDeploymentManager API. Yes, AS7 hot-deployment is also a client of that API. This API already works by sending serialized objects back and forth on a communication channel - the port is 9999. The exception to this rule is remote access to the Aries JMX API, which only works for OSGi bundles. Going forward, it makes sense to use the AS7 API for any deployment including OSGi bundles. So JMX would not be used as the deployment channel.

Given that the ARQ test client already uses a remote communication channel I believe that it is only natural to use that channel to fetch additional deployments from the client side. You would not even have to touch shrinkwrap to make this work

I'll look into starting from ARQ master next.

Please check with Aslak how this client-server event thing is supposed to work with AS7. Is this supposed to go over the test communication channel, the deployment communication channel or something else independent of protocol and deployment? It is not in master yet AFAICS.

Maybe you like to spread the word about your intended ARQ/Shrinkwrap approach on the AS7/SW dev forums. I'd like to hear what folks from all teams say when they hear that they will have to use one API in @Deployment and another in a different portion of the test case when there are deployments generated at test runtime.

It is also possible that this problem is unique to the OSGi benchmark tests and that it is generally sufficient to have multiple test deployments, which are not parameterized and can all get generated before the test is executed i.e. just like the @Deployment archive