Janis Kazakovs's blog

April 17, 2012

Seam Persistence: Transaction Management Altrenative

With regards to the transaction management, apart from Spring and EJB, you may consider using Seam Persistence. This could be applicable in the scenario when you do not use Spring, but rather Weld, and do not want to run you application inside EJB container. As a result, you need to deal with POJOs and need to make you operations to database transactional. However, manual coding of transactional functionality, whether directly using UserTransaction or by means of either aspects or interceptors, is not an options, simply because you are spoiled by the declarative approach introduced by other frameworks, which allows you to configure transactions at a specific places in your application. In this case, as said above, consider Seam Persistence.

In addition of simply being an alternative, Seam Persistence framework, as described on its official page, also solves certain problems recognized in, for example, Hibernate and EJB architectures, such as LazyInitializationException, manual management of EJB stateful session beans or difficulties related to the propagation of the persistence context between stateful EJB components.

Just for background information, the idea behind the optimistic transaction is not to block access to a datastore entities for a duration of a transaction, where transaction may involve several operations, but assume that the data in a datastore will not be updated by another transaction during the duration of this transaction until the actual commit/flush.This is a common scenario, for example, in case of a web application with some flow functionality, where a user has to enter some data on several pages. As a result, a state of an underlying entity changes after every step and you may design your application to persist a state of your entity on a completion of every step or at the end of the whole flow.

Problem Hibernate's LazyInitializationException is related ti its "stateless" architecture, according to which, a persistence context is scoped to an atomic transaction. As a result, when you access a java.util.Collection property of an entity that was previously passed from service to presentation layers, assuming that the transaction starts and ends on invocation of a service operations, you get LazyInitializationException. This happens because Hibernate wraps java.util.Collection objects with its own, which, in turn, require Hibernate session. FetchType.EAGER won't help you either.

To solve the above problem you can either use Open Session In View Filter solution proposed by Hibernate, which would require you to define Servlet Filter that will start and stop a transaction on a request processing, or unwrap Hibernate collection objects before you pass you entity to presentation layer. The first approach is not always desirable, since it may break you design - you may want to explicitly define a boundary for you transactions to begin and end, which, most probably, will be service layer of you application (if it exists). While the second solution requires an additional and unnecessary processing of the returned entity tree, which also creates and additional overhead at run-time.

The above problem was recognized by EJB 3, which introduces a concept of extended persistence context available in case of the statefull session beans. However, as stated by Seam Persistence, it still has problems mentioned above. Seam claims to solve these problems by providing a conversation scope, something in between the request and session scope of you web application. Seam extends persistence context management model introduced by EJB3 and provides conversation scoped extended persistence context. Which solves, at least, the problem of the propagation of the persistence context between the components of your application, e.g. stateless session beans.

In case of conversation scope, you may still need to manually define the boundary of a conversation by marking a beginning and end of a conversation. When it comes to the Context and Dependency Injection (CDI) API, then you would have to use javax.enterprise.context.Conversation begin() and end() methods to achieve the above. In case of Seam API you would use @Begin and @End annotation. The marking of the boundary of a conversation in your application will, most probably, occur on one of the presentation layer classes, e.g. controller or managed bean.

17 Apr 2012 15:09:34

April 13, 2012

JSF: Include JavaScript File on JSF Page Using outputScript Tag

The use case is simple - you use JSF and have some JavaScript code written in a separate file, which you want to include on your page.

You may either use HTM <script> tag as follow:

or you may use JSF outputScript tag:

<h:outputScript library="js" name="common.js" target="head" />

The official description of the outputScript tag specifies the following:

Render the markup for a <script> element that renders the script Resource specified by the optional name attribute and library attributes.

You may already know it, but in case you don't, all resources in JSF should be placed under resources folder in the root of your web application, i.e. in the same level as WEB-INF folder. As a result, every sub-folder of resources folder will be considered by JSF2 as a library and can be referenced from the library attribute on JSF component.

This is the example of our JSF page:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<h:body>

<h:outputScript library="js" name="common.js" target="head" />

<h1>INDEX PAGE</h1>

</h:body>

</html>

which will be rendered as follows:

<?xml version="1.0" encoding="UTF-8"?>

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<head>

</script>

</head>

