c:forEach not working as expected

[Reinhard Moosauer]

Hi List,

it seemed clear to me, that this construct:

  
 ... (some inner logic)
  
 
should be equivalent to this one:

  <%
  for (Iterator it=t.getRecords(); it.hasNext(); ) {
 String x = (String)it.next();
  %>
 ... (some inner logic)
  <% }
  %>

But the forEach-version is not working as expected. What can be wrong?
Here are some quite strange effects:
1. The iterators-method "hasNext()" is called twice for every iteration
(ok: no problem, if the iterator is clean, but why?)
2. The loop-body is executed after hasNext() returned false.
But the next()-method is NOT called ??

The c:forEach-iterator seems to operate like this:

Iterator it = t.getRecords();
while (it.hasNext()) {
String x = (String)it.next();
boolean still_more = it.hasNext();

... here comes the body ...
}

What could this extra-check be good for?

Any help is greatly appreciated.
Kind regards,

Reinhard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: reg. custom security

[Reinhard Moosauer]

Hi Poorna,

you must have access to the manager-application. Otherwise you could not 
deploy/restart your webapp. Don't you?

If you have access to the manager-webapp, you can deploy a context.xml-file 
along with your realm. Please see
http://yourserver:8080/manager/html/

->Install->XML config URL

You have to write a file like this:
(myapp.xml)





Please try it

regards,

Reinhard


Am Dienstag, 21. Februar 2006 08:04 schrieb Poornachandran:
> Hi Mark,
>
> Thank you for your reply.
>
> I understand that context.xml has to be kept in
> $CATALINA_HOME\conf\[hostname] directory. But, I cant even access the
> tomcat folders. Can I somehow manage security within my application
> scope only?
>
> Poorna
>
> Mark Thomas wrote:
> >Poornachandran wrote:
> >>Hi,
> >>
> >>I am in a kind of a strange situation. Basically, I need to implement
> >>security using Form Based authentication in one of my webapps. But, the
> >>catch here is that I cannot access any of the server's configuration
> >>files. I can only work with my app specific files.
> >
> >Can you use a context.xml file? If so, you could define your realm in
> >there.
> >
> >Mark
> >
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

manager-remove/undeploy without losing sessions

[Reinhard Moosauer]

Hello List,

recently I upgraded from tomcat 5.5.9 to 5.5.15
Since then, all my sessions are lost after a remove/install via the manager.

The problem is the following:
I installed a war-file, which is copied to the webapps-folder during 
manager-install. When I want to replace the war with a new version, I _have_ 
to undeploy, which deletes my persistent sessions too.

How can I get back the smooth behavior of 5.5.9, which allowed me an 
application update on the fly without disturbing user sessions?

many thanks in advance for your advice

Reinhard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: manager-remove/undeploy without losing sessions

[Reinhard Moosauer]

Hi List,

I found something, that looked promising, but did not work.
Developers, please look, this could be a bug:

The deploy-task has an attribute "update", removes the context before 
re-installing it. I hoped that this one would do what I want.

