tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cpanon <cpa...@yahoo.com>
Subject Re: Tomcat 6 Struts 1.3
Date Wed, 04 May 2011 18:47:57 GMT
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 the 
page in the report tile.  I have to do this b/c I need to keep my applet running 
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 <chris@christopherschultz.net>
To: Tomcat Users List <users@tomcat.apache.org>
Sent: Tue, May 3, 2011 4:08:50 PM
Subject: Re: Tomcat 6 Struts 1.3

-----BEGIN PGP SIGNED MESSAGE-----
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3AYNIACgkQ9CaO5/Lv0PDeLQCdGpAQd4la81wZWYfqwDIG9qYB
T5kAoLmk8CtM2sjdqwMhMBaymKUebjJu
=Yqxy
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message