date:20121120


Thanks for the question -- I worded that part awkwardly.

Our project has a root-level /src directory with the web app's Java 
files, and a root-level /war directory with the exploded non-Java 
files (static assets, JSPs, etc.).  When developing, Eclipse compiles 
the /src directory into the /war/WEB-INF/classes directory, and then 
copies any changed files from /war into its embedded Tomcat instance.


When we switch Git branches, that could change the .jsp/.tag files 
inside the /war directory, but depending on the branch, those changed 
files might have an earlier modified-timestamp than the .jsp/.tag files 
that have already been copied over to the embedded Tomcat's exploded 
webapp directory.  So my thought was that those files would not, then, 
be recompiled, and so at runtime, Tomcat would be using the older 
versions of those files that are cached in Tomcat's /work directory.  
I think that theory is countered, however, by my colleague's claim that 
she clears out /work before deploying a new branch, and also my own 
experience wherein I watched Tomcat re-compile the .tag file into the 
/work directory, yet still claim the tag's class cannot be resolved.


But to clarify: no part of Tomcat itself, including /work, is kept 
under version control.


-- Jim


On 11/20/12 2:18 AM, Pid * wrote:

On 19 Nov 2012, at 23:58, Jim open...@gmail.com wrote:


Hello!

My team has been having an issue wherein our application occasionally fails to 
start up because Tomcat claims it can't find find a dynamically-created 
classfile.  This doesn't happen all the time, and restarting Tomcat (albeit 
more than once, sometimes) resolves it.

For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, on OS 
10.7.5), tried to load a page, and got:

** snip **

An error occurred at line: 1 in the jsp file: 
/WEB-INF/jsp/about/about_impact.jsp
org.apache.jsp.tag.web.about_tag cannot be resolved to a type
1: %@ include file=../common/constants.jsp %templates:about

** snip/ **

The constants.jsp referenced above contains:
%@ taglib prefix=templates tagdir=/WEB-INF/tags %

... and /WEB-INF/tags contains the about.tag file.

The $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web directory 
exists, and it contains both about_tag.class and about_tag.java, with timestamps 
corresponding to when I loaded the page.

I then deleted those files, and refreshed the page in my browser. 
about_tag.class and about_tag.java get recreated in that directory, but I still 
get the above error claiming about_tag can't be resolved.

I then restarted Tomcat, refreshed the page in my browser, and all is well.


I've also seen this happen regularly for my Windows-using colleagues, as well 
as in a non-Eclipse Linux-based 6.0.29 instance, and (hearsay) a colleague 
reported it happening in his Tomcat 7. Thinking it was a runtime race 
condition, we also tried telling Tomcat to load the JSP on startup via the 
web.xml, and while we did see the .java and .class files being created on 
startup, we still ran into the issue.  We haven't yet tried pre-compiling our 
JSPs/TAGs before starting Tomcat -- but that shouldn't be necessary, right?

I'd love some advice/insight in how I might investigate this further, or if there's a 
gotcha I might be running into.  It feels like a race condition in the 
classloader, but I don't want to submit a bug report without a reliable test case, of course. Since 
we can't reliably recreate the situation, I'm having trouble putting that together.

This seems to happen more often for me when I'm switching between substantially-different 
Git branches, so I thought it might have to do with the /work directory having older 
versions of the JSPs/TAGs, but one of my colleagues claims to clean her /work 
directory every time she switches branches, and before starting Tomcat, and still getting 
the issue.

What is the relationship between Git and Tomcat, exactly?

Does Tomcat load an app (or its files) directly from a version
controlled file system?


p




Thanks in advance for any help!
Jim

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org




-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: multiple tomcat instances for every application

 From: Ashkan Rahmani [mailto:ashkan...@gmail.com] 
 Subject: Re: multiple tomcat instances for every application

 do you know what is  -Xshare:off ?
 is it related to share classes?

http://lmgtfy.com/?q=%22-Xshare%3Aoff%22

 King Regards,

Didn't realize we were dealing with royalty...

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SimpleTCPCluster

2012-11-20 Thread Daniel Mikusa

On Nov 20, 2012, at 5:53 AM, Stephen Nelson-Smith wrote:

 Hi,
 
 I'm trying to test simple session sharing using SimpleTCPCluster on
 Tomcat 7.0.32.
 
 Following the documentation, I've uncommented the Cluster
 className=org.apache.catalina.ha.tcp.SimpleTcpCluster/ element, and
 ensured distributable / is in the web.xml of the examples web app.
 
 From the docs:
 
 - All your session attributes must implement java.io.Serializable
 
 I know the webapps don't, but for proof of concept this is fine.  My
 real app does.
 
 - Uncomment the Cluster element in server.xml
 
 Done.
 
 - If you have defined custom cluster valves, make sure you have the
 ReplicationValve defined as well under the Cluster element in
 server.xml
 
 I haven't.
 
 - If your Tomcat instances are running on the same machine, make sure
 the tcpListenPort attribute is unique for each instance, in most cases
 Tomcat is smart enough to resolve this on it's own by autodetecting
 available ports in the range 4000-4100
 
 I have 2 x VMs running on CentOS 6.3, on different IPs
 
 - Make sure your web.xml has the distributable/ element
 
 Done.
 
 - If you are using mod_jk, make sure that jvmRoute attribute is set at
 your Engine Engine name=Catalina jvmRoute=node01  and that the
 jvmRoute attribute value matches your worker name in
 workers.properties
 
 I'm not.
 
 - Make sure that all nodes have the same time and sync with NTP service!
 
 Done.
 
 - Make sure that your loadbalancer is configured for sticky session mode.
 
 Done (I'm using haproxy).
 
 However, on starting Tomcat, I see:
 
 Nov 20, 2012 10:50:16 AM org.apache.catalina.startup.Catalina start
 SEVERE: Catalina.start:
 org.apache.catalina.LifecycleException: Failed to start component
 [StandardServer[8005]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at org.apache.catalina.startup.Catalina.start(Catalina.java:684)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:322)
at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:451)
 Caused by: org.apache.catalina.LifecycleException: Failed to start
 component [StandardService[Catalina]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at 
 org.apache.catalina.core.StandardServer.startInternal(StandardServer.java:732)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 7 more
 Caused by: org.apache.catalina.LifecycleException: Failed to start
 component [StandardEngine[Catalina]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at 
 org.apache.catalina.core.StandardService.startInternal(StandardService.java:443)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 9 more
 Caused by: org.apache.catalina.LifecycleException: Failed to start
 component [org.apache.catalina.ha.tcp.SimpleTcpCluster[Catalina]]
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
at 
 org.apache.catalina.core.ContainerBase.startInternal(ContainerBase.java:1106)
at 
 org.apache.catalina.core.StandardEngine.startInternal(StandardEngine.java:302)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 11 more
 Caused by: org.apache.catalina.LifecycleException:
 org.apache.catalina.tribes.ChannelException:
 java.lang.IllegalArgumentException: java.net.UnknownHostException:
 auto: Name or service not known; No faulty members identified.
at 
 org.apache.catalina.ha.tcp.SimpleTcpCluster.startInternal(SimpleTcpCluster.java:674)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
... 14 more
 Caused by: org.apache.catalina.tribes.ChannelException:
 java.lang.IllegalArgumentException: java.net.UnknownHostException:
 auto: Name or service not known; No faulty members identified.
at 
 org.apache.catalina.tribes.group.ChannelCoordinator.internalStart(ChannelCoordinator.java:178)
at 
 org.apache.catalina.tribes.group.ChannelCoordinator.start(ChannelCoordinator.java:99)
at 
 org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:162)
at 
 org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:162)
at 
 org.apache.catalina.tribes.group.interceptors.MessageDispatchInterceptor.start(MessageDispatchInterceptor.java:157)
at 
 org.apache.catalina.tribes.group.ChannelInterceptorBase.start(ChannelInterceptorBase.java:162)
at

Re: SimpleTCPCluster

2012-11-20 Thread Stephen Nelson-Smith

Hi Daniel.

On Tue, Nov 20, 2012 at 1:55 PM, Daniel Mikusa dmik...@vmware.com wrote:
 On Nov 20, 2012, at 5:53 AM, Stephen Nelson-Smith wrote:
 I've encountered this with Tomcat clustering on CentOS in the past.  Tomcat's 
 default configuration for the cluster receiver will automatically look up the 
 address to listen.  It does this by calling 
 java.net.InetAddress.getLocalHost().getHostAddress() [1].

 I can't remember exactly why this was failing for me on CentOS, but I'm 
 almost certain it was due to a problem with /etc/hosts.  I'd suggest taking a 
 look at that file and making sure it contains the right entries.