But unfortunately, it is equivalent to undeploy/deploy so my sessions are gone 
again. :-(

Maybe I have to clarify, what I am doing with my sessions (for Rodrigo):

I have all session-attribute in my application serializable, so that tomcat 
can save all session data to disk when the context or tomcat itself is 
stopped.
At startup these serialized data is being read back by tomcat automatically. 
As a result, users can coutinue their work exactly where the are. 
(Except that the application is not available for 1-2 seconds. But it is still 
unlikely that a users fires a request just in this moment, at least for 
medium-frequency apps)
Formerly, the persisted session data survived the remove, so I could 
re-install the app.

Please help!

Reinhard

Am Dienstag, 14. März 2006 13:53 schrieb Reinhard Moosauer:
> Hello List,
>
> recently I upgraded from tomcat 5.5.9 to 5.5.15
> Since then, all my sessions are lost after a remove/install via the
> manager.
>
> The problem is the following:
> I installed a war-file, which is copied to the webapps-folder during
> manager-install. When I want to replace the war with a new version, I
> _have_ to undeploy, which deletes my persistent sessions too.
>
> How can I get back the smooth behavior of 5.5.9, which allowed me an
> application update on the fly without disturbing user sessions?
>
> many thanks in advance for your advice
>
> Reinhard
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: manager-remove/undeploy without losing sessions

[Reinhard Moosauer]

Hi Peter,

thanks for making it clear.

I would appreciate your opinon in how we could enhance this:

- I think, even on production systems, there should be a possibility to 
  do a 'soft' application update without interrupting all users.
  When only minor changes in the application are made, the session state 
  should be fully compatible.
- I agree, that in many situations, a clear state is very much helpful.
  But this applies even more to development systems, doesn't it?
- I hoped, we could simply add a manager attribute 'keepSessions' to the 
 undeploy-task. But I am afraid, that's no easy to get, because deletion is
   not done in the manager but in the context. 
  Do you think its possible?
- It would be quite straightforward, if the 'update'-attribute to
   manager-deploy would have just this effect. 

If anyone has a good idea how to do this, please let me know.
All other please vote for this enhancement because we have lost a very nice 
feature here.

kind regards,

Reinhard


Am Dienstag, 14. März 2006 15:44 schrieb Peter Rossbach:
> Hmm,
>
> I thing you are right.
>
> ContextConfig.destroy() remove the working dir after undeploy the app.
>
>  /**
>   * Process a "destroy" event for this Context.
>   */
>  protected synchronized void destroy() {
>  // Called from StandardContext.destroy()
>  if (log.isDebugEnabled())
>  log.debug(sm.getString("contextConfig.destroy"));
>
>  // Changed to getWorkPath per Bugzilla 35819.
>  String workDir = ((StandardContext) context).getWorkPath();
>  if (workDir != null)
>  ExpandWar.delete(new File(workDir));
>  }
>
> This feature is important do guaranty a clear state after change the
> binary. Feel free to open
> an enhancement bug report, and feel free to add a patch. The current
> behaviour is
> correct for production sites.
>
> Peter
>
> Am 14.03.2006 um 15:03 schrieb Reinhard Moosauer:
> > Hi List,
> >
> > I found something, that looked promising, but did not work.
> > Developers, please look, this could be a bug:
> >
> > The deploy-task has an attribute "update", removes the context before
> > re-installing it. I hoped that this one would do what I want.
> >
> > But unfortunately, it is equivalent to undeploy/deploy so my
> > sessions are gone
> > again. :-(
> >
> > Maybe I have to clarify, what I am doing with my sessions (for
> > Rodrigo):
> >
> > I have all session-attribute in my application serializable, so
> > that tomcat
> > can save all session data to disk when the context or tomcat itself is
> > stopped.
> > At startup these serialized data is being read back by tomcat
> > automatically.
> > As a result, users can coutinue their work exactly where the are.
> > (Except that the application is not available for 1-2 seconds. But
> > it is still
> > unlikely that a users fires a request just in this moment, at least
> > for
> > medium-frequency apps)
> > Formerly, the persisted session data survived the remove, so I could
> > re-install the app.
> >
> > Please help!
> >
> > Reinhard
> >
> > Am Dienstag, 14. März 2006 13:53 schrieb Reinhard Moosauer:
> >> Hello List,
> >>
> >> recently I upgraded from tomcat 5.5.9 to 5.5.15
> >> Since then, all my sessions are lost after a remove/install via the
> >> manager.
> >>
> >> The problem is the following:
> >> I installed a war-file, which is copied to the webapps-folder during
> >> manager-install. When I want to replace the war with a new version, I
> >> _have_ to undeploy, which deletes my persistent sessions too.
> >>
> >> How can I get back the smooth behavior of 5.5.9, which allowed me an
> >> application update on the fly without disturbing user sessions?
> >>
> >> many thanks in advance for your advice
> >>
> >> Reinhard
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: manager-remove/undeploy without losing sessions

[Reinhard Moosauer]

i filed an enhancement request for this issue here:
http://issues.apache.org/bugzilla/show_bug.cgi?id=38975

Rodrigo,

The mentioned session serialization is always activated and works fully 
automatic. But only if all requirements to your applicatin are met:

All objects, which are ever bound to a HttpSession have to implement 
'Serializable' and should also have a serialVersionUid the enable compatible 
changes. And all objects which are referenced by the session-attributes.
In practice there some more requirements:
- follow the guidelines for compatible changes to serializable objects
   (see jdk-docs)
- make all references to unserializable objects 'transient'
- Implement a public no-args constructor to initialize all these transient
   members correctly. (Sometimes necessary for loggers or db-connections)
- Check 'catalina.out' for NotSerializableExceptions and fix them.

A nice side effect of these guidlines is: you can use tomcat's clustering 
facilities quite easily, because it only requires serializable sessions!

Hope that helps,

Reinhard

Am Dienstag, 14. März 2006 16:29 schrieb Asensio, Rodrigo:
> Reinhard, thanks for the tip, is that option (serialize sessions) in the
> manager or in the admin ? Or it is a value that need to be changed manually
> in server.xml or any props file ?
>
> Thanks
>
> Rodrigo Asensio
>
> -Original Message-
> From: Reinhard Moosauer [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, March 14, 2006 9:04 AM
> To: Tomcat Users List
> Subject: Re: manager-remove/undeploy without losing sessions
>
> Hi List,
>
> I found something, that looked promising, but did not work.
> Developers, please look, this could be a bug:
>
> The deploy-task has an attribute "update", removes the context before
> re-installing it. I hoped that this one would do what I want.
>
> But unfortunately, it is equivalent to undeploy/deploy so my sessions are
> gone again. :-(
>
> Maybe I have to clarify, what I am doing with my sessions (for Rodrigo):
>
> I have all session-attribute in my application serializable, so that tomcat
> can save all session data to disk when the context or tomcat itself is
> stopped. At startup these serialized data is being read back by tomcat
> automatically. As a result, users can coutinue their work exactly where the
> are.
> (Except that the application is not available for 1-2 seconds. But it is
> still unlikely that a users fires a request just in this moment, at least
> for medium-frequency apps) Formerly, the persisted session data survived
> the remove, so I could re-install the app.
>
> Please help!
>
> Reinhard
>
> Am Dienstag, 14. März 2006 13:53 schrieb Reinhard Moosauer:
> > Hello List,
> >
> > recently I upgraded from tomcat 5.5.9 to 5.5.15 Since then, all my
> > sessions are lost after a remove/install via the manager.
> >
> > The problem is the following:
> > I installed a war-file, which is copied to the webapps-folder during
> > manager-install. When I want to replace the war with a new version, I
> > _have_ to undeploy, which deletes my persistent sessions too.
> >
> > How can I get back the smooth behavior of 5.5.9, which allowed me an
> > application update on the fly without disturbing user sessions?
> >
> > many thanks in advance for your advice
> >
> > Reinhard
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> This message (including any attachments) contains confidential
> and/or proprietary information intended only for the addressee.
> Any unauthorized disclosure, copying, distribution or reliance on
> the contents of this information is strictly prohibited and may
> constitute a violation of law.  If you are not the intended
> recipient, please notify the sender immediately by responding to
> this e-mail, and delete the message from your system.  If you
> have any questions about this e-mail please notify the sender
> immediately.
>
> Ce message (ainsi que les eventuelles pieces jointes) est
> exclusivement adresse au destinataire et contient des
> informations confidentielles. La copie, la communication ou la
> distribution du contenu de ce message sans l'accord prealable de
> l'expediteur sont strictement interdits et peuvent constituer un
> delit. Si vous n'etes pas destinataire de ce message, merci de le
> detruire et d'avertir l'expediteur. Si vous avez 

Re: manager-remove/undeploy without losing sessions

[Reinhard Moosauer]

Peter,

you saved me. Thanks a lot!
I also upgraded to using the deploy-task with update="true" and got even 
better behavior than before. 
Application-update works with a sub-second downtime now.

BTW I use in META-INF/context.xml:

  

as the path. This it is working out of the box without creating dirs and 
setting permissions.


Reinhard

Am Dienstag, 14. März 2006 16:29 schrieb Peter Rossbach:
> Please open a bug report,
> then we can better discuss the issue.
>
> Peter
>
> Am 14.03.2006 um 16:21 schrieb Reinhard Moosauer:
> > Hi Peter,
> >
> > thanks for making it clear.
> >
> > I would appreciate your opinon in how we could enhance this:
> >
> > - I think, even on production systems, there should be a
> > possibility to
> >   do a 'soft' application update without interrupting all users.
> >   When only minor changes in the application are made, the session
> > state
> >   should be fully compatible.
> > - I agree, that in many situations, a clear state is very much
> > helpful.
> >   But this applies even more to development systems, doesn't it?
> > - I hoped, we could simply add a manager attribute 'keepSessions'
> > to the
> >  undeploy-task. But I am afraid, that's no easy to get, because
> > deletion is
> >not done in the manager but in the context.
> >   Do you think its possible?
> > - It would be quite straightforward, if the 'update'-attribute to
> >manager-deploy would have just this effect.
> >
> > If anyone has a good idea how to do this, please let me know.
> > All other please vote for this enhancement because we have lost a
> > very nice
> > feature here.
> >
> > kind regards,
> >
> > Reinhard
> >
> > Am Dienstag, 14. März 2006 15:44 schrieb Peter Rossbach:
> >> Hmm,
> >>
> >> I thing you are right.
> >>
> >> ContextConfig.destroy() remove the working dir after undeploy the
> >> app.
> >>
> >>  /**
> >>   * Process a "destroy" event for this Context.
> >>   */
> >>  protected synchronized void destroy() {
> >>  // Called from StandardContext.destroy()
> >>  if (log.isDebugEnabled())
> >>  log.debug(sm.getString("contextConfig.destroy"));
> >>
> >>  // Changed to getWorkPath per Bugzilla 35819.
> >>  String workDir = ((StandardContext) context).getWorkPath();
> >>  if (workDir != null)
> >>  ExpandWar.delete(new File(workDir));
> >>  }
> >>
> >> This feature is important do guaranty a clear state after change the
> >> binary. Feel free to open
> >> an enhancement bug report, and feel free to add a patch. The current
> >> behaviour is
> >> correct for production sites.
> >>
> >> Peter
> >>
> >> Am 14.03.2006 um 15:03 schrieb Reinhard Moosauer:
> >>> Hi List,
> >>>
> >>> I found something, that looked promising, but did not work.
> >>> Developers, please look, this could be a bug:
> >>>
> >>> The deploy-task has an attribute "update", removes the context
> >>> before
> >>> re-installing it. I hoped that this one would do what I want.
> >>>
> >>> But unfortunately, it is equivalent to undeploy/deploy so my
> >>> sessions are gone
> >>> again. :-(
> >>>
> >>> Maybe I have to clarify, what I am doing with my sessions (for
> >>> Rodrigo):
> >>>
> >>> I have all session-attribute in my application serializable, so
> >>> that tomcat
> >>> can save all session data to disk when the context or tomcat
> >>> itself is
> >>> stopped.
> >>> At startup these serialized data is being read back by tomcat
> >>> automatically.
> >>> As a result, users can coutinue their work exactly where the are.
> >>> (Except that the application is not available for 1-2 seconds. But
> >>> it is still
> >>> unlikely that a users fires a request just in this moment, at least
> >>> for
> >>> medium-frequency apps)
> >>> Formerly, the persisted session data survived the remove, so I could
> >>> re-install the app.
> >>>
> >>> Please help!
> >>>
> >>> Reinhard
> >>>
> >>> Am Dienstag, 14. März 2006 13:53 schrieb Reinhard Moosaue

Re: keeping same session via apache2 mod_jk2 and tomcat5

[Reinhard Moosauer]

Hi,

please check your browser. I think you have cookies disabled for any reason.
(or cookies are disabled in your tomcat app)

yould check with ethereal or try using cookie-less mode with 
response.encodeURL(hyperlink)

hope this helps

R.

Am Freitag, 17. März 2006 13:35 schrieb Vahid Hedayati:
> Hi All.
>
> Have been looking for a few days now for a fix for this one issue that I
> just cannot get around..
>
> Basically
>
> If I run
> http://www.greenlightproductions.co.uk/servlets/SessionExample
>
> The session ID keeps changing  if you refresh the page
>
> (same goes for all other servlet code I been using you login once logged in
> session info lost as in new session ID assigned)
>
>
> but if I go  to port 8180 it works perfect
> http://www.greenlightproductions.co.uk:8180/servlets/SessionExample
>
> the session ID remains the same no matter how much i refresh.
>
>
> I have been looking all over google for an answer for this and most of it
> is to do with load balancing tomcat and getting same session ID :(
>
> I am sure others have hit this issue before and it must be a tom cat config
> issue (well for the apache listener)
>
> here is some of my config.
>
> ###
> /etc/apache2/mods-enabled/jk2.load
> LoadModule jk2_module /usr/lib/apache2/modules/mod_jk2.so
>
> ###
> /etc/apache2/mods-enabled/jk2.conf
> # To enable mod_jk2, customize workers2.properties* from
> # /usr/share/doc/libapache2-mod-jk2/examples and copy it to
> # /etc/apache2/workers2.properties. Then uncomment the following line:
> JkSet config.file /etc/apache2/workers2.properties
> # Where to put jk logs
> #JkLogFile /var/log/apache2/mod_jk.log
>
> # Set the jk log level [debug/error/info]
> #JkLogLevelinfo
>
> # Select the log format
> #JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
>
> # JkOptions indicate to send SSL KEY SIZE,
> #JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
>
> # JkRequestLogFormat set the request format
> #JkRequestLogFormat "%w %V %T"
>
> # Globally deny access to the WEB-INF directory
> 
>AllowOverride None
>deny from all
> 
>
> ###
> /etc/apache2/workers2.properties
> #
> # This is the minimal JK2 connector configuration file.
> #
>
> [logger]
> info=Native logger
> level=ERROR
>
> [config:]
> file=${serverRoot}/workers2.properties
> debug=0
> debugEnv=0
>
> [uriMap:]
> info=Maps the requests.
> debug=0
>
> [shm:]
> info=Scoreboard. Required for reconfiguration and status with multiprocess
> servers
> file=anonymous
> debug=0
>
> [workerEnv:]
> info=Global server options
> timing=0
> debug=0
>
> [lb:lb]
> info=Default load balancer.
> debug=0
>
> [channel.socket:localhost:8009]
> info=Ajp13 forwarding over socket
> debug=0
> #tomcatId=tomcat1
> tomcatId=localhost:8009
> keepalive=1
>
> [uri:/admin]
> info=Tomcat HTML based administration web application.
> debug=0
>
> [uri:/manager]
> info=A scriptable management web application for the Tomcat Web Server.
> debug=0
>
> [uri:/jsp-examples]
> info=JSP 2.0 Examples.
> debug=0
>
> [uri:/servlets-examples]
> tomcatId = jvmRoute
> info=Servlet 2.4 Examples.
> debug=0
>
> [uri:/*.jsp]
> info=JSP Extension mapping.
> debug=0
>
> [uri:/servlets/*]
> worker=ajp13:localhost:8009
>
> ###
> snippets of /etc/tomcat5/server.xml
> 
> 
> modJk="/usr/lib/apache2/modules/mod_jk2.so"
>   WorkersConfig="/etc/apache2/workers2.properties" />
>
>   append="true" forwardAll="false"
> modJk="/usr/lib/apache2/modules/mod_jk2.so"
> WorkersConfig="/etc/apache2/workers2.properties" />
>
>
> ...
> 
> port="8180" minProcessors="5" maxProcessors="75"
>enableLookups="true" acceptCount="10" debug="0"
>connectionTimeout="2" useURIValidationHack="false" />
> ...
>  appBase="//servlets/"
> unpackWARs="true" autoDeploy="true">
> reloadable="true"/>
>
>  debug="0" saveOnRestart="true" maxActiveSessions="30"
>  minIdleSwap="60" maxIdleSwap="60" maxIdleBackup="60">
>directory="/xxx//log/"/>
> 
> 
>
>driverClassName
>org.gjt.mm.mysql.Driver
> 
>directory="logs"  prefix="greenlight_log." suffix=".txt" pa
> ttern="common" resolveHosts="true"/>
>   
>
>
>
>
> ###

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: keeping same session via apache2 mod_jk2 and tomcat5

[Reinhard Moosauer]

Hi Vahid,

there some things in your configuration, which are at least problematic, maybe 
even faulty:
- One  would be quite enough and your config would be much simpler
   simply put your 2 hosts into it
- The 
   
  could also create problems if configured incorrectly.
  Try simply removing it, until your app works.
- You can NOT use the same appBase for 2 different hosts
   you are always getting all contexts in both hosts
(except if the given dir is completely empty)

good luck!

R.

Am Dienstag, 21. März 2006 13:41 schrieb Vahid Hedayati:
> ok
>
> this is where it starts to get bizzare...
>
> http://www.greenlightproductions.co.uk/servlets/SessionExample
>
> This now works (as in it is keeping the same session ID )
>
> but it is showing the wrong servlets folder (as in for wrong virtual host
> and showing the tomcatid of that virtual host)
>
> Since below is  a servlet for the host in question
>
> http://www.greenlightproductions.co.uk/servlets/GreenLight
>
> but it shows servlets setup for pro.org.uk
>
> http://www.greenlightproductions.co.uk/servlets/ContactMe
> http://www.pro.org.uk/servlets/ContactMe
>
>
> in server.xml i have setup unique engines.
>
>   debug="0" jvmRoute="worker2">
>  prefix="catalina_" suffix=".log" timestamp="true"/>
> debug="0" resourceName="UserDatabase"/>
>   
>
>appBase="/apache_sites/servlets/"
> unpackWARs="true" autoDeploy="true">
> reloadable="true"/>
>  
>driverClassName
>org.gjt.mm.mysql.Driver
>  
>directory="logs"  prefix="green_log." suffix=".txt" pattern="common"
> resolveHosts="true"/>
>   
>
>   
>
>  jvmRoute="worker1">
>  prefix="catalina_" suffix=".log" timestamp="true"/>
> debug="0" resourceName="UserDatabase"/>
>   
>   unpackWARs="true" autoDeploy="true">
>reloadable="true"/>
>reloadable="true"/>
>   
>driverClassName
>org.gjt.mm.mysql.Driver
>  
>directory="logs"  prefix="pro_log." suffix=".txt" pattern="common"
> resolveHosts="true"/>
>   
>
>
>   
>
>
> workers.properties
>
> worker.list=worker1,worker2,worker3
>
> # Definition for local worker using AJP 1.3
> #
> #worker.foo.type=ajp13
> #worker.foo.host=www.pro.org.uk
> #worker.foo.port=8009
> #worker.foo.cachesize=20
>
> [uri:www.pro.org.uk/servlets/*]
> worker.worker1.tomcatId=worker1
> #worker.foo=ajp13:www.pro.org.uk:8009
> worker.worker1.type=ajp13
> worker.worker1.host=localhost
> worker.worker1.port=8009
> worker.worker1.lbfactor=50
> worker.worker1.cachesize=10
> worker.worker1.cache_timeout=600
> worker.worker1.socket_keepalive=1
> worker.worker1.reclycle_timeout=300
>
> [uri:www.greenlightproductions.co.uk/servlets/*]
> worker.worker2.tomcatId=worker2
> #worker.foo=ajp13:www.pro.org.uk:8009
> worker.worker2.type=ajp13
> worker.worker2.host=localhost
> worker.worker2.port=8009
> worker.worker2.lbfactor=50
> worker.worker2.cachesize=10
> worker.worker2.cache_timeout=600
> worker.worker2.socket_keepalive=1
> worker.worker2.reclycle_timeout=300
>
>
>
> virtual host for greenlight
> 
>   JkLogFile /var/log/apache2/mod_jk.log
>   JkMount   /servlets/* worker2
>  
>
> Virtual host for pro.org.uk
> 
>   JkLogFile /var/log/apache2/mod_jk.log
>   JkMount /servlets/* worker1
>   JkMount /vahidservlets/* worker1
>  
>
> Why is tomcat doing this ?
>
> This now proves this has nothing to do with cookies since it can keep the
> same session ID for a servlet that it is not supposed to show lol
>
> Thanks
> vahid
>
> On 3/21/06, Reinhard Moosauer <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > please check your browser. I think you have cookies disabled for any
> > reason.
> > (or cookies are disabled in your tomcat app)
> >
> > yould check with ethereal or try using cookie-less mode with
> > response.encodeURL(hyperlink)
> >
> > hope this helps
> >
> > R.
> >
> > Am Freitag, 17. März 2006 13:35 schrieb Vahid Hedayati:
> > > Hi All.
> > >
> > > Have been looking for a few days now for a fix for this one issue that
> > > I just cannot get around..
> > >
> > > Basic

Re: Classloader question

[Reinhard Moosauer]

Hi,

this sounds like "repackage" would be a huge job.
If yes, I would suggest: learn ant
If not: You have to reload the apps anyway. So what do you achieve?

just my 2 cents.

R.

Am Freitag, 24. März 2006 16:19 schrieb Fran Varin:
> Yes, that is the exact situation we are attempting to avoid in Tomcat. In
> our WSA implementation we can simply replace the effected JARS in one
> location and it is implemented against all WARs running in that server's
> context. In the illustration you provided below we would need to repackage,
> or at the very least, redistribute the "shared" jar files that have changes
> to each WAR. In our situation, we would not be distributing the WARs across
> running server instances...the application is self-contained and runs as a
> unit anyway. It's packaged software that requires customization.
> --
> View this message in context:
> http://www.nabble.com/Classloader-question-t1332679.html#a3573057 Sent from
> the Tomcat - User forum at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: gc tuning

[Reinhard Moosauer]

Hi,

Sun's JDK contains am small Java-App called 'jconsole'.
You can run it remotely after configuring your tomcat like this:
http://tomcat.apache.org/tomcat-5.5-doc/monitoring.html (Enabling JMX Remote)
Consider reading the JDK-docs also.

Real memory usage can be understood much better with this tool.
You can even answer the permGen-question by yourself. And you learn  that 
every reload causes a permanent increase in permGen-usage by some megabytes.

(Interested in sending snmp-traps when reaching a specified memory limit? Look 
into it)
And: no, we are not restarting tomcat every night. But you should really use 
some coutinous availabilty check tool (cron with wget, or jmeter)

Try it!

R. 


Am Mittwoch, 29. März 2006 20:03 schrieb Mark Hagger:
> As I'm sure you know this is something of a large can of worms...
>
> All I can say is that from my experience of this modern JVM's are getting
> much better at working well with the default gc options (ie jdk 5.0 and
> above). We use jrockit for our systems, and just use a simple:
>
> -server -Xms256m -Xmx1024m
>
> Our server are dual processor boxes with 6Gig ram and all runs well for us.
> From what I understand both current jrockit and sun gc strategies are to
> delay gc work until as late as possible (jrockit seems to leave it later
> than sun tbh).  This tends to mean that memory usage never really seems to
> drops much, our servers run with jrockit having grabbed around 1.9Gig
> memory all the time, but then seem to run happily with that for long
> periods of time (ie weeks at a time).  Both jrockit and sun default to
> adaptive gc systems for "large" systems, which ought to get to the right
> approach in due course.
>
> Having said that experience suggests that if the application churns memory
> very fast (tomcat doesn't really qualify for that for us, but some of our
> other apps do), using a two generational concurrent gc approach is best,
> especially for jrockit.
>
> The other thing to note is that a call to System.gc() does very little in
> some jvm's, I think its increasingly taken as a hint, and most gc's almost
> ignore it.  A real full gc is expensive and can cause heavy pauses, gc
> systems tend to avoid it like a plague.
>
> Hope this is of some help, although I'd be interested to hear others
> thoughts on this.
>
> Mark
>
> On Wednesday 29 March 2006 19:17, John Powers wrote:
> > I am trying to tune an instance of tomcat running a single application.
> > And have a couple different questions.
> >
> >
> >
> > I have read lots of faqs and webpages on the various types of garbage
> > collectors.   I get from most of these that it takes lots of tuning
> > particular to each machine/server/application.
> >
> >
> >
> > My main question is why the memory allocated keeps climbing.If I
> > have a fairly consistent number of users, then as some sessions are
> > freed up, others are made.  Wouldn't the amount of allocated level off
> > at some point? When a full GC is started, why does it never go back down
> > to a low number?At night, lets say when there are no users, why
> > wouldn't a GC drop the memory down to what is used by just the bare
> > minimum?
> >
> >
> >
> > Most faqs and webpages say to allocate as much memory as possible.  How
> > can you use the aggressiveHeap tag if tomcat is also trying to specify
> > Mmx and Mms settings?   Does anyone have an example memory settings for
> > a tomcat running on a 2-4 chip machine with around 2G of ram?
> >
> >
> >
> > I understand for a JSP application that we need to keep our permHeap
> > size large.What do you guys normally do for that? 128M? 256M? 512M?
> >
> >
> >
> > Is it common that a tomcat needs restarting nightly to free up memory?
> > In all my other apps I've had with tomcat, I've never needed to do that.
> > I've been trying to use the profiler yourkit, but am uncertain what is a
> > valid object in memory and what is being held on unnecessarily.
> >
> >
> >
> > Thanks for any help you can provide.
> >
> >
> >
> >
> >
> >
> > 
> > This email has been scanned for all known viruses by the MessageLabs
> > SkyScan service.
>
> 
> This email has been scanned for all known viruses by the MessageLabs
> SkyScan service.
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Looking for simple file servlet with etag, range and if-range support

[Reinhard Moosauer]

Hi again,

this sounds like you should use apache for that.
Are you using a specific download manager on the client side?

Note you can always configure tomcat to serve content outside of webapps. Just 
use context.xml-Configuration:
http://tomcat.apache.org/tomcat-5.5-doc/deployer-howto.html
-->"A word on Contexts"

R.

Am Donnerstag, 13. April 2006 11:55 schrieb Duncan McGregor:
> Hi
>
> I need to serve content from directories other than webapps, but need
> to support resumable downloads (and hence serve ETag response headers
> and correctly respond to Range and If-Range request headers).
>
> I've cast high and low for some code which fits the bill, but can
> find nothing. Does anyone know of a nice file servlet implementation?
>
> Thanks in anticipation.
>
> Duncan McGregor
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: JK Sticky Session Handling with Load Balancing

[Reinhard Moosauer]

Hi,

please do not mix up the tomcat cluster and apache load balancing.
Sticky session means that tomcat2 is not used at all in your configuration. 
Only tomcat1, which created the cookie.

When tomcat2 creates no session, the browser gets none and the lb-worker 
cannot work also. Maybe your apps/configurations are not consistent?

Again: when tomcat does not create a session, this has nothing to do with 
mod_jk. Not the request starts a session, tomcat does it!

regards,

Reinhard

Am Dienstag, 18. April 2006 13:43 schrieb Allistair Crossley:
> Hi Edgar,
>
> Yep I just noticed that too :)) However, correcting this configuration
> (to the below) does nothing to resolve the issue, because the lb worker
> type by default has sticky_session=1. I set it explicitly anyway as
> below.
>
> However, I have noticed that in fact Tomcat 2 is not returning
> JSESSIONID headers as Tomcat 1 does when both Tomcats are in.
>
> To recap then, when only Tomcat 1 is in the loop, JSESSIONIDs are
> returned and remains consistent across requests. When Tomcat 2 is
> brought in, Tomcat 1 starts generating a different JSESSIONID per
> request, whilst Tomcat 2 returns no JSESSIONID at all.
>
> Thanks, Allistair
>
> === new config ===
>
> worker.list=loadbalancer
>
> worker.tomcat1.port=8009
> worker.tomcat1.host=localhost
> worker.tomcat1.type=ajp13
> worker.tomcat1.lbfactor=1
> worker.tomcat1.cachesize=10
>
> worker.tomcat2.port=8109
> worker.tomcat2.host=localhost
> worker.tomcat2.type=ajp13
> worker.tomcat2.lbfactor=1
> worker.tomcat2.cachesize=10
>
> worker.loadbalancer.type=lb
> worker.loadbalancer.balance_workers=tomcat1,tomcat2
> worker.loadbalancer.sticky_session=1
>
>
> -Original Message-
> From: Edgar Alves [mailto:[EMAIL PROTECTED]
> Sent: 18 April 2006 12:32
> To: Tomcat Users List
> Subject: Re: JK Sticky Session Handling with Load Balancing
>
> Hi there,
>   You're setting the sticky_session property for each worker. That's not
> how it works.
>   That property is valid only for the loadbalancer and it takes a
> boolean value. Set it to 'True' or '1' to get the desired effect.
>   Read http://tomcat.apache.org/connectors-doc/config/workers.html for
> more info.
>
>   -- Edgar Alves
>
> Allistair Crossley wrote:
> > Hi,
> >
> > I have setup 2 Tomcats on the same machine fronted by IIS, and used a
> > sticky_session=1 JK (1.2.15) load-balanced setup (as printed at the
> > foot of this email)
> >
> > I setup a JSP on both Tomcats that outputs the session ID.
> >
> > With only 1 Tomcat started, making requests to the JSP results in the
> > same session ID being output on each request.
> >
> > When I start up the 2nd Tomcat and continue making requests to the
> > JSP, I am switched between both Tomcats rather than staying on the
> > same Tomcat and therefore acquire a new session ID.
> >
> > However, with the 2 Tomcat's "in the loop" the session Ids become
> > different *per request* no matter which Tomcat is used.
> >
> > I would have expected at most 2 unique session Ids (one per Tomcat)
> > since with 1 Tomcat running only, the 1 unique session ID is
>
> maintained.
>
> > I would appreciate any help or guidance as to why this may be
>
> happening.
>
> > Cookies are enabled, and jsessionid is not being used on URLs.
> >
> > Cheers, Allistair.
> >
> > == config ==
> >
> > worker.list=loadbalancer
> >
> > worker.tomcat1.port=8009
> > worker.tomcat1.host=localhost
> > worker.tomcat1.type=ajp13
> > worker.tomcat1.lbfactor=1
> > worker.tomcat1.cachesize=10
> > worker.tomcat1.sticky_session=1
> >
> > worker.tomcat2.port=8109
> > worker.tomcat2.host=localhost
> > worker.tomcat2.type=ajp13
> > worker.tomcat2.lbfactor=1
> > worker.tomcat2.cachesize=10
> > worker.tomcat1.sticky_session=2
> >
> > worker.loadbalancer.type=lb
> > worker.loadbalancer.balance_workers=tomcat1,tomcat2
> >
> >
> > 
> > ---
> > QAS Ltd.
> > Registered in England: No 2582055
> > Registered in Australia: No 082 851 474
> > ---
> >  
> > Disclaimer:  The information contained within this e-mail is
>
> confidential and may be privileged. This email is intended solely for
> the named recipient only; if you are not authorised you must not
> disclose, copy, distribute, or retain this message or any part of it. If
> you have received this message in error please contact the sender at
> once so that we may take the appropriate action and avoid troubling you
> further.  Any views expressed in this message are those of the
> individual sender.  QAS Limited has the right lawfully to record,
> monitor and inspect messages between its employees and any third party.
> Your messages shall be subject to such lawful supervision as QAS Limited
> deems to be necessary in order to protect its information, its interests
> and its reputation.
>
> > Whilst all efforts are made to safeguard Inbound and Outbound emails,
>
> QAS Limited cannot guarantee that attachments a

Re: Tomcat 5.0.28 - jsp:useBean causing a jsp error

[Reinhard Moosauer]

Or even better:
change "class=.." to "type=.."
class means: this class can be instantiated
type means: This attribute has been set before and should not be instantiated 
(List cannot anyway because its an interface)

Since Tomcat 5 the JSP compiler checks this to reduce runtime errors.

Am Donnerstag, 8. Juni 2006 10:57 schrieb Ángel Luis Diez Hernández:
> Summary: Code that worked in Tomcat 4 throws a jsp exception in Tomcat
> 5.0.28
>
> My Jsp file contains a line:
>  scope="request"/>
>
> In Tomcat 4 this same line worked. However in Tomcat 5.0.28 it causes this
> exception:
>
>
> /cms/Back/code/fvlist_init.jsp(10,0)
> [Thu Jun 08 09:55:07 CEST 2006]
> org.apache.jasper.JasperException: /cms/Back/code/fvlist_init.jsp(10,0)
>  at
> org.apache.jasper.compiler.DefaultErrorHandler.jspError(DefaultErrorHandler
>.java:39) at
> org.apache.jasper.compiler.ErrorDispatcher.dispatch(ErrorDispatcher.java:40
>9) at
> org.apache.jasper.compiler.ErrorDispatcher.jspError(ErrorDispatcher.java:15
>0) at
> org.apache.jasper.compiler.Generator$GenerateVisitor.visit(Generator.java:1
>227) at org.apache.jasper.compiler.Node$UseBean.accept(Node.java:1116) at
> org.apache.jasper.compiler.Node$Nodes.visit(Node.java:2163)
>  at org.apache.jasper.compiler.Node$Visitor.visitBod...
>
> Anyone knows how can I solve it?
>
> Thanks.
>
> Angel

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5.5.17 protected pages JSP examples with valid user and invalid role results in msg 403.

[Reinhard Moosauer]

Hi,

please consider the following:
- Error 403 seems completely suitable from your words
- Browsers always store Login Info until the browser windows is closed 
  (No session here, this applies only to basic-auth!)
   With form auth: you can alyways provide a logout-button
- If Standard-errorpage is too unfriendly, provide a custom error page

If you think tomcat forgot to handle the 403, provide a page which handles 
this error and let the user log out continue to another page.

It is not illogical, because your case is rare enough to not be handled by 
default. Let us know, if this is good enough for you.

regards,


R.

Am Dienstag, 13. Juni 2006 09:59 schrieb [EMAIL PROTECTED]:
> Hi,
> I received a response from Mark to the problem described below,
> which was: "not an issue"/"as per specs".
> Does not look like that to me, because:
>
> 1) After trying to login as a valid user and receiving 403 msg,
> you can not login with a valid user role even after invalidating the
> session.
> So what is the user supposed to do (after entering username with incorrect
> role)?
> a. Ask maintenance team to restart application?
> b. Clean the cookies? (most users do not even know what the cookie is)
> These are the only things that will allow him to access the page again.
> How can this behavior be "not an issue"?
>
> 2) msg 403 as a per specs response for users attempt to access
> protected page with valid user and invalid role does not look logical.
> Reason:
> a. after entering completely wrong username user is redirected to
> reasonably friendly custom error page.
> b. after entering correct username with incorrect role user sees
> unfriendly msg 403.
> Reaction to smaller mistake (case b) is less user friendly that for
> case a.
> This seems illogical.
>
> Regards,
> Val.
>
>
> - Original Message -
> From: "Mark Thomas" <[EMAIL PROTECTED]>
> To: "Tomcat Users List" 
> Sent: Friday, June 09, 2006 21:04
> Subject: Re: Tomcat 5.5.17 protected pages JSP examples with valid user and
> invalid role results in msg 403.
>
> > [EMAIL PROTECTED] wrote:
> >> Hi,
> >>
> >> I am having problem with Tomcat 5.5.17 jsp example of accessing
> >> protected pages
> >> (example:  http://localhost:8080/jsp-examples/security/protected/)
> >>
> >> Logging with valid user and role:
> >> user/password/role="tomcat/tomcat/tomcat" works fine.
> >> Logging with a valid user and invalid role
> >> (user/password/role="role1/tomcat/role1") results in msg 403
> >> (HTTP Status 403 - Access to the requested resource has been denied).
> >> I am using supplied tomcat-users.xml.
> >>
> >> Before experimenting I made this role (role1) invalid by editing
> >> webapps/jsp-examples/WEB-INF/web.xml file like:
> >> ...
> >> 
> >>  tomcat
> >>  
> >> 
> >> ...
> >>
> >> After receiving msg 403 applicatin will not work even with the valid
> >> user role (msg 403 produced).
> >>
> >> I found the same problem for Tomcat4 reported at:
> >> http://mail-archives.apache.org/mod_mbox/tomcat-dev/200204.mbox/%3C20020
> >>[EMAIL PROTECTED]
> >
> > This was resolved as INVALID. See
> > http://issues.apache.org/bugzilla/show_bug.cgi?id=8607
> >
> >> I also have seen somewhere that it was reported to be fixed for Tomcat4.
> >
> > Not fixed, it was never an issue. See above.
> >
> >> Did the old problem penetrate to Tomcat 5.5.17 or
> >> did I forget to configure something?
> >
> > No, there isn't am issue.
> >
> > Mark
> >
> > -
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Outgoing requests to match a specific IP

[Reinhard Moosauer]

Hi,

the outbound address is determined from the routing on OS level.
Fix your routes and the outgoing address is ok also.

If this is not possible, you can resort to NAT (network address translation). 
This solution is used very widely.

regards,
R.

Am Dienstag, 13. Juni 2006 14:56 schrieb Panos Konstantinidis:
> Hello Tim, thank you for your prompt reply.
>
> Your solution would work, however we are using a third party API that does
> this call to the specific server (actually what it is doing is to issue an
> HTTP request to another Servlet), and I do not have access to the source
> code, nor I would like to decompile the API and modify the source code.
>
> Any other alternatives?
>
> Regards
>
> Panos
>
> --- Tim Funk <[EMAIL PROTECTED]> wrote:
> > Its not a tomcat setting, it java socket programming.
>
> http://java.sun.com/j2se/1.4.2/docs/api/java/net/Socket.html#Socket(java.ne
>t.InetAddress,%20int,%20java.net.InetAddress,%20int)
>
> > Whatever library is making the outbound call should have an option to
> > choose the local ip address the connection is bound to. If it doesn't,
> > then you are SOL.
> >
> > -Tim
> >
> > Panos Konstantinidis wrote:
> > > Hello, we have a computer that is registered to two IP addresses. I
> > > have installed Tomcat on this computer and I have deployed a web
> > > application.
> >
> > This
> >
> > > web application does some XML processing and then sends a request to
> >
> > another
> >
> > > server. This other server is configured to only accept requests from a
> >
> > specific
> >
> > > IP address. Unfortunatelly this IP address is not the one Tocmat is
> > > bind to when an outgoing request leaves. My question is how I can make
> > > Tomcat to
> >
> > tie a
> >
> > > specific request to otehr IP address, the one that is allowed to
> > > connect to
> >
> > the
> >
> > > second server. All information I have found so far is only for incoming
> > > requests (listening) not for outgoing.
> >
> > -
> > To start a new topic, e-mail: users@tomcat.apache.org
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
> __
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: tomcat 5.0 context redirect

[Reinhard Moosauer]

Hi,

you can mimimize http traffic by correctly linking to 
http://localhost:8080/mytestapp/?qa=1   (with the slash)

Please consider that "mytestapp" should be seen as a directory by the browser. 
And your first url is wrong (strictly speaking), so Tomcat tries to fix it by 
a redirect.
I see no reason to change the current behavior. Better fix your application.

Kind regards,

Reinhard


Am Mittwoch, 13. Dezember 2006 04:03 schrieb ying lcs:
> Hi,
>
> I notice some strange feature in tomcat 5.0.
>
> If i have a url like this http://localhost:8080/mytestapp?qa=1,
> it will be redirected to http://localhost:8080/mytestapp/?qa=1,
>
> in order words, "context" is automatically redirected to "context/".
>
> Can you please tell me why tomcat 5.0 does it? i don' t notice the
> same thing in tomcat 4.1?
>
> And if there is a way to disable this feature? I think this redirect
> is done via HTTP 302. And i would like to minimize http traffic.
>
> thank you.
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there a way to get access to request object without servlet?

[Reinhard Moosauer]

Hi,

JBoss implements this with ThreadLocal-Variables.
Tomcat does not use them like JBoss, but you can quite easily do it by 
yourself.
see java.lang.ThreadLocal

There may be pitfalls, mainly caused by the very limited lifetime of a request 
object. But for a loginModule this could be appropriate.

hope this helps

R.

Am Freitag, 19. Januar 2007 12:53 schrieb Libor Arndt:
> I need to have access to request in a JAAS logim module.
> Is there something similar in Tomcat like in JBosss:
>
> PolicyContext.getContext(key)?
>
> thanks a lot for any advice
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
-- 
Reinhard Moosauer
IT Beratung

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5.5 and x64 Windows

[Reinhard Moosauer]

Please do not forget that you need a 64-bit JVM in this case!!


Am Donnerstag, 18. Januar 2007 17:38 schrieb Darren Kukulka:
> Thanks for the pointers Mladen.
>
> I carried out the steps you outlined, however the "service install"
> command fails...as follows;
>
> F:\Tomcat5\bin>service install
> Installing the service 'Tomcat5' ...
> Using CATALINA_HOME:F:\Tomcat5
> Using CATALINA_BASE:F:\Tomcat5
> Using JAVA_HOME:C:\Program Files\Java\jre1.5.0_10
> Using JVM:  auto
> The system cannot execute the specified program.
> Failed installing 'Tomcat5' service
>
> I've made sure the tomcat5 service is completely removed by using
> "sc \\servername delete tomcat5" but I receive the same message running
> the "service install".
>
> Should I be specifying any parameters for this?
>
> -Original Message-
> From: Mladen Turk [mailto:[EMAIL PROTECTED]
> Sent: 18 January 2007 14:01
> To: Tomcat Users List
> Subject: Re: Tomcat 5.5 and x64 Windows
>
> Darren Kukulka wrote:
> > Mladen,
> >
> > The binary versions you mentioned are the same ones I have already
> > tried.
> >
> > 2 questions;
> >
> > - how do you install the Tomcat service manually?  I install Tomcat
> > using the binary download, i.e. apache-tomcat-5.5.20.exe which does
>
> not
>
> > give you the option of NOT installing the Tomcat service.
> > - I'm not sure what you mean by running the install.bat.  As mentioned
>
> I
>
> > install using the exe.
>
> .exe installer is 32 bit so it'll probably install as WOW64
> (WindowsOnWindows64)
>
> Unistall the Tomcat.
> download apache-tomcat-5.5.20.zip and unpack to 
> of your choice.
>
> put tomcat5.exe.amd64 as tomcat5.exe inside \bin
> put tomcat5w.exe.amd64 as tomcat5w.exe inside \bin
>
> open cmd.exe (be sure it's 64 bit so, 'Start->run-cmd')
> cd to the \bin
>
>  > service install
>
> That's is :)
>
> Regards,
> Mladen.
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
>
> Connaught honoured AIM 'Decade of Excellence' Award
>
> Connaught awarded Partnering Contractor of the Year 2005
>
> Connaught wins AIM 'Company of the Year' award 2004
>
> West of England Business of the Year Award Winner 2003
>
> Why not visit our website http://www.connaught.plc.uk
> Disclaimer:
>
> The information transmitted is intended only for the person or entity to
> which it is addressed and may contain confidential and/or privileged
> material. Any review, retransmission, dissemination or other use of, or
> taking of any action in reliance upon, this information by persons or
> entities other than the intended recipient is prohibited. If you received
> this in error, please contact the sender and delete this message.
>
>
>
> Connaught plc, Head Office 01392 444546
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-- 
Reinhard Moosauer
IT Beratung

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Tomcat 5.5 failure to deploy javac 1.6 servlet

[Reinhard Moosauer]

Hi,

does your tomcat instance really use JRE 1.6 ?
You can easily check in the manager app.

Anyway I would suggest to always use
-source 1.4 -target 1.4 
for older Classes, because you avoid all possible syntax problems.

Other combinations of source/target could be tested if you suspect a javac 
bug.
Maybe this helps

R.

Am Dienstag, 13. März 2007 21:12 schrieb Horine Travis Contr AEDC/ATA:
> Just recently upgraded our server to use tomcat 5.5 with JRE 1.6 (was
> tomcat 4.0 with JRE 1.3). We had several poorly written servlets that still
> manage to compile under both javac 1.3 and javac 1.6.  When I compile them
> under javac 1.6 they no longer deploy correctly under tomcat 5.5. I have
> used the same 1.6 compiler to compile some of the tomcat 5.5 servlet
> examples and they continue to deploy correctly. Basically I have no idea
> how to cross-reference Signature index 63 from the class file to whatever
> in the java source code is causing it. Has anybody seen this kind of
> behavior before? The strange thing is I can put a static void main(...) sub
> in the class and am able to compile and execute it from the command line so
> I know the JRE 1.6 is able to load the class ...just tomcat seems to have
> the class loading problem
>
>
>
> Thanks for any help,
>
> [EMAIL PROTECTED] 
>
>
>
> Error message from tomcat stdout file:
>
>
>
> SEVERE: Error deploying web application archive dimReporting.war
>
> java.lang.ClassFormatError: Signature index 63 in LocalVariableTable has
> bad constant type in class file
> mil/af/arnold/cm/dimensions/reporting/CrStatusServlet
>
> at java.lang.ClassLoader.defineClass1(Native Method)
>
> at java.lang.ClassLoader.defineClass(ClassLoader.java:620)
>
> at
> java.security.SecureClassLoader.defineClass(SecureClassLoader.java:124)
>
> at
> org.apache.catalina.loader.WebappClassLoader.findClassInternal(WebappClassL
>o ader.java:1650)
>
> at
> org.apache.catalina.loader.WebappClassLoader.findClass(WebappClassLoader.ja
>v a:856)
>
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.ja
>v a:1305)
>
> at
> org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.ja
>v a:1187)
>
> at
> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1
>0 27)
>
> at
> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:925)
>
> at
> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java
>: 3880)
>
> at
> org.apache.catalina.core.StandardContext.start(StandardContext.java:4141)
>
> at
> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:
>7 59)
>
> at
> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:739)
>
> at
> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:524)
>
> at
> org.apache.catalina.startup.HostConfig.deployWAR(HostConfig.java:804)
>
> at
> org.apache.catalina.startup.HostConfig.deployWARs(HostConfig.java:693)
>
> at
> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:472)
>
> at
> org.apache.catalina.startup.HostConfig.start(HostConfig.java:1118)
>
> at
> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:310)
>
> at
> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSuppo
>r t.java:119)
>
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1020)
>
> at
> org.apache.catalina.core.StandardHost.start(StandardHost.java:718)
>
> at
> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1012)
>
> at
> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:442)
>
> at
> org.apache.catalina.core.StandardService.start(StandardService.java:450)
>
> at
> org.apache.catalina.core.StandardServer.start(StandardServer.java:680)
>
> at
> org.apache.catalina.startup.Catalina.start(Catalina.java:536)
>
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3
>9 )
>
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp
>l .java:25)
>
> at java.lang.reflect.Method.invoke(Method.java:597)
>
> at
> org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:275)
>
> at
> org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:413)

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Chrooting Tomcat // Linux threading issue

[Reinhard Moosauer]

Hi,

If security is your main concern, you should really consider 2.6:
Technologies like AppArmor are are giving a lot of confidence. 
And you have intrusion detection included.

And IMHO you have no long term alternative to using current and maintained 
software.

R.

Am Dienstag, 13. März 2007 12:01 schrieb Roman Medina-Heigl Hernandez:
> Hello,
>
> Andrew Miehs escribió:
> > On 13/03/2007, at 11:22 AM, Roman Medina-Heigl Hernandez wrote:
> >>> Hello,
> >>>
> >>> Server version: Apache Tomcat/5.5.17
> >>> Server number:  5.5.17.0
> >>> OS Version: 2.4.34-grsec-rslabs-k7
> >>> JVM Version:1.4.2_10-b03
> >
> > Look for NPTL and Linux in Google...
>
> I liked this article:
> http://linuxdevices.com/articles/AT6753699732.html
>
> > I would seriously recommend upgrading to a 2.6 kernel - (unless
> > performance for your web app is irrelevant)
>
> I'll think about it. Performance, in this case, is not too much relevant. I
> was indeed worried about "memory exhausted" problems and things like that,
> but not about how speedy my application could run. If the application is
> stable enough in 2.4, I could keep that kernel. Many people consider kernel
> 2.4 more secure than 2.6, and in my case I prefer security to performance.
>
> > It would also be time to think about an upgrade to Java 1.5 or 1.6.
>
> Would I notice big performance improvements if upgrading? (specially
> regarding threading?) 1.5 or 1.6?
>
> Thanks for your help, Andrew. It is appreciated.
>
> Cheers,
> -Roman
>
> -
> To start a new topic, e-mail: users@tomcat.apache.org
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]

-
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]