Re: JNI error under tomcat: java.lang.UnsatisfiedLinkError
Hi Dennis.
So do you see the "Load library successful" message?
Also, if I remember correctly, the code in eval.java is not a safe way to
load a native library. It's a very good idea to place the System.loadLibrary
in a static { } block, instead of in a method. The way your class is
written, it's possible for the run method to be executed more than once, in
which case loadLibrary will be called more than once (and so will the native
initModels). Not sure what the effects are and if it's related to your
problem but it's a good idea to avoid trouble by fixing it.
Shay
On Fri, Jul 2, 2010 at 3:46 AM, dennis ch wrote:
> Hi,
>
> I have a java class (eval.java) that invokes a native method in an so file
> (libmodel.so, using SWIG 1.3.29 to generate JNI code/wrapper and compiled
> the library). I can use System.loadLibrary() to load the libmodel.so
> without
> any error (-Djava.library.path=/usr/lib), and the native method initModel()
> works fine as a standalone application.
>
> However, when I deploy it as a web service (tomcat 6.0.26 + axis2 1.5.1 +
> eclipse jee helios) to call the native method, I got the following error
> (the first line means the .so was successfully loaded):
>
> Load library successfully
>
> [ERROR] com.model.modelJNI.initModel()V
> java.lang.reflect.InvocationTargetException
>at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>at java.lang.reflect.Method.invoke(Method.java:597)
>at
> org.apache.axis2.rpc.receivers.RPCUtil.invokeServiceClass(RPCUtil.java:194)
>at
> org.apache.axis2.rpc.receivers.RPCMessageReceiver.invokeBusinessLogic(RPCMessageReceiver.java:102)
>at
> org.apache.axis2.receivers.AbstractInOutMessageReceiver.invokeBusinessLogic(AbstractInOutMessageReceiver.java:40)
>at
> org.apache.axis2.receivers.AbstractMessageReceiver.receive(AbstractMessageReceiver.java:114)
>at org.apache.axis2.engine.AxisEngine.receive(AxisEngine.java:173)
>at
> org.apache.axis2.transport.http.HTTPTransportUtils.processHTTPPostRequest(HTTPTransportUtils.java:167)
>at
> org.apache.axis2.transport.http.AxisServlet.doPost(AxisServlet.java:142)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:637)
>at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
>at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
>at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
>at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
>at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
>at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
>at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
>at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
>at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:298)
>at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:852)
>at
> org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:588)
>at
> org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:489)
>at java.lang.Thread.run(Thread.java:619)
> Caused by: java.lang.UnsatisfiedLinkError: com.model.modelJNI.initModel()V
>at com.model.modelJNI.initModel(Native Method)
>at com.model.model.initModel(model.java:13)
>at com.webservice.run(EvalVita.java:763)
>... 25 more
>
>
> Below is the body of Eval.java:
>
> import com.model.*;
>
> public class Eval {
>
> static void loadModel() {
>
>try {
>System.loadLibrary("model");
>
>System.out.println("Load library successfully");
>
>} catch (UnsatisfiedLinkError e) {
>
>System.err.println("Native code library failed to load." + e);
>
>}
> }
> public void run() {
>
>loadModel();
>model.initModel();
> }
> }
>
>
> Do I miss anything here? Any input is appreciated!
>
> Dennis
>
Re: "Application" vars -
Just my comments on the dispatching idea proposed below... If smooth processing with no freeze-time is important, I'm assuming there is also some sort of cluster/high-availability functionality. If this is the case, you are already running at least two Tomcats on different servers, and using some load-balancing/dispatch mechanism - for example Apache with mod_jk. If you have just one Tomcat you have much more to worry about than Tomcat freezing during webapp reload :) So, why not just use the load balancer's functionalities, instead of writing a dispatcher yourself (webappX below)? In other words, you stop the webapp on tomcat1 - the load balancer (or mod_jk or whatever) detects this immediately and stops forwarding requests to it. You do whatever config change, and start the app again. At this point the new app is added back to the load balancer. Repeat same thing with tomcat2, tomcat3... Seems simpler than deploying two copies of a webapp + a third dispatcher that you need to write and maintain (and all this across the N servers in your cluster)... One last note: if I remember correctly, you can only forward requests within the same servlet context (i.e. webapp), so "dispatching" from webappX to webappA or webappB would be non-trivial. You could do redirections, but this exposes your internal mechanism to clients and is really bad. Shay On Fri, Jul 2, 2010 at 4:27 AM, André Warnier wrote: > Eric P wrote: > >> So it makes sense to go into what "disruption" means. I'm not 100% sure >>> about the following, it would be good if a tomcat heavyweight would >>> confirm/refute what I say. >>> >>> When you initiate a webapp reload, Tomcat waits for requests that have >>> already started processing to terminate. This ensures that people who >>> accessed your app just before the webapp get a complete response. Once >>> that's done, the application is reloaded and your servlets' init methods >>> are >>> called if necessary. During this time, incoming requests aren't denied, >>> they >>> are just paused until the reload is complete. >>> >>> So the only disruption people see is your application freezing up for the >>> time it takes to reload (which is going to depend on what you your >>> initialization consists of). No ugly server unavailable errors or >>> anything >>> of the sort. >>> >>> If you don't like the idea of your app freezing, think about this. >>> Rereading >>> environment params without reloading has its own risks, namely potential >>> race conditions. Imagine you have 5 parameters, and requests are coming >>> in >>> as you are reading these in and initializing your webapp. A request might >>> be >>> handled while 2 params have been read, but 3 still contain the old >>> values. >>> If you start to think about locking/synchronization to solve this you're >>> definitely better off just using Tomcat's reload mechanism. >>> >>> So my answer would be, trust Tomcat's reloading process unless you >>> absolutely want to avoid your webapp freezing for the time it will take >>> for >>> it to init (this depends on the webapp). If you want to do your own >>> "reloading", think long and hard about potential race conditions (which >>> will >>> occur in all except the simplest cases). >>> >>> Again, all this should probably be verified, you can set up very simple >>> test >>> cases with a JSP that sleeps, etc. >>> >>> >>> >> Shay, >> I think you made a good case for keeping app vars in web.xml (i.e., seems >> pretty apparent now that's where they belong). >> >> Thanks for taking the time to respond. I sincerely appreciate it! >> Eric P. >> >> +1 > Very neat explanation. > > While not being a great specialist, I would just like to expone what may be > an alternative, if one really wants to diminish the (apparent) time it takes > for a new version of a webapp to become available. Since I am no great > specialist, I will just outline the idea without Java/servlet specifics. > > (Maybe also I am barging through an open door, and there already exists a > standard mechanism for doing this, but oh well..) > > Imagine that you have 2 identical versions of the same intrinsic webapp > deployed, like > > catalina_base/webapps/webappA > catalina_base/webapps/webappB > > You create a 3rd webapp webappX, which is the one the users see, and which > is just a "dispatcher" to either one of the two webapps webappA and webappB. > So you now have : > > catalina_base/webapps/webappX > catalina_base/webapps/webappA > catalina_base/webapps/webappB > > The users always use the URL "/webappX". > When a call is made to webappX, /it/ decides, in function of some external > parameter Y, whether to dispatch the call to either webappA or webappB. > > Say that initially the external parameter Y (which could be a system-wide > property) is set so that all calls to "/webappX" are currently dispatched to > /webappA. > Now you want to update webappA. > You change the parameter Y so that calls are now dispatched to (identical) > /webappB. > Th
Re: Tomcat 6.0.26
Hi. pid's right - you should really put your classes in packages (although I'm pretty sure it's not technically mandatory). But looking at your attached files, I think I see another problem - confusion between the Java class package and the servlet mapping. In the web.xml element, you reference a Java class and give it a servlet name. Looking at your web.xml, I see a ukjava1900 servlet with the class com.multitel.ukjava1900. This means that you must have a myApp\WEB-INF\classes\com\multitel\ukjava1900.class in your webapp. All good till now. The web.xml element maps a servlet name (defined above) to actual URLs that will be used to access that webapp. This URL has nothing to do with the Java class. In your web.xml, I see /com/multitel/ukjava1900 - this is wrong (unless you want users to access /servlet/com/multitel/ukjava1900). Change this to /ukjava1900 and it should work. Try to understand the difference between your Java classes, their packages and the directory hierarchy under WEB-INF\classes on the one hand, and the URL namespace of your webapp on the other. Shay On Thu, Jul 1, 2010 at 5:48 AM, John Byrne wrote: > Hi Shay > > Still having problems with reading html form with servlet. > > We only have a small number of servlets and would choose not to place > them in a package at this point in time. > > I understand your naming of package com.company.project, can you > replace com\mycompany\Myservlet.class. What is the link between them. > > I noted your comment on web.xml file Have been using tomcat for 3/4 > years and have most probably got away with murder using invoker > servlet and mapping of. > > I attach a file with html form action, server start up log, web.xml > file and error http 404 > > We only have a small number of servlets and would choose not to place > them in a package at this point in time. > > I understand your naming of package com.company.project, can you > replace com\mycompany\ > > On 28 June 2010 13:26, Shay Rojansky wrote: > > Hi John. > > > > Both John and I were right... Moving your directory outside ROOT was the > > first step. > > > > Now, in your web.xml, the element is wrong. It should > > contain a servlet class that should be found under your WEB-INF/classes > > directory. So if you want to reference the class that you have under > > comlinks\WEB-INF\classes\com\mycompany\MyServlet.class, simply put > > "com.mycompany.MyServlet" in the element. > > > > By the way, it's hard to tell what your class name and package actually > are. > > It's a good idea to follow conventions and place it in a package called > > com.company.project > > > > Shay > > > > On Mon, Jun 28, 2010 at 5:11 AM, John Byrne > wrote: > > > >> Hi Shay > >> > >> copy of directory structure > >> > >> C:\Tomcat 6.0\webapps\comlinks\WEB-INF\classes> > >> > >> I have changed this it incorporate your suggestions. > >> > >> I attach a copy of web.xml > >> > >> many thanks for your help. > >> > >> Kind Regards > >> > >> John > >> > >> On 27 June 2010 15:54, Shay Rojansky wrote: > >> > John, > >> > > >> > Can you please send your web.xml as well? I would be it's a > misconfigured > >> > in there (the WEB-INF should not be part of the class > package > >> > name, as it appears in your error log). > >> > > >> > Shay > >> > > >> > On Sun, Jun 27, 2010 at 7:55 AM, John Byrne > >> wrote: > >> > > >> >> Hi > >> >> > >> >> Have installed tomcat 6.0.26 on windows 7. > >> >> > >> >> Have installed jdk1.6.0_20 to use with tomcat > >> >> > >> >> The javac and java commands both give correct response at dos prompt. > >> >> > >> >> The log for server start up reports no errors. > >> >> > >> >> The index page displays ok > >> >> > >> >> The manager page displays ok > >> >> > >> >> The example HelloWorld works ok > >> >> > >> >> The application webpages display ok. > >> >> > >> >> The problem appears to be with the servlet that reads the form data > in > >> >> html page. > >> >> > >> >> I use default install structure for tomcat. I add a applications > >> >> folder under TOMCAT 6.0\webapps\ROOT\myfoloder > >> >> Also add classes fol
Re: "Application" vars -
Hi Eric. On Wed, Jun 30, 2010 at 9:20 PM, Eric P wrote: > Shay, > > Forgive all potential newbness in my responses below. I'm still learning > this stuff. > > No worries for newbiness, your responses all make sense. > > Shay Rojansky wrote: > >> Hi Eric. >> >> Would making your servlet reload all application vars not be akin to >> simply >> reloading your servlet altogether, by changing context/init params in your >> web.xml or context.xml? >> >> > Do you mean "reloading your 'application' altogether"? If so wouldn't that > cause disruption to users currently on the app? This disruption is what I'd > like to avoid. So it makes sense to go into what "disruption" means. I'm not 100% sure about the following, it would be good if a tomcat heavyweight would confirm/refute what I say. When you initiate a webapp reload, Tomcat waits for requests that have already started processing to terminate. This ensures that people who accessed your app just before the webapp get a complete response. Once that's done, the application is reloaded and your servlets' init methods are called if necessary. During this time, incoming requests aren't denied, they are just paused until the reload is complete. So the only disruption people see is your application freezing up for the time it takes to reload (which is going to depend on what you your initialization consists of). No ugly server unavailable errors or anything of the sort. If you don't like the idea of your app freezing, think about this. Rereading environment params without reloading has its own risks, namely potential race conditions. Imagine you have 5 parameters, and requests are coming in as you are reading these in and initializing your webapp. A request might be handled while 2 params have been read, but 3 still contain the old values. If you start to think about locking/synchronization to solve this you're definitely better off just using Tomcat's reload mechanism. So my answer would be, trust Tomcat's reloading process unless you absolutely want to avoid your webapp freezing for the time it will take for it to init (this depends on the webapp). If you want to do your own "reloading", think long and hard about potential race conditions (which will occur in all except the simplest cases). Again, all this should probably be verified, you can set up very simple test cases with a JSP that sleeps, etc. > > If you really want to avoid an application reload, why not just have your >> app read its values from a properties config file instead of a DB? It >> would >> be much more lightweight and standard. >> >> > That's an idea. But wouldn't file I/O every time a servlet needs an > application value be way more expensive than storing settings in a record, > reading and setting them to the application scope once, and only resetting > these vars manually when needed? > I wasn't proposing to perform I/O and parse the properties file upon every request, simply to parse it once upon init and load it into application-scoped vars. This is exactly the same as what you were planning to do, except that instead of pulling the values from a DB record you pull them from a properties file. Note that using a property file will almost surely be faster (and not to mention simpler) than a database, as connecting to a database usually means network activity, authentication, etc. It would also make changing those values easier - editing a properties file is more straightforward than a database with its schema. But at the end of the day, it all depends on your app. If you already have everything in your DB and it makes sense to have those config values in there too, why not. > > Is this standard documented somewhere? > What exactly? :) > > Thanks... I appreciate the ideas. > Eric > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: "Application" vars -
Hi Eric. Would making your servlet reload all application vars not be akin to simply reloading your servlet altogether, by changing context/init params in your web.xml or context.xml? If you really want to avoid an application reload, why not just have your app read its values from a properties config file instead of a DB? It would be much more lightweight and standard. Shay On Mon, Jun 28, 2010 at 11:37 PM, Eric P wrote: > I've been loading up my web.xml with context and init params for my first > app, but I'm thinking at some point it'd be nice to tweak these values on > the fly while the app is running. > > What are some good practices to accomplish this? > > I'm leaning towards storing all application variables in a database table > w/one record, and loading these values into the application scope w/a > servlet on app startup. Then if I need to tweak any values I could update > the db record and hit this servlet to reload all the application scope vars. > > I'm guessing there's some other possibly better ways to go about this. > > Thanks for reading, > Eric P. > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > >
Re: Classloading
Nope, it doesn't... Your webapp's classloader delegates to the common classloader when it can't find something in the webapp - this is the point of having the common classloader! For example, it allows you to share some common infrastructure (e.g. DB driver) between several webapps. So classes in your webapp can depend on common classes, but not the other way around. For further reading: http://tomcat.apache.org/tomcat-6.0-doc/class-loader-howto.html, and see also Java classloaders and chaining in general. Shay On Mon, Jun 28, 2010 at 8:48 AM, Ockleford Paul (NHS Connecting for Health) wrote: > Hi, > > Thanks very much for confirming that and for providing me with more > information. One thing I still find strange though is how SupplementaryEdit > (in the webapp) is able to call a class loaded by the "common" classloader? > Does it not work the other way round as well? > > Thanks, > > Paul > > -Original Message- > From: Shay Rojansky [mailto:r...@roji.org] > Sent: 28 June 2010 13:35 > To: Tomcat Users List > Subject: Re: Classloading > > Hi Paul. > > Yes, this is the normal behavior. As you found out, Tomcat uses a different > classloader for the "common" classes than that used for for loading your > webapp classes. > > Basically, when your application loads PracCalc, Tomcat looks first in the > "common" directory and loads it from there. Then, since the reference to > SupplementaryEdit is from PracCalc, PracCalc's classloader (the "common" > one) is used to search for the dependency, SupplementaryEdit. Since the > "common" classloader knows nothing about your webapp's classes, a > ClassNotFoundException is thrown. > > You have to plan well how to manage your JARs and classes. One solution is > to put all dependencies in your webapp, another is to make sure that if you > put a dependency in Tomcat's common directory, all of the dependency's > dependencies must also be there. > > Shay > > On Mon, Jun 28, 2010 at 8:22 AM, Ockleford Paul (NHS Connecting for Health) > wrote: > > > Hi, > > > > I had a problem this morning that took me a while to sort out, and now I > > know what the issue is I was hoping somebody could explain why the > problem > > was happening. I assume it is because one class had been loaded by a > > different classloader, and so wasn't available to the second class. > > > > I have 2 classes in different packages but within the same web > application: > > > > SupplementaryEdit - webapps/WEB-INF/classes > > PracCalc - webapps/WEB-INF/classes > > > > I added a method to SupplementaryEdit and then called it within this > class > > and it worked ok. Next I created an object of SupplementaryEdit in > PracCalc > > and tried to call this new method. I got a classnotfoundexception for > > SupplementaryEdit at the point of instantiation and I was struggling to > find > > out why. > > > > After spending ages trying different things I started looking through the > > common classes in tomcat and found that someone had previously created a > > symlink to the package PracCalc is in there. I read a little on tomcat > > classloading and came to the conclusion that this was causing PracCalc to > be > > loaded by a different loader to SupplementaryEdit. > > > > If someone could confirm this that would be good, and also could someone > > explain why the class in the web app isn't available to the class > referenced > > in common/lib? > > > > I don't understand because I get a runtime exception in the block where > the > > object is created, and not on initial class use (as I used the class > without > > triggering the code block fine), and I also don't understand why at > runtime > > the common classloader is not able to resolve the class, as I have tested > by > > calling a class that creates a SupplementaryEdit object before trying > from > > PracCalc and it still didn't work. > > > > To resolve the issue I moved the method into PracCalc as this still made > > sense logically and the code now works, just looking for some general > > help\guidance. > > > > Thanks, > > > > Paul > > > > > > > > > > > This message may contain confidential information. If you are not the > > intended recipient please inform the > > sender that you have received the message in error before deleting it. > > Please do not disclose, copy or dis
Re: Classloading
Hi Paul. Yes, this is the normal behavior. As you found out, Tomcat uses a different classloader for the "common" classes than that used for for loading your webapp classes. Basically, when your application loads PracCalc, Tomcat looks first in the "common" directory and loads it from there. Then, since the reference to SupplementaryEdit is from PracCalc, PracCalc's classloader (the "common" one) is used to search for the dependency, SupplementaryEdit. Since the "common" classloader knows nothing about your webapp's classes, a ClassNotFoundException is thrown. You have to plan well how to manage your JARs and classes. One solution is to put all dependencies in your webapp, another is to make sure that if you put a dependency in Tomcat's common directory, all of the dependency's dependencies must also be there. Shay On Mon, Jun 28, 2010 at 8:22 AM, Ockleford Paul (NHS Connecting for Health) wrote: > Hi, > > I had a problem this morning that took me a while to sort out, and now I > know what the issue is I was hoping somebody could explain why the problem > was happening. I assume it is because one class had been loaded by a > different classloader, and so wasn't available to the second class. > > I have 2 classes in different packages but within the same web application: > > SupplementaryEdit - webapps/WEB-INF/classes > PracCalc - webapps/WEB-INF/classes > > I added a method to SupplementaryEdit and then called it within this class > and it worked ok. Next I created an object of SupplementaryEdit in PracCalc > and tried to call this new method. I got a classnotfoundexception for > SupplementaryEdit at the point of instantiation and I was struggling to find > out why. > > After spending ages trying different things I started looking through the > common classes in tomcat and found that someone had previously created a > symlink to the package PracCalc is in there. I read a little on tomcat > classloading and came to the conclusion that this was causing PracCalc to be > loaded by a different loader to SupplementaryEdit. > > If someone could confirm this that would be good, and also could someone > explain why the class in the web app isn't available to the class referenced > in common/lib? > > I don't understand because I get a runtime exception in the block where the > object is created, and not on initial class use (as I used the class without > triggering the code block fine), and I also don't understand why at runtime > the common classloader is not able to resolve the class, as I have tested by > calling a class that creates a SupplementaryEdit object before trying from > PracCalc and it still didn't work. > > To resolve the issue I moved the method into PracCalc as this still made > sense logically and the code now works, just looking for some general > help\guidance. > > Thanks, > > Paul > > > > > This message may contain confidential information. If you are not the > intended recipient please inform the > sender that you have received the message in error before deleting it. > Please do not disclose, copy or distribute information in this e-mail or > take any action in reliance on its contents: > to do so is strictly prohibited and may be unlawful. > > Thank you for your co-operation. > > NHSmail is the secure email and directory service available for all NHS > staff in England and Scotland > NHSmail is approved for exchanging patient data and other sensitive > information with NHSmail and GSI recipients > NHSmail provides an email address for your career in the NHS and can be > accessed anywhere > For more information and to find out how you can switch, visit > www.connectingforhealth.nhs.uk/nhsmail > > > >
Re: Tomcat 6.0.26
Hi John. Both John and I were right... Moving your directory outside ROOT was the first step. Now, in your web.xml, the element is wrong. It should contain a servlet class that should be found under your WEB-INF/classes directory. So if you want to reference the class that you have under comlinks\WEB-INF\classes\com\mycompany\MyServlet.class, simply put "com.mycompany.MyServlet" in the element. By the way, it's hard to tell what your class name and package actually are. It's a good idea to follow conventions and place it in a package called com.company.project Shay On Mon, Jun 28, 2010 at 5:11 AM, John Byrne wrote: > Hi Shay > > copy of directory structure > > C:\Tomcat 6.0\webapps\comlinks\WEB-INF\classes> > > I have changed this it incorporate your suggestions. > > I attach a copy of web.xml > > many thanks for your help. > > Kind Regards > > John > > On 27 June 2010 15:54, Shay Rojansky wrote: > > John, > > > > Can you please send your web.xml as well? I would be it's a misconfigured > > in there (the WEB-INF should not be part of the class package > > name, as it appears in your error log). > > > > Shay > > > > On Sun, Jun 27, 2010 at 7:55 AM, John Byrne > wrote: > > > >> Hi > >> > >> Have installed tomcat 6.0.26 on windows 7. > >> > >> Have installed jdk1.6.0_20 to use with tomcat > >> > >> The javac and java commands both give correct response at dos prompt. > >> > >> The log for server start up reports no errors. > >> > >> The index page displays ok > >> > >> The manager page displays ok > >> > >> The example HelloWorld works ok > >> > >> The application webpages display ok. > >> > >> The problem appears to be with the servlet that reads the form data in > >> html page. > >> > >> I use default install structure for tomcat. I add a applications > >> folder under TOMCAT 6.0\webapps\ROOT\myfoloder > >> Also add classes folder under tomcat 6.0\webapps\ROOT\WEB-INF\classes > >> > >> I attach copy of server start up log and http 500 error text when I > >> use the submit button on html page to activate servlet. > >> > >> would greatly appreciate your help. > >> > >> John Byrne > >> > >> -- > >> Mult-i-tel better by design. > >> > >> http://www.multitel.co.uk > >> > >> tel: 44(0)151 548 8122 > >> fax: 44(0)709 210 1464 > >> skype jcbyrne > >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > >> > > > > > > -- > Mult-i-tel better by design. > > http://www.multitel.co.uk > > tel: 44(0)151 548 8122 > fax: 44(0)709 210 1464 > skype jcbyrne > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: Tomcat 6.0.26
John, Can you please send your web.xml as well? I would be it's a misconfigured in there (the WEB-INF should not be part of the class package name, as it appears in your error log). Shay On Sun, Jun 27, 2010 at 7:55 AM, John Byrne wrote: > Hi > > Have installed tomcat 6.0.26 on windows 7. > > Have installed jdk1.6.0_20 to use with tomcat > > The javac and java commands both give correct response at dos prompt. > > The log for server start up reports no errors. > > The index page displays ok > > The manager page displays ok > > The example HelloWorld works ok > > The application webpages display ok. > > The problem appears to be with the servlet that reads the form data in > html page. > > I use default install structure for tomcat. I add a applications > folder under TOMCAT 6.0\webapps\ROOT\myfoloder > Also add classes folder under tomcat 6.0\webapps\ROOT\WEB-INF\classes > > I attach copy of server start up log and http 500 error text when I > use the submit button on html page to activate servlet. > > would greatly appreciate your help. > > John Byrne > > -- > Mult-i-tel better by design. > > http://www.multitel.co.uk > > tel: 44(0)151 548 8122 > fax: 44(0)709 210 1464 > skype jcbyrne > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: Setting Up AJP Workers as a Failover
David, you might want to take a look at http://tomcat.apache.org/connectors-doc/generic_howto/loadbalancers.html under "Advanced lb Worker properties". There's an example for what you want with what Reiner was talking about (activation/redirect). Shay On Wed, Jun 23, 2010 at 3:48 AM, Pid wrote: > On 23 Jun 2010, at 00:12, David Fisher wrote: > > > Hi All, > > > > I've got myself in a situation where I need a stopgap quick fix - until > we can respond correctly. > > > > I have the following workers file: > > > > # define the worker list > > worker.list=LoadBalancer > > > > # Define the LB worker > > worker.LoadBalancer.type=lb > > worker.LoadBalancer.balance_workers=webprod1,webprod2 > > worker.LoadBalancer.sticky_session=1 > > > > # configure each worker > > worker.webprod1.type=ajp13 > > worker.webprod1.host=webprod1 > > worker.webprod1.port=8009 > > worker.webprod1.lbfactor=100 > > > > worker.webprod2.type=ajp13 > > worker.webprod2.host=webprod2 > > worker.webprod2.port=8009 > > worker.webprod2.lbfactor=100 > > > > If I change the last line to "worker.webprod2.lbfactor=0" will webprod2 > only be used if webprod1 is disconnected or otherwise in an error state? > > > > My other choice is to turn off one of the server's Tomcat instance. > > > > The real solution might take a day or two and that is to put back > JSESSIONID - meanwhile I'm looking at how to fix occasional strangeness for > users. If someone has a way to force JSESSIONID with a valve or filter that > would be great. > > I can't make sense of the above. > Put it back where and why? > > p > > > > > Yes my jvmroutes are set. > > > > Regards, > > Dave > > - > > 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 > >
