Desde hace años, cada vez que se pone de moda un nuevo lenguaje de programación, junto a frameworks orientados al desarrollo web ágil y rápido, se suele decir que Java va a morir, en cambio, sigue ahí, y con más energía que nunca.

Ya pasó con Python y el framework Django, junto con Ruby y el famoso Rails, que además hacen jocosas parodias sobre el lenguaje Java, cuando en realidad Java es un lenguaje, una máquina virtual y una plataforma. Pero claro, si quieres hacer lo mismo que esos frameworks luego tendrías que añadir cualquiera de los cientos de frameworks que existen en el mundo Java: Hibernate, JPA, Spring, Struts, JSF, EJB,…

Pues bien, se acabó el rollo, con Spring Roo se puede realizar un desarrollo ágil igual que Django o Rails, pero llegando aún más allá. Incluye una consola donde, haciendo uso de autocompletado mediante TABs, puedes ir creando, paso a paso, todo lo necesario para implementar una aplicación web Maven2, haciendo uso de los frameworks tipo del mundo Java: Hibernate, Spring, MVC,… y con poco más que ir siguiendo los pasos que te indica la propia ayuda en línea de la consola.

El vídeo siguiente es muy autoexplicativo de la potencia y rapidez de Roo:

Anyone designing a high performance transaction processing system has already needed at least a caching solution for increasing response time on frequently used data. But sometimes these data might become bigger than usual, those are times when you need a sofisticate

WebSphere eXtreme Scale Book

solution, something that can automatically fetch data from a slower storage, offload when not necessary, split its contents between various nodes, …

If you require something like this then you’ll notice that you need a DataGrid solution.

By now you’ll be asking yourself why I am on that subject? Recently I’ve been kindly invited to review a book about IBM WebSphere eXtreme Scale from Packt Publishing.

Apart from this, I work on a project where we were already evaluating WebSphere eXtreme Scale as a replacement for WebSphere DynaCache.

If you are in a hurry and want to have a sneak peak on the book contents, take a look at the sample chapter (Chapter 7: “The DataGrid API”) available for free on Packt Publishing website.

I am doing some work with Apache Maven 2 today. Never touched this stuff before. I am following a tutorial at IBM developerWorks. However if you sitting behing a proxy you will receive a “repository central will be blacklisted” fatal error. The execution will fail. Although it seems that we are searching for a “I am feeling lucky” google response, this is not the case. I didn’t find a clear answer with the first glance.

If you are facing the same problem we need to set a proxy via the command line like this:

prompt>mvn … -DproxySet=true -DproxyHost=1.2.3.4 -DproxyPort=8080.

Setting the proxy details right is the solution here. You will be able now to create your first archetype.

As a first step in order to prepare for the SCBCD exam, I’ll set up a programming environment. As I work with Eclipse in my job, I will do my exercises with Eclipse Galileo. I think Netbeans will be easier. We used it on the training course and it works really fine. Eclipse will be harder I think.

As with every Eclipse distribution, you’ll only have to download and unzip it. No installation. For Web- and Application Server I’ll use the Glassfish Server. As far as I can tell and I’ve learned in the sun training course, this is an implementation very close to the JavaEE and the Glassfish server is also very fast and lightweight. Usually I work with an IBM Websphere Server, which I cannot recommend because it is really fat and slow. So if there isn’t a special feature which only Webspere can provide, use something different.

Now I am starting to install and integrate the Glassfish Server into the Eclipse distribution.

Since Glassfish needs a whole JDK and not only a JRE to run, I started with the download of the recent JavaEE 5 SDK which includes the JDK 6 and the Glassfish 2.1 application server. This package should include everything necessary to start. The link to the download can be found here. After downloading the SDK, I added the JDK6 to the Java Runtime Environment. This is necessary to make the Glassfish server work correctly. Next step is to add the installed Glassfish Server to Eclipse. In the view Servers, add a new Server and download an additional adapter. There you found the Glassfish adapter to select. The installation failed on my system. Can these be anymore complex? Searching the internet I found the following solution. This worked for me.

