You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by "Pilgrim, Peter" <pe...@csfb.com> on 2005/08/24 17:20:39 UTC

[PARTIALLY SOLVED] RE: handleConfigException in Struts 1.1

FYI / HTHSB

Looks like it is the dreaded application server ClassLoader issue 
again and this episode perfectly illustrates the best practice for logging
in Enterprise business software and for framework writers.

http://www.geocities.com/Colosseum/Field/7217/SW/struts/errors.html

It is appears the build environment was changed under the project ANT 
config. An ``ActionForm'' type was included in the EAR and of course
in the WAR portion. 

--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston, 
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497


> -----Original Message-----
> From: Pilgrim, Peter [mailto:peter.pilgrim@csfb.com]
> Sent: 23 August 2005 09:51
> To: Struts User Apache (E-mail)
> Subject: handleConfigException in Struts 1.1
> 
> 
> (I still need the source code for Struts 1.1)
> 
> My real problem is a Struts 1.1 application ( my client does 
> not want to upgrade 1.2. )
> deployed on a WebLogic 8.1 Server. The application fails to 
> deploy because
> of a parsing error. Has anyone come across this type of stack 
> trace before?
> 
> 
> 
> ####<22-Aug-2005 17:57:53 o'clock BST> <Error> <HTTP> 
> <lnl45a-4102> <asds1> <ExecuteThread: '1' for queue: 
> 'weblogic.kernel.System'> <<WLS Kernel>> <> <BEA-1012
> 16> <Servlet: "action" failed to preload on startup in Web 
> application: "asds".
> javax.servlet.UnavailableException: Parsing error processing 
> resource path
>         at 
> org.apache.struts.action.ActionServlet.handleConfigException(A
ctionServlet.java:1035)
>         at 
> org.apache.struts.action.ActionServlet.parseModuleConfigFile(A
ctionServlet.java:1014)
>         at 
> org.apache.struts.action.ActionServlet.initModuleConfig(Action
Servlet.java:955)
>         at 
> org.apache.struts.action.ActionServlet.init(ActionServlet.java:470)
>         at javax.servlet.GenericServlet.init(GenericServlet.java:258)
>         at 
> weblogic.servlet.internal.ServletStubImpl$ServletInitAction.ru
> n(ServletStubImpl.java:993)
>         at 
> weblogic.security.acl.internal.AuthenticatedSubject.doAs(Authe
nticatedSubject.java:317)
>         at 
> weblogic.security.service.SecurityManager.runAs(SecurityManage
> r.java:118)
>         at 
> weblogic.servlet.internal.ServletStubImpl.createServlet(Servle
tStubImpl.java:869)
>         at 
> weblogic.servlet.internal.ServletStubImpl.createInstances(Serv
letStubImpl.java:848)
>         at 
> weblogic.servlet.internal.ServletStubImpl.prepareServlet(Servl
etStubImpl.java:787)
>         at 
> weblogic.servlet.internal.WebAppServletContext.preloadServlet(
WebAppServletContext.java:3260)
>         at 
> weblogic.servlet.internal.WebAppServletContext.preloadServlets
> (WebAppServletContext.java:3205)
>         at 
> weblogic.servlet.internal.WebAppServletContext.preloadResource
> s(WebAppServletContext.java:3182)
>         at 
> weblogic.servlet.internal.WebAppServletContext.setStarted(WebA
ppServletContext.java:5663)
>         at 
> weblogic.servlet.internal.WebAppModule.start(WebAppModule.java:869)
>         at 
> weblogic.j2ee.J2EEApplicationContainer.start(J2EEApplicationCo
ntainer.java:2022)
>         at 
> weblogic.j2ee.J2EEApplicationContainer.activate(J2EEApplicatio
nContainer.java:2063)
>         at 
> weblogic.management.deploy.slave.SlaveDeployer$ComponentActiva
teTask.activateContainer(SlaveDeployer.java:2592)
>         at 
> weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.do
> Commit(SlaveDeployer.java:2515)
>         at 
> weblogic.management.deploy.slave.SlaveDeployer$Task.commit(Sla
veDeployer.java:2317)
>         at 
> weblogic.management.deploy.slave.SlaveDeployer$Task.checkAutoC
> ommit(SlaveDeployer.java:2399)
>         at 
> weblogic.management.deploy.slave.SlaveDeployer$Task.prepare(Sl
aveDeployer.java:2311)
>         at 
> weblogic.management.deploy.slave.SlaveDeployer$ActivateTask.pr
> epare(SlaveDeployer.java:2479)
>         at 
> weblogic.management.deploy.slave.SlaveDeployer.processPrepareT
> ask(SlaveDeployer.java:798)
>         at 
> weblogic.management.deploy.slave.SlaveDeployer.prepareDelta(Sl
aveDeployer.java:507)
>         at 
> weblogic.management.deploy.slave.SlaveDeployer.prepareUpdate(S
laveDeployer.java:465)
>         at 
> weblogic.drs.internal.SlaveCallbackHandler$1.execute(SlaveCall
backHandler.java:25)
>         at 
> weblogic.kernel.ExecuteThread.execute(ExecuteThread.java:197)
>         at weblogic.kernel.ExecuteThread.run(ExecuteThread.java:170)
> 
> 
> The struts-config.xml appears to be flawless, but it is better to have
> multiple eyes beating my two very experienced eyes. I just don't see
> any wrong in the struts-config in the simplest cut down version 
> and the bean classes do exist in the right place. Yes, I 
> started a process
> of elimination investigation to isolate the failure. Is it 
> the XML? Struts? 
> or WLS?
> 
> <?xml version="1.0" encoding="UTF-8"?>
> 
> <!DOCTYPE struts-config PUBLIC
>           "-//Apache Software Foundation//DTD Struts 
> Configuration 1.1//EN"
>           
"http://jakarta.apache.org/struts/dtds/struts-config_1_1.dtd">

<struts-config>

  <!-- ================== Form Bean Definitions =========================== -->

  <form-beans>
    <form-bean name="NavigateForm" type="com.csfb.asds.ui.form.NavigateForm" /> 
  </form-beans>

  <!-- ========== Global Forward Definitions ============================== -->

  <global-forwards>
    <forward name="blank" path="/secured/index.jsp" redirect="true" />
  </global-forwards>

  <!-- ========== Action Mapping Definitions ============================== -->

</struts-config>




The b**t**d thing is that WLS and Struts do not seem to obey Log4j.properties
setting I ordered ``log4j.logger.org.apache.struts = DEBUG''. I would expect
a very verbose WebLogic application server log files, but it doesn't do it
for me. I remember doing it in JBoss, Oracle AS 9.0 and Tomcat 4.1.24 circa 2003! 
How else do you get Struts 1.1 to dump shed load of debugger output (again)? 

Failing that I want to hack the 1.1 code to show the exception stacktrace(s). 
I believe there is nested exception happening that the ActionServlet wants 
to show but I cannot see it in the pristine version.

--
Peter Pilgrim :: J2EE Software Development
Operations/IT - Credit Suisse First Boston, 
Floor 15, 5 Canada Square, London E14 4QJ, United Kingdom
Tel: +44-(0)207-883-4497

==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==============================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org


==============================================================================
Please access the attached hyperlink for an important electronic communications disclaimer: 

http://www.csfb.com/legal_terms/disclaimer_external_email.shtml

==============================================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org