Regarding TOmcat Restart evertime servlet is modified

Hi,
Myself Ashwin MIttal, using Tomcat on the Linux and Windows OS. Hey I am developing servlet and when I deploy servlet each time. I have to restart the Tomcat ....
Is there anyway to solve the problem means There is no need to restart the Tomcat when eber serlvet is modified..
Regards,
Ashwin Mittal.

In the context, type reloadable="true"yup, this is a better option.But you want to only do this on your developement machine. reloadable contexts take up a lot of resources, every x amount of time, the server has to check the classpath directories for modified time. Even if you don't make changes, this takes up resources. So once you move from development to deployment you want to turn this off...

Similar Messages

How can i avoid restarting tomcat server when servlet is modified?

please advice me that how can i avoid restarting the tomcat server, whenever a servlet file is modified in my application. is their any way ?

No probs. Here's how I do things...
1. Install tomcat as normal (e.g. I install to C:\Apps\jakarta-tomcat-5.5.4)
2. Create a webapps directory in your eclipse project with the following directory structure
MyEclipseProject
   - src
   - conf
   - webapps
      - MyApplication
         - META-INF
         - WEB-INF
            - classes
            - lib
            - pages3. Set the project's output folder (e.g. bin folder) to webapps/MyApplication/WEB-INF/classes
4. Put all your jar files in the lib directory
5. Put JSPs / HTML in the pages directory (you may also want to create additional directories for TLDs, config files etc)
6. Ensure your web.xml is in the WEB-INF directory
7. Although it isn't essential I create a context.xml file and store it in META-INF, e.g.
<Context reloadable="true">
    
     <WatchedResource>WEB-INF/web.xml</WatchedResource>
     <WatchedResource>WEB-INF/conf/struts/struts-config.xml</WatchedResource>
     <WatchedResource>WEB-INF/conf/struts/tiles-defs.xml</WatchedResource>
     <WatchedResource>WEB-INF/conf/struts/validation.xml</WatchedResource>
</Context>I use this to set monitored resources that will trigger an automatic appliation reload and to configure JAAS (not shown). See the Tomcat documentation for additional information.
8. In the 'conf' directory I create a server.xml file used to configure Tomcat (you can copy the one from your <TOMCAT_HOME>/conf/server.xml).
After copying the file change appBase attribute in the host element to be the full path to the webapps directory. You can also change the HTTP and HTTPS ports if you wish
9. Download and install the Tomcat Launcher plugin from Sysdeo.
10. In Eclipse's Preferences menu you will see a new entry for Tomcat. Click this then
a. Set your Tomcat Version
b. Set your Tomcat Home
c. Set "Context declaration mode" to server.xml
d. Set the configuration file to the full path to your server.xml file created in step 8
On the "Advanced " sub page select all relevant projects to add to the Tomcat classpath
On the "JVM Settings" page add all the jars in your WEB-INF lib directory to the class path
On the "Source Path" page select all relevant projects
Now if you start Tomcat using the Tomcat icon, you will be able to remote debug your application. If you change web.xml (or any other file in your context.xml watched resources) it will automatically reload. Any changes to JSPs will automatically be picked up (providing your tell your browser not to use the page in cache - e.g. CTRL+F5 in IE)
There are some limitations that I'm still working on however. Primarily that I haven't included the Tomcat Manager application in my webapps directory, so Sysdeo cannot perform a reload. This means that if I change a source file, and eclipse auotmatically rebuilds, Tomcat doesn't pick up the change unless I either change a watched resource file (e.g. web.xml) or stop and restart Tomcat.
There's no reason why this can't be fixed, I just haven't got round to it yet.
I'm sure there are lots of other (probably better) ways of achieving the same thing. This was the first method I tried and it worked, so I stuck with it. I'm not a Tomcat config guru and I'm sure other forum users could provide some improvements should they wish.
Post if you get into trouble, however I won't be able to respond until next week.
Cheers,
Steve

How to run code only at tomcat restart.?

Hi all,
Actually, i have problem that i want to run few lines of code only at deployment, Means only when tomcat restart that particular code run.
Thanks
Anu

