Leia's Metal Bikini Cult

After being bombarded with 30 years of Star Wars marketing and hype, I have to say this is the weirdest Star Wars phenomena I have seen. Enjoy!

Sun JSF vs. Apache MyFaces

Wrestling with Sun JSF classes on JBoss can aggravate and confuse, and from what I have seen on the newsgroups there isnt a clear explanation. Well if I may offer another opaque solution here it is...

The problem: Programming JSF pages that include table components in Sun's NetBeans 5.5 and deploying to JBoss 4.0.5 will cause runtime issues rendering from the javax.faces.component.UIComponentBase class. The results will look something like this...

23:03:40,543 ERROR [[Faces Servlet]] Servlet.service() for servlet Faces Servlet threw exception
java.lang.NullPointerException
at javax.faces.component.UIComponentBase.getRenderer(UIComponentBase.java:741)
at javax.faces.component.UIComponentBase.getClientId(UIComponentBase.java:226)
at javax.faces.component.UIComponentBase.getClientId(UIComponentBase.java:219)
at com.sun.rave.web.ui.component.TableRowGroup.getProperties(TableRowGroup.java:1804)
at com.sun.rave.web.ui.component.TableRowGroup.restoreState(TableRowGroup.java:1490)
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:728)
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:719)
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:719)
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:719)
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:719)
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:719)
at javax.faces.component.UIComponentBase.processRestoreState(UIComponentBase.java:719)
at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreComponentState(JspStateManagerImpl.java:221)
at org.apache.myfaces.application.jsp.JspStateManagerImpl.restoreView(JspStateManagerImpl.java:287)
at org.apache.myfaces.application.jsp.JspViewHandlerImpl.restoreView(JspViewHandlerImpl.java:255)
at com.sun.rave.web.ui.appbase.faces.ViewHandlerImpl.restoreView(ViewHandlerImpl.java:310)
at org.apache.myfaces.lifecycle.LifecycleImpl.restoreView(LifecycleImpl.java:141)
at org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:66)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:137)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at com.sun.rave.web.ui.util.UploadFilter.doFilter(UploadFilter.java:198)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:432)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:595)


Solution: Basically in a nutshell, we are removing all Apache classes and replacing them with the Sun classes in NetBeans. Follow these steps...

1.) Remove the directory
JBOSS_HOME/server/default/deploy/jbossweb-tomcat55.sar/jsf-lib

2.) Remove any instances of the myfaces listener in the web.xml. The section to remove should look like this...

<listener>
<listener-class>
org.apache.myfaces.webapp.StartupServletContextListener
</listener-class>
</listener>

3.) Now all apache libs should be purged from JBoss.  We must now add the Sun libs back in to
the web app.  Add the following libs from NetBeans (right click on libraries in your webapp and the option
to add libs should be selected)
4.) Add the following libs from NetBeans (JSF, and JSTL).  These libs should add several jars including

commons-beanutils.jar, commons-collections.jar, commons-digester.jar,
commons-logging.jar, jsf-api.jar, jsf-impl.jar, standard.jar, and jstl.jsr.

That worked for me.  I have found other articles that may help.   Here's one that seems to be more helpful...

http://blogs.sun.com/divas/entry/missing_image_bug

Good Luck

NetBeans and EJB 3.0 persistence.xml generation

For everyone using Netbeans, I found an issue in generating the persistence.xml for an EJB using EJB3.0, JBoss, and MySQL. The jta-data source in the config file was generated as follows...

<jta-data-source>mysql</jta-data-source>

After making the following update, the datasource was bound correctly from the EJB and all worked fine...

<jta-data-source>java:/mysql</jta-data-source>

Widgets 1.0

W3C has created a widget spec 1.0 which is an attempt to get all of the widget makers to play nice. Google, Yahoo, Microsoft, and Apple were targeted with this spec since each has their own version of widgets.

http://www.w3.org/TR/widgets/

This should be an interesting technology in the same vein as AJAX. The spec doesn't quite instill confidence yet, since it is still in draft form. After a bit of research it seems that current widgets run on an existing app (Yahoo's widget engine / Google's desktop app). It will be interesting to see if any of the browsers pick this up. That would be cool.