Thanks for the validation - that's pretty much exactly where my
deductions have led me.  I didn't build these machines, so I can't
speak for the validity of the config - will report.

 Otherwise, you can override the default Tomcat setting for the cluster 
 receiver's address attribute, which is auto and specify the address 
 manually.  That should workaround the problem.

Thanks a lot!

S.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: SimpleTCPCluster

2012-11-20 Thread Stephen Nelson-Smith

Hi,

On Tue, Nov 20, 2012 at 2:03 PM, Stephen Nelson-Smith
sanel...@gmail.com wrote:
 Hi Daniel.

 On Tue, Nov 20, 2012 at 1:55 PM, Daniel Mikusa dmik...@vmware.com wrote:
 On Nov 20, 2012, at 5:53 AM, Stephen Nelson-Smith wrote:
 I've encountered this with Tomcat clustering on CentOS in the past.  
 Tomcat's default configuration for the cluster receiver will automatically 
 look up the address to listen.  It does this by calling 
 java.net.InetAddress.getLocalHost().getHostAddress() [1].

 I can't remember exactly why this was failing for me on CentOS, but I'm 
 almost certain it was due to a problem with /etc/hosts.  I'd suggest taking 
 a look at that file and making sure it contains the right entries.

 Thanks for the validation - that's pretty much exactly where my
 deductions have led me.  I didn't build these machines, so I can't
 speak for the validity of the config - will report.

Yep - missing entry; entry added; all good.

Thanks again.

S.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: I have a question about websocket in tomcat7.0.30

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Zane,

On 11/19/12 10:56 PM, zane_zh...@wistronits.com wrote:
 I am trying to build a chat-room in the internet by websocket
 based on tomcat7.0.30. the link between server and browser is not
 reliable. when I try to send a message to server from browser after
 the websocket connection having been built, the server has no
 respond, but this just occasionally occur. I would like to know why
 and I need your help.

You are going to have to provide much more information if anyone is
going to help you. Please post source code to the client and server,
any error messages you have received, etc.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlCrmxYACgkQ9CaO5/Lv0PC2iQCdFn90LM3402P+5fbhzt4W1kjo
al0An1an0IN7uc4sZoOr3zkf1aeQbIOk
=yc67
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Get active session list

2012-11-20 Thread Cosio, Raul

As far as I know there is no way to get the list of active sessions for 
security reasons, some time ago I wanted to display in my application a list of 
active sessions, what I did is to implement some listeners, it is tricky but 
fun once you understand how it works.

The first listener I implemented was an HttpSessionListener (declared in my 
web.xml file), the listener has a method sessionCreated() and 
sessionDestroyed() that I used to update my list of active sessions. 

The tricky part is when the server is restarted, because tomcat serializes the 
sessions and after a restart there will be active sessions that are created 
without a sessionCreated() event (which makes sense because they were not 
destroyed, just serialized). I handle this situation with a 
SessionActivationListener interface that has a method sessionDidActivate(), 
usefult to update my list of active sessions.

The SessionActivationListener is used for any attribute that you add to a 
session with the setAttribute() method. To make this listener available I just 
added an object that implements the listener in the 
HttpSessionListener.sessionCreated() method.

Regards

-Original Message-
From: Felipe Jaekel [mailto:fkjae...@gmail.com] 
Sent: Thursday, October 18, 2012 3:59 PM
To: Tomcat Users List
Subject: Re: Get active session list

Found the following:

context = (Context) wrapper.getParent();
 host = (Host) context.getParent();



 Context ctx = (Context) host.findChild(name);
 Manager manager = ctx.getManager();
 Session [] sessions = manager.findSessions();


Had the same doubt I had when I looked at the PSI Probe code some days ago:
how to handle the wrapper property?


As a alternative I tried to implement *HttpSessionActivationListener*, but
the methods aren't called when I restart the server.

Thanks again for the help,
Phillip


2012/10/18 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Felipe,

 On 10/18/12 9:34 AM, Felipe Jaekel wrote:
  I need to get the active session list. Searching about I saw a lot
  of people with the same question, but no answer.
 
  I don't want to write a list inside a HttpSessionListener and keep
  the session list there, because I use session serialization and the
  list inside the listener would be destroyed in case the server is
  restarted.

 You *can* get notification of sessions being de-serialized from the
 disk to maintain your list. Look at the other session-related
 listeners in the servlet API.

 You could also use JMX to get a list of sessions. Use JConsole to
 poke-around in Tomcat's JMX beans and find the one(s) that expose
 sessions. You may have to make your webapp privileged in order to
 make JMX calls.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

 iEYEARECAAYFAlCAEgwACgkQ9CaO5/Lv0PARBACfZ+EG7KJWXt+49sbB1kVsLunF
 A4MAoKv1hM4KBlaAS4a1UaP0ePqfRr3W
 =n3WU
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


Notice:  This e-mail message, together with any attachments, contains
information of Merck  Co., Inc. (One Merck Drive, Whitehouse Station,
New Jersey, USA 08889), and/or its affiliates Direct contact information
for affiliates is available at 
http://www.merck.com/contact/contacts.html) that may be confidential,
proprietary copyrighted and/or legally privileged. It is intended solely
for the use of the individual or entity named on this message. If you are
not the intended recipient, and have received this message in error,
please notify us immediately by reply e-mail and then delete it from 
your system.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Context root query

2012-11-20 Thread vicky007aggarwal

Helo,

Yes , i restarted tomcat after that but that doesn't help.

But if i define the following in server.xml , i am able to override the default 
context root of an application successfully

Context path=/tests docBase=/var/www/test_application1/
 debug=0 reloadable=true crossContext=false
 /Context
 
But this is not the appropriate way as i don't want to touch the tomcat 
server.xml for every application

Please suggest how i can override the context root of an application using 
META-INF/context.xml
 
Thanks for your time,
Vicky



On Nov 20, 2012, at 6:35 PM, Elias Kopsiaftis yemi...@gmail.com wrote:

 did you reload tomcat after changing the file?
 
 On Tue, Nov 20, 2012 at 7:51 AM, vicky007aggar...@yahoo.co.in wrote:
 
 
 
 
 Hello Guys,
 
 I am trying to define the context root in my application using
 context.xml. I defined the following in application context.xml under
 meta-inf directory
 
 Context path=/app1 privileged=true/
 
 But still tomcat is referring the application name as my context. The
 value which i defined in context.xml is not getting referenced by tomcat.
 
 Can some one please help me in defining the context root for an
 application . I don't want to use the application name as context root for
 my app.
 
 Thanks for your help,
 Vicky
 
 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org
 
 

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Context root query

 From: vicky007aggar...@yahoo.co.in [mailto:vicky007aggar...@yahoo.co.in] 
 Subject: Re: Context root query

 Please suggest how i can override the context root of an application using 
 META-INF/context.xml

You cannot.  Please actually read the documentation everyone has been pointing 
you to.

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Get active session list

2012-11-20 Thread Jose María Zaragoza

Sorry, I'm not following this thread but
Don't you want to use

http://localhost:8080/manager/html/sessions?path=/contextpath

?

You only have to parse this plain HTML webpage
I know that it's not very elegant but 


Regards