Deploy a Servlet that has the code in it's init() method and make it [load on startup|http://publib.boulder.ibm.com/infocenter/wxdinfo/v6r0/index.jsp?topic=/com.ibm.websphere.xd.doc/info/WPF51/rwpfservletstart.html].

How to restart the Servlet Engine?

Hi
I am configurating a WebDAV repository in KM
I am required to restart the Servlet Engine.
Can anyone please explain me how to restart the servlet engine.
Thanks in advance
-madhu

Basically it means to restart the Java engine!
On way to do this is to use the NetWeaver Administrator tool (http://portal:port/nwa) and navigate to Administration -> Systems -> <Your SID> and then you will see your dispatcher and server nodes. Just restart the server0..n nodes.
Cheers

How can I restart a Servlet ?

Hi,
I have a Java servlet that starts up automatically with WebLogic. I have found that sometimes it will terminate on its own while WebLogic is still running...
Is there any way to restart a Servlet on the fly, without restarting/redeploying WebLogic? Perhaps via the console, or something else?
I am running WebLogic 8.1.4 (with WLI) on Solaris.
Thanks,
Chris

Normally, a servlet in a web application is just sitting and waiting for requests. Unless you're really talking about a long-running "init()" method, servlets don't really "terminate", unless the application they're in gets undeployed.
Redeploying the webapp the servlet is in will reexecute the "init()" method of the servlet. You can do this through the wls console.

Restart the servlet engine

I made some changes to the KM -> Content Mgt -> Repository Managers -> BO Repository and saved them.
I got a message at the top telling me to:
"restart the servlet engine"
So I'm wondering if that means restart the J2ee or just restart some repository service?
Mike

Michael,
Pls restart the j2ee engine. This is normally reqd if you make changes in Rep managers.
Rgds

How do I get the Tomcat port using Servlet.

I am running Apache + Tomcat. All request are going though Apache. How do I get the Tomcat port using Servlet.

See:
ServletRequest.getServerPort()This will give the port upon which the request was recieved . . .which I blelieve is what you are looking for.

Restart tomcat at every servlet modify?

Hi,
I'm using tomcat 5.5 and working on some servlets, but when I execute a servlet (http://localhost/my_servlet)
and then I modify and recompile it, I have to shutdown and restart tomcat to see the new version on work.
Is this normal? Can I avoid this?
Thanx

Well, I have solved the problem editing contex.wml file modifying the line:
<Context>into the line:
<Context reloadable="true">Now it works even if refresh time is not so low...
Thanx to all.
P.S.
Adding the line
<DefaultContext reloadable="true"/>into server.xml file I don't have obtained any result.

Tomcat restarting problem -plz help

hi,
Can anybody tell me why do i have to restart the server everytime i change my servlet.
Kindly help
Thanks and regards
neha

Hi Neha,
This documentation is from JavaWebServicesDeveloperPack(Evaluation version)
You will get more details if you can download this pack/tutorial from Java site & install it.
http://java.sun.com/webservices/webservicespack.html
Hope this will help you.
Ajay.
Manager App HOW-TO
Introduction
In many production environments, it is very useful to have the capability to deploy a new web application, or undeploy an existing one, without having to shut down and restart the entire container. In addition, you can request an existing application to reload itself, even if you have not declared it to be reloadable in the Tomcat 4 server configuration file.
To support these capabilities, Tomcat 4 includes a web application (installed by default on context path /manager) that supports the following functions:
Deploy a new web application, on a specified context path, from the uploaded contents of a WAR file.
Install a new web application, which can be anywhere on the server's disks.
List the currently deployed web applications, as well as the sessions that are currently active for those web apps.
Reload an existing web application, to reflect changes in the contents of /WEB-INF/classes or /WEB-INF/lib.
Remove an installed web application.
Start a stopped application (thus making it available again).
Stop an existing application (so that it becomes unavailable), but do not undeploy it.
Undeploy a deployed web application and delete its document base directory.
Since Manager is itself a web application, it interacts with you using standard HTTP requests and responses. However, it's "user interface" is minimal, because it is intended to be accessed from scripts set up by the system administrator. For this reason, commands are given as part of the request URI, and responses are in the form of simple text that can be easily parsed and processed.
Future versions of Tomcat 4 will include administrative functionality that is presented in (at least) the following forms:
As web services, so that Tomcat administration can be easily integrated into remote and/or non-Java mnagement environments.
As a web application with a nice user interface (built on top of the web services processing layer) for easy Tomcat administration via a web browser.
In addition to executing Manager commands directly via HTTP, Tomcat 4 includes a convenient set of task definitions for the Ant (version 1.4 or later) build tool. See Executing Manager Commands With Ant for more information.
Configuring Manager Application Access
The description below uses the variable name $CATALINA_HOME to refer to the directory into which you have installed Tomcat 4, and is the base directory against which most relative paths are resolved. However, if you have configured Tomcat 4 for multiple instances by setting a CATALINA_BASE directory, you should use $CATALINA_BASE instead of $CATALINA_HOME for each of these references.
It would be quite unsafe to ship Tomcat with default settings that allowed anyone on the Internet to execute the Manager application on your server. Therefore, the Manager application is shipped with the requirement that anyone who attempts to use it must authenticate themselves, using a username and password that have the role manager associated with them. Further, there is no username in the default users file ($CATALINA_HOME/conf/tomcat-users.xml) that is assigned this role. Therefore, access to the Manager application is completely disabled by default.
To enable access to the Manager web application, you must either create a new username/password combination and associate the role name manager with it, or add the manager role to some existing username/password combination. Exactly where this is done depends on which Realm implementation you are using:
MemoryRealm - If you have not customized your $CATALINA_HOME/conf/server.xml to select a different one, Tomcat 4 defaults to an XML-format file stored at $CATALINA_HOME/conf/tomcat-users.xml, which can be edited with any text editor. This file contains an XML <user> for each individual user, which might look something like this:
<user name="craigmcc" password="secret" roles="standard,manager" />
which defines the username and password used by this individual to log on, and the role names he or she is associated with. You can add the manager role to the comma-delimited roles attriute for one or more existing users, and/or create new users with that assigned role.
JDBCRealm - Your user and role information is stored in a database accessed via JDBC. Add the manager role to one or more existing users, and/or create one or more new users with this role assigned, following the standard procedures for your environment.
JNDIRealm - Your user and role information is stored in a directory server accessed via LDAP. Add the manager role to one or more existing users, and/or create one or more new users with this role assigned, following the standard procedures for your environment.
The first time you attempt to issue one of the Manager commands described in the next section, you will be challenged to log on using BASIC authentication. The username and password you enter do not matter, as long as they identify a valid user in the users database who possesses the role manager.
Supported Manager Commands
All commands that the Manager application knows how to process are specified in a single request URI like this:
http://{host}:{port}/manager/{command}?{parameters}
where {host} and {port} represent the hostname and port number on which Tomcat is running, {command} represents the Manager command you wish to execute, and {parameters} represents the query parameters that are specific to that command. In the illustrations below, customize the host and port appropriately for your installation.
Most commands accept one or more of the following query parameters:
path - The context path (including the leading slash) of the web application you are dealing with. To select the ROOT web application, specify a zero-length string. NOTE - It is not possible to perform administrative commands on the Manager application itself.
war - URL of a web application archive (WAR) file, or pathname of a directory, that contains the web application. You can use URLs in any of the following formats:
file:/absolute/path/to/a/directory - The absolute path of a directory that contains the unpacked version of a web application. This directory will be attached to the context path you specify without any changes.
file:/absolute/path/to/a/webapp.war - The absolute path of a web application archive (WAR) file. This is valid only for the /deploy command, and is the only acceptable format to that command.
jar:file:/absolute/path/to/a/warfile.war!/ - The URL to a local web application archive (WAR) file. You can use any syntax that is valid for the JarURLConnection class for reference to an entire JAR file.
jar:http://hostname:port/path/to/a/warfile.war!/ - You can also deploy web applications from a remote JAR file. You can use any syntax that is valid for the JarURLConnection class for reference to an entire JAR file.
Each command will return a response in text/plain format (i.e. plain ASCII with no HTML markup), making it easy for both humans and programs to read). The first line of the response wil begin with either OK or FAIL, indicating whether the requested command was successful or not. In the case of failure, the rest of the first line will contain a description of the problem that was encountered. Some commands include additional lines of information as described below.
Internationalization Note - The Manager application looks up its message strings in resource bundles, so it is possible that the strings have been translated for your platform. The examples below show the English version of the messages.
Deploy A New Application
http://localhost:8080/manager/deploy?path=/foo
Upload the web application archive (WAR) file that is specified as the request data in this HTTP PUT request, install it into the appBase directory of our corresponding virtual host, and start it on the context path specified by the path request parameter. The application can later be undeployed (and the corresponding application directory removed) by use of the /undeploy.
NOTE - Since this command requires an HTTP PUT request, it is usable only from tools (such as the custom Ant tasks described below). To install a new web application without copying, consider the /install command described below. This command is the logical opposite of the /undeploy command.
If installation and startup is successful, you will receive a response like this:
OK - Deployed application at context path /foo
Otherwise, the response will start with FAIL and include an error message. Possible causes for problems include:
Application already exists at path /foo
The context paths for all currently running web applications must be unique. Therefore, you must either remove or undeploy the existing web application using this context path, or choose a different context path for the new one.
Encountered exception
An exception was encountered trying to start the new web application. Check the Tomcat 4 logs for the details, but likely explanations include problems parsing your /WEB-INF/web.xml file, or missing classes encountered when initializing application event listeners and filters.
Invalid context path was specified
The context path must start with a slash character, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.
No context path was specified
The path parameter is required.
Install A New Application
http://localhost:8080/manager/install?path=/foo&war=file:/path/to/foo
http://localhost:8080/manager/install?path=/bar&war=jar:file:/path/to/bar.war!/
Install and start a new web application, attached to the specified context path (which must not be in use by any other web application). The war parameter specifies a URL (including the file: scheme) for either a directory or a web application archive (WAR) file. The supported syntax for a URL referring to a WAR file is described on the Javadocs page for the java.net.JarURLConnection class. Use only URLs that refer to the entire WAR file. This command is the logical opposite of the /remove command.
If installation and startup is successful, you will receive a response like this:
OK - Installed application at context path /foo
Otherwise, the response will start with FAIL and include an error message. Possible causes for problems include:
Application already exists at path /foo
The context paths for all currently running web applications must be unique. Therefore, you must either remove or undeploy the existing web application using this context path, or choose a different context path for the new one.
Document base does not exist or is not a readable directory
The URL specified by the war parameter must identify a directory on this server that contains the "unpacked" version of a web application, or the absolute URL of a web application archive (WAR) file that contains this application. Correct the value specified by the war parameter.
Encountered exception
An exception was encountered trying to start the new web application. Check the Tomcat 4 logs for the details, but likely explanations include problems parsing your /WEB-INF/web.xml file, or missing classes encountered when initializing application event listeners and filters.
Invalid application URL was specified
The URL for the directory or web application that you specified was not valid. Such URLs must start with file:, and URLs for a WAR file must end in ".war".
Invalid context path was specified
The context path must start with a slash character, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.
No context path was specified
The path parameter is required.
List Currently Deployed and Installed Applications
http://localhost:8080/manager/list
List the context paths, current status (running or stopped), and number of active sessions for all currently deployed and installed web applications. A typical response immediately after starting Tomcat might look like this:
OK - Listed applications for virtual host localhost
/webdav:running:0
/examples:running:0
/manager:running:0
/:running:0
Reload An Existing Application
http://localhost:8080/manager/reload?path=/examples
Signal an existing application to shut itself down and reload. This can be useful when you've recompiled classes on an application that is not configured with the reloadable="true" attribute in its <Context> entry in $CATALINA_HOME/conf/server.xml, or when you've made other changes (such as to conf/web.xml) that are not automatically recognized by Tomcat.
If this command succeeds, you will see a response like this:
OK - Reloaded application at context path /examples
Otherwise, the response will start with FAIL and include an error message. Possible causes for problems include:
Encountered exception
An exception was encountered trying to restart the web application. Check the Tomcat 4 logs for the details.
Invalid context path was specified
The context path must start with a slash character, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.
No context exists for path /foo
There is no deployed or installed application on the context path that you specified.
No context path was specified
The path parameter is required.
Reload note supported on WAR deployed at path /foo
Currently, application reloading (to pick up changes to the classes or web.xml file) is not supported when a web application is installed directly from a WAR file. It only works when the web application is installed from an unpacked directory. If you are using a WAR file, you should remove and then install the application again to pick up your changes.
Remove an Existing Application
http://localhost:8080/manager/remove?path=/examples
Signal an existing application to gracefully shut itself down, and then remove it from Tomcat (which also makes this context path available for reuse later). This command is the logical opposite of the /install command.
If this command succeeds, you will see a response like this:
OK - Removed application at context path /examples
Otherwise, the response will start with FAIL and include an error message. Possible causes for problems include:
Encountered exception
An exception was encountered trying to remove the web application. Check the Tomcat 4 logs for the details.
Invalid context path was specified
The context path must start with a slash character, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.
No context exists for path /foo
There is no deployed or installed application on the context path that you specified.
No context path was specified
The path parameter is required.
Session Statistics
http://localhost:8080/manager/sessions?path=/examples
Display the default session timeout for a web application, and the number of currently active sessions that fall within ten-minute ranges of their actual timeout times. For example, after restarting Tomcat and then executing one of the JSP samples in the /examples web app, you might get something like this:
OK - Session information for application at context path /examples
Default maximum session inactive interval 30 minutes
30 - <40 minutes:1 sessions
Start an Existing Application
http://localhost:8080/manager/start?path=/examples
Signal a stopped application to restart, and make itself available again. Stopping and starting is useful, for example, if the database required by your application becomes temporarily unavailable. It is usually better to stop the web application that relies on this database, rather than letting users continuously encounter database exceptions.
If this command succeeds, you will see a response like this:
OK - Started application at context path /examples
Otherwise, the response will start with FAIL and include an error message. Possible causes for problems include:
Encountered exception
An exception was encountered trying to start the web application. Check the Tomcat 4 logs for the details.
Invalid context path was specified
The context path must start with a slash character, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.
No context exists for path /foo
There is no deployed or installed application on the context path that you specified.
No context path was specified
The path parameter is required.
Stop an Existing Application
http://localhost:8080/manager/stop?path=/examples
Signal an existing application to make itself unavailable, but leave it deployed or installed. Any request that comes in while an application is stopped will see an HTTP error 404, and this application will show as "stopped" on a list applications command.
If this command succeeds, you will see a response like this:
OK - Stopped application at context path /examples
Otherwise, the response will start with FAIL and include an error message. Possible causes for problems include:
Encountered exception
An exception was encountered trying to stop the web application. Check the Tomcat 4 logs for the details.
Invalid context path was specified
The context path must start with a slash character, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.
No context exists for path /foo
There is no deployed or installed application on the context path that you specified.
No context path was specified
The path parameter is required.
Undeploy an Existing Application
http://localhost:8080/manager/undeploy?path=/examples
WARNING - This command will delete the contents of the web application directory if it exists within the appBase directory (typically "webapps") for this virtual host . If you simply want to take an application out of service, you should use the /remove command instead.
Signal an existing application to gracefully shut itself down, and remove it from Tomcat (which also makes this context path available for reuse later). In addition, the document root directory is removed, if it exists in the appBase directory (typically "webapps") for this virtual host. This command is the logical opposite of the /deploy command.
If this command succeeds, you will see a response like this:
OK - Undeployed application at context path /examples
Otherwise, the response will start with FAIL and include an error message. Possible causes for problems include:
Encountered exception
An exception was encountered trying to undeploy the web application. Check the Tomcat 4 logs for the details.
Invalid context path was specified
The context path must start with a slash character, unless you are referencing the ROOT web application -- in which case the context path must be a zero-length string.
No context exists for path /foo
There is no deployed or installed application on the context path that you specified.
No context path was specified
The path parameter is required.
Executing Manager Commands With Ant
In addition to the ability to execute Manager commands via HTTP requests, as documented above, Tomcat 4 includes a convenient set of Task definitions for the Ant (version 1.4 or later) build tool. In order to use these commands, you must perform the following setup operations:
Download the binary distribution of Ant from http://jakarta.apache.org/ant. You must use version 1.4 or later.
Install the Ant distribution in a convenient directory (called ANT_HOME in the remainder of these instructions).
Copy the file server/lib/catalina-ant.jar from your Tomcat 4 installation into Ant's library directory ($ANT_HOME/lib).
Add the $ANT_HOME/bin directory to your PATH environment variable.
Configure at least one username/password combination in your Tomcat user database that includes the manager role.
To use custom tasks within Ant, you must declare them first with a <taskdef> element. Therefore, your build.xml file might look something like this:
<project name="My Application" default="compile" basedir=".">
<-- Configure the directory into which the web application is built -->
<property name="build" value="${basedir}/build"/>
<-- Configure the context path for this application -->
<property name="path" value="/myapp"/>
<-- Configure properties to access the Manager application -->
<property name="url" value="http://localhost:8080/manager"/>
<property name="username" value="myusername"/>
<property name="password" value="mypassword"/>
<-- Configure the custom Ant tasks for the Manager application -->
<taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"/>
<taskdef name="install" classname="org.apache.catalina.ant.InstallTask"/>
<taskdef name="list" classname="org.apache.catalina.ant.ListTask"/>
<taskdef name="reload" classname="org.apache.catalina.ant.ReloadTask"/>
<taskdef name="remove" classname="org.apache.catalina.ant.RemoveTask"/>
<taskdef name="start" classname="org.apache.catalina.ant.StartTask"/>
<taskdef name="stop" classname="org.apache.catalina.ant.StopTask"/>
<taskdef name="undeploy" classname="org.apache.catalina.ant.UndeployTask"/>
<-- Executable Targets -->
<target name="compile" description="Compile web application">
... construct web application in ${build} subdirectory ...
</target>
<target name="install" description="Install web application"
depends="compile">
<install url="${url}" username="${username}" password="${password}"
path="${path}" war="file://${build}"/>
</target>
<target name="reload" description="Reload web application"
depends="compile">
<reload url="${url}" username="${username}" password="${password}"
path="${path}"/>
</target>
<target name="remove" description="Remove web application">
<remove url="${url}" username="${username}" password="${password}"
path="${path}"/>
</target>
</project>
Now, you can execute commands like ant install to install th applcation to a running instance of Tomcat, or ant reload to tell Tomcat to reload it. Note also that most of the interesting values in this build.xml file are defined as replaceable properties, so you can override their values from the command line. For example, you might consider it a security risk to include the real manager password in your build.xml file's source code. To avoid this, omit the password property, and specify it from the command line:
ant -Dpassword=secret deploy