Then create a new Glassfish server and start it from the workbench. Usually you will find the server here

I lost almost 3 hours to make the bookstore1 application to work. This web app is a part of Java EE tutorial provided by Sun,
however the first and most important application cannot be deployed by GlassFish. It returns the following error

HTTP Status 500 -

message

descriptionThe server encountered an internal error () that prevented it from fulfilling this request.

exception

Exception [EclipseLink-4002] (Eclipse Persistence Services - 1.0.1 (Build 20080905)): org.eclipse.
persistence.exceptions.DatabaseException
Internal Exception: java.sql.SQLSyntaxErrorException: Table/View 'WEB_BOOKSTORE_BOOKS' does not exist.
Error Code: -1
Call: SELECT BOOKID, INVENTORY, PRICE, FIRSTNAME, SURNAME, CALENDAR_YEAR, ONSALE, TITLE,
DESCRIPTION FROM WEB_BOOKSTORE_BOOKS WHERE (BOOKID = ?)
	bind => [203]
Query: ReadObjectQuery(com.sun.bookstore.database.Book)

note The full stack traces of the exception and its root causes are available in the GlassFish/v3 logs.

GlassFish/v3

In order to solve the problem you need to

1. First create database connection to jdbc:derby://localhost:1527/sun-appserv-samples (and not to bookDB)
2. execute the tutorial.sql

În feed-urile urmărite în dimineața asta am dat de cursul ăsta de EJB3. Ce are special? Mi-a placut că este un curs practic care constă în construirea unor aplicații pornindu-se de la niște cerințe concrete. Suportul din partea autorului scade gradual în construirea aplicațiilor. Este interesant că oferă o abordare completă a soluției aplicațiilor, pornind de la diagrame UML, arhitectură și cod.

Este inclusă și o carte electronică gratuită, “Mastering Enterprise JavaBeans 3.0”, ca suport teoretic. Soluțiile complete (proiecte Netbeans) sunt oferite de autor. La o primă vedere, mi se pare un curs util și o abordare care te invață prin practică.

Glassfish Server 2.1 yüklemesi sırasında yönetim ekranına giriş yaptığım zaman hata veriyordu ve yönetim ekranına ulaşabilmek için sayfayı tekrar yenilemeniz gerekiyordu. Bu arada belirtmeliyim ki sorun aldığım bilgisayarda  “windows XP English” yüklü , bölgesel seçenekleri ise türkçe. Sorundan şu adımları izleyerek kurtulmamız mümkün.

1. Bilgisayarınızdan “D:\Sun\AppServer\domains\domain1\config” şu yola gidin.

2. “domain.xml” dosyasını açın ve  jvmoptions yazan ayarları bulun şu satırları ekleyin.

“<jvm-options>-Duser.language=en_us</jvm-options>”

3. Serverı yeniden başlatın sorunun çözülmüş olması lazım. Zira benimki bu şekilde düzeldi.

Avilabs.
mustafaaoglu[at]gmail.com

Continuing with the posts about JCA lets now have a look on the specifics of an Inbound JCA connector. As already mentioned in a previous post the term inbound is related to the flow of the call on your application.
The endpointActivation method plays a key role in an Inbound adapter. This is the method that is triggered by the container on each of the Activation Specs you have configured on your Application Server instance. This is also the point where you start your monitoring thread (FooMonitor in our example). Remember that this monitoring object has to have access to a number of key container classes such as MessageEndpointFactory implementation and also WorkManager.
Apart from container objects you’ll certainly need to have the ActivationSpec object passed on the endpointActivation method since it carries on the configuration provided for this activation spec (taking JMS as an example it’d be host, queue, username, …).
Another point to remember is that you’ll need to have a reference to the monitor threads that were activated since on container shutdown it’ll invoke the endpointDeactivation method and you’ll need to retrieve the related monitor thread and stop its execution.

