Bug 267967

Summary: API - Symbol Context Resolver needs to be pluggable
Product: [WebTools] Java Server Faces Reporter: Cameron Bateman <cameron.bateman>
Component: CoreAssignee: Cameron Bateman <cameron.bateman>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P1 CC: david_williams, raghunathan.srinivasan, robert_gallagher, xiaonan_jiang
Version: 3.1Keywords: api
Target Milestone: 3.1 RC1Flags: david_williams: pmc_approved+
raghunathan.srinivasan: pmc_approved? (naci.dai)
raghunathan.srinivasan: pmc_approved? (deboer)
raghunathan.srinivasan: pmc_approved? (neil.hauge)
raghunathan.srinivasan: pmc_approved? (kaloyan)
raghunathan.srinivasan: review+
Hardware: PC   
OS: Windows XP   
URL: ORACLE_P1
Whiteboard: PMC_approved
Attachments:
Description Flags
Adds a new non-breaking extension point that allows contributions to the SymbolContextResolverFactory none

Description Cameron Bateman CLA 2009-03-10 16:10:38 EDT
Currently, if you want to modify the way symbols are resolved by the EL part of the JSF framework, there is no consistent way to do so.  The most important feature impacted is content assist.
Comment 1 Raghunathan Srinivasan CLA 2009-03-13 18:50:46 EDT
    * Explain why you believe this is a stop-ship defect. Or, if it is a
"hotbug" (requested by an adopter) please document it as such. 
This is a hot-bug requested by Oracle. The fix is required to provide enahnces content assist feature in the adopter product.
    * Is there a work-around? If so, why do you believe the work-around is
insufficient?
No.
Comment 2 Xiaonan Jiang CLA 2009-04-07 08:15:12 EDT
Hi Cameron, Could you give more details on the problem? When will it happen? Thanks.
Comment 3 Cameron Bateman CLA 2009-05-04 18:45:46 EDT
Created attachment 134341 [details]
Adds a new non-breaking extension point that allows contributions to the SymbolContextResolverFactory

The SymbolContextResolverFactory is used by JSF framework to create a symbol resolver for resolving variables, properties and methods in EL expressions.  The change allows an adopter to specify a new factory extension that can override the default resolver.

Existing behaviour is unchanged because if no extensions are found, the current default resolver is used.
Comment 4 Cameron Bateman CLA 2009-05-05 18:59:36 EDT
Patch applied to HEAD (3.1).
Comment 5 Xiaonan Jiang CLA 2009-05-29 15:31:43 EDT
Do you have documentation or example on how to use the extension point and how to implement the factory class?
Comment 6 Cameron Bateman CLA 2009-05-29 16:20:23 EDT
(In reply to comment #5)
> Do you have documentation or example on how to use the extension point and how
> to implement the factory class?

It's been introduced as a sort of provisional API in this release.  I haven't documented it yet.  

The basic idea, is that you can use this extension point to add a new ISymbolContextResolver by contributing a IStructuredDocumentSymbolResolverFactory.  When the system requests the new ISymbolContextResolver for a context, your factory will be called before the system default and the resolver it returns will be used (you can choose to return null in any context you don't support).

Where this is useful is if you want change the way all EL symbols (variables, properties, methods etc.) are resolved without changing the designtime variable and property resolvers.  So, for example, if you want to try to improve performance by caching symbols inside the resolver rather than recalculating each time as the default does.  Alternatively, if you want to calculate variables differently in certain scenarios or even ignore the designtime variable and property resolvers in certain contexts, but still use the validation, context assist, hyperlink and hoverhelp features by injecting your own symbols.
Comment 7 Xiaonan Jiang CLA 2009-06-04 14:03:37 EDT
Looks like if using the defined symbolContextResolverFactory to add a new ISymbolContextResolver, the new resolver's getProperty(ISymbol, Object) method won't be called by the validation.

Also, if there are more than one symbolContextResolverFactory extensions specified, only one ISymbolContextResolver can be used. Maybe should have a chain to use all the ISymbolContextResolver(s)?