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

Bug 321728

Summary:	[metatype] Unwanted warning messages when asking metadata that does not exist.
Product:	[Eclipse Project] Equinox	Reporter:	janssk1
Component:	Compendium	Assignee:	equinox.compendium-inbox <equinox.compendium-inbox>
Status:	RESOLVED WORKSFORME	QA Contact:
Severity:	minor
Priority:	P3	CC:	jwross, tjwatson
Version:	unspecified
Target Milestone:	---
Hardware:	PC
OS:	Windows XP
Whiteboard:

Description janssk1

2010-08-04 10:19:13 EDT

Build Identifier: 1.0.0

In our code, we ask bundles for metadata on a regular basis. However, this leads to a lot of unwanted warning messages generated by the org.eclipse.equinox.metatype.MetaTypeProviderImpl class: 

[Warning log]
	Message: Bundle(ID="0", name="org.eclipse.osgi") has no MetaData file.


This should be a debug message, not warning. 

Reproducible: Always

Steps to Reproduce:

metaTypeService.getMetaTypeInformation(bundleThatDoesNotHaveMeta);

Comment 1 John Ross

2010-11-12 16:11:09 EST

I can't find anything in the spec requiring a warning message for this, and it wouldn't make much sense to me if it did since this is an anticipated condition. It's pefectly acceptable for a bundle to provide no metadata XML. In that case, the MetaTypeService must provide the MetaTypeInformation object anyway and listen for any subsequent provisioning of metadata via registrations of MetaTypeProvider, which may come sooner, later, or never. 

A using application knows a particular bundle does not currently provide any metadata via the getPids() and getFactoryPids() methods which will return empty arrays. If getObjectClassDefinition() is naively called anyway with a bogus PID, an IllegalArgumentException results.

I don't see a reasonable justification for a warning message here. The service simply doesn't know whether or not a bundle failing to provide metatdata XML was intentional or not.

Comment 2 Thomas Watson

2010-11-12 17:04:11 EST

I agree.

Comment 3 John Ross

2010-11-12 17:06:15 EST

This message is already being logged at the debug level within the MetaTypeProviderImpl constructor. I can find no other references to that message.

Comment 4 Thomas Watson

2010-11-15 08:54:29 EST

(In reply to comment #3)
> This message is already being logged at the debug level within the
> MetaTypeProviderImpl constructor. I can find no other references to that
> message.

But should we even log this at the debug level?  Seems unnecessary.

Comment 5 John Ross

2010-11-15 16:57:30 EST

(In reply to comment #4)
> (In reply to comment #3)
> > This message is already being logged at the debug level within the
> > MetaTypeProviderImpl constructor. I can find no other references to that
> > message.
> But should we even log this at the debug level?  Seems unnecessary.

I'm a big fan of verbose logging at the debug level. 

I suppose the question boils down to the following.

(1) Does a caller of MetaTypeService.getMetaTypeInformation(Bundle) expect metata to be, or eventually be, there?

(2) Is it more or less common for bundles to provide metadata via XML as opposed to a custom MetaTypeProvider?

As of today, I would say the answer to (2) is more common. However, this may change, and quickly, with RFC 165 where Configurer must register a MetaTypeProvider on behalf of other bundles.

Comment 6 Thomas Watson

2010-11-15 17:24:50 EST

(In reply to comment #3)
> This message is already being logged at the debug level within the
> MetaTypeProviderImpl constructor. I can find no other references to that
> message.

Ummm this is because your patch in bug319501 changed the message to debug ;-)

So are we done?  I still think it is a bit strange to log this as a debug message, but I guess that is acceptable.  I really am not sure how many bundles provide metadata xml files vs. services.

Comment 7 Thomas Watson

2011-02-15 15:17:20 EST

with changes in bug319501 this works for me.  The message is no longer a warning.