Inbound Connector classes

Too much text lets now have a look on some diagrams:

As you may have already guessed, FooMonitor is the thread that will poll for events and schedule their notifications through the WorkManager. You should never use the monitor thread for the notification since it’ll be blocked during notification denying the sending of other notifications. That’s the reason you should schedule an asynchronous notification using WorkManager.

FooNotification implementation

Skipping to the FooNotification class, its implementation will be something like the following code:

public void run() {
	MessageEndpoint endpoint = null;
	try {
		endpoint =  messageEndpointFactory.createEndpoint(null);
		((FooListener) endpoint).onMessage(msg);
	} catch (Exception ex) {
		logger.error("Error on foo notification" ,ex);
	} finally {
		if (endpoint != null)
			endpoint.release();
	}
}

As already mentioned, that’s the point where the MessageEndpointFactory is used. It provides us proxies for FooMDB classes. Remember to ALWAYS invoke release after using this proxy otherwise your container may run out of proxies since it’ll think you are still using them.
Another aspect not really detailed is the msg parameter on the onMessage method: this one is dependent on your ResourceAdapter – You are the one responsible for defining it (unless you have chosen a regular API like JMS).

Citind cartea despre care v-am vorbit într-un articol anterior, am descoperit niște clase despre care nu mai auzisem până acum: interceptorii.

Prezentarea lor începe cu o scurtă introducere despre AOP, noțiune nouă pentru mine. După cum am înțeles, AOP înseamnă să “decorezi” logică refolosibilă, în general, cu diferite funcționalități, fără aduce modificări asupra logicii menționate. De exemplu, AOP ar putea fi transformarea ușoară a unui Session Bean într-un web service sau într-un RESTful service.

În Java EE “aspectele” sunt numite interceptori. Un interceptor este o clasă cu o metodă adnotată și are controlul complet asupra execuției unei metode. Un interceptor este “atașat” unei clase cu ajutorul adnotării @Interceptors({interceptori}). Între acolade este o listă de clase de interceptori.

Iata un exemplu scurt de interceptor:

   1: public class InterceptorDeTest {

   2:  

   3:     @AroundInvoke

   4:     public Object interceptM(InvocationContext ic) {

   5:  

   6:         //fă ceva

   7:         return ic.proceed();

   8:     }

   9: }

Și o clasă care are atașat un interceptor:

   1: @Stateless

   2: @Interceptors({InterceptorDeTest.class})

   3: public class ClasaDeTest{

   4:     public String helloWorld() {

   5:         return "HelloWorld!";

   6:     }

   7: }

În momentul în care este apelată metoda helloWorld firul execuției va trece mai întâi prin interceptor. Acesta execută prelucrările sale și apelează metoda proceed() care are ca efect trecerea la executarea codului următorului interceptor din listă, dacă există, sau a metodei interceptate (în cazul nostru, metoda helloWorld()).

Interceptorii pot fi folosiți pentru diferite inițializări sau validări înainte sau după execuția unei metode. În cartea lui Adam Bien e și un exemplu cu interceptori în care se pot redenumi firele de execuție a unei aplicații în funcție de metoda pe care o execută, pentru o mai bună observare într-un profiler sau într-un dump, scăpând astfel de numele random și lipsite de înțeles date firelor de execuție.

PS: Un articol general despre utilizarea interceptorilor și cel cu redenumirea thread-urilor.

With some search and experiments, I figured out the following maven dependencies for a basic JSF project. These dependencies also allow autocompletion of JSF tags in the IDEs like eclipse and intellij idea. I post this for my own reference and may be someone searching for it.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
  <modelVersion>4.0.0</modelVersion>
  <groupId>com.hardik.jsfinaction</groupId>
  <artifactId>HelloJsf</artifactId>