2012/11/20 Cosio, Raul jose_raul_co...@merck.com:
 As far as I know there is no way to get the list of active sessions for 
 security reasons, some time ago I wanted to display in my application a list 
 of active sessions, what I did is to implement some listeners, it is tricky 
 but fun once you understand how it works.

 The first listener I implemented was an HttpSessionListener (declared in my 
 web.xml file), the listener has a method sessionCreated() and 
 sessionDestroyed() that I used to update my list of active sessions.

 The tricky part is when the server is restarted, because tomcat serializes 
 the sessions and after a restart there will be active sessions that are 
 created without a sessionCreated() event (which makes sense because they were 
 not destroyed, just serialized). I handle this situation with a 
 SessionActivationListener interface that has a method sessionDidActivate(), 
 usefult to update my list of active sessions.

 The SessionActivationListener is used for any attribute that you add to a 
 session with the setAttribute() method. To make this listener available I 
 just added an object that implements the listener in the 
 HttpSessionListener.sessionCreated() method.

 Regards

 -Original Message-
 From: Felipe Jaekel [mailto:fkjae...@gmail.com]
 Sent: Thursday, October 18, 2012 3:59 PM
 To: Tomcat Users List
 Subject: Re: Get active session list

 Found the following:

 context = (Context) wrapper.getParent();
 host = (Host) context.getParent();



 Context ctx = (Context) host.findChild(name);
 Manager manager = ctx.getManager();
 Session [] sessions = manager.findSessions();


 Had the same doubt I had when I looked at the PSI Probe code some days ago:
 how to handle the wrapper property?


 As a alternative I tried to implement *HttpSessionActivationListener*, but
 the methods aren't called when I restart the server.

 Thanks again for the help,
 Phillip


 2012/10/18 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Felipe,

 On 10/18/12 9:34 AM, Felipe Jaekel wrote:
  I need to get the active session list. Searching about I saw a lot
  of people with the same question, but no answer.
 
  I don't want to write a list inside a HttpSessionListener and keep
  the session list there, because I use session serialization and the
  list inside the listener would be destroyed in case the server is
  restarted.

 You *can* get notification of sessions being de-serialized from the
 disk to maintain your list. Look at the other session-related
 listeners in the servlet API.

 You could also use JMX to get a list of sessions. Use JConsole to
 poke-around in Tomcat's JMX beans and find the one(s) that expose
 sessions. You may have to make your webapp privileged in order to
 make JMX calls.

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

 iEYEARECAAYFAlCAEgwACgkQ9CaO5/Lv0PARBACfZ+EG7KJWXt+49sbB1kVsLunF
 A4MAoKv1hM4KBlaAS4a1UaP0ePqfRr3W
 =n3WU
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


 Notice:  This e-mail message, together with any attachments, contains
 information of Merck  Co., Inc. (One Merck Drive, Whitehouse Station,
 New Jersey, USA 08889), and/or its affiliates Direct contact information
 for affiliates is available at
 http://www.merck.com/contact/contacts.html) that may be confidential,
 proprietary copyrighted and/or legally privileged. It is intended solely
 for the use of the individual or entity named on this message. If you are
 not the intended recipient, and have received this message in error,
 please notify us immediately by reply e-mail and then delete it from
 your system.


 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Context root query

2012-11-20 Thread vicky



Pardon me if i am annoying , but from the below mail link, i located the 
snippet(mentioned below) in which its written
that we can define application context in context.xml.

