Thursday, December 28, 2006

Virtual host redirection in tomcat



Go to install_dir/webapps/ROOT/WEB-INF, right-click on the classes directory, and select Copy. Then go to your development directory, right-click, and select Paste Shortcut (not just Paste). Note that if you use my preconfigured Jakarta Tomcat version, this shortcut is already in your C:\Servlets+JSP directory. Now, whenever you compile a packageless servlet, just drag the class files onto the shortcut. When you develop in packages, use the right mouse to drag the entire package directory (e.g., the coreservlets directory) onto the shortcut, release the mouse, and select Copy. On Unix/Linux, you can use symbolic links (created with ln -s) in a manner similar to that for Windows shortcuts.

An advantage of this approach is that it is simple. So, it is good for beginners who want to concentrate on learning servlets and JSP, not deployment tools. Another advantage is that a variation applies once you start using your own Web applications. (See Chapters 4-6 of More Servlets and JSP for details on Web applications). For instance, with Tomcat, you can easily make your own Web application by putting a copy of the install_dir/webapps/ROOT directory into your development directory and renaming it (for example, to testApp). Now, to deploy your Web application, just make a shortcut to install_dir/webapps and copy the entire Web application directory (e.g., testApp) each time by using the right mouse to drag the directory that contains your Web application onto this shortcut and selecting Copy (say Yes when asked if you want to replace existing files). The URL stays almost the same as it was without Web applications: just insert the name of the directory after the hostname (e.g., replace http://localhost/blah/blah with http:/localhost/testApp/blah/blah).

Note that the preconfigured Tomcat version already contains all the test files, has shortcuts from the development directory to the deployment locations, and has shortcuts to start and stop the server.

One disadvantage of this approach is that it requires repeated copying if you use multiple servers. For example, I usually have Apache Tomcat, Macromedia JRun, and Caucho Resin on my desktop system and regularly test my code with all three servers. A second disadvantage is that this approach copies both the Java source code files and the class files to the server, whereas only the class files are needed. This does not matter on your desktop development server, but when you get to the "real" deployment server, you won't want to include the source code files.

Monday, December 25, 2006

Free ceilo hosted in source forge

My  first FOSS project _ Free Ceilo _ hosted in sourceforge
freeceilo.sourceforge.net

Wednesday, December 20, 2006

HowToCreateYourOwnGNULinuxDistribution

As part of creating gNewSense, we created our Builder which allows for the creation of a new GNU/Linux distribution based on Ubuntu Dapper. From a simple config file you can choose the name of your distribution, release, tagline and what packages you'd like to be installed/removed by default. Graphics will be automatically generated. These scripts are obviously biased towards producing gNewSense, but should provide a good base to work off.

You'll need at least 35GB of free disk space, and preferably a very fast internet connection (you'll be pulling 27GB of data). You'll also need about 28GB of space on your mirror (which can be the same system). If you're smart with hardlinks you should be able to avoid some of the duplication. This should be run on a Ubuntu Dapper system without any updates (security or otherwise). Source repositories will need to be enabled. It is possible to downgrade to this state - see Removing Updated Pacakges.

If you have any queries, please drop into our IRC channel. This is still very much beta software, I haven't done a rebuild from scratch in a long time and the code has changed a good bit since.

Step 1: GPG key

More recent verions of apt require GPG signed release files in a repository to ensure the integrity of the distribution, so our first step is to create a GPG key.

 gpg --gen-key

will let you do this. Make sure the key has a blank password. Take a note of the fingerprint of the key as you'll need it later for the config file.

Finally, you'll need to add the public key to root's keyring.

Step 2: Packages

You'll need a number of packages for the Builder to run properly.

 apt-get install reprepro imagemagick debmirror build-essential apache2 subversion cdebootstrap 
apt-get install squashfs-tools netpbm syslinux bittornado
apt-get build-dep linux-image-$(uname -r) ubiquity update-manager ubuntu-artwork base-files ubuntu-meta
apt-get build-dep launchpad-integration grub system-tools-backends example-content gnome-panel
apt-get build-dep gnome-app-install
svn co http://svn.gnewsense.svnhopper.net/gnewsense/builder/trunk builder
sudo ./fixup-kernel-wedge

There's undoubtably packages missing from this, please let me know.

Step 3: Debmirror (optional)

To avoid having to redownload files, I suggest creating a mirror of Ubuntu main and universe. This will take an additional 27GB.

 debmirror --nocleanup --verbose --progress --method=http --host=ie.archive.ubuntu.com --arch=i386 \