<body>

<h1>INDEX PAGE</h1>

</body>

</html>

On your outputScript tag I use the following attributes:

library - a name of a folder under resources folder as explained above;
name - a name of your JavaScript file located under your library;
target - "the target area for which this resource will be rendered. For example, target="head" would cause the resource to be rendered within the head element"

You may also download an example: Download Jsf2-outputScript

13 Apr 2012 11:08:29

April 11, 2012

Application Integration.From Simplicity to Complexity

Every application is built to provide a specific functionality to a target user. In you daily life you use Gmail for emails, Picasa for photos, Facebook for socializing, Twitter for "spamming" of millions of followers. These are self-contained applications build with a specific purpose. Even though there is no explicit integration between these applications, some level of integration already exists. You may share you Facebook post on Twitter or vice versa, you may post a blog and share it through Like and Tweet buttons on a page, you may make a photo with your phone through Instagram and make it available to other applications.

With the business it is the same, but more heavyweight. You have customer relationship management systems used by sales, accounting system used by finance, order management system used by clients, shipping system used by delivery department or content management system used by the whole company. In the real enterprise these systems never work separately, they are always integrated. What kind of integration it is - is another question? Whether it is a person who manually enters data from one system to another or an automated solution based on the enterprise service bus depends on the integration solution implemented in that particular company.

In most of the cases, when it comes to integration of applications, you deal with either data or functionality. Example of data could be a customer address, while that of functionality - get/change customer address. There is nothing super complex to store that data in some kind of a repository and make the above functionality available to an end user, by either implementing it or invoking an existing one. But this is true only when the above is done in a scope of a single system. As soon as that data and functionality need to be shared across several systems, you need to start thinking about the integration solutions.

Here is an example. Customer data is used by several applications within an enterprise - accounting (to compute a sales tax), shipping (to label a shipment), billing (to send an invoice) and customer relationship system (to modify an address). The first question is where to store data? In each system's own repository or in some shared repository? In case data is owned by each system, how do you keep data in synch? If data is shared what is its format? Is it the same across all systems? If not what changes do you need to do to each system in order to make them compatible with the shared data format? Similar questions can be asked about the functionality to retrieve and modify customer address, since it can be implemented either inside each system or a dedicated business function invoked by the above systems.

Several solutions are known to the above problem:

Data Replication
Shared Business Functions
Service Oriented Architecture
Distributed Business Processes

Data Replication

Data Replication solution would be applicable in the scenario when each of the above systems would have its own repository to store customer address. Therefore, when a customer contacts a customer relationship department to change its address and change is done in the system, the change is also propagated to other systems. Here is an example of several strategies you may implement:

use data replication functionality build into the databases provided by some of the database vendors;
come with a custom solution that exports data from one system into, for example, file and imports it into another system;
use some messaging system to transport data as messages;

Please, note that when data is stored in different repositories controlled by different system, it will, most probably, have different format. This happens because every department owning that system dictates the structure of the storage data. Therefore, if, at some point, you decide to store data in a single repository instead of having it scattered across several ones, you may end up being involved in the political discussions, since now, every department needs to agree on a common format of data. As a result, integration becomes more complex.

Shared Business Functions

In the same way that many business systems store duplicate data, they also tend to duplicate functionality. Taking the example of the above system, the customer relationship system would implement Change Customer Address function, while all the other systems, namely, accounting, shipping and billing systems, would implement Get Customer Address function. As you can see, there is already a duplication of functionality.

What you can do here, in order to remove this duplication, is to externalize that functionality as Shared Business Function, implement it once and make it available to other systems. This is very much similar to the situation with the Data Replication described above. In this case, however, you may also think about storing data in a single repository, instead of having it stored in several.

Service Oriented Architecture (SOA)

SOA is a known concept, but let us look at it as an extension of a concept described in Shared Business Functions. You may look at a service as a business function that has a well-defined interface and is universally available. When you enterprise assembles a decent amount of business functions shared among several systems, the management of these function becomes an important task. In order to properly manage them you need to do two things. First, you make these services discoverable, by creating some kind of service directory that lists all known to it service. Second, you describe an interface of each service so that an external system that sends a request to that service is able to negotiate a contract with it. Thus, the discovery and negotiation are the two main elements that make up a Service Oriented Architecture.