**
Individual Context elements may be explicitly defined: 
In an individual file at /META-INF/context.xml inside the application files. 
Optionally (based on the Host's copyXML attribute) this may be copied to 
$CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to application's base 
file name plus a .xml extension. 
**
but wrong i am doing , in defining the context in META-INF/context.xml as 
follows :-
Context path=/app1 privileged=true/

Does we cannot override the default application context in tomcat 6.0 using 
META-INF/context.xml  

Thanks all,
Vicky  


 From: Caldarale, Charles R chuck.caldar...@unisys.com
To: Tomcat Users List users@tomcat.apache.org 
Sent: Tuesday, 20 November 2012 10:15 PM
Subject: RE: Context root query
  
 From: vicky007aggar...@yahoo.co.in [mailto:vicky007aggar...@yahoo.co.in] 
 Subject: Re: Context root query

 Please suggest how i can override the context root of an application using 
 META-INF/context.xml

You cannot.  Please actually read the documentation everyone has been pointing 
you to.

http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Defining_a_context

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Context root query

 From: vicky [mailto:vicky007aggar...@yahoo.co.in] 
 Subject: Re: Context root query

 i located the snippet(mentioned below) in which its written
 that we can define application context in context.xml.

 **
 Individual Context elements may be explicitly defined: 
 In an individual file at /META-INF/context.xml inside the application files.
 Optionally (based on the Host's copyXML attribute) this may be copied to 
 $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to application's base
 file name plus a .xml extension. 
 **

And you completely ignored this wording in the description of the path element:

This attribute must only be used when statically defining a Context in 
server.xml. In all other circumstances, the path will be inferred from the 
filenames used for either the .xml context file or the docBase.

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Context root query

2012-11-20 Thread vicky



Thanks a ton charles for passionatly explaining me the intrinsic things , it 
means a lot to me... 
 
1  What sense does it make to statically defining a Context in server.xml ?? 

2  Just to confirm , so using we cannot override  the default  application 
context  using /META-INF/context.xml  ??

3   As i have a user requirement that they want to have a application context 
as different from application archive file name , so i can achieve
this by adding the below snippet in server.xml, provided the docBase 
location shouldnt be the same as of Tomcat WebApps Directory
to avoid double deployment . correct ??

Context path=/tests docBase=/var/www/test_application1/
debug=0 reloadable=true crossContext=false
/Context

Thanks Again
  


 From: Caldarale, Charles R chuck.caldar...@unisys.com
To: Tomcat Users List users@tomcat.apache.org 
Sent: Tuesday, 20 November 2012 10:57 PM
Subject: RE: Context root query
  
 From: vicky [mailto:vicky007aggar...@yahoo.co.in] 
 Subject: Re: Context root query

 i located the snippet(mentioned below) in which its written
 that we can define application context in context.xml.

 **
 Individual Context elements may be explicitly defined: 
 In an individual file at /META-INF/context.xml inside the application files.
 Optionally (based on the Host's copyXML attribute) this may be copied to 
 $CATALINA_BASE/conf/[enginename]/[hostname]/ and renamed to application's base
 file name plus a .xml extension. 
 **

And you completely ignored this wording in the description of the path element:

This attribute must only be used when statically defining a Context in 
server.xml. In all other circumstances, the path will be inferred from the 
filenames used for either the .xml context file or the docBase.

- Chuck


THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Context root query

2012-11-20 Thread Mark Thomas

On 20/11/2012 17:47, vicky wrote:
 3   As i have a user requirement that they want to have a application 
 context as different from application archive file name

That sounds like an x-y problem to me. What is the real user requirement?

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Context root query

 From: vicky [mailto:vicky007aggar...@yahoo.co.in] 
 Subject: Re: Context root query

 What sense does it make to statically defining a Context in server.xml ?? 

Pretty much none, these days.  Don't do it.

 we cannot override  the default  application context  using 
 /META-INF/context.xml  ??

The path attribute is not allowed, except when using the strongly discouraged 
mechanism of placing the Context element in server.xml.

 As i have a user requirement that they want to have a application context 
 as different from application archive file name 

Your user has a nonsensical requirement.  If you can't get that changed, your 
best alternative is to keep the .war file completely outside of Tomcat's 
directory structure, and place a Context element in the file 
conf/Catalina/[host]/[appName].xml, with a docBase attribute pointing the 
absolute location of the .war file.

 i can achieve this by adding the below snippet in server.xml

That is seriously not recommended.  Use the approach outlined above instead.

 Context path=/tests docBase=/var/www/test_application1/
 debug=0 reloadable=true crossContext=false
 /Context

On a side note, did you see any debug attribute in the documentation for the 
Context element?  Since you didn't, why are you using it?

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Context root query

2012-11-20 Thread vicky



MARK -  

My client has application archives files which all have version string in it as 
stated below :-

eg:- mom-1.2.0.war, mom-1.3.0.war,  mom-1.4.0.war,  mom-1.5.0.war

So they doest want the version string mentioned in the application archive to 
become part of application context.

The context should remain same irrespective of the application archive they 
deploy,

Do you have any better approach /suggestion for this requirement
 
thanks for your help
vicky
 


 From: Mark Thomas ma...@apache.org
To: Tomcat Users List users@tomcat.apache.org 
Sent: Tuesday, 20 November 2012 11:51 PM
Subject: Re: Context root query
  
On 20/11/2012 17:47, vicky wrote:
 3   As i have a user requirement that they want to have a application 
 context as different from application archive file name

That sounds like an x-y problem to me. What is the real user requirement?

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat-native 1.1.24

2012-11-20 Thread Isaac López Marín

Hi again,

I don't know what to do about this problem, so I decided to uninstall
tomcat-native and I'll try to work without it.

Thanks a lot for your help :)


2012/11/16 André Warnier a...@ice-sa.com

 Hi.


 Isaac López Marín wrote:

 We kind of guessed as much, considering the sender and the signature. :-)


 I'll try not to be so newbie next time :))

  I don't know anything about Mac OS, but I would guess that the question

 is : *where and how* did you install tomcat-native-1.1.24-src.tar.**gz ?

 Well, I installed it using the install.sh file and creating a symbolic
 link
 to /usr/lib/java
 I mean, I didn't get errors during the process and the server found the
 correct path for tomcat-native.

 I think it's a little hard to describe the problem, because I blocked when
 I saw that the native version installed is different from the downloaded
 version:

 (from install log)
 ---  Fetching distfiles for tomcat-native
 ---  Verifying checksum(s) for tomcat-native
 ---  Extracting tomcat-native
 ---  Configuring tomcat-native
 ---  Building tomcat-native
 ---  Staging tomcat-native into destroot


  ---  Installing tomcat-native @1.1.22_0 ---  Activating tomcat-native
 @1.1.22_0


 that is indeed quite strange...



  and the downloaded version is:

 Source (please choose the correct format for your platform)


 considering this ...

 - Native 1.1.24 Source Release tar.gz  http://ftp.udc.es/apache//**
 tomcat/tomcat-connectors/**native/1.1.24/source/tomcat-**
 native-1.1.24-src.tar.gzhttp://ftp.udc.es/apache//tomcat/tomcat-connectors/native/1.1.24/source/tomcat-native-1.1.24-src.tar.gz
 (e.g.
Unix, Linux, Mac OS)


 Maybe you should download this again from the original source (the home
 Tomcat website tomcat.apache.org ) ?




  I don't know how to describe the problem in another way.


 That was good enough.
 Again, I don't know the details, but it seems strange that the names of
 the files do not match the version that the install script says it is
 installing.



  2012/11/15 André Warnier a...@ice-sa.com

 Isaac López Marín wrote:

 Hi everyone.

 My name is Isaac.


 We kind of guessed as much, considering the sender and the signature. :-)


  This is the first time I sent a mail to this mailing ist.

 I'm working with Netbeans 7 and Tomcat 7.0.32

 I've installed tomcat-native 1.1.24 for Mac
 OS (tomcat-native-1.1.24-src.tar.**gz) from tomcat.apache.org
 I had no errors, but when I restart the server, I obtain this:

 SEVERE: An incompatible version 1.1.22 of the APR based Apache
 Tomcat Native library is installed, while Tomcat requires version

 1.1.24,

 but I'm just installed the last version of Tomcat-native.
 I couldn't find useful help on the web, and I don't know how to fix it.

  I don't know anything about Mac OS, but I would guess that the question

 is : *where and how* did you install tomcat-native-1.1.24-src.tar.**gz ?


 --**--**
 -
 To unsubscribe, e-mail: 
 users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org




 --**--**-
 To unsubscribe, e-mail: 
 users-unsubscribe@tomcat.**apache.orgusers-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Context root query

 From: vicky [mailto:vicky007aggar...@yahoo.co.in] 
 Subject: Re: Context root query

 My client has application archives files which all have version 
 string in it as stated below :-
 eg:- mom-1.2.0.war, mom-1.3.0.war,  mom-1.4.0.war,  mom-1.5.0.war

 So they doest want the version string mentioned in the application 
 archive to become part of application context.

 Do you have any better approach /suggestion for this requirement

Move to Tomcat 7, and use the parallel deployment capability:

http://tomcat.eu.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment

 - Chuck

THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY 
MATERIAL and is thus for use only by the intended recipient. If you received 
this in error, please contact the sender and delete the e-mail and its 
attachments from all computers.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Context root query

2012-11-20 Thread Mark Eggers


On 11/20/2012 10:32 AM, vicky wrote:



MARK -

My client has application archives files which all have version
string in it as stated below :-

eg:- mom-1.2.0.war, mom-1.3.0.war,  mom-1.4.0.war,  mom-1.5.0.war

So they doest want the version string mentioned in the application
archive to become part of application context.

The context should remain same irrespective of the application
archive they deploy,

Do you have any better approach /suggestion for this requirement

thanks for your help vicky


 From: Mark Thomas
ma...@apache.org To: Tomcat Users List users@tomcat.apache.org
Sent: Tuesday, 20 November 2012 11:51 PM Subject: Re: Context root
query

On 20/11/2012 17:47, vicky wrote:

3   As i have a user requirement that they want to have a
application context as different from application archive file
name


That sounds like an x-y problem to me. What is the real user
requirement?

Mark


As has been said before:

1. Create a directory

This should be outside of the appBase for the host you're deploying on.
This should also not be in a place where a web server can serve content 
(see below).


2. Add all the war files

mom-1.1.0.war
mom-1.2.3.war
mom-5.7.9.war

3. Create a mom.xml file

In the mom.xml file, have a context element. It should read something 
like the following:


Context docBase=/your-directory/mom-1.2.3.war/

That's it. No reloadable=true, no debug=0, no crossContext=false.

reloadable=true is not recommended for production environments, there 
is no debug attribute, and crossContext=false is the default.


4. Place the file in the appropriate spot.

$CATALINA_BASE/conf/[hostname]/mom.xml is where it goes.

The above configuration will serve mom-1.2.3.war as context mom for that 
host when accessed from Tomcat.


And no, hacking server.xml, adding a path attribute to the context.xml 
file (mom.xml file), and other such games will either not work or cause 
you nothing but grief.


Note on the above.

Do NOT place this war file where Apache HTTPD (or another web server) 
can serve the content directly. If it's a WAR file, the user will get to 
download a copy of the application. If it's an exploded WAR file 
(directory, etc.) then JSP files will get served as source (most 
likely), and anything in WEB-INF will be served by the web server unless 
you've taken special precautions.


Just follow the instructions in the Tomcat documentation.

. . . . just my two cents.
/mde/

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: multiple tomcat instances for every application

2012-11-20 Thread Ashkan Rahmani

On Tue, Nov 20, 2012 at 5:13 PM, Caldarale, Charles R 
chuck.caldar...@unisys.com wrote:

  From: Ashkan Rahmani [mailto:ashkan...@gmail.com]
  Subject: Re: multiple tomcat instances for every application

  do you know what is  -Xshare:off ?
  is it related to share classes?

 http://lmgtfy.com/?q=%22-Xshare%3Aoff%22

  King Regards,

 Didn't realize we were dealing with royalty...

  - Chuck

 THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
 MATERIAL and is thus for use only by the intended recipient. If you
 received this in error, please contact the sender and delete the e-mail and
 its attachments from all computers.

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

http://lmgtfy.com/?q=thank+you.+I+did+it+before.

Re: Context root query

2012-11-20 Thread Mark Thomas

On 20/11/2012 18:45, Caldarale, Charles R wrote:
 From: vicky [mailto:vicky007aggar...@yahoo.co.in] 
 Subject: Re: Context root query
 
 
 My client has application archives files which all have version 
 string in it as stated below :-
 eg:- mom-1.2.0.war, mom-1.3.0.war,  mom-1.4.0.war,  mom-1.5.0.war
 
 So they doest want the version string mentioned in the application 
 archive to become part of application context.
 
 Do you have any better approach /suggestion for this requirement
 
 Move to Tomcat 7, and use the parallel deployment capability:
 
 http://tomcat.eu.apache.org/tomcat-7.0-doc/config/context.html#Parallel_deployment

To be clear, use the naming convention mom##1.2.0.war and you'll get
what you want. You don;t have do have multiple versions for this to work.

Mark


-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded

2012-11-20 Thread Pid *

On 20 Nov 2012, at 13:42, Jim open...@gmail.com wrote:

 Thanks for the question -- I worded that part awkwardly.

 Our project has a root-level /src directory with the web app's Java files, 
 and a root-level /war directory with the exploded non-Java files (static 
 assets, JSPs, etc.).  When developing, Eclipse compiles the /src directory 
 into the /war/WEB-INF/classes directory, and then copies any changed files 
 from /war into its embedded Tomcat instance.

 When we switch Git branches, that could change the .jsp/.tag files inside the 
 /war directory, but depending on the branch, those changed files might have 
 an earlier modified-timestamp than the .jsp/.tag files that have already been 
 copied over to the embedded Tomcat's exploded webapp directory.  So my 
 thought was that those files would not, then, be recompiled, and so at 
 runtime, Tomcat would be using the older versions of those files that are 
 cached in Tomcat's /work directory.  I think that theory is countered, 
 however, by my colleague's claim that she clears out /work before deploying 
 a new branch, and also my own experience wherein I watched Tomcat re-compile 
 the .tag file into the /work directory, yet still claim the tag's class 
 cannot be resolved.

 But to clarify: no part of Tomcat itself, including /work, is kept under 
 version control.

 -- Jim


 On 11/20/12 2:18 AM, Pid * wrote:
 On 19 Nov 2012, at 23:58, Jim open...@gmail.com wrote:

 Hello!

 My team has been having an issue wherein our application occasionally fails 
 to start up because Tomcat claims it can't find find a dynamically-created 
 classfile.  This doesn't happen all the time, and restarting Tomcat (albeit 
 more than once, sometimes) resolves it.

 For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, on 
 OS 10.7.5), tried to load a page, and got:

 ** snip **

 An error occurred at line: 1 in the jsp file: 
 /WEB-INF/jsp/about/about_impact.jsp
 org.apache.jsp.tag.web.about_tag cannot be resolved to a type
 1: %@ include file=../common/constants.jsp %templates:about

 ** snip/ **

 The constants.jsp referenced above contains:
 %@ taglib prefix=templates tagdir=/WEB-INF/tags %

 ... and /WEB-INF/tags contains the about.tag file.

 The $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web 
 directory exists, and it contains both about_tag.class and about_tag.java, 
 with timestamps corresponding to when I loaded the page.

 I then deleted those files, and refreshed the page in my browser. 
 about_tag.class and about_tag.java get recreated in that directory, but I 
 still get the above error claiming about_tag can't be resolved.

 I then restarted Tomcat, refreshed the page in my browser, and all is well.


 I've also seen this happen regularly for my Windows-using colleagues, as 
 well as in a non-Eclipse Linux-based 6.0.29 instance, and (hearsay) a 
 colleague reported it happening in his Tomcat 7. Thinking it was a runtime 
 race condition, we also tried telling Tomcat to load the JSP on startup via 
 the web.xml, and while we did see the .java and .class files being created 
 on startup, we still ran into the issue.  We haven't yet tried 
 pre-compiling our JSPs/TAGs before starting Tomcat -- but that shouldn't be 
 necessary, right?

 I'd love some advice/insight in how I might investigate this further, or if 
 there's a gotcha I might be running into.  It feels like a race 
 condition in the classloader, but I don't want to submit a bug report 
 without a reliable test case, of course. Since we can't reliably recreate 
 the situation, I'm having trouble putting that together.

 This seems to happen more often for me when I'm switching between 
 substantially-different Git branches, so I thought it might have to do with 
 the /work directory having older versions of the JSPs/TAGs, but one of my 
 colleagues claims to clean her /work directory every time she switches 
 branches, and before starting Tomcat, and still getting the issue.
 What is the relationship between Git and Tomcat, exactly?

 Does Tomcat load an app (or its files) directly from a version
 controlled file system?


 p



 Thanks in advance for any help!
 Jim

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org



 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Is any part of the compiled output, under /war in version control?
(It should not be).


p

-
To unsubscribe, e-mail:

Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded

No -- the /war/WEB-INF/classes directory is .gitignored, and empty until 
we deploy, at which point we copy in the compiled .java files, etc.


I suppose my core question is: if 
$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class 
exists, what situations could cause Tomcat to give the following error:


An error occurred at line: 1 in the jsp file: 
/WEB-INF/jsp/about/about_impact.jsp

org.apache.jsp.tag.web.about_tag cannot be resolved to a type
1: %@ include file=../common/constants.jsp %templates:about

If I delete 
$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class, 
and re-visit /WEB-INF/jsp/about/about_impact.jsp, 
$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class 
gets re-created, but I still get the above error.


So, Tomcat appears to be compiling the JSP fine, but that compiled JSP 
does not appear to be making it into the classloader?


-- Jim


On 11/20/12 2:34 PM, Pid * wrote:

On 20 Nov 2012, at 13:42, Jim open...@gmail.com wrote:


Thanks for the question -- I worded that part awkwardly.

Our project has a root-level /src directory with the web app's Java files, and a root-level /war 
directory with the exploded non-Java files (static assets, JSPs, etc.).  When developing, Eclipse compiles the /src 
directory into the /war/WEB-INF/classes directory, and then copies any changed files from /war into its 
embedded Tomcat instance.

When we switch Git branches, that could change the .jsp/.tag files inside the /war directory, but depending on the 
branch, those changed files might have an earlier modified-timestamp than the .jsp/.tag files that have already been copied over 
to the embedded Tomcat's exploded webapp directory.  So my thought was that those files would not, then, be recompiled, and so at 
runtime, Tomcat would be using the older versions of those files that are cached in Tomcat's /work directory.  I 
think that theory is countered, however, by my colleague's claim that she clears out /work before deploying a new 
branch, and also my own experience wherein I watched Tomcat re-compile the .tag file into the /work directory, yet 
still claim the tag's class cannot be resolved.

But to clarify: no part of Tomcat itself, including /work, is kept under 
version control.

-- Jim


On 11/20/12 2:18 AM, Pid * wrote:

On 19 Nov 2012, at 23:58, Jim open...@gmail.com wrote:


Hello!

My team has been having an issue wherein our application occasionally fails to 
start up because Tomcat claims it can't find find a dynamically-created 
classfile.  This doesn't happen all the time, and restarting Tomcat (albeit 
more than once, sometimes) resolves it.

For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, on OS 
10.7.5), tried to load a page, and got:

** snip **

An error occurred at line: 1 in the jsp file: 
/WEB-INF/jsp/about/about_impact.jsp
org.apache.jsp.tag.web.about_tag cannot be resolved to a type
1: %@ include file=../common/constants.jsp %templates:about

** snip/ **

The constants.jsp referenced above contains:
%@ taglib prefix=templates tagdir=/WEB-INF/tags %

... and /WEB-INF/tags contains the about.tag file.

The $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web directory 
exists, and it contains both about_tag.class and about_tag.java, with timestamps 
corresponding to when I loaded the page.

I then deleted those files, and refreshed the page in my browser. 
about_tag.class and about_tag.java get recreated in that directory, but I still 
get the above error claiming about_tag can't be resolved.

I then restarted Tomcat, refreshed the page in my browser, and all is well.


I've also seen this happen regularly for my Windows-using colleagues, as well 
as in a non-Eclipse Linux-based 6.0.29 instance, and (hearsay) a colleague 
reported it happening in his Tomcat 7. Thinking it was a runtime race 
condition, we also tried telling Tomcat to load the JSP on startup via the 
web.xml, and while we did see the .java and .class files being created on 
startup, we still ran into the issue.  We haven't yet tried pre-compiling our 
JSPs/TAGs before starting Tomcat -- but that shouldn't be necessary, right?

I'd love some advice/insight in how I might investigate this further, or if there's a 
gotcha I might be running into.  It feels like a race condition in the 
classloader, but I don't want to submit a bug report without a reliable test case, of course. Since 
we can't reliably recreate the situation, I'm having trouble putting that together.

This seems to happen more often for me when I'm switching between substantially-different 
Git branches, so I thought it might have to do with the /work directory having older 
versions of the JSPs/TAGs, but one of my colleagues claims to clean her /work 
directory every time she switches branches, and before starting Tomcat, and still getting 
the issue.

What is the relationship between Git and Tomcat, exactly?

Does Tomcat load

Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded

2012-11-20 Thread Pid *

On 20 Nov 2012, at 19:44, Jim open...@gmail.com wrote:

 No -- the /war/WEB-INF/classes directory is .gitignored, and empty until we 
 deploy, at which point we copy in the compiled .java files, etc.

 I suppose my core question is: if 
 $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class
  exists, what situations could cause Tomcat to give the following error:

 An error occurred at line: 1 in the jsp file: 
 /WEB-INF/jsp/about/about_impact.jsp
 org.apache.jsp.tag.web.about_tag cannot be resolved to a type
 1: %@ include file=../common/constants.jsp %templates:about

 If I delete 
 $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class,
  and re-visit /WEB-INF/jsp/about/about_impact.jsp, 
 $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class
  gets re-created, but I still get the above error.

 So, Tomcat appears to be compiling the JSP fine, but that compiled JSP does 
 not appear to be making it into the classloader?

 -- Jim


 On 11/20/12 2:34 PM, Pid * wrote:
 On 20 Nov 2012, at 13:42, Jim open...@gmail.com wrote:

 Thanks for the question -- I worded that part awkwardly.

 Our project has a root-level /src directory with the web app's Java 
 files, and a root-level /war directory with the exploded non-Java files 
 (static assets, JSPs, etc.).  When developing, Eclipse compiles the /src 
 directory into the /war/WEB-INF/classes directory, and then copies any 
 changed files from /war into its embedded Tomcat instance.

 When we switch Git branches, that could change the .jsp/.tag files inside 
 the /war directory, but depending on the branch, those changed files 
 might have an earlier modified-timestamp than the .jsp/.tag files that have 
 already been copied over to the embedded Tomcat's exploded webapp 
 directory.  So my thought was that those files would not, then, be 
 recompiled, and so at runtime, Tomcat would be using the older versions of 
 those files that are cached in Tomcat's /work directory.  I think that 
 theory is countered, however, by my colleague's claim that she clears out 
 /work before deploying a new branch, and also my own experience wherein I 
 watched Tomcat re-compile the .tag file into the /work directory, yet 
 still claim the tag's class cannot be resolved.

 But to clarify: no part of Tomcat itself, including /work, is kept under 
 version control.

 -- Jim


 On 11/20/12 2:18 AM, Pid * wrote:
 On 19 Nov 2012, at 23:58, Jim open...@gmail.com wrote:

 Hello!

 My team has been having an issue wherein our application occasionally 
 fails to start up because Tomcat claims it can't find find a 
 dynamically-created classfile.  This doesn't happen all the time, and 
 restarting Tomcat (albeit more than once, sometimes) resolves it.

 For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, 
 on OS 10.7.5), tried to load a page, and got:

 ** snip **

 An error occurred at line: 1 in the jsp file: 
 /WEB-INF/jsp/about/about_impact.jsp
 org.apache.jsp.tag.web.about_tag cannot be resolved to a type
 1: %@ include file=../common/constants.jsp %templates:about

 ** snip/ **

 The constants.jsp referenced above contains:
 %@ taglib prefix=templates tagdir=/WEB-INF/tags %

 ... and /WEB-INF/tags contains the about.tag file.

 The $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web 
 directory exists, and it contains both about_tag.class and 
 about_tag.java, with timestamps corresponding to when I loaded the page.

 I then deleted those files, and refreshed the page in my browser. 
 about_tag.class and about_tag.java get recreated in that directory, but I 
 still get the above error claiming about_tag can't be resolved.

 I then restarted Tomcat, refreshed the page in my browser, and all is 
 well.


 I've also seen this happen regularly for my Windows-using colleagues, as 
 well as in a non-Eclipse Linux-based 6.0.29 instance, and (hearsay) a 
 colleague reported it happening in his Tomcat 7. Thinking it was a 
 runtime race condition, we also tried telling Tomcat to load the JSP on 
 startup via the web.xml, and while we did see the .java and .class files 
 being created on startup, we still ran into the issue.  We haven't yet 
 tried pre-compiling our JSPs/TAGs before starting Tomcat -- but that 
 shouldn't be necessary, right?

 I'd love some advice/insight in how I might investigate this further, or 
 if there's a gotcha I might be running into.  It feels like a race 
 condition in the classloader, but I don't want to submit a bug report 
 without a reliable test case, of course. Since we can't reliably recreate 
 the situation, I'm having trouble putting that together.

 This seems to happen more often for me when I'm switching between 
 substantially-different Git branches, so I thought it might have to do 
 with the /work directory having older versions of the JSPs/TAGs, but one 
 of my colleagues claims to clean her /work directory every time she 
 switches

Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded


What I'm getting at is this: your release process should produce a
.war (or exploded directory) that is copied to Tomcat and that Tomcat
should not be reading any part of the app from the /war directory - a
source controlled directory.
Right: we produce an exploded directory which is then copied to Tomcat.  
The exploded /war directory in our project is copied into 
$CATALINA_HOME/webapps/[name of app].  All of Tomcat, including the 
/work and /webapps directories, is separate from our 
source-controlled project.


To clarify one thing: the JSPs /are/ being compiled, and recompiled.  I 
will see the classfile for the JSP/tag appear in Tomcat's /work 
directory, but Tomcat claims it can't find it. If I remove the .class 
file in the /work directory, and re-visit the JSP, Tomcat will 
re-compile the .class file, but the page will still fail to load with 
the same error about not being able to resolve the class.  That latter 
behavior makes me think that Git/timestamps are a red herring; my 
problem seems to be that the compilation occurs correctly, but that the 
classes are sometimes not loaded into the classloader.  Also, when this 
error happens, restarting Tomcat -- without changing the contents of 
/webapp/[name of app] at all -- resolves the issue, which hints at 
some sort of classloading race condition.


-- Jim

On 11/20/12 3:40 PM, Pid * wrote:

On 20 Nov 2012, at 19:44, Jim open...@gmail.com wrote:


No -- the /war/WEB-INF/classes directory is .gitignored, and empty until we 
deploy, at which point we copy in the compiled .java files, etc.

I suppose my core question is: if 
$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class
 exists, what situations could cause Tomcat to give the following error:

An error occurred at line: 1 in the jsp file: 
/WEB-INF/jsp/about/about_impact.jsp
org.apache.jsp.tag.web.about_tag cannot be resolved to a type
1: %@ include file=../common/constants.jsp %templates:about

If I delete $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class, and 
re-visit /WEB-INF/jsp/about/about_impact.jsp, 
$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class gets re-created, 
but I still get the above error.

So, Tomcat appears to be compiling the JSP fine, but that compiled JSP does not 
appear to be making it into the classloader?

-- Jim


On 11/20/12 2:34 PM, Pid * wrote:

On 20 Nov 2012, at 13:42, Jim open...@gmail.com wrote:


Thanks for the question -- I worded that part awkwardly.

Our project has a root-level /src directory with the web app's Java files, and a root-level /war 
directory with the exploded non-Java files (static assets, JSPs, etc.).  When developing, Eclipse compiles the /src 
directory into the /war/WEB-INF/classes directory, and then copies any changed files from /war into its 
embedded Tomcat instance.

When we switch Git branches, that could change the .jsp/.tag files inside the /war directory, but depending on the 
branch, those changed files might have an earlier modified-timestamp than the .jsp/.tag files that have already been copied over 
to the embedded Tomcat's exploded webapp directory.  So my thought was that those files would not, then, be recompiled, and so at 
runtime, Tomcat would be using the older versions of those files that are cached in Tomcat's /work directory.  I 
think that theory is countered, however, by my colleague's claim that she clears out /work before deploying a new 
branch, and also my own experience wherein I watched Tomcat re-compile the .tag file into the /work directory, yet 
still claim the tag's class cannot be resolved.

But to clarify: no part of Tomcat itself, including /work, is kept under 
version control.

-- Jim


On 11/20/12 2:18 AM, Pid * wrote:

On 19 Nov 2012, at 23:58, Jim open...@gmail.com wrote:


Hello!

My team has been having an issue wherein our application occasionally fails to 
start up because Tomcat claims it can't find find a dynamically-created 
classfile.  This doesn't happen all the time, and restarting Tomcat (albeit 
more than once, sometimes) resolves it.

For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, on OS 
10.7.5), tried to load a page, and got:

** snip **

An error occurred at line: 1 in the jsp file: 
/WEB-INF/jsp/about/about_impact.jsp
org.apache.jsp.tag.web.about_tag cannot be resolved to a type
1: %@ include file=../common/constants.jsp %templates:about

** snip/ **

The constants.jsp referenced above contains:
%@ taglib prefix=templates tagdir=/WEB-INF/tags %

... and /WEB-INF/tags contains the about.tag file.

The $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web directory 
exists, and it contains both about_tag.class and about_tag.java, with timestamps 
corresponding to when I loaded the page.

I then deleted those files, and refreshed the page in my browser. 
about_tag.class and about_tag.java get recreated in that directory, but I still 
get the above error

Re: connection autoReconnect?

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Arnaud,

On 11/20/12 4:23 AM, Arnaud wrote:
We have been struggling with this MySQL last packet message for
some times as well. And we are still not sure if we have solved it
yet.

You can get the last packet message for a number of reasons.
Typically, it's because the connection has gone stale due to firewall
or other connection timeout and the connection has been closed but it
is still in the connection pool.

However we did discover quite a few things.

We minimized our DBCP configuration to only a few parameters
Context path= Resource auth=Container
driverClassName=com.mysql.jdbc.Driver name=jdbc/retailUser
type=javax.sql.DataSource username=xx password=x
url=jdbc:mysql://server/db validationQuery=SELECT 1
testOnBorrow=true/ /Context

Sounds to me that the default values aren't acceptable, then.

So, now and then you will retrieve a connection that has timed out.
The validation query solves this.

Correct. For MySQL, you'll want to use /* ping */ SELECT 1 for your
query: it will be fasted with any reasonably-recent version of
Connector/J which does a lightweight ping to the database instead of
actually issuing the query, fetching the results, etc.

As far as we know the autoReconnect is a jConnector parameter and
only applies to MySQL.

That is correct. The product is Connector/J.

MySQL says in their documentation that it's the applications job to
handle failed connections. For the step of just getting the
connection DBCP is solving this with the validationQuery=SELECT
1 testOnBorrow=true settings. But if it happens in the midst of
a transaction, your application should handle it.

While true, I can't imagine any database that would
commit-on-connection-failure. Most applications are written to simply
throw a SQLException and either abandon the transaction or re-try it.
In either case, the intended behavior is achieved: no half-performed
transactions are committed.

If you do not set validationQuery than testOnBorrow will simply not
run.

This is clear from the DBCP documentation.

removeAbandoned only removes connections that you forget to close
in your application.

This isn't strictly true: the abandonedTimeout specifies a window of
opportunity that the client has to return a particular resource. If
the transaction runs long, the connection can be considered
abandoned even if the application eventually closes it.

You can use this setting for a while together with logAbandoned to
find your application leaks where you forget to close the
connection after use, but when done you should remove logAbandoned
because the logging adds overhead from every connection borrowed.

This is also clear from the documentation.

Most of this we found at
tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html
http://tomcat.apache.org/tomcat-7.0-doc/jdbc-pool.html and at
dev.mysql.com/doc/refman/5.5/en/connector-j-reference-configuration-properties.html

http://dev.mysql.com/doc/refman/5.5/en/connector-j-reference-configuration-properties.html

DBCP != Tomcat-pool

They can be configured in very similar ways, but tomcat-pool is a lot
more flexible and was designed to be higher-performing than DBCP --
though I haven't independently verified that it is actually faster.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlCr+28ACgkQ9CaO5/Lv0PAG4gCfS225GnljSNwwAaOuVMuRqWD1
umEAnAuYOb5YML3B4Vbxvcj4cjm/Wfu9
=Y/Ij
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: Get active session list

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Raul,

On 11/20/12 11:02 AM, Cosio, Raul wrote:
 As far as I know there is no way to get the list of active
 sessions for security reasons

You can also use JMX to get a list of sessions.

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlCr+9sACgkQ9CaO5/Lv0PCgMgCfdycQlWtur1RBFzXEMiuGxf+H
7DUAnigezADr+Ee5hnxSRTifEjTr+IjS
=CES6
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat-native 1.1.24

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

André,

On 11/16/12 3:31 AM, André Warnier wrote:
 considering this ...
 
 - Native 1.1.24 Source Release tar.gz 
 http://ftp.udc.es/apache//tomcat/tomcat-connectors/native/1.1.24/source/tomcat-native-1.1.24-src.tar.gz(e.g.


 
Unix, Linux, Mac OS)
 
 
 Maybe you should download this again from the original source (the 
 home Tomcat website tomcat.apache.org ) ?