--source --dist=dapper,dapper-security,dapper-updates,dapper-backports --section=main,main/debian-installer,universe --ignore-release-gpg \
--root=ubuntu /the/target/directory

You'll also need to setup apache so you can get to the mirror via HTTP over localhost. This step is optional, but it is strongly reccommended to have a local Ubuntu mirror (for some value of local).

Step 4: Configuration

cd into the builder directory you created earlier and open the config file in a text editor. The settings you need to worry about are MIRROR, RELEASE, DISTRONAME, DOMAIN, BASEDIR, and REPOAPT.

MIRROR is either the mirror you setup in step 3, or an Ubuntu mirror. It should contain the security packages. MIRRORDIST is the distribution in the mirror, usually 'dapper'.

DISTRONAME is what you want to call your distribution, similaraly RELEASE is the name of your release. Your release should be all lowercase as it will appear in paths. LOGOLETTER is the letter that will be your logo, while TAGLINE is used in the bootsplash and login screnn. SIGNINGKEY is your GPG fingerprint from step 1, it should not contain any spaces.

DOMAIN is used to create the default sources.list when installing. We assume an Ubuntu-like setup where you have archive.DOMAIN and security.DOMAIN and subdomains for all the country codes.

BASEDIR is the directory under which the repository, livecd and temporary files will be put. REPOAPT is where the build scripts will pull packages from, so you should setup apache to serve the REPODST directory ($BASEDIR/(lowercase distribution name)).

META_*_{ADD,REMOVE} control what packages you'd like added and removed from the ubuntu-meta package when your meta packages are being created.

*_VERSION are the numbers appended to created packages versions. You will need to increment these every time you rebuild a package. You will probably want to set these all to 1 when starting.

RSYNC_DEST is where the generated repo and livecds should be rsynced to by a push-repo or push-cd.

Step 5: Generate the repository

 ./gen-repo && ./do-update

This will take a while. The repository will possibly be in an inconsistant state while this is running, which is why you only push your changes to a mirror in Step 7. Every time there's new versions upstream (e.g. security updates) re-run do-update (and debmirror if needed).

Step 6: Generate the LiveCD

 sudo ./gen-livecd

The created image will be placed in $LIVECDDIR/$DISTRONAME_L-livecd-$LIVECD_VERSION.iso

 ./gen-cdsource
./stage-cd

Will prepare a source tarball and push the iso to $REPODST/cdimage

Step 7: Push your repository to a mirror and publicise

You can now publish your repository (the dists and pool) directories as well as your LiveCD to your mirror and publicise your new distribution to the world.

 ./push-repo
./push-cd

Saturday, December 16, 2006

Friday, December 15, 2006

mysql user addition

mysql>use mysql;
mysql> insert into user  values("localhost","saj",password("saj123"));
mysql>grant all privilages on *.* to 'saj'@'localhost' identified by 'saj123' with grant option;

telnet smtp communication

root@Linux:/> telnet mail.somedomain.com 25
Trying 10.10.10.10...
Connected to mail.somedomain.com.
Escape character is '^]'.
220 mail.somedomain.com ESMTP Exim 4.04 Wed, 13 Nov 2002 16:27:42 -0700
HELO mail.someotherdomain.com
250 mail.somedomain.com Hello mail.someotherdomain.com [10.10.10.20]
MAIL FROM:<Jim@someotherdomain.com >
250 OK
RCPT TO:<Joe@somedomain.com>
250 OK
DATA
354 Enter message, ending with "." on a line by itself
Subject:Test Message
This is a test message.
.

250 OK: queued as 18C6vd0005Ey-00
QUIT
221 mailhub.somedomain.com closing connection
Connection closed by foreign host

Tuesday, December 12, 2006

TOMCAT TUTOR

Introduction

