Showing posts with label Java Tech Zone. Show all posts
Showing posts with label Java Tech Zone. Show all posts

Sunday, June 10, 2012

Eclipse Shortcuts

Eclipse Shortcuts:


Ctrl+Shift+T

Find Java Type

Start typing the name and the list gets smaller. Try typing the capital letters of the class only (e.g. type "CME" to find "ConcurrentModificationException")

Ctrl+Shift+R

Find Resource

Use this to look for XML files, text files, or files of any other type. which are in your workspace.

Ctrl+E

Open Editor Drop-Down

Presents a popup window listing currently opened files. Start typing to limit the list or simply use the down arrow key.

Ctrl+O

Quick Outline

Use this to find a method or a member variable in a class. Start typing to limit the choices. Press Ctrl+O a second time to include inherited methods.

Ctrl+Space

Content Assist

Context sensitive content completion suggestions while editing Java code.

Ctrl+Shift+Space

Context Information

If typing a method call with several parameters use this to show the applicable parameter types. The current parameter where the cursor is will be shown in bold.

Ctrl+Shift+O

Organize Imports

After typing a class name use this shortcut to insert an import statement. This works if multiple class names haven't been imported too.

F3

Open Declaration

Drills down to the declaration of the type, method, or variable the cursor is on. This works much like a browser hyperlink.

Alt+Left

Backward History

This works like a browser's Back button.

Alt+Right

Forward History

This works like a browser's Forward button

Ctrl+L

Go to Line

Go to a specific line number.

F4

Open Type Hierarchy

Show the type hierarchy (downward tree) or the supertype hierarchy (upward tree).

Ctrl+Alt+H

Open Call Hierarchy

Show where a method is called from. In the Call Hierarchy view keep expanding the tree to continue tracing the call chain.

Ctrl+H

Open Search Dialog

Opens a search dialog with extensive search options for Java packages, types, methods, and fields.

Alt+Shift+R

Rename - Refactoring

Use this to rename type, method, or field. All existing references will be refactored as well.

Alt+Shift+L

Extract Local Variable

Use this to create a local variable from the selected expression. This is useful for breaking up larger expressions to avoid long lines.

Alt+Shift+M

Extract Method

Use this to extract a new method from existing code. The parameter list and return type will be automatically created.

Alt+Shift+Up
Alt+Shift+Down
Alt+Shift+Left
Alt+Shift+Right


Select Enclosing Element / Restore Last Selection / Select Previous Element /
Select Next Element


Useful for selecting context-sensitive blocks (e.g. surrounding loop, method, class, etc.)

Ctrl+Up
Ctrl+Down


Scroll Line Up / Scroll Line Down

Very handy if you want to scroll by 1 line without changing your cursor position or using the mouse.

Ctrl+Shift+U
Alt+Shift+U


Go to Previous Member / Go to Next Member

Great for stepping down through the methods of a Java source file.

Ctrl+Shift+U
Alt+Shift+U


Show Occurrences in File / Remove Occurrences Annotations

Use this to search within the same file - useful for occurrences of private fields and methods.

Ctrl+Shift+P

Go to Matching Bracket

Helps to find the closing bracket of lengthly if-else statements.

Ctrl+J
Ctrl+Shift+J


Incremental Find / Reverse Incremental Find

The first matching occurrence is shown with each typed letter. Press again and the next matching occurrence is shown.

Shift+Enter
Ctrl+Shift+Enter


Insert Line Below / Insert Line Above

Insert a line above or below the current line.

Ctrl+/
Ctrl+\


Add Block Comment / Remove Block Comment

Comment in/out blocks of code with a key stroke.

Ctrl+M

Maximize Active View or Editor

Maximize the current view or editor at the expense of all other currently shown views. Press again to restore to normal view.

Ctrl+F6
Ctrl+F7
Ctrl+F8


Next Editor / Next View / Next Perspective

Learn these to switch among edited files, open views and perspectives.

Ctrl+Alt+Up
Ctrl+Alt+Down


Duplicate Lines / Copy Lines

