[Design of JBoss Profiler] - Internal Error in Webinterface
by tabbe
Hello all,
after having profiled my webapplication, I wanted to view the results in the webinterface. I got the page with the selection of the process id etc but in the next step the webinterface crashes with the following message:
org.apache.jasper.JasperException: Exception in JSP: /internalMenu.inc:6
3: * Distributable under LGPL license.
4: * See terms of license at gnu.org.
5:
6: * This file belongs to a simple implementation of a web interface for the "disconnectedProfiler".
7: */
8: %>
9:
Stacktrace:
anonymous wrote :
| org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:504)
| org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375)
| org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
| org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
|
| root cause
|
| javax.servlet.ServletException: Cannot find bean filterForm in scope null
| org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:858)
| org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:791)
| org.apache.jsp.mainMenu_jsp._jspService(mainMenu_jsp.java:172)
| org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
| org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
| org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
|
| root cause
|
| javax.servlet.jsp.JspException: Cannot find bean filterForm in scope null
| org.apache.struts.util.RequestUtils.lookup(RequestUtils.java:493)
| org.apache.struts.taglib.bean.DefineTag.doStartTag(DefineTag.java:200)
| org.apache.jsp.mainMenu_jsp._jspService(mainMenu_jsp.java:92)
| org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
| org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
| org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
| javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
|
server.log:
anonymous wrote :
| javax.servlet.jsp.JspException: Cannot find bean filterForm in scope null
| at org.apache.struts.util.RequestUtils.lookup(RequestUtils.java:493)
| at org.apache.struts.taglib.bean.DefineTag.doStartTag(DefineTag.java:200)
| at org.apache.jsp.mainMenu_jsp._jspService(mainMenu_jsp.java:92)
| at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332)
| at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314)
| at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264)
| at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
| at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
| 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.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.apache.catalina.valves.RequestDumperValve.invoke(RequestDumperValve.java:150)
| 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)
|
I'm using JBoss AS 4.0.4.GA on WinXP, Java 5 and the latest JBossProfiler CR4
Does anyone have an idea?
Thanks in advance
Tom
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998961#3998961
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998961
19 years, 3 months
[Design of JBoss Web Services] - Re: Using jbossws/trunk for jboss-5.0, jboss-4.2, jboss-4.0.
by darran.lofthouse＠jboss.com
I can get JBossWS to deploy to JBoss 5 and JBoss 4.2 and run the testsuite with a high test success rate but for JBoss 4.0 I am getting a lot of failures.
I am using the JBoss 4.0.5 release and I am getting this error logged for a lot of the tests: -
anonymous wrote : 2007-01-08 12:13:21,026 ERROR [org.jboss.ws.core.soap.SOAPMessageUnMarshaller:80] Cannot unmarshall SOAPMessage
| javax.xml.soap.SOAPException: Cannot find SOAPFactory implementation
| at javax.xml.soap.SOAPFactory.newInstance(SOAPFactory.java:96)
| at org.jboss.ws.core.soap.SOAPFactoryImpl.createElement(SOAPFactoryImpl.java:113)
| at org.jboss.ws.core.soap.SAAJPayloadBuilderDOM.build(SAAJPayloadBuilderDOM.java:86)
| at org.jboss.ws.core.soap.MessageFactoryImpl.createMessageInternal(MessageFactoryImpl.java:254)
| at org.jboss.ws.core.soap.SOAPMessageUnMarshaller.read(SOAPMessageUnMarshaller.java:75)
| at org.jboss.remoting.transport.http.HTTPClientInvoker.useHttpURLConnection(HTTPClientInvoker.java:175)
| at org.jboss.remoting.transport.http.HTTPClientInvoker.transport(HTTPClientInvoker.java:81)
| at org.jboss.remoting.RemoteClientInvoker.invoke(RemoteClientInvoker.java:143)
| at org.jboss.remoting.Client.invoke(Client.java:525)
| at org.jboss.remoting.Client.invoke(Client.java:488)
It looks like an old version of 'javax.xml.soap.SOAPFactory' is being used from the JBoss jars instead of the latest version from JBossWS.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998960#3998960
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998960
19 years, 3 months
[Design of JBoss Portal] - LayouStrategy and StrategyResponse API
by radzish
I am using JBoss Portal 2.4.0.
I consider my question not of 'user' category, because it is related to Portal Theme API, so I am posting it here, not into user forum.
I was trying to write my own strategy implementation for specific layout behaviour and was disapointed of useless of this API. It seems like LayoutStrategy was designed only for MaximizingStrategyImpl implementation.
The problem is in following:
We have method StrategyResponse.addWindowStateChange(WindowContext portlet, WindowState state), which takes a WindowContext instance as parameter. In the same time only WindowLocations are available from StrategyContext.
The only way of using it is for updating state of the target window, which context is available from StrategyEvent, but it would be really nice to update states of other windows.
At the same time we have StrategyResponse.addNoRender(WindowLocation portlet) method that takes WindowLocation as parameter (that was actually needed for MaximizingStrategyImpl implementation).
It would be really nice to have StrategyResponse.addWindowStateChange(WindowLocation location, WindowState state).
The same applies to StrategyResponse.addPortletModeChange() method
For now, I have to use reflection in order to get WindowContext from WindowLocation and use StrategyResponse.addWindowStateChange(WindowContext portlet, WindowState state) method, which is not proper sollution, though it works
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998959#3998959
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998959
19 years, 3 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: Bug in transactional delivery in an MDB
by timfox
Weston - what is the correct behaviour of the JCA JMS managed connection factory here?
Just to recap:
If I obtain a session from a connection created from the JCA JMS managed cf (i.e. the one normally at java:/jmsXA), and there is *no* JTA transaction associated with the current thread, and I receive a message, should the session act like a non transacted session and the message get acknowledged immediately, OR should it act like a transacted session? This is the key question.
If it should act like a non transacted session, how can we reconcile this with transactional message receipt for MDBs?
In a MDB the message is received *before* the MDB container has a chance to start a global tx, therefore it is received in a session where no JTA tx is associated with the current thread. In this case we must *not* ack it immediately, but we must let the session behave as a transacted session and later when the MDB container starts a JTA tx and enlists it, we can transfer the work done in the local tx into the global tx.
Funnily enough - transferring the work into the JTA tx is exactly how JBoss MQ does it too, so I am puzzled as to how this behaviour is consistent with the behaviour of JCA without a JTA tx as Ovidiu reports. This is why I am trying to find out whether the supposed JCA behaviour is real or bogus.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3998913#3998913
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3998913
19 years, 3 months