1、先创建web project,项目名为Hello,

2、在WebRoot 目录下创建login.jsp文件,只需修改body中的内容,如下所示:



5、在WebRoot目录下编写success.jsp文件 成功后跳转

6、在WebRoot目录下编写fail.jsp文件 失败后跳转


Eclipse with Tomcat 7 on Ubuntu

Eclipse with Tomcat V7.0 in Ubuntu
1. Download Eclipse from the Eclipse web site. (J2EE version)
2. Download Tomcat version 7 or install it via apt-get
apt-get install tomcat7 tomcat7-admin tomcat7-common tomcat7-docs tomcat7-examples
3. Set the following configuration:

3. Run eclipse
4. Add a view ( Windows -> Show View -> Other -> Server -> Servers -> OK )
5. Go to the view
6. Add a Tomcat v7 (consider /user/share/tomcat7 as your path)
7. Enjoy Tomcat 7 in Eclipse.

Eclipse add Tomcat 7 blank server name

I was trying to add Tomcat 7 in my Eclipse in Ubuntu. When I click "Add new server" in Eclipse and select "Tomcat v7.0 Server", the field "Server Name" is blank and I cannot type in anything in that textbox as shown below:


It is a bug in Eclipse. I had exactly the same problem, also on Ubuntu with Eclipse Java EE Juno.

Here is the workaround that worked for me:

1.Close Eclipse
2.In {workspace-directory}/.metadata/.plugins/org.eclipse.core.runtime/.settings delete the following two files:
3.Restart Eclipse


将apache-tomcat-7.0.42.tar.gz 解压缩到目标目录

编辑 apache-tomcat-7.0.42/conf/tomcat-users.xml , 加入

設定好後執行 apache-tomcat-7.0.42/bin/startup.sh , 再使用browser連到http://localhost:8080, 如果可以看到以下画面, Tomcat Server的安裝算是初步完成

Apache Tomcat_7.0.42_Default_Page

設定Launchd主要讓Mac OS X server啟動時, 也順便啟動Tomcat Server, Launchd有點類似Windows的NT Service使用Launchd來啟動Tomcat Server

1.到 apache-tomcat-7.0.42/bin/目錄下新增一個檔案 launchd_wrapper.sh, 內容如下

请注意 ,launchd_wrapper.sh要使用


2. 加入tomcat for Launchd 文件, 到/Library/LaunchDaemons目录使用


3. 使用

, 编辑tomcat.plist, 文件內容如下, 要注意的是/Users/admin为安装目录, 请改成你的目录



测试OK后, 下次重新开机Tomcat Server就会自己执行了.




在浏览器里输入http://localhost或者是http://,如果看到了It works!,那就说明Apache就成功的安装了,Apache的默认安装,会在/var下建立一个名为www的目录,这个就是Web目录了,所有要能过浏览器访问的Web文件都要放到这个目录里。

步骤二 ,安装php:

此外,建议安装扩展php5-gd php5-mysql,安装方式同上.









在安装过程中会要求选择Web server:apache2或lighttpd,使用空格键选定apache2,按tab键然后确定。然后会要求输入设置的Mysql数据库密码连接密码Password of the database’s administrative user。

然后将phpmyadmin与apache2建立连接,以我的为例:www目录在/var/www,phpmyadmin在/usr/share /phpmyadmin目录,所以就用命令:







处理在64位Ubuntu使用jd-gui报错error while loading shared libraries: libgtk-x11-2.0.so.0

error while loading shared libraries: libgtk-x11-2.0.so.0


(Ubuntu 13.04 x64)

(Ubuntu 13.10 x64)

Ubuntu 下远程桌面rdesktop的安装及配置


其中-g 参数就是指定分辨率。因为我是1280*800 所以我使用1024*768的分辨率是正好的。你可以根据你的情况来调整分辨率,找到一个最佳值。

打开~/.bashrc 这个文件。在里面可以添加别名(写在最后面就可以了):

关闭终端。重新打开终端,此时只要敲 rdp ip地址 -u 用户名 -p 密码 就可以了。

PS:1、用户主目录下的.bashrc 文件会在终端启动的时候被终端读取。
2、此外,-g 还可以 以 百分比 的形式填写 如下:

Example compiling the latest Audacity source code on Ubuntu

These simple steps have been tested building Audacity 2.x on Ubuntu 11.04 (natty) and onwards including 13.04 (raring). The steps should also work with appropriate modification on most other Debian-based systems and for most legacy 1.3 versions of Audacity.

Open a terminal and type the following commands:

This should now give you the Audacity program at usr/local/bin and the plug-ins at usr/local/share/audacity.
On occasions, changes to latest Audacity HEAD may require you to regenerate the configure file before running it. To do this




cannot find sources (wx-config.in)







Building on Snow Leopard for Snow Leopard

When trying to build wx under 10.6 you might - on certain machines - end up with errors like this:

The reason is that the default compiler on 10.6 is gcc 4.2, and if you are on a Core 2 Duo which is 64-bit capable, you end up compiling Carbon-only 2.8 for 64 bits which fails, due to the lack of 64-bit Carbon support. If you want 64-bit wxWidgets on OS X you'll need 2.9+ and configure -with-osx_cocoa - see below; but remember that 2.9 is not an official, stable release and wxOSX/Cocoa is not yet complete.

