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

Bug 49594

Summary:	[misc] filebuffers.documentCreation semantics are undefined for multiple doc. factories for the same file extension
Product:	[Eclipse Project] Platform	Reporter:	Marat Boshernitsan <maratb>
Component:	Text	Assignee:	Kai-Uwe Maetzel <kai-uwe_maetzel>
Status:	RESOLVED DUPLICATE	QA Contact:
Severity:	enhancement
Priority:	P3	CC:	burner, david_williams
Version:	3.0
Target Milestone:	---
Hardware:	All
OS:	All
Whiteboard:

Description Marat Boshernitsan

2004-01-06 15:31:31 EST

I would like to provide an alternative implementation of IDocument for use by
the JDT Java editor.  To do this I am registering a document factory class for
the "java" extension with org.eclipse.core.filebuffers.documentCreation ext.
point.  However, my document factory clashes with the JDT's document factory for
the "java" extension.  This causes the results to be rather undeterministic -
depending on which plugin gets loaded first, the Java editor uses either my
document factory or its own. The only solution I have right now is to patch
org.eclipse.jdt.ui's plugin.xml file to disable that plugin's documentCreation
extension.

Is there any way to improve this situation?

Comment 1 Dani Megert

2004-01-07 13:02:13 EST

Kai, please commment

Comment 2 Dani Megert

2004-04-27 12:48:03 EDT

*** Bug 55415 has been marked as a duplicate of this bug. ***

Comment 3 Marat Boshernitsan

2005-07-22 18:26:54 EDT

This is still an issue for me.  Unlike the poster of bug 55415, I do not have a
distinct editor instance that reports a different content type (so, I cannot
resolve this conflict based on content type).  I have a document factory that is
registered to the content type of the org.eclipse.jdt.core.javaSource, with
intention to provide an alternative IDocument implementation for the JDT's
CompilationUnitEditor.  As far as I can tell, the culprit is this method in 
org.eclipse.core.internal.filebuffers.ExtensionsRegistry, which always returns
the first element of the extension set:

	private IConfigurationElement selectConfigurationElement(Set set) {
		if (set != null && !set.isEmpty()) {
			Iterator e= set.iterator();
			return (IConfigurationElement) e.next();
		}
		return null;
	}

Comment 4 Bob Foster

2005-07-22 18:33:03 EDT

I'd vote for either making these pseudo-random APIs work consistently for all or
removing them. So far document sharing has brought us one collision after another.

Comment 5 Dani Megert

2005-08-23 04:51:34 EDT


*** This bug has been marked as a duplicate of 107682 ***