Distributed Business Processes

Let us make a step further. So far, you have shared functions that support your business. You have made them universally available by describing interface to each of your functions and by making them discoverable, thus transforming them to services. However, such business function as Change Customer Address, alone, is, probably, not of much use to your business. The problem is that even a simple business process spans several systems. For example, to verify a status of an order a customer representative may need to check order management system running on a mainframe as well as access another system that manages orders placed over the Internet. Therefore, having well-defined atomic functions is not sufficient to execute your business processes. What is missing is some kind of coordination. What you need is some business process management component that will coordinate execution of business functions across several systems.

Summary

What I wanted to show in this article is that integration has several levels. Integrating two systems at data level may be as simple as exporting data from one system and importing it into another, but when you need to share that data across several systems, either in the predefined data format or through some business function, you may end up creating more complex solution. As a result, your shared business function becomes a discoverable service with the well-defined interface and your business processes are described in some dedicated business process management component that coordinates invocation of your services.

11 Apr 2012 14:00:19 | EAI

March 27, 2012

JAXB2:Custom Adapter on Model Generation

In this post I will give an example of generation of Java class model from an XSD using custom adapter for a date element. By default, the date fields of the generated class model are of XMLGregorianCalendar type. However, you do not want to write a custom wrappers to convert java.util.Date to XMLGregorianCalendar, but want directly operate with java.util.Date object when dealing with the model classes.

One way to do it is to use @XmlJavaTypeAdapter annotation on your models date fields. But, you do not want to manually modify generated model classes since, in your situation, you model is regenerated frequently. Thus, you need a way to tell to your JAXB binding compiler (xjc) how exactly it should act upon date fields.

At the bottom of this post you will find a link to the working project. You may use it as you wish and adapt to your problem.

This example is composed of the following component:

java 5
maven 2
jaxb 2.0
maven-jaxb2-plugin 0.8.1

Maven project

To generate class model from XSD I will use Maven plug-in. All you need is to specify the following details in you POM:

JAXB dependencies

<dependencies>
<dependency>
<groupId>javax.xml.bind</groupId>
<artifactId>jaxb-api</artifactId>
<version>2.0</version>
</dependency>
<dependency>
<groupId>com.sun.xml.bind</groupId>
<artifactId>jaxb-impl</artifactId>
<version>2.0</version>
</dependency>
</dependencies>

Java version, which should be at least 5

<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>
<encoding>UTF-8</encoding>
<configuration>
</plugin>

JAXB plug repository

<pluginRepositories>
<pluginRepository>
<id>maven2-repository.dev.java.net</id>
<url>http://download.java.net/maven/2</url>
<layout>default</layout>
</pluginRepository>
<pluginRepository>
<id>maven-repository.dev.java.net</id>
<url>http://download.java.net/maven/1</url>
<layout>legacy</layout>
</pluginRepository>
</pluginRepositories>

JAXB plug-in itself

<plugin>
<groupId>org.jvnet.jaxb2.maven2</groupId>
<artifactId>maven-jaxb2-plugin</artifactId>
</plugin>

Schema

I will use the following simple schema for the example:

<s:schema xmlns:s="http://www.w3.org/2001/XMLSchema">
<s:element name="getValue">
<s:complexType>
<s:sequence>
<s:element name="date" type="s:dateTime"/>
</s:sequence>
</s:complexType>
</s:element>
</s:schema>

It has all I need for my example; namely, simple date element.

If you generate the model at this stage you will get the following model class:

@XmlRootElement(name = "getValue")
public class GetValue {
@XmlElement(required = true)
@XmlSchemaType(name = "time")
protected XMLGregorianCalendar date;
...
}

As you can see, the date property is of type XMLGregorianCalendar and as you remember, our goal is to have it of type java.util.Date.

Place your schema file under src/main/resources directory. This is the default location the maven-jaxb2-plugin is looking for schemas. You can configure another location by using schemaDirectory element on a plugin.

Create Adapter

The first thing we need to do is to create an adapter class that will be responsible for the conversion of date values from/to XMLGregorianCalendar and java.util.Date. In order to plugin our custom implementation of the adapter we will need to comply with the contracts defined by JAXB. Namely, we'll have to implement javax.xml.bind.annotation.adapters.XmlAdapter interface.

The XmlAdapter JavaDoc specifies the following:

Some Java types do not map naturally to a XML representation, for example HashMap or other non JavaBean classes. Conversely, a XML repsentation may map to a Java type but an application may choose to accesss the XML representation using another Java type... In both cases, there is a mismatch between bound type , used by an application to access XML content and the value type, that is mapped to an XML representation.

This abstract class defines methods for adapting a bound type to a value type or vice versa...

In other words, we need to implmement two methods:

XmlAdapter.marshal
XmlAdapter.unmarshal

Below is of the the possible implementations:

public class DateAdapter extends XmlAdapter<String, Date> {
public Date unmarshal(String value) {
try {
return new SimpleDateFormat("yyyy-MM-dd").parse(value);
} catch (ParseException e) {
throw new IllegalArgumentException(e);
}
}
public String marshal(Date value) {
return new SimpleDateFormat("yyyy-MM-dd").format(value);
}
}

Create JAXB binding

In order to tell JAXB binding compiler how it should deal with the date types I will customize JAXB date binding by means of custom binding declaration made in external file passed to the binding compiler. I will create a binding file - call it date-binding.xsd.

Note: There are two types of custom binding declarations: inine and external file. In case of inline declarion the custom binding declation is made inside a schema, e.g.

<schema ...>
<complexType name="size">
<annotation>
<appinfo>
<jaxb:class name="widgetSize" />
</appinfo>
</annotation>
</complexType>
...
<schema>

Since, in my example I am using the external file (date-binding.xsd) to declare JAXB binding the declaration will look as follows:

<jaxb:bindings
xmlns:jaxb="http://java.sun.com/xml/ns/jaxb"
    xmlns:xsd="http://www.w3.org/2001/XMLSchema"     xmlns:xjc="http://java.sun.com/xml/ns/jaxb/xjc"
    jaxb:extensionBindingPrefixes="xjc"
    jaxb:version="2.0">
<jaxb:globalBindings >
<xjc:javaType name="java.util.Date"
xmlType="xsd:dateTime"
adapter="org.devtoolbox.adapter.DateAdapter"/>
</jaxb:globalBindings>
</jaxb:bindings>

Place the binding file under the same directory you have placed your schem, namely src/main/resources.

Few things to note:

to declare date binding I am using <xjc:javaType> customization and not <jaxb:javaType> customization. <xjc:javaType> allows you to specify an XmlAdapter-derived class, instead of parse&print method pair.
I am using <jaxb:globalBindings > to apply binding to all dateTime elements defined withing a schema. Alternative would be to use the following construct:

<jxb:bindings schemaLocation = "xs:anyURI">
<jxb:bindings node = "xs:string">*
[your binding declaration]
<jxb:bindings>
</jxb:bindings>

where schemaLocation is a URI reference to the remote schema and node is an XPath 1.0 expression that identifies the schema node within schemaLocation to which the given binding declaration is associated.

Example Maven Project

As promised, below is the example. You can either

access it via SVN : svn co https://devtoolbox.googlecode.com/svn/trunk/jaxb-custom-adapter-binding
or download from here: Download Jaxb-custom-adapter-binding

When you get the project run "mvn compile" command from a command line (make sure you have maven installed). The generated model classes will be located under target directory.

27 Mar 2012 12:07:16

March 17, 2012

Challenges of Enterprise Integration Projects

The difficulty of integration projects at enterprise level is related not only by the technological challenges, but also to the social aspects within the organisation. Conway's law suggests that ¨the interface structure of a software system will reflect the social structure of the organization(s) that produced it.¨This law is based on the reasoning that in order for two systems to interact correctly, the designers of the these systems should communicate with each other.

For example, if a company consisting of three units e1, e2 and e3 is given an assignment to develop a product X and this assignment is handed over to these three units, then result of their work will be three subsystems - s1, s2 and s3. More to that, the interfaces between these systems will reflect the quality and nature of the real world interpersonal communications between the representatives of these units.

Conway's law was also rephrased by Harrison: "If the parts of an organization (departments, teams and etc) do not reflect the essential parts of a product or, if the interaction between the parts of an organisation do not reflect the interaction between the parts of a product, then product is in trouble. Therefore, make sure that organization is compatible with an architecture of a product."

In other words, in order for an integration project to be successful, the communication should be established not only between the systems, but also between business units of an organisation for which an integration project is executed. This may require a significant shift in organisation´s politics, which will make you to deal not only with the technological obstacles.

17 Mar 2012 22:45:19 | EAI

March 11, 2012

openshift: security key config

When working with rhc you communicate with OpenShift from your computer using SSH, which utilizes security keys located in your $HOME/.ssh directory. When you generate new keys using, for example, ssh-keygen -t rsa, you get id_rsa and id_rsa.pub files in your $HOME/.ssh folder. You may decide to give different names to you keys, e.g. myopenshift_rsa and myopenshift_rsa.pub, just to be able to distinguish them from other keys you may already have. In this case you may also want to provide a separate SSH configuration in your OpenShift application in $HOME/.ssh/config file, which will look as follows:

Host *.rhcloud.com

IdentityFile ~/.ssh/myopenshift_rsa

VerifyHostKeyDNS yes

StrictHostKeyChecking no

PasswordAuthentication no

UserKnownHostsFile ~/.ssh/myopenshift_known_hosts

Do not forget to set the right permission to $HOME/.ssh/config file:

chmod 600 $HOME/.ssh/config

11 Mar 2012 17:18:59 | Java, OpenShift

November 03, 2011

AspectJ:Compile Time Weaving:CTW

Just to give an alternative to the Load Time Weaving with AspectJ, which I have explained in my two previous post (LTW Abstract Aspect, LTW Concrete Aspect), I will describe here how you can achieve the same with the Compile Time Weaving (CTW).

In case of LTW you had to configure the AspectJ weaver in aop.xml file and make it available in the class path. In addition to that, you had to enable a "weaving agent" by providing -javaagent:<pathto>/aspectjweaver.jar option to your JVM. For CTW you may skip the both steps and invoke ApectJ compiler that will take class files as input and produce woven class files as output. Afterwards, on execution of your code, the weaving process output class is loaded into JVM as a normal Java class. The difference with the LTW here is that in case of LTW the weaving is defered until the point that a class loader loads a class file and defines that class to JVM.

Assuming you are using Maven, in order to trigger AspectJ weaving process you will have to use aspectj-maven-plugin and configure it appropriately in your pom.xml. This is how it will look like:

<plugin>

     <groupId>org.codehaus.mojo</groupId>

     <artifactId>aspectj-maven-plugin</artifactId>

    <version>1.4</version>

    <configuration>

        <complianceLevel>1.6</complianceLevel>

    </configuration>

    <executions>

        <execution>

            <goals>

                <goal>compile</goal>

                <goal>test-compile</goal>

            </goals>

        </execution>

    </executions>

</plugin>

If you develop you aspects using the annotation based development style (the way it was done in the two previous posts mentioned before) then you have to specify an appropriate Java compliance level using <complianceLevel> tag.

In <execution> tag you may also specify the Maven build phases during which the AspectJ weaving of the classes should be triggered. In case of the <goal>compile</goal> configuration the AspectJ weaver will weave all your main classes, while in case of the <goal>test-compile</goal> configuration - your test classes.

Thats actually it. I am not going to explain the details of an actual aspect declaration, since I have already done that in the referenced posts; you may just have a look. Otherwise, you may directly look into the working example, which you may access here: Logging Aspect Implementation using Compile Time Weaving

3 Nov 2011 17:01:07

November 02, 2011

AspectJ:Load Time Weaving:Concrete Aspect

In my previous post I was describing the scenario of using abstract aspect in case of the AspectJ Load Time Weaving. In this post I will just mention the alternative to that approach, namely declaration of concrete aspect. You may compare two approach and pick up the one that better suits your need.

The same as in the previous scenario with the abstract aspect you do the following steps:

Create @Aspect annotated Java class;
On your aspect class declare a pointcut method;
On you aspect class declare desired advices;
In weaver configuration file declare concrete aspect;

Create @Aspect annotated Java class

Straightforward Java class declaration with @Aspect annotation

public @Aspect class LoggingAspect

On your aspect class declare a pointcut method

The difference from the abstract class declaration is that you do not need to declare a simple abstract pointcut, but rather a normal pointcut. By doing that you can use capabilities offered to you by AspectJ, as for example, passing @Loggable annotation to the pointcut method, which later can be passed to the executing advices of you aspect.

@Pointcut ( "within(com.company.service.*) && execution(* *(..)) && @annotation(loggable)" )

public void logging ( Loggable loggable ) { }

You can also declare a static pointcut and perform custom conditional logic in your pointcut method in order to determine whether your aspect should be weaved in the identified by the pointcut join point. Static pointcut method should be public, static and return boolean.

@Pointcut ( "within(com.company.service.*) && execution(* *(..)) && @annotation(loggable) && if()" )

public static boolean logging ( Loggable loggable ) {

boolean result = false;

// evaluate result value

return result;

}

On you aspect class declare desired advices

In case of the advices there is also a slight change when comparing to the abstract aspect declaration. Namely, the value of the @Before advice annotation should reflect the fact that your pointcut method accepts Loggable parameter, i.e. @Before(value="logging(loggable)"):

public @Aspect abstract class AbstractLoggingAspect {

@Before ( value = "logging(loggable)", argNames = "joinPoint,loggable")

public void enteringMethod ( JoinPoint joinPoint, Loggable loggable ) {}

}

Please, not that you could as well declare your pointcut methed as follows:

@Pointcut ( "within(com.company.service.*) && execution(* *(..)) && @annotation(org.devtoolbox.logging.aspect.annotation.Loggable)" )

public void logging ( ) { }

i.e. without passing Loggable argument to the pointcut method. As a result you advice declaration will look the same way the advice declaration for the abstract aspect looked like:

public @Aspect abstract class AbstractLoggingAspect {

@Before ( value = "logging()", argNames = "joinPoint" )

public void enteringMethod ( JoinPoint joinPoint ) {}

}

In weaver configuration file declare concrete aspect

Declare your aspect to the weaver in the aop.xml configuration file:

<aspectj>
    <aspects>
        <aspect name="org.devtoolbox.logging.aspect.LoggingAspect"/>
    </aspects>
</aspectj>

aop.xml file should be placed under META-INF directory located on the class loader search path.

The working scenario of the above logging aspect is available from the following SVN location: Concrete Logging Aspect Implementation

The same as in case of abstract aspect, in order to use LTW you need to enable it in your application. Do that by configuring Java agent using -javaagent:<pathto>/aspectjweaver.jar option and by providing it to your JVM.

2 Nov 2011 21:54:17

November 01, 2011

AspectJ:Load Time Weaving:Abstract Aspect

AspectJ Load Time Weaving (LTW) allows you to define an abstract aspect, containing implementation of the defined by you advices, and separately specify a pointcut in a weaver configuration file, i.e. aop.xml. This approach may be useful in situations when you want to externalize the configuration into a file. For example, for the deployed application, you may still access the file, change the configuration and restart application for your changes to take effect, without redeploying that application.

The steps to archive the above are relatively simple, assuming the annotation-based style of aspect declaration is used:

Create @Aspect annotated abstract Java class;
On your abstract aspect class declare simple abstract pointcut;
On your abstract aspect class declare desired advices;
In weaver configuration file declare concrete aspect;

Create @Aspect annotated abstract Java class

This should be simple to accomplish:

public @Aspect abstract class AbstractLoggingAspect {}

Declare simple abstract pointcut

A simple abstract pointcut is the pointcut that does not expose state through args(), this(), target(), if() and is the one declared on the abstract method, which has no arguments and returns void. In other words, just do the following:

public @Aspect abstract class AbstractLoggingAspect {

@Pointcut public abstract void logging ( );

}

Declare desired advices

This is when you declare advices on you abstract advice class and specify behaviour of these advices. For example, for before advice you will have the following:

public @Aspect abstract class AbstractLoggingAspect {

@Before ( value = "logging()", argNames = "joinPoint" )

public void enteringMethod ( JoinPoint joinPoint ) {}

}

Do not forget to specify the right @Before advice value, which should correspond to the name of the method on which you have specified @Pointcut annotation. In the example above it is value = "logging()".

Declare concrete aspect inline in weaver configuration file

As a last step you have to declare a concrete aspect extending an abstract one created previously and, as already mentioned in the beginning, this declaration should be done in the weaver's configuration file using concrete-aspect tag.

<concrete-aspect name="org.devtoolbox.logging.aspect.LoggingAspect"extends="org.devtoolbox.logging.aspect.AbstractLoggingAspect">

...

</concrete-aspect>

It is enough to specify two peaces of information in the concrete-aspect tag. These are (1) the fully qualified name of your abstract aspect and (2) the name of you concrete aspect. The first one is specified in the extends attribute of the concrete-aspect tag, while the second one in the name attribute.

One thing to note, the concrete aspect class name should be a valid fully qualified Java name, since this is the name that will be given to an actual class that will be generated by AspectJ.

Afterwards, you should configure the pointcut expression for the concrete aspect you have declared as follows:

<aspectj>

    <aspects>

        <concrete-aspect

            name="org.devtoolbox.logging.aspect.LoggingAspect"

            extends="org.devtoolbox.logging.aspect.AbstractLoggingAspect">

            <pointcut name="logging"

                expression="within(com.company.service.*) &&

    execution(* *(..)) &&

                    @annotation(org.devtoolbox.logging.aspect.annotation.Loggable)"/>

        </concrete-aspect>

    </aspects>

</aspectj>

Note, that the name attribute of the pointcut tag should correspond to the name of the abstract method of your abstract aspect on which you have specified @Pointcut annotation, i.e. loggin.

Another think to not is that your aop.xml file should be placed under META-INF directory located on the class loader search path.

Now, you should be ready to execute you abstract aspect. In order for you to enjoy the result of the effort of reading the above post, I provide an implementation of a simple logging scenario. It is available from the following SVN location: Abstract Logging Aspect Implementation

Please, note that in order to use LTW you need to enable it in your application. In order to do that you need to use an AspectJ a load-time weaving agent, which can be configured by specifying -javaagent:<pathto>/aspectjweaver.jar option to your JVM.

1 Nov 2011 17:47:05

June 27, 2011

Jackrabbit:Glassfish 3.1:JCA Resource Adapter Deployment

This post gives instructions on the deployment of Jackrabbit JCA Resource Adapter on Glassfish application server. I describe deployment steps in this post, since I wasn't able to find any decent description to do the above and, thus had to figure it out myself. Even though, it isn't a painfull process at all, it took a little bit of time.

I have used the following products:

In order to set up Jackrabbit JCA Resource Adapter on Glassfish you will have to do the following:

Make JCR API known to Glassfish;
Install Jackrabbit JCA Resource Adapter on Glassfish;
Configure Connector Connection Pools on Glassfish;
Configure Connector Resources on Glassfish;

Make JCR API known to Glassfish

By making JCR API known to Glassfish I mean dropping jcr-2.0.jar library under the <glassfish-install-dir>/glassfish/domains/<your-domain>/lib/ directory. You may need to restart your Glassfish instance.

Install Jackrabbit JCA Resource Adapter on Glassfish

Assuming you have downloaded the required artifacts and started up the Glassfish instance, through the Glassfish web admin UI deploy jackrabbit-jca-2.2.7.rar file using the Applications menu on the Commons Task tree.

Configure Connector Connection Pools on Glassfish

Create new Connector Connection Pools by selecting previously installed jackrabbit-jca-2.2.7.rar in the Resource Adapter field and give name in the Pool Name field, e.g. my-pool.

After clicking Next you will be redirected to the second page. On this page you will have to configure two properties, namely ConfigFile and HomeDir.

ConfigFile property points to the Jackrabbit repository.xml file, e.g. ~/repo/repository.xml
HomeDir property points to the location of the Jackrabbit repository on you file system, e.g. ~/repo;

Configure Connector Resources on Glassfish

Finally, create Connector Resource by selecting previously created Connector Connection Pool. You will be able to select you my-pool from the drop down Pool Name menu. Give JNDI Name to you connector resource, e.g. jcr/resource and click OK button. You are done!

Now, you should be able to access JCR repository from you class by injecting as follows:

@Resource ( name = "jcr/repository" )

private Repository repository;

Enjoy!

27 Jun 2011 11:00:52