Yes, you're right, it shouldn't be static. I guess with the JSF jars
increasingly being moved from the WAR to a common directory of the app
server, the classloading ramifications are that static fields are not
private to a webapp anymore? Or does the classloader still segregate the
JSF classes?
- Mark
Ryan Lubke wrote:
> Mark Collette wrote:
>
>> This task has languished on our end because the scope of necessary
>> changes, to every single component's state saving, both in Mojarra
>> and in our suite, is a little too large. Hopefully a simpler approach
>> might be sufficient. I was wondering if it would be possible to just
>> set a context-param, that would globally enable use of
>> attributesThatAreSet. Applications could turn it on if the components
>> they used would benefit from it, and could turn it off if the state
>> savings cost was too great. Regardless of the context-param, the
>> standard components would behave as they already do. And in fact, if
>> the context-param was true, it would run ever so slightly faster,
>> since it wouldn't have to do the string test on the class name.
>
> One problem I see with the suggestion is:
>
> private static boolean ALLOW_ALL_USE_ATTRIBUTES_THAT_ARE_SET = ...;
>
> If the class is shared across all webapps, then the value assigned there
> is shared by all of them. I don't think that behavior is desirable.
> It should
> be per-webapp.
>
>>
>>
>> public abstract class UIComponent implements StateHolder {
>> // Old way
>> List<String> getAttributesThatAreSet(boolean create) {
>> String name = this.getClass().getName();
>> if (name != null && name.startsWith(OPTIMIZED_PACKAGE)) {
>> if (create && attributesThatAreSet == null) {
>> attributesThatAreSet = new ArrayList<String>(6);
>> }
>> }
>> return attributesThatAreSet;
>> }
>>
>>
>> // New way
>> private static boolean ALLOW_ALL_USE_ATTRIBUTES_THAT_ARE_SET = ...;
>>
>> List<String> getAttributesThatAreSet(boolean create) {
>> if (create && attributesThatAreSet == null) {
>> String name;
>> if ( ALLOW_ALL_USE_ATTRIBUTES_THAT_ARE_SET ||
>> ((name = this.getClass().getName()) != null &&
>> name.startsWith(OPTIMIZED_PACKAGE)) {
>> attributesThatAreSet = new ArrayList<String>(6);
>> }
>> }
>> return attributesThatAreSet;
>> }
>> }
>>
>>
>> Mark Collette
>> ICEsoft Technologies, Inc.
>> http://mark-icefaces-reflections.blogspot.com/
>>
>>
>> Ryan Lubke wrote:
>>
>>> Mark Collette wrote:
>>>
>>>> Maybe the list could always track the set attributes, without
>>>> requiring the component be a stock JSF component? It would just be
>>>> the pass-through attribute rendering code that would impose the
>>>> limitation, that it would only use the list for stock JSF components?
>>>
>>>
>>> Would like to have a way to say what components so we don't force a
>>> state saving penalty on those component sets that don't depend on an
>>> implementation specific feature.
>>>
>>>>
>>>>
>>>> Mark Collette
>>>> ICEsoft Technologies, Inc.
>>>> http://mark-icefaces-reflections.blogspot.com/
>>>>
>>>>
>>>> Ryan Lubke wrote:
>>>>
>>>>> Mark Collette wrote:
>>>>>
>>>>>> Are there any limitations on adding public or protected methods
>>>>>> into UIComponent or UIComponentBase?
>>>>>
>>>>>
>>>>>
>>>>> Yes, it can't be done as the TCK signature tests would fail the
>>>>> build.
>>>>>
>>>>> Any changes to the API (public or protected) must be backed by the
>>>>> specification.
>>>>>
>>>>>>
>>>>>> Mark Collette
>>>>>> ICEsoft Technologies, Inc.
>>>>>> http://mark-icefaces-reflections.blogspot.com/
>>>>>>
>>>>>>
>>>>>> Ryan Lubke wrote:
>>>>>>
>>>>>>> Mark Collette wrote:
>>>>>>>
>>>>>>>> Is there any way for third party components to opt into making
>>>>>>>> use of the attributesThatAreSet feature?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Probably not given the changes that were made for this feature
>>>>>>> in 1.2_10.
>>>>>>>
>>>>>>>> Or any plans to facilitate that, in the future?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> No plans at this point. Patches are welcome.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Mark Collette
>>>>>>>> ICEsoft Technologies, Inc.
>>>>>>>> http://mark-icefaces-reflections.blogspot.com/
>>>>>>>
>>>>>>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
>> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_javaserverfaces.dev.java.net
> For additional commands, e-mail: dev-help_at_javaserverfaces.dev.java.net
>