<packaging>war</packaging>
  <version>1.0</version>
  <name>HelloJsf Maven Webapp</name>
  <url>http://maven.apache.org</url>
  <dependencies>
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <version>4.0</version>
      <scope>test</scope>
    </dependency>
    <dependency>
        <groupId>jstl</groupId>
        <artifactId>jstl</artifactId>
        <version>1.1.2</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>javax.faces</groupId>
        <artifactId>jsf-api</artifactId>
        <version>1.2_02</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>javax.faces</groupId>
        <artifactId>jsf-impl</artifactId>
        <version>1.2-b19</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>taglibs</groupId>
        <artifactId>standard</artifactId>
        <version>1.1.2</version>
        <scope>compile</scope>
    </dependency>
    <dependency>
        <groupId>javax.el</groupId>
        <artifactId>el-api</artifactId>
        <version>1.0</version>
        <scope>provided</scope>
    </dependency>
  </dependencies>
  <build>
    <finalName>HelloJsf</finalName>
<plugins>
<plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <configuration>
                <source>1.6</source>
                <target>1.6</target>
            </configuration>
        </plugin>
<plugin>
            <groupId>org.codehaus.mojo</groupId>
            <artifactId>tomcat-maven-plugin</artifactId>
            <configuration>
                <server>tomcat</server>
            </configuration>
        </plugin>
    </plugins>
  </build>
</project>

This post is only an update to the previous post. Recently I found an even more elegant solution in order to disable seam.deployer. Instead of removing the package from JBoss AS deployers folder we can provide a jboss-scanning.xml file which as documented on JBoss Wiki is able to remove certain files from scanning process.
So, a better (and also less instrusive) workaround is to provide under war/WEB-INF/classes a jboss-scanning.xml file with the following contents:

<scanning xmlns="urn:jboss:scanning:1.0">
  <path name="servlet-1.0.war/WEB-INF/classes">
    <exclude name="seam.properties"/>
  </path>
</scanning>

This is a little late, but anyway…

Two weeks ago I attend one more of the Globalcode’s Casual Class‘es. This one was about JAVAEE 6 and the main technologies that will be part of it when it comes out – apparently very soon.

I don’t have many pictures because I’m very smart and let my mobile’s battery run out… but let’s go through a few of the ones I got and talk about the contents of this event.

Preparations

The event was split in a few individual topics, among them: JSF 2.0, JAX-RS, EJB 3.1 and JPA 2.0. Each one had different presenters, all of them great speakers! =)

JSF 2.0

JSF 2.0 was presented by Yara Senger and Alberto “Spock” Lemos. They mentioned some changes that are coming to JSF, and used a small demo application, SCRUM Toys, to explain how they got involved into actually using the new features.

JPA 2.0

Melissa Vilela spoke about the new features coming in JPA 2.0. There are a lot of nice things. Among them, the new Criteria API is not. To be brutally honest, that thing is ridiculously complex. It is clearly lacking some usage of the KISS principle.

Then there was a presentation about REST, more specifically JAX-RS. (no pictures, sorry). Nothing really new here, just the fact that the API, which was already done and available, is going to be part of JAVAEE 6.

EJB 3.1

The last topic was EJB 3.1. Like with EJB 3.0, things are moving towards a simpler development model, and this is what was presented. Nice, simplifications to EJBs are always welcome! =)

After that, Pizza! uhu! My only complain this time is that the technical sessions took longer than usual, and I was really hungry in the end! But it was well worth the time =)

Recently I started a proof of concept for a new project that will run on JBoss 5.1. The reason for picking JBoss 5.1 instead of the mature 4.2 series was due to its full support for JavaEE 1.5 (4.2 supports only EJB3 spec, no servlet injection, etc) as well as its longer support (4.2 will start an EOL cycle soon).
As soon as I decided to use JBoss 5.x the classloading nightmare started. First of all, Seam uses a kinda strange hack for detecting its components (its scanner class makes use of java.io.File which in turn does not work on newer VFS system released on JBoss 5.x).
Recommendation on Seam forums is to include no Seam file at you EAR/WAR and let Seam deployer do the trick but thiss comes with much obvious limitations:

