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

Bug 327885

Summary:	StateObjectFactory.createBundleDescription case sensitivity
Product:	[Eclipse Project] Equinox	Reporter:	Glyn Normington <glyn.normington>
Component:	Framework	Assignee:	equinox.framework-inbox <equinox.framework-inbox>
Status:	RESOLVED WONTFIX	QA Contact:
Severity:	minor
Priority:	P3	CC:	alex.blewitt, tjwatson
Version:	3.6.1
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Glyn Normington

2010-10-15 09:00:48 EDT

StateBuilder.validateHeaders throws a BundleException complaining, incorrectly, that the Bundle-SymbolicName header must be specified when it is specified as "Bundle-symbolicname". (The logic calls Hashtable.get passing "Bundle-SymbolicName" which returns null since the hashtable key is "Bundle-symbolicname".)

The interface Virgo is calling, StateObjectFactory.createBundleDescription(State, Dictionary, String, long) says in its javadoc:

"The manifest should contain String keys and String values which correspond to proper OSGi manifest headers and values."

which is the case here because manifest header names are case-insensitive.

See https://bugs.eclipse.org/bugs/show_bug.cgi?id=327209#c12 for the background.

This bug is classifed as minor because the user can easily work around it by using the traditional capitalisation of headers.

Comment 1 Thomas Watson

2010-10-15 09:31:55 EDT

Another work around which I would prefer is for the client to pass a dictionary that implements case insensitive key lookups.  This is how the framework uses the state object factory.  Otherwise, I think we will have to consider wrapping the headers in the implementation of the object factory.

Comment 2 Glyn Normington

2010-10-15 09:44:21 EDT

That's not an unreasonable solution given the internal nature of StateObjectFactory. I certainly wouldn't want to impact the mainline performance of Equinox. However, this approach would be a change in the contract of StateObjectFactory which could presumably impact other users. I'm not sure how many such users there are.

The change could be inconvenient too. It is rather inconvenient for Virgo which has a case-insensitive implementation of Map<String,V> rather than a Dictionary.

So users would need to implement a case insensitive Dictionary or reuse Equinox's. Is Equinox's public and available for users to reuse?

Comment 3 Thomas Watson

2011-03-24 16:29:17 EDT

(In reply to comment #2)
> That's not an unreasonable solution given the internal nature of
> StateObjectFactory. I certainly wouldn't want to impact the mainline
> performance of Equinox. However, this approach would be a change in the
> contract of StateObjectFactory which could presumably impact other users. I'm
> not sure how many such users there are.
>

PDE is a big user of this, but I am pretty sure they use a case insensitive map.
 
> The change could be inconvenient too. It is rather inconvenient for Virgo which
> has a case-insensitive implementation of Map<String,V> rather than a
> Dictionary.
> 

You could easy implement a Dictionary using this Map impl.

> So users would need to implement a case insensitive Dictionary or reuse
> Equinox's. Is Equinox's public and available for users to reuse?

No, it is not public.

I would prefer to require the client to pass a map that implements the lookup correctly.