Why server is not restarted when JSP is modified?

Hi,
Can anyone pls clarify the following -
Why we don't have to restart the webserver when we make changes to JSP file?
And in case of Servlet changes why do we have to restart the server?
Thanks in advance.

hi,
when you request that corresponding JSP file.. then it will convert into servlet coding and compile then its executed..
so no need to restart the web server
but if you modify the servlet, that changes will reflect while you restart the webserver only.. bcoz then only that new modified class will be handled by the webserver
Note: sometimes even that new (modified) file too will not updated.. at that time you have to delete all under tomcatx.x\work\localhost

LocateRegistry.getRegistry() fails when called from Tomcat 5.5 servlet

I'm trying to access a simple RMI server from a Tomcat 5.5 (Java 5) servlet. I get access exceptions having to do with java.util.logging.LoggingPermission. (The RMI server works fine with a simple command line Java app.)
Is there some reason that calling getRegistry() from within a servlet should fail? Is there some reason that it should require LoggingPermission?
I've modified the catalina.policy file to grant all permission to everything but I still get the same errors.
Surely there is a way to make RMI calls from a servlet. Any suggestions on how to fix this? Thanks.

show us the script

How to avoid restart weblogic after I modify EJB implementation class?

I am sure I redeploy my application after I modify EJB implementation class. It
is unacceptable to restart weblogic server if I changed some EJB . Is there any
way to avoid this?
Thanks!