Doesn't seem like it at first but a great shortcut once you learn to use it. Instead of select, copy and paste simply select and duplicate without affecting the clipboard.

Alt+/

Word Completion

This is excellent for code editing or writing plain help files with variables and other words having no English language equivalents. The word completion is based on the set of words already present in the current file.

Ctrl+I

Correct Indentation

Select a block of Java code or an entire class file and use this shortcut to correct its indentation.

Tuesday, October 11, 2011

Seeting up SSL on Tomcat

Setting up SSL on Tomcat is easy and you don’t have to do much for converting your web application to work with the Https protocol. But however, the problem you would find to set up SSL is the documentation available over the web. The documentation source is available on the Apache site but it starts off good and ends with a lot of confusion. Especially I was confused on the OpenSSL part where it says to use OpenSSL.
It might be good in a production environment to use OpenSSL but if you just want to test out SSL with Tomcat alone then it is more than enough to just have your JDK and Tomcat setups. So I would make you walk through the same steps which I did while getting SSL up and running and building a secured web app within a matter of minutes.
The things which I have used to setup SSL consists of:
  • JDK 1.6
  • Tomcat 6
Even though I have used the latest version I don’t see any problems which you might face in carrying out the same set of steps for JDK 1.5 which I am about to explain. JDK comes shipped with a keytool executable which is required to generate a keystore. The keytool can be found in the earlier version of JDK too. The 3 steps which would make you to get started with setting up SSL are:
  1. Generating the Keystore file
  2. Configuring Tomcat for using the Keystore file
  3. Configuring your web application to work with SSL
Let’s get this party started now.
1. Generating the KeyStore file
The keystore file is the one which would store the details of the certificates necessary to make the protocol secured. Certificates contain the information as to who is the source from which you are receiving the application data and to authenticate whether it is the intended party or not. To make this keystore you would have to use the keytool. So open command prompt in Windows or the shell in Linux and type:
cd %JAVA_HOME%/bin on Windows
cd $JAVA_HOME/bin on Linux
You would land up in the Java bin directory. Now time to run the keytool command. You have to provide some parameters to the command as follows :
keytool -genkey -alias trace -keypass testadmin -keystore trace.bin -storepass testadmin
The highlighted words are the ones which you would have to change according to your requirements. But keep one thing in mind that both the keypass and storepass passwords should be the same. The .bin file is actually your keystore file. It would now start a questionnaire. So fill in the relevant details accordingly. Look below for a reference as to what to answer for the questions.
What is your first and last name?
[Unknown]: pankaj api
What is the name of your organizational unit?
[Unknown]: home
What is the name of your organization?
[Unknown]: trace
What is the name of your City or Locality?
[Unknown]: Delhi
What is the name of your State or Province?
[Unknown]: India
What is the two-letter country code for this unit?
[Unknown]: IN
Is CN=pankaj api, OU=home, O=trace, L=Delhi, ST=India, C=IN correct?
[no]: yes

The command would then conclude. It would make a .bin file with the name you had provided inside the bin directory itself. In my case it was trace.bin which was located in
C:\Program Files\Java\jdk1.6.0_02\bin\
Put the .bin file in the webapps directory of Tomcat. This is required to avoid the need to give an absolute path of the file in the next step.
2. Configuring Tomcat for using the Keystore file
Here we would be making some changes to the server.xml file inside tomcat to tell it to use the keystore which was created in the earlier step for configuring SSL. Open the file server.xml which can be found as:
<CATALINA_HOME>/conf/server.xml
Now you have to modify it. Find the Connector element which has port=”8443″ and uncomment it if already not done. Add two lines. The highlighted lines are the newly added ones.
<Connector port=”8443″
maxThreads=”150″ minSpareThreads=”25″ maxSpareThreads=”75″
enableLookups=”true” disableUploadTimeout=”true”
acceptCount=”100″ debug=”0″ scheme=”https” secure=”true”
clientAuth=”false” sslProtocol=”TLS”
keystoreFile=”../webapps/trace.bin”
keystorePass=”testadmin” />