1. You’ll need a separate packaging for your application on JBoss (this is probably the worst limitation)
2. Seam (and its dependencies) upgrades will involve patching Application Server files

But although recommended you can still deploy a regular Seam application without Seam Deployer. I’ll try to provide a step-by-step guide on how to circumvent this limitation:

First step: remove seam.deployer from $JBOSS_HOME/server/default/deployers (an alternative and less intrusive solution that I just found after writting this post is described over here)
Second step: add all Seam dependencies (jboss-seam-ui.jar, jboss-seam.jar, etc) inside EAR (I sincerely suggest under a lib folder).
Third step: place a jboss-app.xml with the following content on you EAR/META-INF folder

<?xml version="1.0" encoding="UTF-8"?>
  <!DOCTYPE jboss-app
    PUBLIC "-//JBoss//DTD J2EE Application 4.2//EN"
    "http://www.jboss.org/j2ee/dtd/jboss-app_4_2.dtd">
<jboss-app>
      <loader-repository>
            myapp.ear=MyAppEar
      </loader-repository>
</jboss-app>

Fourth step: place a jboss-classloading.xml also on EAR/META-INF folder with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
              name="myapp.ear"
              domain="MyAppEar">
</classloading>

Fifth step: place jboss-seam-int-jbossas.jar from seam.deployer/lib-int into your EAR/lib folder. (this jar contains org.jboss.seam.integration.jbossas.vfs.VFSScanner)
Sixth step: place another jboss-classloading.xml on WAR/WEB-INF folder with the following contents:

<?xml version="1.0" encoding="UTF-8"?>
<classloading xmlns="urn:jboss:classloading:1.0"
              name="mywebapp.war"
              domain="MyWebAppWar">
</classloading>

Seventh step: Place a jboss-web.xml under WAR/WEB-INF with the following contents:

<jboss-web>
	<class-loading java2ClassLoadingCompliance="false">
		<loader-repository>
			mywebapp.war:loader=MyWebApp
			<loader-repository-config>java2ParentDelegation=false
			</loader-repository-config>
		</loader-repository>
	</class-loading>
</jboss-web>

Eighth step: place a seam-deployment.properties anywhere in the classpath (anywhere but before seam jar) with the following contents:

org.jboss.seam.deployment.scanners=org.jboss.seam.integration.jbossas.vfs.VFSScanner

Ninth step: Add all Seam dependencies on MANIFEST.MF file under WAR/META-INF and remember to include jboss-seam-int-jbossas.jar on the classpath.

That’s all you need to avoid having a separate packaging for a Seam enterprise application running on JBoss 5.x (sincerely I guess that you risk having to remove the seam-deployment.properties only). This also makes it easier to replace the JSF implementation on your application.

Presentación en la Jazoon 2009 de las nuevas características incluídas en Spring 3.0.

Vía SoftDevTube.

The 0.6 version of our EAR archetype includes a hardcoded version number for the H2 database engine artifact. Recent changes in the [fleXive] trunk (i.e. 3.1-SNAPSHOT) require a newer version of H2, otherwise the initialization of the database will fail with a “Syntax error in SQL statement”.

The fix for existing projects is to fix the version number in your main module’s pom.xml: increase the h2.version property from 1.1.106 to 1.1.117.

To avoid this issue in the future, I moved the H2 dependency to the flexive-h2 artifact. The current snapshot version of the archetype (1.0-SNAPSHOT) therefore no longer includes a dependency on com.h2database.h2, and potential changes in the required H2 version number (always a possibility since H2 development is very active) won’t affect existing projects.