Comment 1 Raghunathan Srinivasan 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 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 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 2009-05-05 18:59:36 EDT

Patch applied to HEAD (3.1).

Comment 5 Xiaonan Jiang 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 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 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)?