how to create a shortcut in program
Cut and paste the shortcut from that folder into the \Windows\Start Menu\Programs folder on your device. You can also then rename the shortcut if you want.
Wednesday, July 28, 2010
Monday, July 26, 2010
Java MIDP2.1和JAVA MIDP2.0的本质区别是什么啊?
MIDP 2.1 新特性
在经历了N长时间的等待之后，MIDP 2.1终于诞生并应用于实际的机型中，对于MIDP2.0的升级版本，我们没有看到太多的功能推进，而是看到了将MIDP2.0中的许多特性进行了强制化的规定，从而更加的标准性，在兼容MIDP2.0的同时，对于许多组件的规格和性能作出了明确的规定，只是我们最高兴看到的，尤其是对于Image的数个规定，让我们感到欣慰，因为对于不同的厂商，他们的手机对于图片等多媒体能力的支持是相差很大的，比如韩系的手机（三星，LG之流）对于多媒体的支持那不是一般的差，除了外形说的过去以外，我真的不知道韩系手机有什么过人之处，总体而言，韩系手机是标注的“金絮其外，败絮其中”，而且还买的贼TMD贵，坑害广大的勤劳的中国人们-_-!!!
目前，支持MIDP 2.1的手机主要是Nokia的（不愧是老大级的人物啊～），机型是Nokia 5610 XpressMusic、Nokia 5310 XpressMusic、Nokia 6555、Nokia 7500 Prism 、Nokia 7900 Prism、Nokia 6267、Nokia 6500 classic、Nokia 6500 slide 相信这些手机我们都是能看得到的（不是行货就是水货），MIDP标准的统一之路又跨进了一步了，不过，在我看过MIDP3.0之后，我觉得如果说MIDP3.0将来能够以比较快的速度普及的话，那比然是J2ME的又一个春天。
MIDP 2.1 新特性：
1、 一个TextField或一个TextBox的最小尺寸（存储容量）不能少于1000个字符
2、 LCDUI布局指令必须被遵循
3、 LayoutManager.insert()方法的行为必须依照以下的描述：insert(Layer,int)
描述：
Public void insert(javax.microedition.lcdui.game.Layer l,int index)
插入一个新的Layer对象到LayoutManager在指定的索引值
描述：
插入一个已经被添加到这个LayoutManager的Layer对象等于先使用LayoutManager.remove()方法删除它，再用insert()方法添加到特定的索引。在LayoutManager.remove()方法被调用前，抛出IndexOutOfBoundsException的情况被检查
参数：
Layer l：被插入的Layer对象
int Index：在被添加的新的Layer对象的索引值
异常抛出：NullPointerException：如果Layer对象为null
IndexOutOfBoundsException：如果索引值小于0。如果索引值大于已经被添加到LayoutManager中的Layer对象的数量且Layer对象不能被添加到这个LayoutManager中。如果索引值大于已经被添加到LayoutManager中的Layer对象的数量且Layer对象已经被添加到这个LayoutManager中
4、 一个带有item Command对象且表示模式是Item.PLAIN的StringTtem对象必须总是被作为添加了Command对象且表示模式是Item.HYPERLINK的StringTtem对象的方式显示
5、 许多的MIDP LUDUI图像组件能包含文本（换句话说，一个字母数字字符），那被显示给用户。这些组件的例子是List, TextBox , Alert , StringItem ,Form和Item。一个实现常常需要截断这些可见的文本因为不能适合被给的UI组件的指定空间。在这种情况下，一个实现必须使用一个适当的可视化指示（例如一个省略符号）来指示用户，文本被截断。实际的符号或被用来显示截断的文本的符号以来于当前设备选择的区域设置。然而，可视化指示应该和用在设备本地的UI的指示一致。
6、 Canvas的触摸事件必须被支持，如果基础硬件支持这个特色。在这种情况下，Canvas.hasPointerEvents()方法应该总是返回true。
7、 Canvas的触摸拖曳事件必须被支持，如果基础硬件支持这个特色。在这种情况下，Canvas.hasPointerEvents()方法应该总是返回true。
8、 Canvas的重复事件必须被支持。在这种情况下，Canvas.hasRepeatEvents()方法应该总是返回true。
9、 双缓冲图像必须被支持。在这种情况下，Canvas.isDoubleBuffered()方法应该总是返回true。
10、 不同的文本输入模式的可用性（例如：预言输入和仅仅是数字的输入）应该和Java和本地的应用程序相一致。这意味着，例如，如果预言输入文本模式在本地应用程序中可用，那也应该在Java应用程序中可用。
11、 Image对象的创建（不管格式）必须至少支持：尺寸等于（屏幕宽度）乘以（屏幕高度）乘以（以字节为单位的颜色深度）或262144比特（128×128×16比特＝32KB），无论哪一个更大。注意，一个Image对象的内在表现应该保持至少每个象素16字节的颜色/透明度数据
12、 每一个包括在字符串值的通过System.getProperty(“microedition.commports”)方法返回的串行端口名字必须可获取通过javax.microedition.io.CommConnection接口
12、 在每个协议，AllowedSender域必须匹配适当的输入事件的地址域。地址域的使用和语法和语意以来于协议。然而，地址和过滤器必须被比较通过精确的字符串匹配，在那里，字符串被一个接着一个字符的比较，字符需要正确地匹配通过两个通配符
13、 以下地网络通信协议必须被支持，提供了以下Java ME接口的实现：javax.microedition.io.SockerConnection , javax.microedition.io.SecureConnection, javax.microedition.io.HttpsConnection
14、 javax.microedition.io.HttpsConnection和javax.microedition.io.SecureConnection必须支持SSLv3协议，其它的，例如TLS,WTLS也许被支持。
15、 应用程序描述符应该包含MIDlet-Permissions
16、 以下的JAD/manifest文件属性被定义来支持指定预期的运行时执行环境：Runtime-Execution-Environment：这是一个可选的属性，指出了应用程序必须的运行时执行环境。这个属性也许有值MIDP.CLDC.如果MIDlet suite不指定属性，隐含的默认值是MIDP.CLDC。当值是MIDP.CLDC，实现的行为必须坚持在以下显示的更多的细节描述。这个属性值的附加值被在将来定义。手机实现必须支持这个属性。当值是MIDP.CLDC，实现的行为必须坚持以下要求：1、支持API和API行为，以及基础虚拟机，必须顺从CLDC1.1规范。2、手机实现也许二选一地使用Java ME的CDC规范。然而，如果CDC被用作基础配置，运行在这个平台顶端的应用程序必须看见一个语义学和功能上等于CLDC1.1平台的环境。CDC特定的API或者CDC特定行为必须不能被暴露给应用程序或应用程序开发者。3、当一个应用程序定义了Runtime-Execution-Environment属性值，应用程序必须也定义一个CLDC平台在MicroEdition-Configuration属性值中。4、如果一个应用程序定义了不被实现支持的Runtime-Execution-Environment属性值或MicroEdition-Configuration属性值，应用程序不能被安装。所有的手机实现必须支持MIDP.CLDC值对于Runtime-Execution-Environment属性。
17、 用户使用OTA下载安装之后，实现必须提示用户是否启动MIDlet
18、 实现必须允许MIDlet创建最小为10个的线程
19、 支持至少512个属性
20、 支持MIDlet suite包含1到5个MIDlet
21、 每个MIDlet suite的RMS至少保证64K的空间，在内存足够的情况下
22、 每个MIDlet suite至少可以创建10个独立记录存储
23、 MIDP的MMAPI的子集必须遵守MMAPI1.1或以后版本
24、 MicroEdition.profiles系统属性不能包含相同profile的不同的版本
25、 Image对象中ISO/IEC JPEG和JFIF被支持
26、 支持载入深度为1、2、4、8、16和32位的PNG格式
27、 TextBox和TextField的约束TextField.EMAILDDR和TextField.URL必须允许相同的字符被输入如同被允许输入在TextField.ANY约束下
28、 适合的设备必须实现基于时间的推注册，如果没有其它的安全机制基于时间的推注册不需要被显式的用户的许可
Sunday, July 25, 2010
如何在Java ME平台上获取手机串号
本文系转载,证实S40确实无法获得IMEI(没有签名,也没有保错,返回null),se测试可以,5800I可以(不用签名),WM暂时没有找到任何方法.
注意：在Java ME平台上获取手机串号，在某些手机中是可行的，但是某些手机中就是无法获取的。对于即便是可以获取串号的手机来说，也仅仅限于进行了签名的应用程序才可以获得手机串号。
在诺基亚手机中，我们可以这样获取手机串号： System.getProperty("com.nokia.mid.imei")
在Series60平台的手几种，这样的获取串号操作需要你的应用程序被认证为网络运营商信任的应用程序或者手机生产商信任的应用程序，并且只有在 Series40第三版功能包1之后的手机设备中才能够使用。 On Series 40 phones this requires that your midlet is signed to either operator or manufacturer domain, and this is only available Series 40 3rd Edition FP1 devices and newer.
在S60平台，有些S60第三版的手机已经实现了这样的功能，如E60，E61，E62，但是不包括3250和5500。对于S60平台，获取串号并不需要签名认证。
在西门子手机中，我们可以这样获取传号： System.getProperty("com.siemens.IMEI")
其他手机:
三星: System.getProperty("com.samsung.imei");
索尼爱立信: System.getProperty("com.sonyericsson.imei");
摩托罗拉: System.getProperty("IMEI" );
诺基亚: System.getProperty("phone.imei");
System.getProperty("com.nokia.IMEI");
注意：在Java ME平台上获取手机串号，在某些手机中是可行的，但是某些手机中就是无法获取的。对于即便是可以获取串号的手机来说，也仅仅限于进行了签名的应用程序才可以获得手机串号。
在诺基亚手机中，我们可以这样获取手机串号： System.getProperty("com.nokia.mid.imei")
在Series60平台的手几种，这样的获取串号操作需要你的应用程序被认证为网络运营商信任的应用程序或者手机生产商信任的应用程序，并且只有在 Series40第三版功能包1之后的手机设备中才能够使用。 On Series 40 phones this requires that your midlet is signed to either operator or manufacturer domain, and this is only available Series 40 3rd Edition FP1 devices and newer.
在S60平台，有些S60第三版的手机已经实现了这样的功能，如E60，E61，E62，但是不包括3250和5500。对于S60平台，获取串号并不需要签名认证。
在西门子手机中，我们可以这样获取传号： System.getProperty("com.siemens.IMEI")
其他手机:
三星: System.getProperty("com.samsung.imei");
索尼爱立信: System.getProperty("com.sonyericsson.imei");
摩托罗拉: System.getProperty("IMEI" );
诺基亚: System.getProperty("phone.imei");
System.getProperty("com.nokia.IMEI");
Thursday, July 22, 2010
Setting http Proxy for Java Application
There are 2 main ways to set/configure http proxy in your java application.
* As a command line option when invoking the VM
* Using the System.setProperty(String, String) in your code
There are 3 properties you can set to specify the proxy that will be used by the http protocol handler:
* http.proxyHost: the host name of the proxy server
* http.proxyPort: the port number, the default value being 80
* http.nonProxyHosts: a list of hosts that should be reached directly, bypassing the proxy
Example of using command line option to set proxy configuration on java
java -Dhttp.proxyHost=webcache.mydomain.com -Dhttp.proxyPort=8080
-Dhttp.noProxyHosts=”localhost|host.mydomain.com” YourAppMainClass
Example of using code to configure proxy setting on java
//Set the http proxy to webcache.mydomain.com:8080
System.setProperty("http.proxyHost", "webcache.mydomain.com");
System.setPropery("http.proxyPort", "8080");
// Next connection will be through proxy.
There are other proxy settings that you can set as well such as https, ftp, socks.
More resources:
http://java.sun.com/javase/6/docs/technotes/guides/net/proxies.html
* As a command line option when invoking the VM
* Using the System.setProperty(String, String) in your code
There are 3 properties you can set to specify the proxy that will be used by the http protocol handler:
* http.proxyHost: the host name of the proxy server
* http.proxyPort: the port number, the default value being 80
* http.nonProxyHosts: a list of hosts that should be reached directly, bypassing the proxy
Example of using command line option to set proxy configuration on java
java -Dhttp.proxyHost=webcache.mydomain.com -Dhttp.proxyPort=8080
-Dhttp.noProxyHosts=”localhost|host.mydomain.com” YourAppMainClass
Example of using code to configure proxy setting on java
//Set the http proxy to webcache.mydomain.com:8080
System.setProperty("http.proxyHost", "webcache.mydomain.com");
System.setPropery("http.proxyPort", "8080");
// Next connection will be through proxy.
There are other proxy settings that you can set as well such as https, ftp, socks.
More resources:
http://java.sun.com/javase/6/docs/technotes/guides/net/proxies.html
Tuesday, July 20, 2010
Thursday, July 15, 2010
Top Ten Tomcat Configuration Tips
1. Configuring the Admin Web Application
Most commercial J2EE servers provide a fully functional administrative interface, and many of these are accessible as web applications. The Tomcat Admin application is on its way to becoming a full-blown Tomcat administration tool rivaling these commercial offerings. First included in Tomcat 4.1, Admin already provides control over contexts, data sources, and users and groups. You can also control resources such as initialization parameters, as well as users, groups, and roles in a variety of user databases. The list of capabilities will be expanded upon in future releases, but the present implementation has proven itself to be quite useful.
The Admin web application is defined in the auto-deployment file CATALINA_BASE/webapps/admin.xml.
You must edit this file to ensure that the path specified in the docBase attribute of the Context element is absolute; that is, the absolute path of CATALINA_HOME/server/webapps/admin. Alternatively, you could just remove the auto-deployment file and specify the Admin context manually in your server.xml file. On machines that will not be managed by this application, you should probably disable it altogether by simply removing CATALINA_BASE/webapps/admin.xml.
If you're using a UserDatabaseRealm (the default), you'll need to add a user and a role to the CATALINA_BASE/conf/tomcat-users.xml file. For now, just edit this file, and add a role named "admin" to your users database:
You must also have a user who is assigned to the "admin" role. Add a user line like this after the existing user entries (changing the password to something a bit more secure):
Once you've performed these steps and restarted Tomcat, visit the URL http://localhost:8080/admin, and you should see a login screen. The Admin application is built using container-managed security and the Jakarta Struts framework. Once you have logged in as a user assigned to the admin role, you will be able to use the Admin application to configure Tomcat.
2. Configuring the Manager Web Application
The Manager web application lets you perform simple management tasks on your web applications through a more simplified web user interface than that of the Admin web app.
The Manager web application is defined in the auto-deployment file CATALINA_BASE/webapps/manager.xml.
You must edit this file to ensure that the path specified in the docBase attribute of the Context element is absolute; that is, the absolute path of CATALINA_HOME/server/webapps/manager.
If you're using the default UserDatabaseRealm, you'll need to add a user and role to the CATALINA_BASE/conf/tomcat-users.xml file. For now, just edit this file, and add a role named "manager" to your users database:
You must also have a user who is assigned the "manager" role. Add a user line like this after the existing user entries (changing the password to something a bit more secure):
Then restart Tomcat and visit the URL http://localhost/manager/list to see the plain-text manager interface, or http://localhost/manager/html/list for the simple HTML manager interface. Either way, your Manager application should now be working.
The Manager application lets you install new web applications on a non-persistent basis, for testing. If we have a web application in /home/user/hello and want to test it by installing it under the URI /hello, we put "/hello" in the first text input field (for Path) and "file:/home/user/hello" in the second text input field (for Config URL).
The Manager also allows you to stop, reload, remove, or undeploy a web application. Stopping an application makes it unavailable until further notice, but of course it can then be restarted. Users attempting to access a stopped application will receive an error message, such as 503 - This application is not currently available.
Removing a web application removes it only from the running copy of Tomcat -- if it was started from the configuration files, it will reappear the next time you restart Tomcat (i.e., removal does not remove the web application's content from disk).
3. Deploying a Web Application
There are two ways of deploying a web application on the filesystem:
1. Copy your WAR file or your web application's directory (including all of its content) to the $CATALINA_BASE/webapps directory.
2. Create an XML fragment file with just the Context element for your web application, and place this XML file in $CATALINA_BASE/webapps. The web application itself can then be stored anywhere on your filesystem.
If you have a WAR file, you can deploy it by simply copying the WAR file into the directory CATALINA_BASE/webapps. The filename must end with an extension of ".war". Once Tomcat notices the file, it will (by default) unpack it into a subdirectory with the base name of the WAR file. It will then create a context in memory, just as though you had created one by editing Tomcat's server.xml file. However, any necessary defaults will be obtained from the DefaultContext element in Tomcat's server.xml file.
Another way to deploy a web app is by writing a Context XML fragment file and deploying it into the CATALINA_BASE/webapps directory. A context fragment is not a complete XML document, but just one Context element and any subelements that are appropriate for your web application. These files are like Context elements cut out of the server.xml file, hence the name "context fragment."
For example, if we wanted to deploy the WAR file MyWebApp.war along with a realm for accessing parts of that web application, we could use this fragment:
Put that in a file called "MyWebApp.xml," and copy it into your CATALINA_BASE/webapps directory.
These context fragments provide a convenient method of deploying web applications; you do not need to edit the server.xml file and, unless you have turned off the default liveDeploy feature, you don't have to restart Tomcat to install a new web application.
4. Configuring Virtual Hosts
The Host element normally needs modification only when you are setting up virtual hosts. Virtual hosting is a mechanism whereby one web server process can serve multiple domain names, giving each domain the appearance of having its own server. In fact, the majority of small business web sites are implemented as virtual hosts, due to the expense of connecting a computer directly to the Internet with sufficient bandwidth to provide reasonable response times and the stability of a permanent IP address.
Name-based virtual hosting is created on any web server by establishing an aliased IP address in the Domain Name Service (DNS) data and telling the web server to map all requests destined for the aliased address to a particular directory of web pages. Since this article is about Tomcat, we don't try to show all of the ways to set up DNS data on various operating systems. If you need help with this, please refer to DNS and Bind, by Paul Albitz and Cricket Liu (O'Reilly). For demonstration purposes, I'll use a static hosts file, since that's the easiest way to set up aliases for testing purposes.
To use virtual hosts in Tomcat, you just need to set up the DNS or hosts data for the host. For testing, making an IP alias for localhost is sufficient. You then need to add a few lines to the server.xml configuration file:
Tomcat's server.xml file, as distributed, contains only one virtual host, but it is easy to add support for additional virtual hosts. The simplified version of the server.xml file in the previous example shows in bold the overall additional structure needed to add one virtual host. Each Host element must have one or more Context elements within it; one of these must be the default Context for this host, which is specified by having its relative path set to the empty string (for example, path="").
5. Configuring Basic Authentication
Container-managed authentication methods control how a user's credentials are verified when a web app's protected resource is accessed. When a web application uses basic authentication (BASIC in the web.xml file's auth-method element), Tomcat uses HTTP basic authentication to ask the web browser for a username and password whenever the browser requests a resource of that protected web application. With this authentication method, all passwords are sent across the network in base64-encoded text.
Note: using basic authentication is generally considered insecure because it does not strongly encrypt passwords, unless the site also uses HTTPS or some other form of encryption between the client and the server (for instance, a virtual private network). Without this extra encryption, network monitors can intercept (and misuse) users' passwords. But, if you're just starting to use Tomcat, or if you just want to test container-managed security with your web app, basic authentication is easy to set up and test. Just add and elements to your web app's web.xml file, and add the appropriate and elements to your CATALINA_BASE/conf/tomcat-users.xml file, restart Tomcat, and Tomcat takes care of the rest.
The example below shows a web.xml excerpt from a club membership web site with a members-only subdirectory that is protected using basic authentication. Note that this effectively takes the place of the Apache web server's .htaccess files.
Entire Application
/members/*
member
BASIC
My Club Members-only Area
6. Configuring Single Sign-On
Once you've set up your realm and method of authentication, you'll need to deal with the actual process of logging the user in. More often than not, logging into an application is a nuisance to an end user, and you will need to minimize the number of times they must authenticate. By default, each web application will ask the user to log in the first time the user requests a protected resource. This can seem like a hassle to your users if you run multiple web applications and each application asks the user to authenticate. Users cannot tell how many separate applications make up any single web site, so they won't know when they're making a request that crosses a context boundary, and will wonder why they're being repeatedly asked to log in.
The "single sign-on" feature of Tomcat 4 allows a user to authenticate only once to access all of the web applications loaded under a virtual host. To use this feature, you need only add a SingleSignOn Valve element at the host level. This looks like the following:
The Tomcat distribution's default server.xml contains a commented-out single sign-on Valve configuration example that you can uncomment and use. Then, any user who is considered valid in a context within the configured virtual host will be considered valid in all other contexts for that same host.
There are several important restrictions for using the single sign-on valve:
The valve must be configured and nested within the same Host element that the web applications (represented by Context elements) are nested within.
The Realm that contains the shared user information must be configured either at the level of the same Host or in an outer nesting.
The Realm cannot be overridden at the Context level.
The web applications that use single sign-on must use one of Tomcat's built-in authenticators (in the element of web.xml), rather than a custom authenticator. The built-in methods are basic, digest, form, and client-cert authentication.
If you're using single sign-on and wish to integrate another third-party web application into your web site, and the new web application uses only its own authentication code that doesn't use container-managed security, you're basically stuck. Your users will have to log in once for all of the web applications that use single sign-on, and then once again if they make a request to the new third-party web application. Of course, if you get the source and you're a developer, you could fix it, but that's probably not so easy to do.
The single sign-on valve requires the use of HTTP cookies.
7. Configuring Customized User Directories
Some sites like to allow individual users to publish a directory of web pages on the server. For example, a university department might want to give each student a public area, or an ISP might make some web space available on one of its servers to customers that don't have a virtually hosted web server. In such cases, it is typical to use the tilde character (~) plus the user's name as the virtual path of that user's web site:
http://www.cs.myuniversity.edu/~username
http://members.mybigisp.com/~username
Tomcat gives you two ways to map this on a per-host basis, using a couple of special Listener elements. The Listener's className attribute should be org.apache.catalina.startup.UserConfig, with the userClass attribute specifying one of several mapping classes. If your system runs Unix, has a standard /etc/passwd file that is readable by the account running Tomcat, and that file specifies users' home directories, use the PasswdUserDatabase mapping class:
Web files would need to be in directories such as /home/users/ian/public_html or /users/jbrittain/public_html. Of course, you can change public_html to be whatever subdirectory into which your users put their personal web pages.
In fact, the directories don't have to be inside of a user's home directory at all. If you don't have a password file but want to map from a user name to a subdirectory of a common parent directory such as /home, use the HomesUserDatabase class:
In this case, web files would be in directories such as /home/ian/public_html or /home/jasonb/public_html. This format is more useful on Windows, where you'd likely use a directory such as C:\home.
These Listener elements, if present, must be inside of a Host element, but not inside of a Context element, as they apply to the Host itself.
8. Using CGI Scripts with Tomcat
Tomcat is primarily meant to be a servlet/JSP container, but it has many capabilities rivalling a traditional web server. One of these is support for the Common Gateway Interface (CGI), which provides a means for running an external program in response to a browser request, typically to process a web-based form. CGI is called "common" because it can invoke programs in almost any programming or scripting language: Perl, Python, awk, Unix shell scripting, and even Java are all supported options. However, you probably wouldn't run a Java application as a CGI due to the start-up overhead; elimination of this overhead was what led to the original design of the servlet specification. Servlets are almost always more efficient than CGIs because you're not starting up a new operating-system-level process every time somebody clicks on a link or button.
Tomcat includes an optional CGI servlet that allows you to run legacy CGI scripts; the assumption is that most new back-end processing will be done by user-defined servlets and JSPs.
To enable Tomcat's CGI servlet, you must do the following:
Rename the file servlets-cgi.renametojar (found in CATALINA_HOME/server/lib/) to servlets-cgi.jar, so that the servlet that processes CGI scripts will be on Tomcat's CLASSPATH.
In Tomcat's CATALINA_BASE/conf/web.xml file, uncomment the definition of the servlet named cgi (this is around line 241 in the distribution).
Also in Tomcat's web.xml, uncomment the servlet mapping for the cgi servlet (around line 299 in the distributed file). Remember, this specifies the HTML links to the CGI script.
Either place the CGI scripts under the WEB-INF/cgi directory (remember that WEB-INF is a safe place to hide things that you don't want the user to be able to view, for security reasons), or place them in some other directory within your context and adjust the cgiPathPrefix initialization parameter of the CGIServlet to identify the directory containing the files. This specifies the actual location of the CGI scripts, which typically will not be the same as the URL in the previous step.
Restart Tomcat, and your CGI processing should now be operational.
The default directory for the servlet to locate the actual scripts is WEB-INF/cgi. As has been noted, the WEB-INF directory is protected against casual snooping from browsers, so this is a good place to put CGI scripts, which may contain passwords or other sensitive information. For compatibility with other servers, though, you may prefer to keep the scripts in the traditional directory, /cgi-bin, but be aware that files in this directory may be viewable by the curious web surfer. Also, on Unix, be sure that the CGI script files are executable by the user under which you are running Tomcat.
9. Changing Tomcat's JSP Compiler
In Tomcat 4.1 (and above, presumably), compilation of JSPs is performed by using the Ant program controller directly from within Tomcat. This sounds a bit strange, but it's part of what Ant was intended for; there is a documented API that lets developers use Ant without starting up a new JVM. This is one advantage of having Ant written in Java. Plus, it means you can now use any compiler supported by the javac task within Ant; these are listed in the javac page of the Apache Ant manual. It is easy to use because you need only an with a name of "compiler" and a value of one of the supported compiler names:
jsp
org.apache.jasper.servlet.JspServlet
logVerbosityLevel WARNING
compiler jikes
3
Of course, the given compiler must be installed on your system, and the CLASSPATH may need to be set, depending on which compiler you choose.
10. Restricting Access to Specific Hosts
Sometimes you'll only want to restrict access to Tomcat's web app to only specified host names or IP addresses. This way, only clients at those specified sites will be served content. Tomcat comes with two Valves that you can configure and use for this purpose: RemoteHostValve and RemoteAddrValve.
These Valves allow you to filter requests by host name or by IP address, and to allow or deny hosts that match, similar to the per-directory Allow/Deny directives in Apache httpd. If you run the Admin application, you might want to only allow access to it from localhost, as follows:
If no allow pattern is given, then patterns that match the deny attribute patterns will be rejected, and all others will be allowed. Similarly, if no deny pattern is given, patterns that match the allow attribute will be allowed, and all others will be denied.
Most commercial J2EE servers provide a fully functional administrative interface, and many of these are accessible as web applications. The Tomcat Admin application is on its way to becoming a full-blown Tomcat administration tool rivaling these commercial offerings. First included in Tomcat 4.1, Admin already provides control over contexts, data sources, and users and groups. You can also control resources such as initialization parameters, as well as users, groups, and roles in a variety of user databases. The list of capabilities will be expanded upon in future releases, but the present implementation has proven itself to be quite useful.
The Admin web application is defined in the auto-deployment file CATALINA_BASE/webapps/admin.xml.
You must edit this file to ensure that the path specified in the docBase attribute of the Context element is absolute; that is, the absolute path of CATALINA_HOME/server/webapps/admin. Alternatively, you could just remove the auto-deployment file and specify the Admin context manually in your server.xml file. On machines that will not be managed by this application, you should probably disable it altogether by simply removing CATALINA_BASE/webapps/admin.xml.
If you're using a UserDatabaseRealm (the default), you'll need to add a user and a role to the CATALINA_BASE/conf/tomcat-users.xml file. For now, just edit this file, and add a role named "admin" to your users database:
You must also have a user who is assigned to the "admin" role. Add a user line like this after the existing user entries (changing the password to something a bit more secure):
Once you've performed these steps and restarted Tomcat, visit the URL http://localhost:8080/admin, and you should see a login screen. The Admin application is built using container-managed security and the Jakarta Struts framework. Once you have logged in as a user assigned to the admin role, you will be able to use the Admin application to configure Tomcat.
2. Configuring the Manager Web Application
The Manager web application lets you perform simple management tasks on your web applications through a more simplified web user interface than that of the Admin web app.
The Manager web application is defined in the auto-deployment file CATALINA_BASE/webapps/manager.xml.
You must edit this file to ensure that the path specified in the docBase attribute of the Context element is absolute; that is, the absolute path of CATALINA_HOME/server/webapps/manager.
If you're using the default UserDatabaseRealm, you'll need to add a user and role to the CATALINA_BASE/conf/tomcat-users.xml file. For now, just edit this file, and add a role named "manager" to your users database:
You must also have a user who is assigned the "manager" role. Add a user line like this after the existing user entries (changing the password to something a bit more secure):
Then restart Tomcat and visit the URL http://localhost/manager/list to see the plain-text manager interface, or http://localhost/manager/html/list for the simple HTML manager interface. Either way, your Manager application should now be working.
The Manager application lets you install new web applications on a non-persistent basis, for testing. If we have a web application in /home/user/hello and want to test it by installing it under the URI /hello, we put "/hello" in the first text input field (for Path) and "file:/home/user/hello" in the second text input field (for Config URL).
The Manager also allows you to stop, reload, remove, or undeploy a web application. Stopping an application makes it unavailable until further notice, but of course it can then be restarted. Users attempting to access a stopped application will receive an error message, such as 503 - This application is not currently available.
Removing a web application removes it only from the running copy of Tomcat -- if it was started from the configuration files, it will reappear the next time you restart Tomcat (i.e., removal does not remove the web application's content from disk).
3. Deploying a Web Application
There are two ways of deploying a web application on the filesystem:
1. Copy your WAR file or your web application's directory (including all of its content) to the $CATALINA_BASE/webapps directory.
2. Create an XML fragment file with just the Context element for your web application, and place this XML file in $CATALINA_BASE/webapps. The web application itself can then be stored anywhere on your filesystem.
If you have a WAR file, you can deploy it by simply copying the WAR file into the directory CATALINA_BASE/webapps. The filename must end with an extension of ".war". Once Tomcat notices the file, it will (by default) unpack it into a subdirectory with the base name of the WAR file. It will then create a context in memory, just as though you had created one by editing Tomcat's server.xml file. However, any necessary defaults will be obtained from the DefaultContext element in Tomcat's server.xml file.
Another way to deploy a web app is by writing a Context XML fragment file and deploying it into the CATALINA_BASE/webapps directory. A context fragment is not a complete XML document, but just one Context element and any subelements that are appropriate for your web application. These files are like Context elements cut out of the server.xml file, hence the name "context fragment."
For example, if we wanted to deploy the WAR file MyWebApp.war along with a realm for accessing parts of that web application, we could use this fragment:
Put that in a file called "MyWebApp.xml," and copy it into your CATALINA_BASE/webapps directory.
These context fragments provide a convenient method of deploying web applications; you do not need to edit the server.xml file and, unless you have turned off the default liveDeploy feature, you don't have to restart Tomcat to install a new web application.
4. Configuring Virtual Hosts
The Host element normally needs modification only when you are setting up virtual hosts. Virtual hosting is a mechanism whereby one web server process can serve multiple domain names, giving each domain the appearance of having its own server. In fact, the majority of small business web sites are implemented as virtual hosts, due to the expense of connecting a computer directly to the Internet with sufficient bandwidth to provide reasonable response times and the stability of a permanent IP address.
Name-based virtual hosting is created on any web server by establishing an aliased IP address in the Domain Name Service (DNS) data and telling the web server to map all requests destined for the aliased address to a particular directory of web pages. Since this article is about Tomcat, we don't try to show all of the ways to set up DNS data on various operating systems. If you need help with this, please refer to DNS and Bind, by Paul Albitz and Cricket Liu (O'Reilly). For demonstration purposes, I'll use a static hosts file, since that's the easiest way to set up aliases for testing purposes.
To use virtual hosts in Tomcat, you just need to set up the DNS or hosts data for the host. For testing, making an IP alias for localhost is sufficient. You then need to add a few lines to the server.xml configuration file:
Tomcat's server.xml file, as distributed, contains only one virtual host, but it is easy to add support for additional virtual hosts. The simplified version of the server.xml file in the previous example shows in bold the overall additional structure needed to add one virtual host. Each Host element must have one or more Context elements within it; one of these must be the default Context for this host, which is specified by having its relative path set to the empty string (for example, path="").
5. Configuring Basic Authentication
Container-managed authentication methods control how a user's credentials are verified when a web app's protected resource is accessed. When a web application uses basic authentication (BASIC in the web.xml file's auth-method element), Tomcat uses HTTP basic authentication to ask the web browser for a username and password whenever the browser requests a resource of that protected web application. With this authentication method, all passwords are sent across the network in base64-encoded text.
Note: using basic authentication is generally considered insecure because it does not strongly encrypt passwords, unless the site also uses HTTPS or some other form of encryption between the client and the server (for instance, a virtual private network). Without this extra encryption, network monitors can intercept (and misuse) users' passwords. But, if you're just starting to use Tomcat, or if you just want to test container-managed security with your web app, basic authentication is easy to set up and test. Just add
The example below shows a web.xml excerpt from a club membership web site with a members-only subdirectory that is protected using basic authentication. Note that this effectively takes the place of the Apache web server's .htaccess files.
Entire Application
6. Configuring Single Sign-On
Once you've set up your realm and method of authentication, you'll need to deal with the actual process of logging the user in. More often than not, logging into an application is a nuisance to an end user, and you will need to minimize the number of times they must authenticate. By default, each web application will ask the user to log in the first time the user requests a protected resource. This can seem like a hassle to your users if you run multiple web applications and each application asks the user to authenticate. Users cannot tell how many separate applications make up any single web site, so they won't know when they're making a request that crosses a context boundary, and will wonder why they're being repeatedly asked to log in.
The "single sign-on" feature of Tomcat 4 allows a user to authenticate only once to access all of the web applications loaded under a virtual host. To use this feature, you need only add a SingleSignOn Valve element at the host level. This looks like the following:
The Tomcat distribution's default server.xml contains a commented-out single sign-on Valve configuration example that you can uncomment and use. Then, any user who is considered valid in a context within the configured virtual host will be considered valid in all other contexts for that same host.
There are several important restrictions for using the single sign-on valve:
The valve must be configured and nested within the same Host element that the web applications (represented by Context elements) are nested within.
The Realm that contains the shared user information must be configured either at the level of the same Host or in an outer nesting.
The Realm cannot be overridden at the Context level.
The web applications that use single sign-on must use one of Tomcat's built-in authenticators (in the
If you're using single sign-on and wish to integrate another third-party web application into your web site, and the new web application uses only its own authentication code that doesn't use container-managed security, you're basically stuck. Your users will have to log in once for all of the web applications that use single sign-on, and then once again if they make a request to the new third-party web application. Of course, if you get the source and you're a developer, you could fix it, but that's probably not so easy to do.
The single sign-on valve requires the use of HTTP cookies.
7. Configuring Customized User Directories
Some sites like to allow individual users to publish a directory of web pages on the server. For example, a university department might want to give each student a public area, or an ISP might make some web space available on one of its servers to customers that don't have a virtually hosted web server. In such cases, it is typical to use the tilde character (~) plus the user's name as the virtual path of that user's web site:
http://www.cs.myuniversity.edu/~username
http://members.mybigisp.com/~username
Tomcat gives you two ways to map this on a per-host basis, using a couple of special Listener elements. The Listener's className attribute should be org.apache.catalina.startup.UserConfig, with the userClass attribute specifying one of several mapping classes. If your system runs Unix, has a standard /etc/passwd file that is readable by the account running Tomcat, and that file specifies users' home directories, use the PasswdUserDatabase mapping class:
Web files would need to be in directories such as /home/users/ian/public_html or /users/jbrittain/public_html. Of course, you can change public_html to be whatever subdirectory into which your users put their personal web pages.
In fact, the directories don't have to be inside of a user's home directory at all. If you don't have a password file but want to map from a user name to a subdirectory of a common parent directory such as /home, use the HomesUserDatabase class:
In this case, web files would be in directories such as /home/ian/public_html or /home/jasonb/public_html. This format is more useful on Windows, where you'd likely use a directory such as C:\home.
These Listener elements, if present, must be inside of a Host element, but not inside of a Context element, as they apply to the Host itself.
8. Using CGI Scripts with Tomcat
Tomcat is primarily meant to be a servlet/JSP container, but it has many capabilities rivalling a traditional web server. One of these is support for the Common Gateway Interface (CGI), which provides a means for running an external program in response to a browser request, typically to process a web-based form. CGI is called "common" because it can invoke programs in almost any programming or scripting language: Perl, Python, awk, Unix shell scripting, and even Java are all supported options. However, you probably wouldn't run a Java application as a CGI due to the start-up overhead; elimination of this overhead was what led to the original design of the servlet specification. Servlets are almost always more efficient than CGIs because you're not starting up a new operating-system-level process every time somebody clicks on a link or button.
Tomcat includes an optional CGI servlet that allows you to run legacy CGI scripts; the assumption is that most new back-end processing will be done by user-defined servlets and JSPs.
To enable Tomcat's CGI servlet, you must do the following:
Rename the file servlets-cgi.renametojar (found in CATALINA_HOME/server/lib/) to servlets-cgi.jar, so that the servlet that processes CGI scripts will be on Tomcat's CLASSPATH.
In Tomcat's CATALINA_BASE/conf/web.xml file, uncomment the definition of the servlet named cgi (this is around line 241 in the distribution).
Also in Tomcat's web.xml, uncomment the servlet mapping for the cgi servlet (around line 299 in the distributed file). Remember, this specifies the HTML links to the CGI script.
Either place the CGI scripts under the WEB-INF/cgi directory (remember that WEB-INF is a safe place to hide things that you don't want the user to be able to view, for security reasons), or place them in some other directory within your context and adjust the cgiPathPrefix initialization parameter of the CGIServlet to identify the directory containing the files. This specifies the actual location of the CGI scripts, which typically will not be the same as the URL in the previous step.
Restart Tomcat, and your CGI processing should now be operational.
The default directory for the servlet to locate the actual scripts is WEB-INF/cgi. As has been noted, the WEB-INF directory is protected against casual snooping from browsers, so this is a good place to put CGI scripts, which may contain passwords or other sensitive information. For compatibility with other servers, though, you may prefer to keep the scripts in the traditional directory, /cgi-bin, but be aware that files in this directory may be viewable by the curious web surfer. Also, on Unix, be sure that the CGI script files are executable by the user under which you are running Tomcat.
9. Changing Tomcat's JSP Compiler
In Tomcat 4.1 (and above, presumably), compilation of JSPs is performed by using the Ant program controller directly from within Tomcat. This sounds a bit strange, but it's part of what Ant was intended for; there is a documented API that lets developers use Ant without starting up a new JVM. This is one advantage of having Ant written in Java. Plus, it means you can now use any compiler supported by the javac task within Ant; these are listed in the javac page of the Apache Ant manual. It is easy to use because you need only an
org.apache.jasper.servlet.JspServlet
Of course, the given compiler must be installed on your system, and the CLASSPATH may need to be set, depending on which compiler you choose.
10. Restricting Access to Specific Hosts
Sometimes you'll only want to restrict access to Tomcat's web app to only specified host names or IP addresses. This way, only clients at those specified sites will be served content. Tomcat comes with two Valves that you can configure and use for this purpose: RemoteHostValve and RemoteAddrValve.
These Valves allow you to filter requests by host name or by IP address, and to allow or deny hosts that match, similar to the per-directory Allow/Deny directives in Apache httpd. If you run the Admin application, you might want to only allow access to it from localhost, as follows:
If no allow pattern is given, then patterns that match the deny attribute patterns will be rejected, and all others will be allowed. Similarly, if no deny pattern is given, patterns that match the allow attribute will be allowed, and all others will be denied.
Subscribe to:
Posts (Atom)