Skip to main content

jsftemplating exceptions on startup

12 replies [Last post]
cameronr
Offline
Joined: 2006-07-27

Hi,

I have been seeing these for a while now - since b28 or thereabouts. I am currently using v2 b32 (WinXP, jdk1.6, Netbeans 5.5.1) and I always get a number of jsftemplating exceptions on server startup. The server still runs ok, but it is a bit disconcerting. Is there something wrong with my environment or is this a bug..? I assume this is being caused by the admin console because I am not using jsftemplating in my application.

executePhase(RESTORE_VIEW 1,com.sun.faces.context.FacesContextImpl@14556c) threw exception
com.sun.jsftemplating.layout.SyntaxException: Handler 'setResourceBundle' in event 'beforeCreate' is not declared! Ensure the '@Handler' annotation has been defined on the handler Java method, that it has been compiled with the annotation processing tool, and that the resulting 'META-INF/jsftemplating/Handler.map' is located in your classpath (you may need to do a clean build).
at com.sun.jsftemplating.layout.template.TemplateReader$EventParserCommand.readHandler(TemplateReader.java:842)
at com.sun.jsftemplating.layout.template.TemplateReader$EventParserCommand.process(TemplateReader.java:784)
at com.sun.jsftemplating.layout.template.BaseProcessingContext.beginSpecial(BaseProcessingContext.java:121)
at com.sun.jsftemplating.layout.template.TemplateReader$LayoutComponentContext.beginSpecial(TemplateReader.java:725)
at com.sun.jsftemplating.layout.template.TemplateReader.process(TemplateReader.java:264)
at com.sun.jsftemplating.layout.template.BaseProcessingContext.beginComponent(BaseProcessingContext.java:81)
at com.sun.jsftemplating.layout.template.TemplateReader.process(TemplateReader.java:270)
at com.sun.jsftemplating.layout.template.TemplateReader.readLayoutDefinition(TemplateReader.java:156)
at com.sun.jsftemplating.layout.template.TemplateReader.read(TemplateReader.java:114)
at com.sun.jsftemplating.layout.template.TemplateLayoutDefinitionManager.getLayoutDefinition(TemplateLayoutDefinitionManager.java:167)
at com.sun.jsftemplating.layout.LayoutDefinitionManager.getLayoutDefinition(LayoutDefinitionManager.java:123)
at com.sun.jsftemplating.layout.LayoutViewRoot.getLayoutDefinition(LayoutViewRoot.java:230)
at com.sun.jsftemplating.layout.LayoutViewHandler.createView(LayoutViewHandler.java:142)
at com.sun.faces.lifecycle.RestoreViewPhase.execute(RestoreViewPhase.java:196)
at com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:248)
at com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at com.sun.faces.extensions.avatar.lifecycle.PartialTraversalLifecycle.execute(PartialTraversalLifecycle.java:79)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:244)
at org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:398)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:304)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185)
at com.sun.webui.jsf.util.UploadFilter.doFilter(UploadFilter.java:240)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:217)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:185)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:275)
at org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:255)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:188)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at com.sun.enterprise.web.WebPipeline.invoke(WebPipeline.java:73)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:207)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1067)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:137)
at org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:586)
at org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:556)
at org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1067)
at org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:249)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:618)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:549)
at com.sun.enterprise.web.connector.grizzly.DefaultProcessorTask.process(DefaultProcessorTask.java:790)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.executeProcessorTask(DefaultReadTask.java:326)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:248)
at com.sun.enterprise.web.connector.grizzly.DefaultReadTask.doTask(DefaultReadTask.java:199)
at com.sun.enterprise.web.connector.grizzly.TaskBase.run(TaskBase.java:252)
at com.sun.enterprise.web.connector.grizzly.WorkerThreadImpl.run(WorkerThreadImpl.java:103)

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
matt_tricks
Offline
Joined: 2006-08-02

Hi vbk,

