[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [virgo-dev] Virgo test framework - @BundleDependencies question
|
Glyn,
I was wrong on where BundleDependencies are applied.
These are appended to the end of the list of the Framework startup order. That is FrameworkBuilder is populated with test.config.properties and after that BundleDependencies are queried and added to the FrameworkBuilder. So it is not user region but kernel region.
To attach BundleDependencies to the user region I see few approaches:
1. Modify the timing of lookup for BundleDependencies till after OsgiTestRunner.getTargetBundleContext call and use bundleContext returned by that call to install/start extra bundle. This changes the behavior of annotation a bit. Now the attachment of BundleDependencies will depend on the runner used. In case of OsgiTestRunner, it will be system bundle context. In case of DmKernelTestRunner - it will be user region. This can potentially cause confusion.
2. Add a region property to the BundleDependencies annotation with enum KERNEL, USER to specify where to attach. In this case we again run into situation where we dependent on the runner and can lead to some confusion.
3. Introduce second annotation UserRegionBundleDependency and do all work related to this new annotation in DmKernelTestRunner after user region bundle is up. Package this annotation close to DmKernelTestRunner and document dependency. This new annotation will still require bundles to be transitively complete. A potential extension for this new annotation is a flag to use ApplicationDeployer vs. install/start with bundleContext - thus simulating initialArtifacts. With configured initialArtifacts in org.eclipse.virgo.kernel.userregion processed prior to this annotation kicking in.
I am leaning towards option 3 right now. Thoughts?
Plugins are also applied at the time of framework creation.
I was looking at possibly registering a ConfigurationPlugin to modify/inspect org.eclipse.virgo.kernel.userregion configuration on update, but plugin is only applied to ManagedService/Factory not to directly read configurations from ConfigurationAdmin (correct me if I am wrong here - just going on javadocs). RegionManager (the entity responsible for user region creation) is reading config directly.
A work around is possible where a ConfigAdminWrapper service can be registered with a higher service ranking. This wrapper will can be used to adjust configuration to add required user region bundles if baseBundles or other properties are missing.
Does the work on plugins worth the effort in light of work on bug330776-framework-hooks branch? Will there be configuration "scoping" and support for multiple user regions?
Regards,
Dmitry
On Tue, Dec 21, 2010 at 9:52 AM, Glyn Normington
<gnormington@xxxxxxxxxx> wrote:
Modulo the likelihood that the unused code has rotted, sounds great! ;-)
I'm sure you can fix any problems that are lurking...
On 21 Dec 2010, at 14:44, Dmitry Sklyut wrote:
Interesting. How about instead of killing Plugins, we keep them?
One issue that I have with the current set-up of framework is proper set-up of launcher-bundles in test.config.properties as well as other set of properties.
I would be a nice extension to have a Plugin, call it a DefaultKernelSetupPlugin that can be simply included by client to get a correctly ordered list of kernel bundles. Attributes can be something like a prefix to use to resolve location of bundles and potentially others.
Another plugin could be targeted at web container set-up. With additional properties specific to web container, i.e. port number etc.
Another plugin that I am thinking about - can be used to deploy extra bundles with help of ArtifactDeployer vs. having to provide a "transitively complete" enclosure of bundles to deploy (as BundleDependencies require now). Maybe with a new annotation like UserRegionBundleDependencies or a reuse of BundleDependencies.
Thoughts?
Regards,
Dmitry
On Tue, Dec 21, 2010 at 4:45 AM, Glyn Normington
<gnormington@xxxxxxxxxx> wrote:
On 20 Dec 2010, at 20:08, Dmitry Sklyut wrote:
> While we are on the subject of test framework - what was the idea behind @Plugins annotation and Plugin interface?
I don't think those are used, but the original idea was to support plugins of the test framework so that standard sets of bundles could be installed. The code can probably be deleted.
Regards,
Glyn
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev
_______________________________________________
virgo-dev mailing list
virgo-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/virgo-dev
