Winston Prakash wrote:
>
>>>
>>> The following is not the offending code. The Resource loading
>>> happened to happen here. The offending code is at
>>> JavaScriptUtilities.getThemeJavaScript which is exposed via this
>>> method.
>>>
>> This is not the source of the problem.
>> This call site only references "themeContext.getResourcePath". The
>> contract of "getResourcePath" is to
>> return absolute reference to the argument. The assumption being that
>> the argument is a relative path.
>> The contract does not say that the argument cannot be "". Clearly if
>> this interface were tightened
>> then it might not be appropriate to call this method in this way.
>> Note that the code that is
>> not in the "isDesignTime" block will not generate the warning.
>>
>> The reason that the warning is showing up is because of the design
>> time hack in
>> JSFThemeContext. If a runtime ThemeContext were implemented by
>> VWP/Creator
>> then we wouldn't have had to have these "isDesignTime" hacks in
>> component level code
>> which is clearly not good practice.
>>
>> That said, if this is a problem the "isDesignTime" hack can check for
>> "" and act appropriately.
>>
>>> BTW, work around in this code is because of the image properties
>>> specified as fully qualified name
>>>
>>> Ex.
>>>
>>> ALARM_CRITICAL_SMALL=/com/sun/webui/jsf/suntheme/images/alarms/critical_small.gif
>>>
>>>
>>> It should be
>>>
>>> ALARM_CRITICAL_SMALL=com/sun/webui/jsf/suntheme/images/alarms/critical_small.gif
>>>
>>>
>>> NB complains about this, since it is against the recommendation by JLS
>>
>>
>> Again this is not a runtime problem. And has nothing to do with JLS
>> recommendations.
>> It is just a data format in a properties file.
>>
>> And we know the history of this issue. Our component resource bundles
>> have been
>> specified in this way for a very long time and it was risky to change
>> this in case other
>> code that we did not control was referencing this theme data.
>>
>> Please do not forget that these are independent component libraries
>> and have a life
>> of their own. They are not and should not have to have NB specific
>> code as part
>> of the implementation.
>>
>>> >If you VWP/Creator had fully implemented FacesContext like we had
>>> been asking over the years
>>> > then these design time tests would also not have to be necessary
>>> and again this issue would not have
>>> > arisen.
>>>
>>> We do. We use JSF RI 1.2 directly at designtime via JSF support module.
>>
>>
>> Are you saying you are no longer creating a FacesContext wrapper ?
>
> We do. But it is a pure wrapper, in the sense it set the ClassLoader
> (Project Class Loader) and
> delegates everything to JSF RI 1.2
>
> But one thing I should mention, when we call the component rendering
> at design time, we directly
> call the encodeBegin(facesContext ) etc in the component, since we
> don't have a JSP container
> at designtime. So I don't see the possibility of creating ThemeContext
> at design time.
>
> Do I miss something about creating ThemeContext at designtime?
If you create an implementation of ThemeContext like we implemented
JSFThemeContext, then VWP
can control all aspects of the Theme. For example it can choose which
class loader to use. It can
choose what the current theme is, i.e. switch themes when the developer
does, control the locale,
and in more detail choose the ThemeFactory implementation. It can also
provide design time
theme resources that could replace the "runtime" theme values in cases
where the runtime
value is not sufficient at designtime. This would have been ideal for
providing default values
in label's etc, but unfortunately we never got around to getting to this
level of "defaults".
We have another hack in that we put the Theme name in the session, which
was for VWP/Creator
to switch themes. I don't know if this is still referenced by VWP.
The instance of VWP's ThemeContext implementation ends up in the "faux"
VWP FacesContext's
servlet context.
When the components try to get a ThemeContext instance, they get the one
VWP created and
does not create an instance of JSFThemeContext.
-rick
> - Winston
>
>>
>> -rick
>>
>>>
>>> - Winston
>>>
>>>>
>>>> You should have also referenced this code in your email since you
>>>> reference JSFThemeContext
>>>>
>>>> /**
>>>> * Return an appropriate resource path within this theme context.
>>>> * Use is Beans.isDesignTime to prevent ThemeServlet prefix from
>>>> * being appended. Creator handles doing the right thing with
>>>> * getRequestContextPath()
>>>> */
>>>> public String getResourcePath(String path) {
>>>> String resourcePath = path;
>>>> if (Beans.isDesignTime()) {
>>>> <<<====================================
>>>> ClassLoader cl = getDefaultClassLoader();
>>>> // NB6 gives warnings if the path has a leading "/". So,
>>>> strip it of
>>>> f if it has one
>>>> URL url = cl.getResource(path.startsWith("/") ?
>>>> path.substring(1) :
>>>> path);
>>>> if (url != null) {
>>>> resourcePath = url.toExternalForm();
>>>> }
>>>> } else if (path != null) {
>>>> FacesContext context = FacesContext.getCurrentInstance();
>>>> String servletContext = getThemeServletContext();
>>>> StringBuilder sb = new StringBuilder(128);
>>>> // Just to make sure
>>>> //
>>>> if (!servletContext.startsWith("/")) {
>>>> sb.append("/");
>>>> }
>>>> sb.append(servletContext);
>>>> if (!path.startsWith("/") &&
>>>> !servletContext.endsWith("/")) {
>>>> sb.append("/");
>>>> }
>>>> sb.append(path);
>>>> resourcePath = context.getApplication().getViewHandler().
>>>> getResourceURL(context, sb.toString());
>>>> }
>>>> return resourcePath;
>>>> }
>>>>
>>>> If you VWP/Creator had fully implemented FacesContext like we had
>>>> been asking over the years
>>>> then these design time tests would also not have to be necessary
>>>> and again this issue would not have
>>>> arisen.
>>>>
>>>> -rick
>>>>
>>>>>
>>>>> -rick
>>>>>
>>>>>>
>>>>>> - Winston
>>>>>>
>>>>>>>> Netbeans enforces it by throwing an exception. Since this part
>>>>>>>> of the
>>>>>>>> code in JSFThemeContext viloates seems to violate this
>>>>>>>> principle, NB keeps throwing
>>>>>>>> the informational exception
>>>>>>>>
>>>>>>>> java.lang.IllegalStateException: You are trying to access
>>>>>>>> file: from the default package. Please see
>>>>>>>> http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html#default_package
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.netbeans.ProxyClassLoader.printDefaultPackageWarning(ProxyClassLoader.java:478)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.netbeans.ProxyClassLoader.getResource(ProxyClassLoader.java:258)
>>>>>>>>
>>>>>>>> at java.lang.ClassLoader.getResource(ClassLoader.java:972)
>>>>>>>> at java.lang.ClassLoader.getResource(ClassLoader.java:972)
>>>>>>>> at
>>>>>>>> com.sun.webui.jsf.theme.JSFThemeContext.getResourcePath(JSFThemeContext.java:148)
>>>>>>>>
>>>>>>>> at
>>>>>>>> com.sun.webui.jsf.util.JavaScriptUtilities.getThemeJavaScript(JavaScriptUtilities.java:509)
>>>>>>>>
>>>>>>>> at
>>>>>>>> com.sun.webui.jsf.util.JavaScriptUtilities.getDojoConfig(JavaScriptUtilities.java:131)
>>>>>>>>
>>>>>>>> at
>>>>>>>> com.sun.webui.jsf.renderkit.html.HeadRenderer.renderAttributes(HeadRenderer.java:134)
>>>>>>>>
>>>>>>>> at
>>>>>>>> com.sun.webui.jsf.renderkit.html.AbstractRenderer.encodeBegin(AbstractRenderer.java:156)
>>>>>>>>
>>>>>>>> at
>>>>>>>> javax.faces.component.UIComponentBase.encodeBegin(UIComponentBase.java:785)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.netbeans.modules.visualweb.insync.faces.FacesPageUnit.renderBean(FacesPageUnit.java:1276)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.netbeans.modules.visualweb.insync.faces.FacesPageUnit.renderNode(FacesPageUnit.java:1532)
>>>>>>>>
>>>>>>>> at
>>>>>>>> org.netbeans.modules.visualweb.insync.faces.FacesPageUnit.renderBean(FacesPageUnit.java:1324)
>>>>>>>>
>>>>>>>>
>>>>>>>> - Winston
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>>>>>>>>
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_woodstock.dev.java.net
>>>>> For additional commands, e-mail: dev-help_at_woodstock.dev.java.net
>>>>>
>>>
>