Following is a summary of how you would install and configure Tomcat 4 for use as a standalone Web server that supports servlets 2.3 and JSP 1.2. Integrating Tomcat as a plugin within the regular Apache server or a commercial Web server is more complicated (for details, see http://jakarta.apache.org/tomcat/tomcat-4.0-doc/).

Integrating Tomcat with a regular Web server is valuable for a deployment scenario, but my goal here is to show how to use Tomcat as a development server on your desktop. Regardless of what deployment server you use, you'll want a standalone server on your desktop to use for development.

The examples here assume you are using Windows, but they can be easily adapted for Solaris, Linux, and other versions of Unix. I've gotten reports of successful use on MacOS X, but don't know the setup details. Except when I refer to specific Windows paths (e.g., C:\blah\blah), I use URL-style forward slashes for path separators (install_dir/webapps/ROOT). Adapt as necessary.

The information here is adapted from More Servlets and JavaServer Pages from Sun Microsystems Press. For the book table of contents, index, source code, and information on basic and advanced servlet and JSP short courses, please see http://www.moreservlets.com/. To report errors or omissions in this writeup, please contact Marty at hall@coreservlets.com.

Executive Summary

I give extremely detailed instructions in the following sections. If you're pretty experienced and just want a short summary, this section will probably be enough for you.

  1. Install the JDK. Make sure you have JDK 1.3 or 1.4 installed.
  2. Configure Tomcat.
    1. Download the software. Go to http://jakarta.apache.org/builds/jakarta-tomcat-4.0/release/ and download and unpack the zip file for the latest version.
    2. Change the port to 80. Edit install_dir/conf/server.xml and change the port attribute of the Connector element from 8080 to 80.
    3. Turn on servlet reloading. Edit install_dir/conf/server.xml and add a DefaultContext subelement to the main Service element and supply true for the reloadable attribute.
    4. Set the JAVA_HOME variable. Set it to refer to the base JDK directory, not the bin subdirectory.
    5. Change the DOS memory settings. If you get an "Out of Environment Space" error message when you start the server, right-click on install_dir/bin/startup.bat, select Properties, select Memory, and change the Initial Environment entry from Auto to at least 2816. Repeat the process for install_dir/bin/shutdown.bat.
    6. Set the CATALINA_HOME variable. Optionally, set CATALINA_HOME to refer to the top-level Tomcat installation directory.
  3. Test the server.
    1. Verify that you can start the server. Double-click install_dir/bin/startup.bat and try accessing http://localhost/.
    2. Check that you can access your own HTML & JSP pages. Drop some simple HTML and JSP pages into install_dir/webapps/ROOT and access them with http://localhost/filename.
  4. Set up your development environment.
    1. Create a development directory. Put it anywhere except within the Tomcat installation hierarchy.
    2. Make shortcuts to the Tomcat startup & shutdown Scripts. Put shortcuts to install_dir/bin/startup.bat and install_dir/bin/shutdown.bat in your development directory and/or on your desktop.
    3. Set your CLASSPATH. Include the current directory ("."), install_dir/common/lib/servlet.jar, and the main development directory.
    4. Bookmark the servlet & JSP javadocs. Add install_dir/webapps/tomcat-docs/servletapi/index.html to your bookmarks/favorites list.
  5. Compile and test some simple Sservlets.
    1. Test a packageless servlet. Compile a simple servlet, put the .class file in install_dir/webapps/ROOT/WEB-INF/classes, and access it with http://localhost/servlet/ServletName.
    2. Test a servlet that uses packages. Compile the servlet, put the .class file in install_dir/webapps/ROOT/WEB-INF/classes/packageName, and access it with http://localhost/servlet/packageName.ServletName.
    3. Test a servlet that uses packages and utility classes. Follow the same procedure as the second step above. This third step verifies that the CLASSPATH includes the top level of your development directory.
  6. Establish a simplified deployment method.
    1. Copy to a shortcut. Make a shortcut to install_dir/webapps/ROOT. Copy packageless .class files directly there. With packages, copy the entire directory there.
    2. Use the -d option of javac. Use -d to tell Java where the deployment directory is.
    3. Let your IDE take care of deployment. Tell your IDE where the deployment directory is and let it copy the necessary files.
    4. Use ant or a similar tool. Use the Apache make-like tool to automate copying of files.


Friday, December 08, 2006

മലയാ‍ളം ബ്ളോുുഗ്

പ്രിയ സുൂഹ്രു ത്തുൂുക്കളേ
മലയാ‍ളം ബ്ളോുുഗ് ഇത്തിരി കഷ്ട പ്പാടാണ് മക്കളേ


IT IS A SAMPLE CHARSET



ൌൈാീൂബഹദജഡ‍ർഔഐഈഊഭങഘധഝഠഢഞ
ോേ്ിുപരകതചടർഓഏഅഇഉഫറഖഥഛഠ
െംമനവലവസ,.യർഎൺണൻഴളശഷൽ?

Thursday, December 07, 2006

apache-ant enviorment setting in linux


# vi /etc/profile.d/java.sh

and then add:

export JAVA_HOME=/usr/java/jdk
export ANT_HOME=/usr/local/apache-ant-1.6.5
export PATH=$PATH:$JAVA_HOME/bin:$ANT_HOME/bin



JDK and JRE File Structure


JDK Tools

This document gives an overview of the JDK directories and the files they contain. This page may also be used as a reference for the file structure of the JRE. To see the file structure of the Runtime Environment, just look at the description of the contents of the JDK's jre directory on this page. The file structure of the JRE is identical to that of the JDK's jre directory.

Development Files and Directories

This section describes the files and directories that are required to develop apps for the Java platform. (The directories that are not required include demos, Java source code, and C header files. They are discussed in the following section, Additional Files and Directories.) The following chart shows the most important directories:

              jdk1.5.0
    ___________|_________________
    | | |
    bin lib jre
    | | ________|__________
    java* tools.jar | |
    javac* dt.jar bin lib
    javap* | ________ ___|___ _________ ________ _______
    javah* java* | | | | | |
    javadoc* rt.jar ext security i386 applet fonts
    charsets.jar | / \
    localedata.jar server client

Assuming the JDK software is installed at /jdk1.5.0, here are some of the most important directories:

/jdk1.5.0
The root directory of the JDK software installation. Contains copyright, license, and README files. Also contains src.jar, the archive of source code for the Java 2 platform.

/jdk1.5.0/bin
The executables for all the development tools contained in the Java 2 JDK. The PATH environment variable should contain an entry for this directory. For more information on the tools, see the JDK Tools.

/jdk1.5.0/lib
Files used by the development tools. Includes tools.jar, which contains non-core classes for support of the tools and utilities in the JDK. Also includes dt.jar, the DesignTime archive of BeanInfo files that tell interactive development environments (IDE's) how to display the Java components and how to let the developer customize them for the application.

/jdk1.5.0/jre
The root directory of the Java runtime environment used by the JDK development tools. The runtime environment is an implementation of the Java 2 platform. This is the directory referred to by the java.home system property.

/jdk1.5.0/jre/bin
Executable files for tools and libraries used by the Java platform. The executable files are identical to files in /jdk1.5.0/bin. The java launcher tool serves as an application launcher, in place of the old jre tool that shipped with 1.1 versions of the JDK software. This directory does not need to be in the PATH environment variable.

/jdk1.5.0/jre/lib
Code libraries, property settings, and resource files used by the Java runtime environment. Includes:
  • rt.jar -- the bootstrap classes (the RunTime classes that comprise the Java platform's core API).
  • charsets.jar -- character-conversion classes.
Aside from the ext subdirectory (described below) there are several additional resource subdirectories not described here.

/jdk1.5.0/jre/lib/ext
Default installation directory for Extensions to the Java platform. This is where the JavaHelp jar file goes when it is installed, for example.
  • localedata.jar -- locale data for java.text and java.util.
/jdk1.5.0/jre/lib/security
Contains files used for security management. These include the security policy (java.policy) and security properties (java.security) files.

/jdk1.5.0/jre/lib/i386/client
Contains the .so file used by the Java HotSpot Client Virtual Machine, which is implemented with Java HotSpotTM technology. This is the default VM.

/jdk1.5.0/jre/lib/i386/server
Contains the .so file used by the Java HotSpot Server Virtual Machine.

/jdk1.5.0/jre/lib/applet
Jar files containing support classes for applets can be placed in the lib/applet/ directory. This reduces startup time for large applets by allowing applet classes to be pre-loaded from teh local file system by the applet class loader, providing the same protections as if they had been downloaded over the net.

/jdk1.5.0/jre/lib/fonts
Font files for use by platform.

Additional Files and Directories

This section describes the directory structure for the demos, Java source code, and C header files. Here is the directory structure:

                            jdk1.5.0
    ___________|__________ _________
    | | | |
    demo include src.jar man
    ___|___ _________ __________ ________
    | | | | |
    applets jfc jpda plugin jni

The additional files and directories shown above are:

/jdk1.5.0/src.jar
Archive containing source code for the Java 2 platform.

/jdk1.5.0/demo
Examples, with source code, that show you how to program for the Java platform.

/jdk1.5.0/demo/applets
Applets that can be used on a Web page.

/jdk1.5.0/demo/jfc
Examples that use Java 2DTM and JFC/Swing components.

/jdk1.5.0/demo/jpda
Examples of using the Java Platform Debugging Architecture. Includes source code for the javadt and jdb utilities.

/jdk1.5.0/demo/plugin
Demos for use with Java Plug-in product.

/jdk1.5.0/demo/jni
Example classes and C code that demonstrate access to poll(2) functionality from the Java 2 Platform.

/jdk1.5.0/include
C-language header files that support native-code programming using the Java Native Interface and the Java Virtual Machine Debugger Interface.

/jdk1.5.0/man
Contains troff-formatted man pages for the Java 2 JDK tools.