So, to compile with 2.8 on a 64-bit Mac, you have to explicitly indicate the architectures you want:

This makes the library and samples build nicely for Intel 32-bit targets, and you can also add -arch ppc to the arch_flags so that you can build universal binaries.







转载自 http://hi.baidu.com/dbfr2011818/item/d26f6820dc80e08c6f2cc30e

Why your Android NDK breakpoints might fail and how to fix them



First of all let's overview the structure of a typical Android app containing native code:


The app code is stored inside an .apk file that is essentially a ZIP archive containing the classes.dex file (with all the Java code) and one or more native libraries in lib\<EABI name> subdirectory. The typical lifecycle of an application with native code is the following:

  1. The Android OS loads the Java code and starts executing it
  2. The Java code calls System.loadLibrary() to load a native library.
  3. The Java code starts calling functions from the native code.

Each native library exists in 2 versions:

  •  A "full" version debugging information that associates code addresses inside the library with source files and lines. This version resides in obj\local\armeabi under your project directory.
  • A "stripped" version without the debugging information that resides in libs\armeabi and gets packaged into the APK file.

While the Android device runs the smaller "stripped" version of the library, the GDB debugger needs the larger "non-stripped" version to map source files into addresses and vice versa:


Setting breakpoints


When you set a breakpoint on a given line of a source file, the GDB debugger needs to perform certain computations before the breakpoint can be physically created and starts triggering. Assume libNative1 is loaded at address 0x10000 and the user is setting a breakpoint in line 24 of c:\main.cpp. GDB will do the following before it can set a breakpoint:

  1. GDB starts searching all loaded libraries for the file called "c:\main.cpp". In this example the Android OS only reports the libNative1.so library.
  2. GDB looks inside obj\local\armeabi for a file called libNative1.so which is the "non-stripped" version of the library containing the debug information. GDB reads the symbol table from it and finds c:\main.cpp inside it.
  3. Based on the symbol table GDB computes that line 24 corresponds to offset +0x2. It adds 0x2 to the load address of libNative1.so (0x10000) and sets the breakpoint at 0x10002.

If any of the 3 steps fail, the breakpoint will not be created, or will be created wrongly and will never be hit. The next section explains how to diagnose and fix the related problems.

Diagnosing the problems

This section provides detailed instructions how to check for the most common problems with breakpoints caused by non-standard configurations or missing files:

A. Ensure that the library is loaded

First thing to do is to determine if the native library has been actually loaded and if GDB knows about it. It is done by running the "info shared" command in GDB:


The output from the info shared command should include 3 important lines:

  1. Loaded symbols for "linker"
  2. Loaded symbols for "libc.so"
  3. Loaded symbols for all native libraries you want to debug.

Here's an example of those lines:

If some of the libraries are not present, you can force GDB to manually reload the symbols by running the following command in GDB:

If your .so library (e.g. libMyAndroidApp.so) is listed, but the symbols are not loaded ("Syms read" states "no"), GDB was not able to find a non-stripped version of the library. To fix it please run the "show solib-search-path" command in GDB:


The obj/local/armeabi directory of your project should be present among the reported directories and it should contain the .so file with symbols. If not, copy the correct .so file into a directory listed here and rerun the "sharedlibrary" command.

You can alternatively force GDB to search additional directories for the .so file using the set solib-search-path command.

If your .so library is not present in the list, it has not been loaded by the Java code yet. Please ensure that System.loadLibrary() is called from your Java code and that it succeeds without any Java exceptions.

B. Ensure that you are using correct file paths

A common cause of many breakpoint problems is a configuration when the directories using for building and debugging your project are different. E.g. if the library was compiled from c:\projects and then the sources were moved to d:\projects, setting a breakpoint in d:\projects\main.cpp will fail, as GDB will not accept c:\projects\main.cpp as a substitute.

Those problems can be diagnosed by looking into the source file lists and comparing them with the file used to set a breakpoint. First of all, remove your breakpoint, try setting your breakpoint again and watch what GDB command is issued by your IDE:


The -break-insert command used to set a breakpoint will specify a path to your source file.

Run the "info sources" command to see the source files discovered by GDB:


Copy the output of the command to the clipboard (Ctrl-A, Ctrl-C), paste it into a text editor and search for the source file you are trying to debug (e.g. MyAndroidApp.c):


If the file is not present in the list, you have loaded a wrong version of the .so file (see previous section). If the file is present, but the path is different from the one used in -break-insert command, you have found the cause of your problem. Rebuild your app using the new path, or move the file back to an old location so that the path used for creating breakpoints matches the path reported by the "info sources" command.

Note that GDB requires the file path to be EXACTLY the same as reported by "info sources", including double slash before "jni".

C. Recheck file versions and do a clean build

If your breakpoints are set, but never hit, there is probably a mismatch between the .so file version loaded into the Android application and the .so file version used by GDB to compute addresses from source lines. The most common cause for it is the bug in the Android loader that loads the armeabi library instead of the armeabi-v7a version. If you suspect this to happen, change your build configuration to build either armeabi, or armeabi-v7a platform, but not both at the same time and rebuild your application.'

引用自  http://www.codeproject.com/Articles/493043/Why-your-Android-NDK-breakpoints-might-fail-and-ho