Eclipse Community Forums: Virgo » "external" directive in Bundle-ClassPath for config resources

Home » Eclipse Projects » Virgo » "external" directive in Bundle-ClassPath for config resources

"external" directive in Bundle-ClassPath for config resources [message #635465]

Tue, 26 October 2010 18:47

Eclipse User

I am looking for a way to externalize resources for optional per-installation configurations. These might include changes to the applicationContext.xml or bundle-context.xml files, locale-specific properties files, hibernate hbm.xml files and/or jasper reports. I was thinking of including the default versions in the bundles but configuring a location external to the bundle where they could be overridden. Could this be done with the external directive in Bundle-ClassPath? Since this is not a recommended approach, is there an alternate, recommended approach for doing this?

Thanks,
Ellen

Re: "external" directive in Bundle-ClassPath for config resources [message #635484 is a reply to message #635465]

Tue, 26 October 2010 23:22

Eclipse User

This kind of external classpath content has been discussed in the context of JSR 291 and also in the OSGi Alliance. There may ultimately be a solution in the form of a virtual bundle which is essentially a programmatically created Bundle object that can control its own content, but that is a long way off appearing in Equinox even if it is ever approved as a standard.

However, there is a reasonable solution today to the use cases you describe: fragment bundles. You can add classes, resources, and manifest metadata such as package imports and exports. It is even possible to leave "gaps" (in the form of named JARs) in the bundle classpath and have these filled by a fragment to override classes in the host bundle.

You can read about fragments and how to use them in the OSGi Core 4.2 specification, but feel free to ask here if you have questions not answered by the spec.

Essentially, Virgo automatically installs fragments present in its repository when the host is installed - part of the way we satisfy dependencies. So you would put the optional fragments needed for a particular installation somewhere in the repository chain.

Re: "external" directive in Bundle-ClassPath for config resources [message #635681 is a reply to message #635484]

Wed, 27 October 2010 13:28

Eclipse User

+1 for fragments.

One issue that I have with fragments is that you need to refresh host bundle when fragment changes. That might cause a fairly long resolution cycle if there are other bundles depending on your host bundle.

When using fragments for resources like locale specific files or "static" content, I found that following scenario works best if you need both dynamics and externalized resources.

Use services! Services decouple bundle and dynamic in nature.
I have API bundle, Service bundle that implements API from the bundle and another service bundle that for something like MyConfiguration implements Configuration.
Configuration might have methods to find ResourceBundles/Properties/URIs to images, domain specific methods to retrieve config property values, etc...

When I need to refresh the external config only bundle that is affected is a config service bundle. Refresh that and fragment is attached, services is re-deployed and no nasty cascade to all dependent bundles.
If you use SpringDM/DS/etc client of MyConfiguration service might not even notice that it went away for a sec.

Regards,
Dmitry

Re: "external" directive in Bundle-ClassPath for config resources [message #635759 is a reply to message #635484]

Wed, 27 October 2010 21:55

Eclipse User

Thanks, Glyn. I have read the spec where it pertains to Fragment bundles and have some questions -

If Virgo attaches a fragment bundle to a host, does it log which bundle was attached?

I am assuming that the fragment bundle should be placed in the resources/usr directory - is this correct?

Does the fragment have to be named anywhere as a possible extension to the host bundle (like in a plan, etc.) or is its presence all that is needed?

Is any type of resource valid and usable by the host if included in an attached fragment? (Images, for example)or is there a limit to the types of things that should be included in the fragment?

Can a fragment bundle be used with a war bundle?

I tried making a fragment bundle that is a jar file. All it contains is an "images" directory at the bundle root and a manifest:

Manifest-Version: 1.0
Bundle-ClassPath: .
JDK_VERSION: 1.6
Built-By: estrnod
Tool: Bnd-0.0.357
Bundle-Name: Configuration Bundle
Created-By: Apache Maven Bundle Plugin
Fragment-Host: host.bundle.symbolic.name
Build-Jdk: 1.6.0_16
Bundle-Version: 1.1.0.b
Bnd-LastModified: 1288223456259
BundlePermission: [host.bundle.symbolic.name,FRAGMENT]
Bundle-ManifestVersion: 2
Bundle-SymbolicName: config.fragment.bundle

The host bundle is the original war file bundle with the "images" directory removed (moved to the fragment). This images directory was also at the root of its bundle before I moved it. The host bundle manifest:

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: 1.6.0_16 (Sun Microsystems Inc.)
Built-By: estrnod
Build-Jdk: 1.6.0_16
JDK_VERSION: 1.6
Tool: Bnd-0.0.357
Bundle-Name: Web Application Bundle
Import-Library: org.springframework.spring;version="[3.0.0.RELEASE,3.0
 .0.RELEASE]"
Web-ContextPath: myapp
Import-Bundle: <elided>
Bundle-Version: 1.1.0.b
BundlePermission: [host.bundle.symbolic.name,HOST]
Bnd-LastModified: 1288226901394
Bundle-ManifestVersion: 2
Import-Package: <elided>
Bundle-SymbolicName: host.bundle.symbolic.name

Both the host and fragment bundles are in the resources/usr directory. The host bundle is named in a plan in the pickup directory but the fragment bundle is not. There is no evidence that the fragment bundle was attached to the host, and when I view the website, the images are not present. Is there anything else I need to do to get the fragment to be "attached"? Or, did it probably already attach, and I just can't provide images to a war file in this manner (and need to try some other resource as an example)?

Thanks,
Ellen

Re: "external" directive in Bundle-ClassPath for config resources [message #635767 is a reply to message #635759]

Wed, 27 October 2010 23:26

Eclipse User

estrnod wrote on Thu, 28 October 2010 02:55

Thanks, Glyn. I have read the spec where it pertains to Fragment bundles and have some questions -

If Virgo attaches a fragment bundle to a host, does it log which bundle was attached?

No, but you can see the relationship between fragments and hosts in the admin console or the Equinox console. For an example, see the Catalina ha and tribes bundles which attach to the main Catalina bundle.

Quote:

I am assuming that the fragment bundle should be placed in the resources/usr directory - is this correct?

Yes.

Quote:

Does the fragment have to be named anywhere as a possible extension to the host bundle (like in a plan, etc.) or is its presence all that is needed?

Its presence in the repository is all that is needed.

Quote:

Is any type of resource valid and usable by the host if included in an attached fragment? (Images, for example)or is there a limit to the types of things that should be included in the fragment?

I think any resource is valid.

Quote:

Can a fragment bundle be used with a war bundle?

I don't see why not, provided the fragment-host header in the fragment refers to the correct bundle symbolic name, which is automatically generated for a WAR file that doesn't specify a bundle symbolic name.

Quote:

I tried making a fragment bundle that is a jar file. All it contains is an "images" directory at the bundle root and a manifest:

Manifest-Version: 1.0
Bundle-ClassPath: .
JDK_VERSION: 1.6
Built-By: estrnod
Tool: Bnd-0.0.357
Bundle-Name: Configuration Bundle
Created-By: Apache Maven Bundle Plugin
Fragment-Host: host.bundle.symbolic.name
Build-Jdk: 1.6.0_16
Bundle-Version: 1.1.0.b
Bnd-LastModified: 1288223456259
BundlePermission: [host.bundle.symbolic.name,FRAGMENT]
Bundle-ManifestVersion: 2
Bundle-SymbolicName: config.fragment.bundle

Manifest-Version: 1.0
Archiver-Version: Plexus Archiver
Created-By: 1.6.0_16 (Sun Microsystems Inc.)
Built-By: estrnod
Build-Jdk: 1.6.0_16
JDK_VERSION: 1.6
Tool: Bnd-0.0.357
Bundle-Name: Web Application Bundle
Import-Library: org.springframework.spring;version="[3.0.0.RELEASE,3.0
 .0.RELEASE]"
Web-ContextPath: myapp
Import-Bundle: <elided>
Bundle-Version: 1.1.0.b
BundlePermission: [host.bundle.symbolic.name,HOST]
Bnd-LastModified: 1288226901394
Bundle-ManifestVersion: 2
Import-Package: <elided>
Bundle-SymbolicName: host.bundle.symbolic.name

Take a look in the admin console. The only thing slightly out of the ordinary is the security permissions, so you could try without those and see if that helps. If it does, you are missing some permissions.

Quote:

Thanks,
Ellen

Hope that helps.

Re: "external" directive in Bundle-ClassPath for config resources [message #635768 is a reply to message #635767]

Wed, 27 October 2010 23:37

Eclipse User

I did try it first without the permissions and it wasn't working (same issue) so I added them (having seen them in the spec.)

Re: "external" directive in Bundle-ClassPath for config resources [message #635770 is a reply to message #635768]

Wed, 27 October 2010 23:42

Eclipse User

On the face of it, this is looking like a bug.

You can list the fragment in a plan, so you might want to try that for comparison.

Re: "external" directive in Bundle-ClassPath for config resources [message #635781 is a reply to message #635770]

Thu, 28 October 2010 01:45

Eclipse User

When I add the fragment to the plan, it is loaded and the images are found for the website.

Re: "external" directive in Bundle-ClassPath for config resources [message #635795 is a reply to message #635781]

Thu, 28 October 2010 03:49

Eclipse User

I took your manifests and created a simple example that works. index.html is correctly served from the web app but is provided by the fragment.

I put host.jar in pickup and fragment.jar in repository/usr, started the server, checked the fragment was attached using the OSGi state pane of the admin console, then drove http://localhost:8080/myapp and saw "Hello World!".

Perhaps you'd like to try using these examples and then you can compare and contrast with your code to spot what the difference is?

Attachment: host.jar
(Size: 23.72KB, Downloaded 341 times)

Re: "external" directive in Bundle-ClassPath for config resources [message #635796 is a reply to message #635795]

Thu, 28 October 2010 03:49

Eclipse User

Here's the fragment.

Attachment: fragment.jar
(Size: 0.68KB, Downloaded 327 times)

Re: "external" directive in Bundle-ClassPath for config resources [message #635909 is a reply to message #635796]

Thu, 28 October 2010 11:09

Eclipse User

Maybe if they were zipped together in a zip file for download they might work, but I'm having trouble with Virgo recognizing the fragment & host jars as valid jars. But I placed my war file in the pickup directory as you did and removed the plan file for it, and restarted Virgo, and the fragment got picked up.

(The plan is scoped and atomic. )

Re: "external" directive in Bundle-ClassPath for config resources [message #635915 is a reply to message #635909]

Thu, 28 October 2010 11:21

Eclipse User

Ok, so I changed the plan to be unscoped and atomic (and removed its reference to the fragment), restored it to the pickup directory, and moved the war file back to the repository. The host and fragment were both loaded.

It appears that a scoped plan doesn't load fragments for its artifacts automatically. Is this a bug? One of the (big) reasons I have it scoped is so I can have logging for bundles in the plan separate from other bundles' logging.

Re: "external" directive in Bundle-ClassPath for config resources [message #636521 is a reply to message #635915]

Mon, 01 November 2010 12:55

Eclipse User

Scoping may cause the fragment to fail to resolve because of some uses constraint failure introduced by scoping (which draws together all the exports of the contents of the scope and imports them into the generated "synthetic context" bundle).

Virgo will only flag a failure to resolve a fragment as an error if the fragment is part of a plan being deployed as it will then spot that the fragment did not resolve. (Normal OSGi semantics apply otherwise - a fragment failing to attach is not an error.)

I guess that making the plan unscoped ensures that the fragment does resolve and so it can attach to its host.

So the case I would like to understand better is where you list the fragment in the plan and you make the plan scoped (for your logging requirement). Does this work? If it does, it sounds pretty good as you are specifying (in the plan) the need for the fragment to be resolved. If it doesn't work, do you see any symptoms apart from the fragment not attaching? If there are no symptoms, this may be a bug.

Previous Topic:	Virgo 2.1.0 Release Available
Next Topic:	Adding bundle to dm server to extend tomcat

Goto Forum:

-=] Back to Top [=-

Current Time: Sun May 18 10:28:27 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter