To find the application which is using the 80 port number
In “Command Prompt” type the following command:
(1) netstat -o -n -a | findstr 0.0:8080
and then
(2) taskkill /F /PID 988
Change the PID value from 988to your required port value

1. Define service interface
2. Define service Implementation
3. Web.xml – add JAX-WS commons spring ext servlet
4. Spring beans configuration using annotations
5. Spring configurations for Web Services
6. pom.xml – Add ‘jaxws-maven-plugin’ plugin
7. Build deployment using maven
8. Check the web service
9. Test web service using sopaUI
10. Download Source Code mo-ws.zip
    or war file mo-ws.war

(1) Define service interface

//TemperatureService .java
package uk.co.mo.training.ws;

import javax.jws.WebMethod;
import javax.jws.WebParam;
import javax.jws.WebService;
@SuppressWarnings("restriction")
@WebService
public interface TemperatureService {
	
	@WebMethod
	public double toCelsius(@WebParam(name="fahrenheit") double fahrenheit);
	@WebMethod
	public double toFahrenheit(@WebParam(name="celsius") double celsius);

}

//TemperatureServiceImple .java
package uk.co.mo.training.ws;

import javax.jws.WebService;

import org.springframework.stereotype.Service;
@SuppressWarnings("restriction")
@WebService(endpointInterface = "uk.co.mo.training.ws.TemperatureService",serviceName="temperatureService")
@Service
public class TemperatureServiceImple implements TemperatureService {


	public double toCelsius(double fahrenheit) {
		double celsius = (5.0 / 9.0) * (fahrenheit - 32.0);
		//C° = (5 / 9)x (F° - 32)  
		return celsius;
	}


	public double toFahrenheit(double celsius) {
		double fahrenheit = (celsius *1.8)+32.0;
		//F° = (C° x 1.8) + 32
		return fahrenheit;
	}

}

(3) Web.xml – add JAX-WS commons spring ext servlet

<!DOCTYPE web-app PUBLIC
 "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN"
 "http://java.sun.com/dtd/web-app_2_3.dtd" >

<web-app>
   
  <!-- spring framework context configuration -->
  <context-param>
    <param-name>contextConfigLocation</param-name>
    <param-value>/WEB-INF/conf/main-application-context.xml</param-value>
  </context-param>
 
  
  <!-- Spring Context Listener -->
  <listener>
    <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>    
  </listener>
  
  <!-- this is for JAX-WS commons spring ext. -->
  <servlet>
      <servlet-name>jaxws-servlet</servlet-name>
      <servlet-class>
        com.sun.xml.ws.transport.http.servlet.WSSpringServlet
      </servlet-class>
      <load-on-startup>1</load-on-startup>
   </servlet>
   
   <servlet-mapping>
      <servlet-name>jaxws-servlet</servlet-name>
      <url-pattern>/webservice/*</url-pattern>
   </servlet-mapping>
  
</web-app>

(4) Spring beans configuration using annotations

<!-- main-application-context.xml-->
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:context="http://www.springframework.org/schema/context"
       xsi:schemaLocation="
            http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
            http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.5.xsd
            http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.5.xsd
            http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-2.5.xsd">
	    <!—scan annotations -->         
       <context:component-scan base-package="uk.co.mo.training.ws"/>
       <context:annotation-config/>
       <!-- Web Services -->         
       <import resource="ws-context.xml"/>        
          
</beans>

(5) Spring configurations for Web Services

<!--  ws-context.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xmlns:ws="http://jax-ws.dev.java.net/spring/core"
	xmlns:wss="http://jax-ws.dev.java.net/spring/servlet"
	xsi:schemaLocation="
    http://www.springframework.org/schema/beans
    http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
    http://jax-ws.dev.java.net/spring/core
    http://jax-ws.dev.java.net/spring/core.xsd
    http://jax-ws.dev.java.net/spring/servlet
    http://jax-ws.dev.java.net/spring/servlet.xsd">
   
   <!-- Temperature Web Service -->
	<wss:binding url="/webservice/temperaturewebservice"> 
      <wss:service> 
         <ws:service bean="#temperatureServiceImple">             
         </ws:service> 
      </wss:service> 
   </wss:binding> 

   </beans>

(6) pom.xml – Add ‘jaxws-maven-plugin’ plugin

<!-- pom.xml-->
.....
  <build>
    <finalName>mo-ws</finalName>
    <plugins>
      <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <version>2.3.2</version>
        <configuration>
          <source>1.5</source>
          <target>1.5</target>
        </configuration>
      </plugin>
      
      	<plugin>
				<groupId>org.codehaus.mojo</groupId>
				<artifactId>jaxws-maven-plugin</artifactId>
				<version>1.10</version>				
			<executions>
				
				<execution>
					<id>TemperatureWS</id>
					<configuration>
						<sei>uk.co.mo.training.ws.TemperatureServiceImple</sei>
						<genWsdl>true</genWsdl>
						<keep>true</keep>
						<verbose>true</verbose>
					</configuration>
					<phase>package</phase>
					<goals>
						<goal>wsgen</goal>
					</goals>
				</execution>
			</executions>				
      </plugin>
    </plugins>
  </build>
....

(7) Build deployment using maven: Run (1) “mvn clean package” and again (2) “mvn package”

"mvn clean package" - it will create required WSDL files at "/target/jaxws/wsgen/wsdl"
"mvn package" it will create some files at "/target/mo-ws/WEB-INF/classes/uk/co/mo/training/ws/jaxws"

<!-- server.xml-->
...
<Context
			docBase="D:/projects/mo-ws-project/target/mo-ws"
			path="/ws">
					
	</Context>
...

(9) Check the web service http://localhost:8080/ws/webservice/temperaturewebservice

(10) Using soapUI test web service

(11) Download Source Code mo-ws.zip or war file at mo-ws.war

The solution is Using Mock Objects

We use mock objects during testing for two main reasons: to isolate the class under test from outside influence and to control dependencies.

If the dependency is a simple POJO, using the new operator is an easy way to create an instance used just for the test. However, if the dependency is not easily created or requires heavyweight resources such as database connections, using the new operator isn’t often possible. Mock objects step in to “mock” the dependency, thus allowing the code under test to operate without invoking outside resources.

Mock objects are used when you need to either replace a heavyweight dependency with a lightweight instance just for testing, or when you need to use an intelligent stub. Those two situations often occur simultaneously, making mock objects a perfect addition to any testing tool belt.

The following example shows how we can test application component that has DAO (heavy weight) dependency using jmock objects  and web layer (Controller)  using spring mock api.

@RunWith(JMock.class)
public class HomeControllerTest {

	Mockery context = new JUnit4Mockery();
	//mock object : ContactDAO (using JMock)
	ContactDAOInterface contactDAO = context.mock(ContactDAOInterface.class);
	// Spring MVC controller
	HomeController cc = new HomeController();
	// mock objects (using spring mock)
	private MockHttpServletRequest request;
	private MockHttpServletResponse response;

	@Before
	public void init() throws Exception
	{
		cc.setContactDAO(contactDAO);
		// mock objects created
		request = new MockHttpServletRequest();
		response = new MockHttpServletResponse();
	}

	@Test
	public void HomePage() throws Exception
	{
		// define expectations for mock object
		context.checking(new Expectations() {{
			ArrayList<ContactData> data = new ArrayList<ContactData>();
			data.add(new ContactData(1,"Abdul Aziz","07525776781"));
	        oneOf (contactDAO).getContacts(); will(returnValue(data));
	    }});

		// test
		request.setMethod("GET");
		ModelAndView mav= cc.handleRequest(request, response);
		Assert.assertEquals("viewContacts", mav.getViewName());
		ArrayList<ContactData> obj=(ArrayList<ContactData>)mav.getModel().get("contacts");
		Assert.assertNotNull(obj);
		Assert.assertEquals(1,obj.size());
		Assert.assertEquals("Abdul Aziz",obj.get(0).getName());
		Assert.assertEquals("07525776781",obj.get(0).getPhone());
	}
}

org.acegisecurity.AccessDecisionManager
interface:

    public
interface AccessDecisionManager {

        public
void
decide(Authentication authentication, Object object,

            ConfigAttributeDefinition config)

            throws AccessDeniedException,

            InsufficientAuthenticationException;

        public
boolean
supports(ConfigAttribute attribute);

        public
boolean
supports(Class clazz);

    }

The decide()method is where the ultimate decision is made. If it returns without throwing an AccessDeniedException
or InsufficientAuthenticationException, access to the secured resource is granted. Otherwise, access is denied.

Decision by Voting:

Spring Security’s access decision managers are ultimately responsible for determining the access rights for an authenticated user. They poll one or more objects that vote on whether or not a user is granted access to a secured resource. Once all votes are in, the decision manager tallies the votes and arrives at its final decision.

<bean id=“accessDecisionManager” class=“org.acegisecurity.vote.UnanimousBased”>

<property name=“decisionVoters”>

<list>

<ref bean=“roleVoter”/>

</list>

</property>

</bean>

The decisionVoters property is where you provide the access decision manager with its list of voters.

<bean id=“roleVoter” class=“org.acegisecurity.vote.RoleVoter”/>

RoleVoter only votes when the secured resource has configuration attributes that are prefixed with ROLE_

By default, all the access decision managers deny access to a resource if all the voters abstain. However, you can override this default behavior by setting the allowIfAllAbstain
property on the access decision manager to true.

 Spring Web Services, a solution for contract-first, document-driven web services;

 XFire also allows you to export Spring-managed beans as a web service, through built-in spring support

For securing web applications, Spring Security uses servlet filters that intercept servlet requests to perform authentication and enforce security. When securing methods, Spring Security uses Spring AOP to proxy objects, applying aspects that ensure that the user has proper authority to invoke the secured methods.

Security Interceptors:

The actual implementation of a security interceptor will depend on what resource is being secured. If you’re securing a URL in a web application, the security interceptor will be implemented as a servlet filter. But if you’re securing a method invocation, aspects will be used to enforce security. It does not actually apply security rules. Instead, it delegates that responsibility to the various managers.

• Authentication managers
  
• Access decisions managers
  
• Run-as managers
  
• After-invocation managers
  

Authentication managers:

The authentication manager is responsible for determining who you are. It does this by considering your principal
(username) and your credentials
(password). The authentication manager is a pluggable interface-based component. This makes it possible to use Spring Security with virtually any authentication mechanism you can imagine. Spring Security comes with authentication managers.

Access decisions managers:

The access decision manager performs authorization, deciding whether to let you in by considering your authentication information and the security attributes that have been associated with the secured resource. The access decision manager is also pluggable.

Run-as managers:

A run-as manager can be used to replace your authentication with an authentication that allows you access to the secured objects that are deeper in your application. Run-as managers are an optional security component and are not necessary in many applications secured by Spring Security.

After-invocation managers:

The after-invocation manager enforces security after the secured resource is accessed. The after-invocation manager also has the option of altering the returned value to ensure that the user is only able to access certain properties of the returned object. Applications only need an after-invocation manager if the application’s security scheme requires that access be restricted at the domain level on a per-instance basis.

Spring and POJO-based remote services

Remote Method Invocation (RMI) – Accessing/exposing Java-based services when network constraints aren’t a factor

Hessian or Burlap – Accessing/exposing Java-based services over HTTP when network constraints are a factor

HTTP Invoker – Accessing/exposing Spring-based services over HTTP when network constraints are a factor

JAX-RPC/SOAP – Accessing/exposing platform-neutral, SOAP-based web-services

In all models, services can be configured into your application as spring managed beans. This is accomplished using a proxy factory bean that enables you to wire remote services into properties of your other beans as if they were local objects.

If the call to the remote service results in a java.rmi.RemoteException, the proxy handles that exception and rethrows it as an unchecked org.springframework.remoting.RemoteAccessException

On the service side, you are able to expose the functionality of any spring managed bean as a remote service using any of the models

1. Using the RMI
   

Using spring’s support for RMI, you basically need a configuration similar to remote EJBs, except for the fact that there is no standard support for security context propagation or remote transaction propagation. Spring does provide hooks for such additional invocation context when using the RMI invoker

Using the RmiServiceExporter, The interface can be accessed by using RmiProxyFactoryBean, or via plain RMI in case of a traditional RMI service. The RmiServiceExporter explicitly supports the exposing of any non-RMI services via RMI invokers.

Exposing services:

<bean id="accountService" class="com.example.AccountServiceImpl">

					<!-- any additional properties, maybe a DAO? -->
					

</bean>

<bean class=”org.springframework.remoting.rmi.RmiServiceExporter“>

<!– does not necessarily have to be the same name as the bean to be exported –>

<property name=”serviceName” value=”AccountService”/>

<property name=”service” ref=”accountService”/>

<property name=”serviceInterface” value=”com.example.AccountService”/>

<!– defaults to 1099 –>

<property name=”registryPort” value=”1199″/>

</bean>

The service will be bound at rmi://HOST:1199/AccountService We’ll use the URL later on to link in the service at the client side

Linking in the service at the client

<bean class="example.SimpleObject">

    <property name="accountService" ref="accountService"/>

</bean>

<bean id="accountService" class="org.springframework.remoting.rmi.RmiProxyFactoryBean">

    <property name="serviceUrl" value="rmi://HOST:1199/AccountService"/>

    <property name="serviceInterface" value="example.AccountService"/>

</bean>

1. Using Hessian or Burlap to remotely call services via HTTP
   

Hessian offers a binary HTTP-based remoting protocol. One of the advantages of Hessian and Burlap is that we can easily apply HTTP basic authentication.

Both protocols are HTTP-based,

Hessian communicates via HTTP and does so using a custom Servlet; So we need a new Servlet configuration

<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>

Exposing Services:

Defined in remoting-servlet.xml

<bean id="accountService" class="example.AccountServiceImpl">

					<!-- any additional properties, maybe a DAO? -->
					

</bean>

<bean name="/AccountService" class="org.springframework.remoting.caucho.HessianServiceExporter">

    <property name="service" ref="accountService"/>

    <property name="serviceInterface" value="example.AccountService"/>

</bean>

Now we’re ready to link in the service at the client. No explicit handler mapping is specified, mapping request URLs onto services, so BeanNameUrlHandlerMapping will be used: Hence, the service will be exported at the URL indicated through its bean name within the containing DispatcherServlet’s mapping (as defined above): ‘http://HOST:8080/remoting/AccountService’.

Alternative Way

Alternatively, consider the use of Spring’s simpler HttpRequestHandlerServlet. This allows you to embed the remote exporter definitions in your root application context (by default in ’WEB-INF/applicationContext.xml’), with individual servlet definitions pointing to specific exporter beans. Each servlet name needs to match the bean name of its target exporter in this case

Define a corresponding servlet for this exporter in ‘web.xml’; The exporter getting mapped to the request path /remoting/AccountService. Note that the servlet name needs to match the bean name of the target exporter.

<servlet>

    <servlet-name>accountExporter</servlet-name>

    <servlet-class>org.springframework.web.context.support.HttpRequestHandlerServlet</servlet-class>

</servlet>

<servlet-mapping>

    <servlet-name>accountExporter</servlet-name>

    <url-pattern>/remoting/AccountService</url-pattern>

</servlet-mapping>

Create a HessianServiceExporter in your root application context (e.g. in ’WEB-INF/applicationContext.xml’):

<bean name="accountExporter" class="org.springframework.remoting.caucho.HessianServiceExporter">

    <property name="service" ref="accountService"/>

    <property name="serviceInterface" value="example.AccountService"/>

</bean>

Can be accessed using ‘http://HOST:8080/remoting/AccountService’

Linking in the service on the client

<bean class="example.SimpleObject">

    <property name="accountService" ref="accountService"/>

</bean>

<bean id="accountService" class="org.springframework.remoting.caucho.HessianProxyFactoryBean">

    <property name="serviceUrl" value="http://remotehost:8080/remoting/AccountService"/>

    <property name="serviceInterface" value="example.AccountService"/>

</bean>

Applying HTTP basic authentication to a service exposed through Hessian or Burlap

One of the advantages of Hessian and Burlap is that we can easily apply HTTP basic authentication, because both protocols are HTTP-based. Your normal HTTP server security mechanism can easily be applied through using the web.xml security features

1. Using HTTP invokers
   

Spring Http invokers use the standard Java serialization mechanism to expose services through HTTP

The HTTP invoker is a new remoting model created as part of the Spring Framework to perform remoting across HTTP and using Java’s serialization.

To expose the AccountService (mentioned above) within a Spring Web MVC DispatcherServlet, the following configuration needs to be in place in the dispatcher’s application context:

<bean name="/AccountService" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">

    <property name="service" ref="accountService"/>

    <property name="serviceInterface" value="example.AccountService"/>

</bean>

Such an exporter definition will be exposed through the DispatcherServlet’s standard mapping facilities, as explained in the section on Hessian.

Alternatively, create an HttpInvokerServiceExporter in your root application context (e.g. in ’WEB-INF/applicationContext.xml’):

<bean name="accountExporter" class="org.springframework.remoting.httpinvoker.HttpInvokerServiceExporter">

    <property name="service" ref="accountService"/>

    <property name="serviceInterface" value="example.AccountService"/>

</bean>

Define a corresponding servlet for this exporter in ‘web.xml’, with the servlet name matching the bean name of the target exporter:

<servlet>

<servlet-name>accountExporter</servlet-name>

<servlet-class>org.springframework.web.context.support.HttpRequestHandlerServlet</servlet-class>

</servlet>

<servlet-mapping>

<servlet-name>accountExporter</servlet-name>

<url-pattern>/remoting/AccountService</url-pattern>

</servlet-mapping>

Linking in the service at the client

Linking in the service from the client much resembles the way you would do it when using Hessian or Burlap. Using a proxy, spring will be able to translate your calls to HTTP POST requests to the URL pointing to the exported service.

<bean id=”httpInvokerProxy” class=”org.springframework.remoting.httpinvoker.HttpInvokerProxyFactoryBean“>

<property name=”serviceUrl” value=”http://remotehost:8080/remoting/AccountService”/>

<property name=”serviceInterface” value=”example.AccountService”/>

</bean>

Spring’s HTTP invoker presents a best-of-both-worlds remoting solution combining the simplicity of HTTP communication with Java’s built-in object serialization. This makes HTTP invoker services an appealing alternative to either RMI or Hessian/Burlap.
it is a remoting solution offered by the Spring Framework only. This means that both the client and the service must be Spring-enabled applications. This also implies, at least for now, that both the client and the service must be Java based. And because Java serialization is being used, both sides must have the same version of the classes
(much like RMI).

RMI: When using RMI, it’s not possible to access the objects through the HTTP protocol, unless you’re tunneling the RMI traffic. RMI is a fairly heavy-weight protocol in that it support full-object serialization which is important when using a complex data model that needs serialization over the wire. However, RMI-JRMP is tied to Java clients: It is a Java-to-Java remoting solution.

HTTP Invoker: Spring’s HTTP invoker is a good choice if you need HTTP-based remoting but also rely on Java serialization. It shares the basic infrastructure with RMI invokers, just using HTTP as transport. Note that HTTP invokers are not only limited to Java-to-Java remoting but also to Spring on both the client and server side. (The latter also applies to Spring’s RMI invoker for non-RMI interfaces.)

Hessian and/or Burlap might provide significant value when operating in a heterogeneous environment, because they explicitly allow for non-Java clients. However, non-Java support is still limited. Known issues include the serialization of Hibernate objects in combination with lazily-initialized collections. If you have such a data model, consider using RMI or HTTP invokers instead of Hessian.

JMS can be useful for providing clusters of services and allowing the JMS broker to take care of load balancing, discovery and auto-failover. By default: Java serialization is used when using JMS remoting but the JMS provider could use a different mechanism for the wire formatting, such as XStream to allow servers to be implemented in other technologies.

EJB has an advantage over RMI in that it supports standard role-based authentication and authorization and remote transaction propagation. It is possible to get RMI invokers or HTTP invokers to support security context propagation as well, although this is not provided by core Spring: There are just appropriate hooks for plugging in third-party or custom solutions here.

Spring RMI: the service interface doesn’t extend java.rmi.Remote
and none of its methods throw java.rmi.RemoteException, this trims the interface down a bit. But more importantly, a client accessing the service through this interface will not have to catch exceptions that they probably won’t be able to deal with.

We have no need to implement java.rmi.Remote and no more java.rmi.RemoteExceptions are being thrown around.

For using this service remotely, we’ll use Spring’s RmiServiceExporter

RmiServiceExporter
exports any Spring-managed bean as an RMI service; RmiServiceExporter works by wrapping the bean in an adapter class.

RMI has difficulty working across firewalls.

RMI is Java based so both the client and the service must be written in Java.

RMI uses Java serialization.

The types of the objects being sent across the network must have the exact same version on both sides of the call.

Hessian and Burlap that enable lightweight remote services over HTTP.

Hessian, like RMI, uses binary messages to communicate between client and service.

Burlap, on the other hand, is an XML-based remoting technology,

The only difference is that Hessian messages are binary and Burlap messages are XML

HessianServiceExporter
is a Spring MVC controller.

RMI uses Java’s standard object serialization but is difficult to use across firewalls. On the other side, Hessian/Burlap work well across firewalls but use a proprietary object serialization mechanism.

HTTP invoker perform remoting across HTTP
and using Java’s serialization

Deploy, a *-ds.xml file. You can use any name for the file that you like, as long at the suffix is –ds.xml.

The <local-tx-datasource>
tag defines a particular type of data source that handles local transactions. Three different data source types are available, each of which handles transactions differently.

<local-tx-datasource> : Identifies a data source that uses transactions, even distributed transactions within the local application server, but doesn’t use distributed transactions among multiple application servers.

<xa-datasource>:
Identifies a data source that uses distributed transaction among multiple application servers. This option isn’t shown in the example, but would appear in place of the <local-tx-datasource> tag.

<no-tx-datasource>: Identifies a data source that doesn’t use transactions.

In most cases, you’ll use <local-tx-datasource>
because it handles transactions within a single application server. If you’re clustering your application servers or wanting to use distributed transactions among multiple application servers, then you should use <xa-datasource>.

Note that both <local-tx-datasource>
and <xa-datasource> handle distributed transactions involving multiple data sources.

The difference is that <local-tx-datasource> handles them only within a single running application server, whereas <xa-datasource> handles them among many running application servers.

On the other end of the spectrum, if your applications only read from the database,

Then using <no-tx-datasource>
would be appropriate.

<jndi-name> : Name used to look up the data source in the JNDI namespace. The java: prefix is automatically added to this name.

<min-pool-size>

<max-pool-size>

<idle-timeout-minutes>

<blocking-timeout-millis>

<exception-sorter-class-name>

<check-valid-connection-sql>

<transaction-isolation>

You can define multiple data sources within a single *-ds.xml file

The *-ds.xml file goes into the deploy directory. Yes, that’s right; it’s treated as an application, specifically as a service. Second, you must provide the JAR file for the JDBC driver for the database. Place the driver JAR file in the server/xxx/lib directory.

Once the data source is deployed, the application server creates several MBeans for the data source

You can also place the *-ds.xml file in the EAR file

1. In web.xml (\WEB-INF\web.xml) add the following

<resource-ref>

<description>

Resource reference to a factory for java.sql.Connection

instances that may be used for talking to the database

that is configured in server.xml in TOMCAT.

For JBOSS- jboss-web.xml and *-ds.xml

</description>

<res-ref-name>jdbc/SampleDB</res-ref-name>

<res-type>javax.sql.DataSource</res-type>

<res-auth>Container</res-auth>

</resource-ref>

1. In jboss-web.xml (\WEB-INF\ jboss-web.xml) add the following

<resource-ref>

<res-ref-name>jdbc/SampleDB</res-ref-name>

<jndi-name>java:/jdbc/SampleDS</jndi-name>

</resource-ref>

(res-ref-name in web.xml and jboss-web.xml should be the same)

(jdbc/SampleDS should match with jndi in *-ds.xml)

1. Add the following msssql-ds.xml (at server\default\deploy)

   <datasources>

   <local-tx-datasource>

   <jndi-name>jdbc/SampleDS</jndi-name>

   <connection-url>jdbc:jtds:sqlserver://localhost:1433/sampleDB</connection-url>

   <driver-class>net.sourceforge.jtds.jdbc.Driver</driver-class>

   <user-name>sa</user-name>

   <password>dev123456</password>

   <check-valid-connection-sql>SELECT 1 FROM sysobjects</check-valid-connection-sql>

   <metadata>

        <type-mapping>MS SQLSERVER2005</type-mapping>

   </metadata>

   </local-tx-datasource>

   </datasources>

2. Add the required jar files in \server\default\lib FOLDER

Cheers!

Advice: the job of an aspect is called advice; Advice defines both what and the when of an aspect describing the job that an aspect will perform, advice addresses the question of when to perform the job. Before a method or after the method is invoked.

Joinpoint: A joinpoint is a point in the execution of the application where an aspect can be plugged in. This point could be a method being called, an exception being thrown, or even a field being modified. These are the points where your aspect’s code can be inserted into the normal flow of your application to add new behavior.

Pointcut: pointcuts define the where. A pointcut definition matches one or more joinpoints at which advice should be woven

Aspect: An aspect is the merger of advice and pointcuts