Anissa and Ken,
Anissa Lam wrote:
>
> Hi Amy,
> As suggested, a P2 bug is filed.
>
> https://glassfish.dev.java.net/issues/show_bug.cgi?id=4440
>
> Without able to get any exception nor stack trace is really hurting
> the progress of admin console development.
> Appreciate if you can give this a high priority.
I do see an exception and stack trace in server.log so not sure what the
issue is.
[#|2008-03-17T17:17:54.328-0700|SEVERE|GlassFish10.0|javax.enterprise.system.container.web|_ThreadID=12;_ThreadName=Thread-4;|StandardWrapperValve[jsp]:
PWC1406: Servlet.service() for servlet jsp threw exception
java.lang.RuntimeException: Do you see a stack trace?
at org.apache.jsp.hello_jsp._jspService(hello_jsp.java:67)
at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:93)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at
org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:373)
at
org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:473)
at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:367)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:831)
at
org.apache.catalina.core.ApplicationFilterChain.servletService(ApplicationFilterChain.java:411)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:290)
at
org.apache.catalina.core.StandardContextValve.invokeInternal(StandardContextValve.java:271)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:202)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:206)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:150)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:632)
at
org.apache.catalina.core.StandardPipeline.doInvoke(StandardPipeline.java:577)
at
org.apache.catalina.core.StandardPipeline.invoke(StandardPipeline.java:571)
at
org.apache.catalina.core.ContainerBase.invoke(ContainerBase.java:1080)
at
org.apache.coyote.tomcat5.CoyoteAdapter.service(CoyoteAdapter.java:270)
at
com.sun.grizzly.http.DefaultProcessorTask.invokeAdapter(DefaultProcessorTask.java:605)
at
com.sun.grizzly.http.DefaultProcessorTask.doProcess(DefaultProcessorTask.java:536)
at
com.sun.grizzly.http.DefaultProcessorTask.process(DefaultProcessorTask.java:785)
at
com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:130)
at
com.sun.enterprise.v3.services.impl.HttpProtocolFilter.execute(HttpProtocolFilter.java:99)
at
com.sun.enterprise.v3.services.impl.GlassfishProtocolChain.executeProtocolFilter(GlassfishProtocolChain.java:61)
at
com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:78)
at
com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:54)
at
com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.util.WorkerThreadImpl.run(WorkerThreadImpl.java:179)
|#]
As Jan mentioned earlier, we deliberately omit stacktraces in the
browser but the full stack trace is available in server.log.
Amy
>
> thanks
> Anissa
>
>
> Amy Roh wrote:
>> Hi Ken,
>>
>> You should see logging messages from web container in server.log.
>> What is it that you're not seeing?
>> Pls feel free to file a bug (if you think it's a bug) with your
>> webapp and assign it to me.
>>
>> Thanks,
>> Amy
>>
>> Ken Paulsen wrote:
>>>
>>> Hi Amy,
>>>
>>> I recently got around to trying this out, however... no luck. I
>>> still don't see any difference.
>>>
>>> Any other ideas?
>>>
>>> Thanks,
>>>
>>> Ken
>>>
>>> Amy Roh wrote:
>>>> You're welcome. Thanks for being patient.
>>>>
>>>> I can't seem to commit since java.net is down. You can try this
>>>> simple patch if you'd like.
>>>>
>>>> Index:
>>>> web/webtier/src/main/java/com/sun/enterprise/web/WebContainer.java
>>>> ===================================================================
>>>> ---
>>>> web/webtier/src/main/java/com/sun/enterprise/web/WebContainer.java
>>>> (revision 18791)
>>>> +++
>>>> web/webtier/src/main/java/com/sun/enterprise/web/WebContainer.java
>>>> (working copy)
>>>>
>>>> @@ -3678,7 +3678,7 @@
>>>> // log-level setting then use that
>>>> try {
>>>> Config config =
>>>> _serverContext.getDefaultHabitat().getComponent(Config.class);
>>>> - level =
>>>> Level.parse(config.getMonitoringService().getModuleMonitoringLevels().getWebContainer());
>>>>
>>>> + level =
>>>> Level.parse(logserviceBean.getModuleLogLevels().getWebContainer());
>>>> setLogLevel(level);
>>>> } catch (NullPointerException e) {
>>>> if (_debug > 0)
>>>>
>>>> Ken Paulsen wrote:
>>>>> Thanks Amy!
>>>>>
>>>>> Amy Roh wrote:
>>>>>> I'm observing the same behavior and logging used to work before,
>>>>>> I think. I'm taking a look at this.
>>>>>>
>>>>>> Ken Paulsen wrote:
>>>>>>>
>>>>>>> Hi Jan,
>>>>>>>
>>>>>>> I spoke with Ryan. He is also unable to get exceptions that he
>>>>>>> throws to appear in the log file. He even tried w/ a plain JSP
>>>>>>> and was unable to see the trace. I have also tried setting the
>>>>>>> JSF logger (and others) in the logging.properties file to
>>>>>>> FINEST... and that doesn't generate any extra messages in the
>>>>>>> log file -- there should be a lot. I suspect our logging system
>>>>>>> is not configured correctly (by me??) or is just plain broken.
>>>>>>> Any ideas on who I can talk to? Or where to look next?
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Ken
>>>>>>>
>>>>>>> Jan.Luehe_at_Sun.COM wrote:
>>>>>>>> Ken,
>>>>>>>>
>>>>>>>> Ken Paulsen wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> I am unable to see stack traces that would help me debug.
>>>>>>>>> Here's what I see in the browser:
>>>>>>>>>
>>>>>>>>> javax.servlet.ServletException: Unable to determine parameter
>>>>>>>>> type 'com.sun.appserv.management.config.PropertiesAccess' for
>>>>>>>>> parameter named 'mbean'.
>>>>>>>>>
>>>>>>>>> *root cause*
>>>>>>>>>
>>>>>>>>> java.lang.RuntimeException: Unable to determine parameter type
>>>>>>>>> 'com.sun.appserv.management.config.PropertiesAccess' for
>>>>>>>>> parameter named 'mbean'.
>>>>>>>>>
>>>>>>>>> *root cause*
>>>>>>>>>
>>>>>>>>> java.lang.ClassNotFoundException:
>>>>>>>>> com.sun.appserv.management.config.PropertiesAccess
>>>>>>>>>
>>>>>>>>
>>>>>>>> we deliberately omit stacktraces in the responses to clients,
>>>>>>>> as requested
>>>>>>>> by the Netbeans folks (originally, stacktraces were included in
>>>>>>>> the response,
>>>>>>>> which was considered a usability issue).
>>>>>>>>
>>>>>>>> You should see stacktraces in the server.log, though.
>>>>>>>>
>>>>>>>>> In the console (w/ asadmin start-domain -v):
>>>>>>>>>
>>>>>>>>> SEVERE: JSF1054: (Phase ID: RESTORE_VIEW 1, View ID:
>>>>>>>>> /testIP.jsf)
>>>>>>>>> Exception thrown during phase execution:
>>>>>>>>>
>>>>>>>>> javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl_at_fa54fe]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> And the server.log file:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [#|2008-03-11T23:18:46.158+0000|SEVERE|GlassFish10.0|javax.enterprise.resource.webcontainer.jsf.lifecycle|_ThreadID=20;_ThreadName=Thread-4;RESTORE_VIEW
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 1;/testIP.jsf;javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl_at_fa54fe];|JSF1054:
>>>>>>>>>
>>>>>>>>> (Phase ID: RESTORE_VIEW 1, View ID: /testIP.jsf) Exception
>>>>>>>>> thrown
>>>>>>>>> during phase execution:
>>>>>>>>>
>>>>>>>>> javax.faces.event.PhaseEvent[source=com.sun.faces.lifecycle.LifecycleImpl_at_fa54fe]|#]
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>> I'll let the JSF team comment on this.
>>>>>>>>
>>>>>>>> Jan
>>>>>>>>
>>>>>>>>
>>>>>>>>> I also attempted to set the logging.properties log levels, but
>>>>>>>>> that did not do anything.
>>>>>>>>>
>>>>>>>>> In this case, I can guess what the problem is, although I
>>>>>>>>> would like to know why it's a problem b/c I shouldn't be
>>>>>>>>> accessing any of the server api's with the request I made. A
>>>>>>>>> simple stack trace would show me exactly what I'm not
>>>>>>>>> understanding and I could move on quickly.
>>>>>>>>>
>>>>>>>>> When is this going to be fixed? Is there something I am not
>>>>>>>>> configuring correctly that hides all errors for the user?
>>>>>>>>> Why? Why? Why? :) This is slowing down my development
>>>>>>>>> significantly.
>>>>>>>>>
>>>>>>>>> Ken
>>>>>>>>>
>>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>>
>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>>
>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>>
>>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>>
>>>>>>
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>>
>>>>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>>>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>>>>
>>>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>