I really think it's more than noise. In fact if you assume the majority of people are using the standard Netbeans 5.5 download then it really means none of them will use the latest Glassfish builds. 5.5 standard doesn't detect a running app server properly so launching from the command line doesn't help.

I certainly don't intend to use any build later than b26 until this issue is fixed. It's just too much hassle having to manually deploy when it's so easy in the earlier builds!

Cheers,
Matt

vbkraemer
Offline
Joined: 2003-09-03

we are working on it. the fix will go into 5.5.1 builds when we have the fix.

AFAIK, the fix will not be released on the update center, for vanilla 5.5...

vbk

cameronr
Offline
Joined: 2006-07-27

Thanks for the update vbk.

If you could let us know when it is done (or give us the netbeans issue number) that would be great!

Cheers
Cameron

vince kraemer

glassfish@javadesktop.org wrote:
> Thanks for the update vbk.
>
> If you could let us know when it is done (or give us the netbeans issue number) that would be great!
>
http://www.netbeans.org/issues/show_bug.cgi?id=92624
> Cheers
> Cameron
> [Message sent by forum member 'cameronr' (cameronr)]
>
> http://forums.java.net/jive/thread.jspa?messageID=202373
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net

vbkraemer
Offline
Joined: 2003-09-03

I checked the change into the nb trunk..

I have started the process for getting the change verified and approved to go into the release551 branch.

I hope to get the change committed there by Monday PM PST...

vbk

matt_tricks
Offline
Joined: 2006-08-02

Great work, thanks VBK.

You guys rock.

A+

//matt

vbkraemer
Offline
Joined: 2003-09-03

The real bug fix is courtesy of Jean-Francois Arcand... http://weblogs.java.net/blog/jfarcand/

I have looked the fix over a few times and am still baffled by its subtlety...

http://serverplugins.netbeans.org/servlets/ReadMsg?list=cvs&msgNo=2347

While I was waiting for some hints from JFA, I had done a ham-handed change in the TEST_QUERY, that is also part of the PortDetector...

I replaced the exploded 'GET / HTTP/1.0' with 'GET /index.html HTTP/1.0'. That also resolved the issue. Since JFA is one of the folks responsible for Grizzly, I figured I could defer to him on this change pretty safely.

vbk

vbkraemer
Offline
Joined: 2003-09-03

Official word: we are working on it.

I have been able to duplicate the issue, but only at the first startup of the app server from inside my NetBeans build.

Since the trace appears to be a "noise" problem, I haven't been able to allocate a lot of effort to tracing it down.

If you are experiencing issues that make you think this is more than "noise", let me know about them.

Thanks,
vbk

suttridge_farm
Offline
Joined: 2006-01-27

Hi All,

I believe this is more than just a little "noise" problem, since sometimes you also can get a stack overflow. This can be sometimes (but unfortunately, not always) be found when starting the app server from NetBeans, and then using a browser to connect to the admin console. If all goes well, you can get a connection, but at other times you get a servlet failure (along with a stack overflow or other exceptions), and you have to restart the app server to be able to get hold of the admin console again.

It's annoying that the problem is not more reproduceable, but it is lurking there ...

Regards,

Steve.

cameronr
Offline
Joined: 2006-07-27

Hi Steve,

I have also seen a few stack overflow exceptions but not for a few weeks now. I will keep my eyes open and post a stack trace if I see it again.

Cheers
Cameron

suttridge_farm
Offline
Joined: 2006-01-27

Hi there,

Yes, I am getting exactly the same problems with the same environment. I've been asking about this since b28, but nothing much appears to be getting done about it. To work-around it, I always start and stop the app server with the command-line asadmin, and not use NetBeans to start and stop the app server. Deployment of applications then goes OK, without filling the app server log with the JSF exceptions.

Regards,

Steve.

cameronr
Offline
Joined: 2006-07-27

Thanks for the reply. I might have to give that a go. It would be nice if we could get some 'official' response on the matter.

Is it a netbeans problem, or a glassfish problem?

Cheers
Cameron