[WSS-264] OSGi bundle should NOT specify the universal DynamicImport-Package: *

• Type: Improvement
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Affects Version/s: 1.5.10
• Fix Version/s: 1.6
• Component/s: WSS4J Core
• Assignee: Colm O hEigeartaigh
• Reporter: Ancoron Luciferis
• Created: 08/Jan/11 00:10
• Updated: 06/Apr/11 15:27
• Resolved: 28/Feb/11 11:13

Description

WSS4J is about security and so should the OSGi bundle at the class loading level.

In version 1.5.10 you are using this Manifest header:

DynamicImport-Package: *

which resolves all class loading issues but effectively disables the benefit of OSGi in terms of class visibility.

So please put some effort in here to get only those packages listed that may eventually being accessed at runtime.

A simple search yields only these classes for dynamic loading:

org.bouncycastle.jce.provider.BouncyCastleProvider
org.apache.security.juice.provider.JuiCEProviderOpenSSL

...so the header could be:

DynamicImport-Package: org.bouncycastle.jce.provider,org.apache.security.juice.provider

I also see that configuration properties like "org.apache.ws.security.saml.issuerClass" in the SAMLIssuerFactory class may introduce problems herewith but after all there are 2 solutions:

1.) the implementor rebuilds the WSS4J bundle and adds an appropriate dynamic import
2.) the implementor packages the implementation class inside a fragment bundle attaching to the WSS4J host bundle

Option 2 is much more elegant, keeps package/class visibility at a minimum and also does not require to customize the WSS4J OSGi bundle.