The package from the above link appears to be the same as from
apache.org: MD5-sum is cfd4762f2da19ba79d1b6a2a948c9d21.

Also, every binary release of Tomcat includes tomcat-native.tar.gz in
the bin/ directory, so you don't have to guess at what version you
need (unless you want to).

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlCr/ScACgkQ9CaO5/Lv0PBbWgCfWnt2hLPYbaP5FHscTpz+JqqB
v9EAoIR0a/Z9DogtbDC3/qVmAYEUZtro
=R0AV
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat-native 1.1.24

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Isaac,

On 11/15/12 6:47 PM, Isaac López Marín wrote:
 Well, I installed it using the install.sh file and creating a
 symbolic link to /usr/lib/java I mean, I didn't get errors during
 the process and the server found the correct path for
 tomcat-native.
 
 I think it's a little hard to describe the problem, because I
 blocked when I saw that the native version installed is different
 from the downloaded version:
 
 (from install log) ---  Fetching distfiles for tomcat-native ---
 Verifying checksum(s) for tomcat-native

So you downloaded the source and then ran a program that downloads the
source? I can't find these strings anywhere in the tcnative-1.1.24
package:

 ---  Extracting tomcat-native ---  Configuring tomcat-native ---
 Building tomcat-native ---  Staging tomcat-native into destroot 
 ---  Installing tomcat-native @1.1.22_0 ---  Activating
 tomcat-native @1.1.22_0

