Sample SFTP using Perl

Perl Program to do SFTP : http://www.pastie.org/564818

Shell script to call the perl: http://www.pastie.org/564822

Easy remoting with Spring HttpInvoker

If you’re looking for a simple solution to expose/access services using Java, maybe you should consider using SpringHttpInvoker. Here’s a quick recipe of how to use it (extracted from Spring docs).

Let’s start with the domain class:

public class Account implements Serializable{
private String name;
public String getName(){
return this.name;
}
public void setName(String name) {
this.name = name;
}
}

The service interface:

public interface AccountService {
public void insertAccount(Account account);
public List getAccounts(String name);
}

And some implementation of the service:

// the implementation doing nothing at the moment
public class AccountServiceImpl implements AccountService {
public void insertAccount(Account acc) {
// do something...
}
public List getAccounts(String name) {
// do something...
}
}


In order to expose this service you’ll need a ServletDispatcher configured inside your web.xml like the following:

<servlet>
<servlet-name>remoting</servlet-name>
<servlet-class>
org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>

<servlet-mapping>
<servlet-name>remoting</servlet-name>
<url-pattern>/remoting/*</url-pattern>
</servlet-mapping>

And then it’s just a matter of exposing your service in the WEB-INF/remoting-servlet.xml file:

<bean name="/AccountService"
class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">
<property name="service" ref="accountService">
<property name="serviceInterface" value="example.AccountService">
</bean>

And that’s all you need! To access it on the client application, you just need to declare the remote service:

<bean id="httpAccountServiceProxy"
class="org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean">
<property name="serviceUrl"
value="http://remotehost:8080/remoting/AccountService"/>
<property name="serviceInterface" value="example.AccountService">
</bean>


After this point your client application can use your service transparently via the httpAccountServiceProxy. As simple as it should be!

Different ways of Injecting Spring beans in Struts Applications

Accessing Spring beans in Action Form, Action Classes of Struts

Step 1:
Load the spring context file using the ContextLoader Listener in the web.xml

<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener </listener-class>
</listener>

Usages:

Usage 1: Using the loaded beans in the Action Forms:

We can use the loaded beans from the servletContext using the WebApplicationContextUtils provided by spring.

Example:
import org.springframework.web.context.support.WebApplicationContextUtils;

WebApplicationContextUtils.getWebApplicationContext(this.getServlet().getServletContext()).getBean("TestService");

Usage 2: Using the loaded beans in Action Classes:

Another convienient way of using the loaded beans in the Action Class
extend Action class with org.springframework.web.struts.ActionSupport
and use the getWebApplicationContext().getBean("testService");

Example:

public class TestAction extends ActionSupport
{
public ActionForward execute(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception {
TestService serv = (TestService) getWebApplicationContext().getBean("testService");
}
}

Usage 3: Using Spring-managed Struts Action , so that all the beans gets injected directly into the Struts.

Proxy for a Spring-managed Struts Action that's defined in ContextLoaderPlugIn's WebApplicationContext.

The proxy is defined in the Struts config file, specifying this class as action class. It will delegate to a Struts Action bean in the ContextLoaderPlugIn context.

<action path="/login" type="org.springframework.web.struts.DelegatingActionProxy"/>


The name of the Action bean in the WebApplicationContext will be determined from the mapping path and module prefix. This can be customized by overriding the determineActionBeanName method.

Example:
mapping path "/login" -> bean name "/login"
mapping path "/login", module prefix "/mymodule" -> bean name "/mymodule/login"

A corresponding bean definition in the ContextLoaderPlugin context looks as follows, being able to fully leverage Spring's configuration facilities:

<bean class="myapp.MyAction" name="/login">
<property name="...">...</property>
</bean>

Note that you can use a single ContextLoaderPlugIn for all Struts modules. That context can in turn be loaded from multiple XML files, for example split according to Struts modules. Alternatively, define one ContextLoaderPlugIn per Struts module, specifying appropriate "contextConfigLocation" parameters. In both cases, the Spring bean name has to include the module prefix.

If you want to avoid having to specify DelegatingActionProxy as Action type in your struts-config, for example to be able to generate your Struts config file with XDoclet, consider DelegatingRequestProcessor . The latter's disadvantage is that it might conflict with the need for a different RequestProcessor subclass.
The default implementation delegates to the DelegatingActionUtils class as fas as possible, to reuse as much code as possible with DelegatingRequestProcessor and DelegatingTilesRequestProcessor.

Interesting Websites

• Setting up Surveys - http://www.zoomerang.com
• Pasting your code to public - http://pastie.org
• Online Project Management - http://www.zohoprojects.com

HTTP Debugger

HTTP Debug proxying tools generally allows us to log HTTP traffic between the computer and the Internet. These logs can be helpful to identify performance issues while loading screens. There are lots of commercial tools and open source tools available in the market.

I have used the following products:
Commercial Product:
Charles Web debugging proxy is really good and it automatically takes up the settings from the browser and proxies the request.
URL: http://www.xk72.com/charles/

Open source Tool:
Fiddler
URL: http://www.fiddlertool.com/fiddler/

Apache + SSL

1.0 Download Apache SSL and Open SSL

Download Apache With SSL Support and OpenSSL

Extra both zip files into two different location, and replace all *.exe, *.dll, *.so files from Apache with OpenSSL support to your Apache local installation.

Download ssl.conf into APACHE_HOME/conf

Download openssl.cnf into your OpenSSL directory Also copy the files ssleay32.dll and libeay32.dll from the OpenSSL distribution directory to WINDOWS\System32 directory !!!

2.0 Create Certificate

Enter the following command
openssl req -config openssl.cnf -new -out my-server.csr
This creates a certificate signing request and a private key.

openssl rsa -in privkey.pem -out my-server.key
This removes the passphrase from the private key.

openssl x509 -in my-server.csr -out my-server.cert -req -signkey my-server.key
This creates a self-signed certificate.

Create an APACHE_HOME/conf/ssl directory and move my-server.key and my-server.cert into it.

3.0 Configure mod_ssl and Apache

Edit APACHE_HOME/conf/httpd.conf add the following line

LoadModule ssl_module modules/mod_ssl.so

# SSL
SSLMutex default
SSLRandomSeed startup builtin
SSLSessionCache none


 SSLEngine On
 SSLCertificateFile conf/ssl/my-server.cert
 SSLCertificateKeyFile conf/ssl/my-server.key

You also need to modify APACHE_HOME/conf/ssl.conf to update DocumentRoot and ServerName

Restart your Apache server and you could test it on https://localhost/

For reference please go tohttp://www.thompsonbd.com/tutorials/apachessl.php and http://tud.at/programm/apache-ssl-win32-howto.php3

How Spring can Leverage any ORM

I was previously working with Spring with Hibernate (2.3) Combination. It was really painful because hibernate was throwing all the exceptions as checked exceptions and we were forced to catch all the exceptions in the Service Layer. But now a days it is very simple as we can catch the exceptions as Throwable in Service Layer and can use an Interceptor to log those message and rethrow as application specific exceptions. I came across a good article about the Spring leveraging any ORM and thought of adding its content into my blog with the reference to the source site.

In a typical Spring architecture, DAOs are effectively Strategy Pattern objects, isolating service layer objects from the technology specifics of obtaining and saving persistent objects.

Spring supports a range of ORM tools and persistence frameworks, including (but not limited to) TopLink, Hibernate, JDO (Java Data Objects), iBATIS SQL Maps, and Apache OJB (ObjectRelational Bridge).

Spring provides a consistent approach to working with all these tools, but doesn't attempt to completely abstract the ORM tool, because doing so would be counterproductive. Thus, for example, implementations of DAO interfaces will use the native query API of the ORM tool: Spring does not attempt to create a query abstraction, which would be less powerful than that of leading ORM products.

How Spring can Leverage any ORM ?

For DAO interfaces to be independent of the underlying persistence technology, we need to solve some crucial issues. Spring provides important help here, especially in the areas of exception handling; resource acquisition and release; and transaction management. Spring exception handling: Two key features of Spring's exception handling enable it to remain independent of the underlying persistence technology. First, it uses a class-based hierarchy of generic data access exceptions (Figure shows the most important classes in the hierarchy) that can leverage any underlying ORM's exception mechanisms. The exception hierarchy can easily be extended. Thus, for example, you can write service layer code to handle DataIntegrityViolationException (violation of a constraint such as a primary key constraint), without concern as to the data access tool in use, which may be JDBC, TopLink, JDO, Hibernate or another supported framework. This hierarchy is even extensible without modifying Spring code, if you wish to add mappings to error conditions unique to your database or persistence tool.

Secondly, Spring's exception handling approach uses unchecked exceptions. Using unchecked exceptions works particularly well in conjunction with an exception hierarchy, because it is only necessary to catch a particular subclass that may be recoverable. Catching subclasses of checked exceptions is less useful, since the base class still needs to be caught. (Note that JDBC was always something of an odd API out, in terms of using checked exceptions: TopLink and JDO, for example, both use unchecked exceptions. In version 3, Hibernate will switch from checked to unchecked exceptions.)

Resource acquisition and release: One of the major challenges of working with any data access technology is that resources such as JDBC connections or ORM sessions must be acquired and released correctly even in the event of errors.

Spring solves the problem of resource acquisition and release by using a callback approach. The framework is responsible for acquiring and releasing resources, while the application developer implements code in a callback method to perform the necessary persistence operation with the desired resource. Thus application developers focus on the unique needs of their application, rather than writing plumbing code.

Helper classes that provide this functionality are termed templates, and Spring provides a consistent approach across many APIs where such resource acquisition and release is a problem, such as JDBC, JNDI and JMS.

Transaction management and thread binding: Spring's resource acquisition and release strategy is integrated with its transaction management support. It's important to get the same resource for every operation in the same transaction. While JTA and JCA may provide support for this in a full-blown J2EE environment (depending on the persistence tool), Spring provides support for this in any environment, including J2SE environments. The necessary Spring configuration is also simpler than JCA configuration.

Spring does this by binding resources such as JDBC connections or TopLink or Hibernate Sessions to the current thread. Many application developers have implemented such support in their own applications. However, the Spring solution not only has the merit of being far more sophisticated than typical in-house solutions (with support for transaction suspension and many other complex-to-implement value adds), but eliminates the need to write and maintain such custom code. Again, generic concerns are best given a generic solution.

Source: http://www.oracle.com/technology/pub/articles/masterj2ee/j2ee_wk9.html