Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 338113

Summary:	RegionDigraph should allow all exported packages of allowed bundles
Product:	[RT] Virgo	Reporter:	Glyn Normington <glyn.normington>
Component:	runtime	Assignee:	Glyn Normington <glyn.normington>
Status:	CLOSED FIXED	QA Contact:
Severity:	normal
Priority:	P3	CC:	b.kapukaranov, hsiliev, tjwatson, zteve.powell
Version:	3.0.0.M01
Target Milestone:	3.0.0.M03
Hardware:	All
OS:	All
Whiteboard:

Description Glyn Normington

2011-02-24 11:16:22 EST

Currently if a bundle is allowed to be visible between regions, then package filtering is applied to the bundle's exported packages, so they won't necessarily be visible too. There isn't a good use case for this and it tends to result in extra configuration being necessary.

The proposal is to change the behaviour so that package filtering is not applied to packages exported by bundles which are allowed by a region filter.

The user region properties should also be tidied up as the package imports that were added for system bundle packages will no longer be needed.

Comment 1 Thomas Watson

2011-02-24 12:25:20 EST

Take this all with a grain of salt, but I have some suggestions for RegionFilter.

In my opinion the filter of resources should be a generic as possible.  Right now RegionFilter splits shared resources into three categories.

- allowed bundles
- java packages
- osgi services

It may be better to use the namespace approach used by OSGi for the generic requirements/capabilities.

For example, there are three built-in namespaces in osgi

osgi.wiring.package - to represent java package capabilities/requirements

osgi.wiring.bundle - to represent bundle capability/requirement for resolving Require-Bundle

osgi.wiring.host - to represent host capability/requirement for resolving Fragment-Host

OSGi leaves all other namespaces that are not prepended by osgi.* to be generic capabilities/requirements as specified by the Provide-Capability and Require-Capability headers.

What you could do is define your own namespace constants for sharing services and allowing bundles across regions.  Something like this:

virgo.allow.bundle - namespace for allowing bundles into a region
virgo.allow.service - namespace for allowing services into a region

Then you could replace the the six methods on RegionFilter with this:

public void setPolicy(String namespace, Filter policy);
public Filter getPolicy(String namespace);

Where the Map uses the namespace as the key (e.g. osgi.wiring.package etc.) and the value is the Filter for matching the shared resource.  

The virgo.allow.service namespace would be used by the service hooks to call Filter.match(ServiceReference) method, much like I imagine you do today.

Filter filter = regionFilter.getPolicy("virgo.allow.service");
boolean allow = 
  filter == null ? false : filter.match(serviceReference);


In the resolver hook you would call something like this:

Filter filter = regionFilter.getPolicy(BundleCapability.getNamespace());
boolean allow = 
  filter == null ? false : filter.matches(BundleCapability.getAttributes());

The tricky part is the virgo.allow.bundle namespace for bundle hooks.  Here you would have to create a Map to hold the BSN and version

Filter filter = regionFilter.getPolicy("virgo.allow.bundle");
Map<String, Object> bundleAttrs = new HashMap();
bundleAttrs.put("bundle-symbolic-name", bundle.getSymbolicName());
bundleAttrs.put("bundle-version", bundle.getVersion());
boolean allow = 
  filter == null ? false : filter.matches(bundleAttrs);

Perhaps that would pose a performance issue and you could decide to keep the allowBundle and isBundleAllowed methods on RegionFilter.

Comment 2 Glyn Normington

2011-02-24 17:04:03 EST

In discussion in Southampton, it was mentioned that SAP may have requirements to subset the packages available from e.g. the system bundle in order to construct "sandbox" regions. If this bug was implemented, then it would be necessary to filter out the system bundle and filter in some of its packages. However, application bundles might be surprised by the absence of a system bundle, leading to bug reports.

Perhaps SAP would like to comment?

Comment 3 Glyn Normington

2011-02-24 17:05:32 EST

(In reply to comment #1)

Thanks Tom. Definitely worth considering.

Comment 4 Glyn Normington

2011-03-01 07:00:13 EST

(In reply to comment #1)
I raised bug 338525 to cover this enhancement suggestion.

Comment 5 Hristo Iliev

2011-03-01 08:13:00 EST

(In reply to comment #2)
> In discussion in Southampton, it was mentioned that SAP may have requirements
> to subset the packages available from e.g. the system bundle in order to
> construct "sandbox" regions. If this bug was implemented, then it would be
> necessary to filter out the system bundle and filter in some of its packages.
> However, application bundles might be surprised by the absence of a system
> bundle, leading to bug reports.
> 
> Perhaps SAP would like to comment?

I think we have no objections and a "sandbox" can still be achieved with this change.

In fact this may even help with P2 integration since it makes the configuration easier to model.

Comment 6 Glyn Normington

2011-03-01 09:29:24 EST

(In reply to comment #5)
> (In reply to comment #2)
> > In discussion in Southampton, it was mentioned that SAP may have requirements
> > to subset the packages available from e.g. the system bundle in order to
> > construct "sandbox" regions. If this bug was implemented, then it would be
> > necessary to filter out the system bundle and filter in some of its packages.
> > However, application bundles might be surprised by the absence of a system
> > bundle, leading to bug reports.
> > 
> > Perhaps SAP would like to comment?
> 
> I think we have no objections and a "sandbox" can still be achieved with this
> change.
> 
> In fact this may even help with P2 integration since it makes the configuration
> easier to model.

Thanks!