What script did you actually run?

- -chris
-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlCr/aoACgkQ9CaO5/Lv0PA2BwCglFASJGdyMOCm0eemU6htmCgW
QxgAniss5vezNxhRfe2sRoX52zaujEV6
=2xTf
-END PGP SIGNATURE-

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded

2012-11-20 Thread Pid *

On 20 Nov 2012, at 21:44, Jim open...@gmail.com wrote:

 What I'm getting at is this: your release process should produce a
 .war (or exploded directory) that is copied to Tomcat and that Tomcat
 should not be reading any part of the app from the /war directory - a
 source controlled directory.
 Right: we produce an exploded directory which is then copied to Tomcat.  The 
 exploded /war directory in our project is copied into 
 $CATALINA_HOME/webapps/[name of app].  All of Tomcat, including the /work 
 and /webapps directories, is separate from our source-controlled project.

 To clarify one thing: the JSPs /are/ being compiled, and recompiled.  I will 
 see the classfile for the JSP/tag appear in Tomcat's /work directory, but 
 Tomcat claims it can't find it. If I remove the .class file in the /work 
 directory, and re-visit the JSP, Tomcat will re-compile the .class file, but 
 the page will still fail to load with the same error about not being able to 
 resolve the class.  That latter behavior makes me think that Git/timestamps 
 are a red herring; my problem seems to be that the compilation occurs 
 correctly, but that the classes are sometimes not loaded into the 
 classloader.  Also, when this error happens, restarting Tomcat -- without 
 changing the contents of /webapp/[name of app] at all -- resolves the 
 issue, which hints at some sort of classloading race condition.

 -- Jim

 On 11/20/12 3:40 PM, Pid * wrote:
 On 20 Nov 2012, at 19:44, Jim open...@gmail.com wrote:

 No -- the /war/WEB-INF/classes directory is .gitignored, and empty until we 
 deploy, at which point we copy in the compiled .java files, etc.

 I suppose my core question is: if 
 $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class
  exists, what situations could cause Tomcat to give the following error:

 An error occurred at line: 1 in the jsp file: 
 /WEB-INF/jsp/about/about_impact.jsp
 org.apache.jsp.tag.web.about_tag cannot be resolved to a type
 1: %@ include file=../common/constants.jsp %templates:about

 If I delete 
 $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class,
  and re-visit /WEB-INF/jsp/about/about_impact.jsp, 
 $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class
  gets re-created, but I still get the above error.

 So, Tomcat appears to be compiling the JSP fine, but that compiled JSP does 
 not appear to be making it into the classloader?

 -- Jim


 On 11/20/12 2:34 PM, Pid * wrote:
 On 20 Nov 2012, at 13:42, Jim open...@gmail.com wrote:

 Thanks for the question -- I worded that part awkwardly.

 Our project has a root-level /src directory with the web app's Java 
 files, and a root-level /war directory with the exploded non-Java files 
 (static assets, JSPs, etc.).  When developing, Eclipse compiles the 
 /src directory into the /war/WEB-INF/classes directory, and then 
 copies any changed files from /war into its embedded Tomcat instance.

 When we switch Git branches, that could change the .jsp/.tag files inside 
 the /war directory, but depending on the branch, those changed files 
 might have an earlier modified-timestamp than the .jsp/.tag files that 
 have already been copied over to the embedded Tomcat's exploded webapp 
 directory.  So my thought was that those files would not, then, be 
 recompiled, and so at runtime, Tomcat would be using the older versions 
 of those files that are cached in Tomcat's /work directory.  I think 
 that theory is countered, however, by my colleague's claim that she 
 clears out /work before deploying a new branch, and also my own 
 experience wherein I watched Tomcat re-compile the .tag file into the 
 /work directory, yet still claim the tag's class cannot be resolved.

 But to clarify: no part of Tomcat itself, including /work, is kept 
 under version control.

 -- Jim


 On 11/20/12 2:18 AM, Pid * wrote:
 On 19 Nov 2012, at 23:58, Jim open...@gmail.com wrote:

 Hello!

 My team has been having an issue wherein our application occasionally 
 fails to start up because Tomcat claims it can't find find a 
 dynamically-created classfile.  This doesn't happen all the time, and 
 restarting Tomcat (albeit more than once, sometimes) resolves it.

 For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, 
 on OS 10.7.5), tried to load a page, and got:

 ** snip **

 An error occurred at line: 1 in the jsp file: 
 /WEB-INF/jsp/about/about_impact.jsp
 org.apache.jsp.tag.web.about_tag cannot be resolved to a type
 1: %@ include file=../common/constants.jsp %templates:about

 ** snip/ **

 The constants.jsp referenced above contains:
 %@ taglib prefix=templates tagdir=/WEB-INF/tags %

 ... and /WEB-INF/tags contains the about.tag file.

 The $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web 
 directory exists, and it contains both about_tag.class and 
 about_tag.java, with timestamps corresponding to when I loaded the page.

 I then deleted those files, and

Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded


On 11/20/12 5:02 PM, Pid * wrote:

On 20 Nov 2012, at 21:44, Jim open...@gmail.com wrote:


What I'm getting at is this: your release process should produce a
.war (or exploded directory) that is copied to Tomcat and that Tomcat
should not be reading any part of the app from the /war directory - a
source controlled directory.

Right: we produce an exploded directory which is then copied to Tomcat.  The exploded /war directory in our 
project is copied into $CATALINA_HOME/webapps/[name of app].  All of Tomcat, including the 
/work and /webapps directories, is separate from our source-controlled project.

To clarify one thing: the JSPs /are/ being compiled, and recompiled.  I will see the classfile for the JSP/tag appear in Tomcat's 
/work directory, but Tomcat claims it can't find it. If I remove the .class file in the /work 
directory, and re-visit the JSP, Tomcat will re-compile the .class file, but the page will still fail to load with the same error 
about not being able to resolve the class.  That latter behavior makes me think that Git/timestamps are a red 
herring; my problem seems to be that the compilation occurs correctly, but that the classes are sometimes not loaded into the 
classloader.  Also, when this error happens, restarting Tomcat -- without changing the contents of /webapp/[name of 
app] at all -- resolves the issue, which hints at some sort of classloading race condition.

-- Jim

On 11/20/12 3:40 PM, Pid * wrote:

