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

Bug 90669

Summary: Need ability to set priorities for conflicting artifact adapters
Product: [WebTools] WTP ServerTools Reporter: Daniel R Somerfield <dsomerfi>
Component: wst.serverAssignee: Tim deBoer <deboer>
Status: CLOSED FIXED QA Contact:
Severity: blocker    
Priority: P3 CC: blancett, david_williams, gorkem.ercan
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows XP   
See Also: https://git.eclipse.org/r/107006
Whiteboard:
Bug Depends on:    
Bug Blocks: 90003    

Description Daniel R Somerfield CLA 2005-04-07 13:16:41 EDT 
If someone needs to be able to create a new type of artifact based a resource
type that already has an adapter for the given module, the new adapter is hidden
by the pre-existing adapter and is never called. For example, if I want to add
an ArtifactAdapter for PageFlow that would reside in the web module, I am in a
bind because the existing JST servlet adapter overrides it. If I could get
priority over the existing adapter, than I could do my processing first and
then, if the resource is a PageFlow, then I can adapt it to the artifact I need,
otherwise, I can let the other adapters handle it.

This is going to be critical for every new type of deployable resource that is
based on a resource (for example ICompilationUnit) for which there are other
adapters within the same module type.
Comment 1 Daniel R Somerfield CLA 2005-04-11 13:52:09 EDT 
This is an enhancement, but it is blocking progress on cactus integration work
(90003).
Comment 2 Tim deBoer CLA 2005-04-17 14:56:42 EDT 
Fix dropped to HEAD. There is a new optional priority attribute on the 
moduleArtifactAdapter extension point, which defaults to 0. If a higher 
priority is specified, the adapter will be used first and override the default 
adapters.
Comment 3 David Williams CLA 2005-04-17 18:44:27 EDT 
Maybe you've clarified this else where, but sounds like an integer covers the
case of two adapters, since you have "0" and "other" ... but what if other
plugins both pick same prioirty (say both pick "100") or what if one pick's 50
and works fine for a while, then someone comes a long and adds a plugin that
adds one at priority 100, then the '50' one suddenly gets ignored?

Just wondering ... I'd think you'd at least want do log something, and perhaps
maybe document that "this API behavior may change in future to give the end user
some choice in resolving conflicts" (if that's indeed an appropriate solution
for this case).
Comment 4 Tim deBoer CLA 2005-04-19 09:00:17 EDT 
Hi David,

I've had several talks with Jeem about this kind of situation, and we could come
up with no "good" solutions to this problem. Since we have a completely
extendable environment, someone else can always come along and pick the same
priority, or two extenders could provide extensions that conflict. In practise,
we'll always be shipping a tested unit in which we can tweak the priorities if
something is wrong. Using an integer is marginally better than using something
like 'override="someid"' - if you have any better ideas, please let me know
(soon :) ).

Change dropped to M-build stream.
Comment 5 Tim deBoer CLA 2005-07-07 14:37:30 EDT 
Closing.
Comment 6 Eclipse Genie CLA 2017-10-11 15:43:25 EDT 
New Gerrit change created: https://git.eclipse.org/r/107006