I would open a case with BEA support. I would take a look at it, but I'm going
on vacation :(
pat
"CottonXu" <[email protected]> wrote:
>
My WLS version is 7.0 and I use weblogic console to redeploy the entire
application.
I am sure that EJBs are not in classpath.
What should I do ?
"Pat Bumpus" <[email protected]> wrote:
Hi,
I haven't seen this behavior. My EJBs seem to redeploy and pick upthe
EJB bean
changes. Make sure that your EJB is not in the system classpath that
could cause
this problem.
What version of WLS?
How are you deploying the EJB?
pat
"CottonXu" <[email protected]> wrote:
I am sure I redeploy my application after I modify EJB implementation
class. It
is unacceptable to restart weblogic server if I changed some EJB .
Is
there any
way to avoid this?
Thanks!

Tomcat 4.0,Servlet 2.3 and JSP1.2

Trying to figure out what to do with the Servlet 2.3 and JSP 1.2 zip files. Have the JDK 1.4 and Tomcat 4.0 already installed. Cant find any instructions at all on the java website on where to unzip the classes. JDK1.4/lib?Thanks in advance.

Thanks for the reply. So then where do the javax.* classes reside? How does the servlet.java file find the imported servlet classes when the pgm is compiled? Why is java such a PITA to get up and running? Sorry. I keep getting:
A Servlet Exception Has Occurred
org.apache.jasper.JasperException: Unable to compile class for JSPNote: sun.tools.javac.Main has been deprecated.
if (pageContext != null) pageContext.handlePageException(t);
when I try to run a .jsp with tomcat.

Web.xml Tomcat 5.0 Servlet problem

Hey guys....
The last time I used a servlet was before the new change in security in Tomcat. Ive been looking all over the net for some easy references about how they are to be mapped but no matter what I try nothing seems to work.
My servlet is located in ROOT\Admin\WEB-INF\classes\colt and is called AddOLO.class
My web.xml file is located in ROOT\Admin\WEB-INF and contains the following code:
<servlet>
<servlet-name>AddOLO</servlet-name>
<servlet-class>colt.AddOLO</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>AddOLO</servlet-name>
<url-pattern>/Admin/add</url-pattern>
</servlet-mapping>
On the HTML form invoking the Servlet (addOLO.html) Im using the following small piece of code
<form action="http://Colt/Admin/servlet/AddOLO" method="post" align="centre">
The server is operating on Port 80.
All I seem to be getting is a 404 Error Saying The requested resource (/Admin/servlet/AddOLO) is not available. Can anyone see what is wrong here?
Thanks in advance

I don't think there's anything to prohibit you from deploying servlets in ROOT, but webapps that have pages and servlets that work together should be in their own context. That's what you did when you created the directory under webapps. I think it's the right way to deploy web apps. Even better, learn how to create and deploy WAR files:
http://access1.sun.com/techarticles/simple.WAR.html
Once you have a WAR, which is simply a JAR'd version of the directory you just created under webapps, you can simply pick it up and deploy it by dropping it into the webapps directory of any Tomcat server. Tomcat will unpack it for you. - MOD

Help regarding Tomcat - execution of my application

Hi All,
I have developed an Online Banking system. But its giving an error when I am trying to execute it.
Package name is 'com'.
I have placed the code in the following manner.
Apache Tomcat 4.0->webapps->com->WEB-INF->java->com
1st com folder is tha main folder, this com has folder html, jsp and WEB-INF.
html folder has .html files, jsp folder has .jsp files.
WEB-INF has 1 folder java and web.xml file.
java folder has a folder com, this com has .class files and in the java folders there are .java files.
When I try to execute a functonality AddCustomer its giving an error :
'error in compiling AddCustomer.jsp , package com does not exist'
Please help in this regard. What might be the reason for error.
Thanks,
Saher

Apache Tomcat 4.0->webapps->com->WEB-INF->java->comLooks like you have 'java' directory under WEB-INF and you have kept you classes in 'java' directory.
You must place your classes in WEB-INF/classes directory. If you have a class LoginHelper in package com.onlinebank then the structure will look like:
Apache Tomcat 4.0->webapps->com->WEB-INF->classes->com->onlinebank->LoginHelper.
Though 'com' is a valid root directory name of any web application, but I suggest you give an appropriate name of your online banking web application.
Thanks,
Mrityunjoy

Regarding TOmcat Restart evertime servlet is modified

Similar Messages

Maybe you are looking for