On 20 Nov 2012, at 19:44, Jim open...@gmail.com wrote:


No -- the /war/WEB-INF/classes directory is .gitignored, and empty until we 
deploy, at which point we copy in the compiled .java files, etc.

I suppose my core question is: if 
$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class
 exists, what situations could cause Tomcat to give the following error:

An error occurred at line: 1 in the jsp file: 
/WEB-INF/jsp/about/about_impact.jsp
org.apache.jsp.tag.web.about_tag cannot be resolved to a type
1: %@ include file=../common/constants.jsp %templates:about

If I delete $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class, and 
re-visit /WEB-INF/jsp/about/about_impact.jsp, 
$CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web/about_tag.class gets re-created, 
but I still get the above error.

So, Tomcat appears to be compiling the JSP fine, but that compiled JSP does not 
appear to be making it into the classloader?

-- Jim


On 11/20/12 2:34 PM, Pid * wrote:

On 20 Nov 2012, at 13:42, Jim open...@gmail.com wrote:


Thanks for the question -- I worded that part awkwardly.

Our project has a root-level /src directory with the web app's Java files, and a root-level /war 
directory with the exploded non-Java files (static assets, JSPs, etc.).  When developing, Eclipse compiles the /src 
directory into the /war/WEB-INF/classes directory, and then copies any changed files from /war into its 
embedded Tomcat instance.

When we switch Git branches, that could change the .jsp/.tag files inside the /war directory, but depending on the 
branch, those changed files might have an earlier modified-timestamp than the .jsp/.tag files that have already been copied over 
to the embedded Tomcat's exploded webapp directory.  So my thought was that those files would not, then, be recompiled, and so at 
runtime, Tomcat would be using the older versions of those files that are cached in Tomcat's /work directory.  I 
think that theory is countered, however, by my colleague's claim that she clears out /work before deploying a new 
branch, and also my own experience wherein I watched Tomcat re-compile the .tag file into the /work directory, yet 
still claim the tag's class cannot be resolved.

But to clarify: no part of Tomcat itself, including /work, is kept under 
version control.

-- Jim


On 11/20/12 2:18 AM, Pid * wrote:

On 19 Nov 2012, at 23:58, Jim open...@gmail.com wrote:


Hello!

My team has been having an issue wherein our application occasionally fails to 
start up because Tomcat claims it can't find find a dynamically-created 
classfile.  This doesn't happen all the time, and restarting Tomcat (albeit 
more than once, sometimes) resolves it.

For example, I just started my Tomcat 6.0.26 instance (via Eclipse WTP, on OS 
10.7.5), tried to load a page, and got:

** snip **

An error occurred at line: 1 in the jsp file: 
/WEB-INF/jsp/about/about_impact.jsp
org.apache.jsp.tag.web.about_tag cannot be resolved to a type
1: %@ include file=../common/constants.jsp %templates:about

** snip/ **

The constants.jsp referenced above contains:
%@ taglib prefix=templates tagdir=/WEB-INF/tags %

... and /WEB-INF/tags contains the about.tag file.

The $CATALINA_HOME/work/Catalina/localhost/_/org/apache/jsp/tag/web directory 
exists, and it contains both about_tag.class and about_tag.java, with timestamps 
corresponding to when I loaded the page.

I then deleted those files, and refreshed the page in my browser. 
about_tag.class and

Re: TC 6.0.2*: Dynamically-compiled jsps/tags not being loaded

2012-11-20 Thread Mark Thomas

On 20/11/2012 22:19, Jim wrote:
 Sorry about that; thanks for the note -- it looked like other recent
 messages to the list were top-posted, or inline, so I assumed that was
 desired.

Top-posting bad.

Bottom-posting fine.

In-line better.

Appropriate quoting even better.

 One of my colleagues was using a recent Tomcat 7 release with our
 project and claims to have been getting the same issue, so I'm skeptical
 that an upgrade will solve this.  That's hearsay, though; it's on my
 list to confirm that for myself.

I'd suggest starting Tomcat with debugging enabled and stepping through
the JSP loading code when the problem starts. With a better idea of why
the class doesn't load we might be able to figure out the root cause.

Mark

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

Re: tomcat-native 1.1.24

2012-11-20 Thread Isaac López Marín

 So you downloaded the source and then ran a program that downloads the
 source? I can't find these strings anywhere in the tcnative-1.1.24
 package:
  ---  Extracting tomcat-native ---  Configuring tomcat-native ---
  Building tomcat-native ---  Staging tomcat-native into destroot
  ---  Installing tomcat-native @1.1.22_0 ---  Activating
  tomcat-native @1.1.22_0
 What script did you actually run?
 - -chris

Hi Chris,

So, I've just realized about my error during the installation. Thanks a lot
for that :)
I used an application to facilitate the installation of tomcat-native and I
thought I'm downloading the last version. I apologize for my mistake.
So my problem with tomcat-native has been fixed.

Thanks a lot again :)

Isaac.


2012/11/20 Christopher Schultz ch...@christopherschultz.net

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Isaac,

 On 11/15/12 6:47 PM, Isaac López Marín wrote:
  Well, I installed it using the install.sh file and creating a
  symbolic link to /usr/lib/java I mean, I didn't get errors during
  the process and the server found the correct path for
  tomcat-native.
 
  I think it's a little hard to describe the problem, because I
  blocked when I saw that the native version installed is different
  from the downloaded version:
 
  (from install log) ---  Fetching distfiles for tomcat-native ---
  Verifying checksum(s) for tomcat-native

 So you downloaded the source and then ran a program that downloads the
 source? I can't find these strings anywhere in the tcnative-1.1.24
 package:

  ---  Extracting tomcat-native ---  Configuring tomcat-native ---
  Building tomcat-native ---  Staging tomcat-native into destroot
  ---  Installing tomcat-native @1.1.22_0 ---  Activating
  tomcat-native @1.1.22_0

 What script did you actually run?

 - -chris
 -BEGIN PGP SIGNATURE-
 Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
 Comment: GPGTools - http://gpgtools.org
 Comment: Using GnuPG with undefined - http://www.enigmail.net/

 iEYEARECAAYFAlCr/aoACgkQ9CaO5/Lv0PA2BwCglFASJGdyMOCm0eemU6htmCgW
 QxgAniss5vezNxhRfe2sRoX52zaujEV6
 =2xTf
 -END PGP SIGNATURE-

 -
 To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
 For additional commands, e-mail: users-h...@tomcat.apache.org

Re: connection autoReconnect?

2012-11-20 Thread Arnaud

So, yes indeed. The problem would then be solved by making sure that all
connections are rotated at least once within the MySQL wait-timeout right?
How do we do this? Measure the average concurrent number of connections and
then set the initialSize the same?



--
View this message in context: 
http://tomcat.10.n6.nabble.com/connection-autoReconnect-tp4340944p4989844.html
Sent from the Tomcat - User mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org

RE: Running two different version of tomcat on the same server