tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cpanon <>
Subject Re: Tomcat 6 Struts 1.3
Date Thu, 05 May 2011 20:05:24 GMT
Hi Martin
What is so odd is it is all loading just fine as witnessed by the fact that the 
default case works.  Either the frameset way, the tiles way or the most 
primitive jsp:include, all show the default client view, cache the applet and 
work quite well.  The problem is when I want to change the client view remove 
the form bean, make the change for the jsp desired, add the form bean to the 
session and forward, it fails.

From: Martin Gainty <>
To: Tomcat Users List <>
Sent: Wed, May 4, 2011 8:38:36 PM
Subject: RE: Tomcat 6 Struts 1.3

tiles-defs.xml is loaded by struts-config.xml
struts-config.xml is loaded by WEB-INF/web.xml
web.xml is loaded by the container at webapp initialisation

except when attribute reloadable=true for <Context 
Set to true if you want Catalina to monitor classes in
        /WEB-INF/classes/ and /WEB-INF/lib for
        changes, and automatically reload the web application if a change
        is detected.  This feature is very useful during application
        development, but it requires significant runtime overhead and is
        not recommended for use on deployed production applications.  That's
        why the default setting for this attribute is false.  You
        can use the Manager web
        application, however, to trigger reloads of deployed applications
        on demand.

Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité

Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.

> Date: Wed, 4 May 2011 11:47:57 -0700
> From:
> Subject: Re: Tomcat 6 Struts 1.3
> To:
> Hi  Chris
> What I find so inscrutable is I know I am hitting the second state with the 
> different jsp for the report tile.  I know that b/c I have a breakpoint set on 

> the return mapping.findForward("posSO");  What I expect is TC or Jasper to 
> detect the tiles-defs is different than the one presenting to this session and 

> process it with the current session attributes, render it and insert it into 
> page in the report tile.  I have to do this b/c I need to keep my applet 
> and not shut down.  It is something systemic for sure.  I know tiles works for 

> thousands of other developers.  How can it work for me perfectly the first time 
> and fail and successive time with a different state?  Am I not correct in my 
> expectation of Tiles processing and the fact that it works for others?  Any 
> further ideas?  
> ________________________________
> From: Christopher Schultz <>
> To: Tomcat Users List <>
> Sent: Tue, May 3, 2011 4:08:50 PM
> Subject: Re: Tomcat 6 Struts 1.3
> Hash: SHA1
> cpanon,
> On 5/2/2011 4:04 PM, cpanon wrote:
> > Thank you for your attention.
> No problem.
> > What is odd and almost answers all the questions, leaving the BIG
> > one, is that all three techniques work the first time.
> Hah... that actually raises more questions than answers IMO.
> > That means that all the resolving, mapping and substitution work.
> > The proxy names are all resolved in the framset(not shown), tiles and
> > jsp:include.  In the second state what I expected is the recompiling
> > of the ccAuth15_soDetail_fragment.jsp, caching the other areas and
> > presenting the different view to the client.  By "nothing" I mean
> > that the original view is shown even thought I know, via setting a
> > breakpoint, I hit the second state but do now show the proper jsp.
> Why would the JSP be recompiled? You aren't changing the code, so it
> should just be re-running the already-compiled code. Maybe you're not
> explaining it well enough for me to understand.
> Are you sure you don't somehow hit the first state again somehow?
> > I have read this about the attribute "antiResourceLocking", however
> > that was in 5.5 and I assume it is fully fixed or know(no google cit
> > it), but 6.0.30.  Does this help with any further ideas?
> anti resource locking has mostly do to with not performing file-locking
> on .jar files that your webapp uses. If you're having problems
> undeploying webapps where the files aren't being deleted, you may have
> to mess with this setting. It does not appear to be related to anything
> you are doing.
> - -chris
> Version: GnuPG v1.4.10 (MingW32)
> Comment: Using GnuPG with Mozilla -
> T5kAoLmk8CtM2sjdqwMhMBaymKUebjJu
> =Yqxy
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message