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@woodstock.dev.java.net >>>>>>>> For additional commands, e-mail: dev-help@woodstock.dev.java.net >>>>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscribe@woodstock.dev.java.net >>>>> For additional commands, e-mail: dev-help@woodstock.dev.java.net >>>>> >>>