You can notice that I have given the path to the keystoreFile property as relative to tomcat bin directory because the startup command will look for the .bin file. Now all you have to do is start your server and check the working of SSL by pointing your browser to the URL to:
https://localhost:8443/
Now that you have your tomcat running in the SSL mode you are ready to deploy an application to test its working. You must note that still your tomcat can run in normal mode too at the same time i.e on port 8080 with http. So it is but obvious that any application deployed to the server will be running on http and https at the same time. This is something that we don’t want. We want our application to run only in the secured mode.
3. Configuring your web application to work with SSL
In order to do this for our test, take any application which has already been deployed successfully in Tomcat and first access it through http and https to see if it works fine. If yes, then open the web.xml of that application and just add this XML fragment before web-app ends i.e </web-app>
<security-constraint>
<web-resource-collection>
<web-resource-name>securedapp</web-resource-name>
<url-pattern>/*</url-pattern>
</web-resource-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

Explanation of the fragment is beyond the scope of this tutorial but all you should notice is that the /* indicates that now, any resource in your application can be accessed only with https be it Servlets or JSP’s. The term CONFIDENTIAL is the term which tells the server to make the application work on SSL. If you want to turn the SSL mode for this application off then just turn don’t delete the fragment. Just put the value as NONE instead of CONFIDENTIAL. That’s it!
Conclusion
These were the 3 easy steps in which you can make Tomcat to work in the SSL mode and also it tells you how easily you can turn the SSL mode on and off. If you find any difficulty or are not clear on any of the above steps feel free to drop in your queries. If you like this tutorial it would be nice of you to drop in a comment of appreciation or feedback as to how this tutorial can be improved.

Thursday, October 6, 2011

What is the difference between an application server and a Web server?


What is the difference between an application server and a Web server?
Taking a big step back, a Web server serves pages for viewing in a Web browser, while an application server provides methods that client applications can call. A little more precisely, you can say that:
A Web server exclusively handles HTTP requests, whereas an application server serves business logic to application programs through any number of protocols.
Let's examine each in more detail.
The Web server
A Web server handles the HTTP protocol. When the Web server receives an HTTP request, it responds with an HTTP response, such as sending back an HTML page. To process a request, a Web server may respond with a static HTML page or image, send a redirect, or delegate the dynamic response generation to some other program such as CGI scripts, JSPs (JavaServer Pages), servlets, ASPs (Active Server Pages), server-side JavaScripts, or some other server-side technology. Whatever their purpose, such server-side programs generate a response, most often in HTML, for viewing in a Web browser.
Understand that a Web server's delegation model is fairly simple. When a request comes into the Web server, the Web server simply passes the request to the program best able to handle it. The Web server doesn't provide any functionality beyond simply providing an environment in which the server-side program can execute and pass back the generated responses. The server-side program usually provides for itself such functions as transaction processing, database connectivity, and messaging.
While a Web server may not itself support transactions or database connection pooling, it may employ various strategies for fault tolerance and scalability such as load balancing, caching, and clustering—features oftentimes erroneously assigned as features reserved only for application servers.
The application server
As for the application server, according to our definition, an application server exposes business logic to client applications through various protocols, possibly including HTTP. While a Web server mainly deals with sending HTML for display in a Web browser, an application server provides access to business logic for use by client application programs. The application program can use this logic just as it would call a method on an object (or a function in the procedural world).
Such application server clients can include GUIs (graphical user interface) running on a PC, a Web server, or even other application servers. The information traveling back and forth between an application server and its client is not restricted to simple display markup. Instead, the information is program logic. Since the logic takes the form of data and method calls and not static HTML, the client can employ the exposed business logic however it wants.
In most cases, the server exposes this business logic through a component API, such as the EJB (Enterprise JavaBean) component model found on J2EE (Java 2 Platform, Enterprise Edition) application servers. Moreover, the application server manages its own resources. Such gate-keeping duties include security, transaction processing, resource pooling, and messaging. Like a Web server, an application server may also employ various scalability and fault-tolerance techniques.
An example
As an example, consider an online store that provides real-time pricing and availability information. Most likely, the site will provide a form with which you can choose a product. When you submit your query, the site performs a lookup and returns the results embedded within an HTML page. The site may implement this functionality in numerous ways. I'll show you one scenario that doesn't use an application server and another that does. Seeing how these scenarios differ will help you to see the application server's function.
Scenario 1: Web server without an application server
In the first scenario, a Web server alone provides the online store's functionality. The Web server takes your request, then passes it to a server-side program able to handle the request. The server-side program looks up the pricing information from a database or a flat file. Once retrieved, the server-side program uses the information to formulate the HTML response, then the Web server sends it back to your Web browser.
To summarize, a Web server simply processes HTTP requests by responding with HTML pages.
Scenario 2: Web server with an application server
Scenario 2 resembles Scenario 1 in that the Web server still delegates the response generation to a script. However, you can now put the business logic for the pricing lookup onto an application server. With that change, instead of the script knowing how to look up the data and formulate a response, the script can simply call the application server's lookup service. The script can then use the service's result when the script generates its HTML response.
In this scenario, the application server serves the business logic for looking up a product's pricing information. That functionality doesn't say anything about display or how the client must use the information. Instead, the client and application server send data back and forth. When a client calls the application server's lookup service, the service simply looks up the information and returns it to the client.
By separating the pricing logic from the HTML response-generating code, the pricing logic becomes far more reusable between applications. A second client, such as a cash register, could also call the same service as a clerk checks out a customer. In contrast, in Scenario 1 the pricing lookup service is not reusable because the information is embedded within the HTML page.
To summarize, in Scenario 2's model, the Web server handles HTTP requests by replying with an HTML page while the application server serves application logic by processing pricing and availability requests.

Recently, XML Web services have blurred the line between application servers and Web servers. By passing an XML payload to a Web server, the Web server can now process the data and respond much as application servers have in the past.
Additionally, most application servers also contain a Web server, meaning you can consider a Web server a subset of an application server. While application servers contain Web server functionality, developers rarely deploy application servers in that capacity. Instead, when needed, they often deploy standalone Web servers in tandem with application servers. Such a separation of functionality aids performance (simple Web requests won't impact application server performance), deployment configuration (dedicated Web servers, clustering, and so on), and allows for best-of-breed product selection.

Tuesday, September 13, 2011

CONFIGURING APPLICATION IN ECLIPSE FOR TOMCAT SERVER

   Prerequisites
Eclipse (Eclipse Java EE IDE for Web Developers. Version: Helios Service Release 1; Build id: 20100917-0705)
Tomcat 5.0
Tomcat server plugin for eclipse
--------------------------------------
Setup Steps :


  1. Select NEW à Project from SVN. Enter all necessary url (your SVN server location) and credentials.

  1. When SVN Repository opens; on “Check Out As” screen à select “Check out as a project configured using the New project wizard” à Select “TOMCAT project” à Finish.

  1. Select Project Properties and right click and select “Java Build Path” and in that remove test source files and add main source files.
 


               3.1       Add the default output folder as …./main/src/webapp/WEB-INF/classess.
               3.2       Select “Libraries” tab and specify all libraries.
               3.3       Select “Order and Export”, specify build classpath order and exported entries.

  1. Select “Project” and right click and select “Tomcat Project”
               4.1       Click on create JSP directory
               4.2       Select update context properties.          

5      Select “Project Properties” and right click and select tomcat
5.1 Choose “General tab” and specify the subdirectory location in it.
5.2 Choose “DevLoader Classpath” and uncheck xmlparser.jar files and servletapi.jar file
6.   Select “Project” and right click and select “Maven”
      6.1.       Choose Run Maven and click on “Choose” button to select Classpath. On the next screen select ECLIPSE à Generate-classpath (check it) and click OK.




7. Goto ECLIPSE à Window à Preferences
Select MAVEN. Your MAVEN Locations screen should look like this