Quiclky Create a Maven-aware project

If you are (or want to start) using Maven as a build tool for your project, a quick way to start is to use an archetype to create a pom.xml and the default folder structure. This is the command:


mvn archetype:create

-DarchetypeGroupId=[archetype-groupId]

-DarchetypeArtifactId=[archetype-artifactId]

-DarchetypeVersion=[archetype-version]

-DgroupId=[my.groupid]

-DartifactId=[my-artifactId]



Debugging Information passed to a JSP Page

Well, scriptlets inside a JSP page Suck. Alright, I agree!!
But sometimes it is necessary to check what are the parameters in the request or session scopes reaching your jsp page.

I found this code somewhere on the web sometime ago. One day (yeah, right) I will right a version of it using JSTL tags, but for now I allow myself to add this scriptlet in one of the pages that are included everywhere in my system. As I use Struts Tiles in my system, I do have a bottom.jsp page which is included everywhere.

So I leave the debug attribute in false state until I need to debug on page or another. At this moment, all I have to do is turn on the debug information in my page by setting the attribute to true.

Below is the scriptlet and page includes that should be added to the page where you want the debug information to be displayed.




<%@ taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core" %>

<%@ page import="java.util.*" %>
<%@ page import="org.apache.struts.*" %>

<%@ page import="org.apache.struts.util.*" %>
<%@ page import="org.apache.struts.action.*" %>

<%
// Print all attributes in the request object
out.println("<p><b>All Attributes in request scope:</b>");
Enumeration paramNames = request.getAttributeNames();
while (paramNames.hasMoreElements()) {
String name = (String) paramNames.nextElement();
Object values = request.getAttribute(name);
out.println("<br> " + name + ":" + values);
}

// Print all attributes in the session object
out.println("<p><b>All Attributes in session scope:</b>");
paramNames = session.getAttributeNames();
while (paramNames.hasMoreElements()) {
String name = (String) paramNames.nextElement();
Object values = session.getAttribute(name);
out.println("<br> " + name + ":" + values);
}

out.println("<p><b>Data in ActionMessages:</b>");

// Get the ActionMessages
Object o = request.getAttribute(Globals.MESSAGE_KEY);
if (o != null) {
ActionMessages ae = (ActionMessages)o;

// Get the locale and message resources bundle
Locale locale =
(Locale)session.getAttribute(Globals.LOCALE_KEY);
MessageResources messages =
(MessageResources)request.getAttribute
(Globals.MESSAGES_KEY);

// Loop thru all the labels in the ActionMessage's
for (Iterator i = ae.properties(); i.hasNext();) {
String property = (String)i.next();
out.println("<br>property " + property + ": ");

// Get all messages for this label
for (Iterator it = ae.get(property); it.hasNext();) {
ActionMessage a = (ActionMessage)it.next();
String key = a.getKey();
Object[] values = a.getValues();
out.println(" [key=" + key +
", message=" +
messages.getMessage(locale,key,values) +
"]");
}
}
}
%>






EJB3 QL: Using the COUNT function

If you are using EJB3 Query Language to build your application, you will probably need to use some functions other than the regular SELECT statements and logical WHERE clauses. One of the most simplest of these functions is the COUNT function.
The syntax for the COUNT function is very simple, and it receives only a parameter which is the identifier to be count, as in:

SELECT COUNT(c) FROM Customers AS c WHERE c.address.country = 'BR'

This query will count all the Customers who live in Brazil.

The COUNT function can be used with an identifier, in which case it always counts entities (as the example above demonstrates), or with path expressions but this last one can always be converted into an expression that counts entities only by managing the conditions in the WHERE clause.

Below is an example on how you could write a piece of code that would count the Patients from a medical database, depending on which Clinic they are registered to:


Query query = entityManager.createQuery("SELECT COUNT (p) FROM Patients p WHERE p.clinic.idtClinic = :idtClinic");
query.setParameter("idtClinic", idtClinic);
return (Long)query.getSingleResult();


I will write about other EJB QL functions later! :)

CU!

SVN Keywords

One useful feature that subversion and many other Versioning Systems offer for developers is the ability to include keywords in text files stored in the repository.

These keywords get replaced when some action is done on them by the server. This book excerpt (reproduced below) documents some keyword supported by subversion.

The keyword to be replaced is identified by an anchor in the text with the keyword name surrounded by two '$keywordName$.

Subversion defines the list of keywords available for substitution. That list contains the following five keywords, some of which have shorter aliases that you can also use:

LastChangedDate

This keyword describes the last time the file was known to have been changed in the repository, and looks something like $LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $. It may be abbreviated as Date.

LastChangedRevision

This keyword describes the last known revision in which this file changed in the repository, and looks something like $LastChangedRevision: 144 $. It may be abbreviated as Revision or Rev.

LastChangedBy

This keyword describes the last known user to change this file in the repository, and looks something like $LastChangedBy: harry $. It may be abbreviated as Author.

HeadURL

This keyword describes the full URL to the latest version of the file in the repository, and looks something like $HeadURL: http://svn.collab.net/repos/trunk/README $. It may be abbreviated as URL.

Id

This keyword is a compressed combination of the other keywords. Its substitution looks something like $Id: calc.c 148 2002-07-28 21:30:43Z sally $, and is interpreted to mean that the file calc.c was last changed in revision 148 on the evening of July 28, 2002 by the user sally.
as in $keywordName$.

Have fun!

UPDATE on march/2009
Normally it would be necessary to set the properties on every single file of your system so the replacement of these props would happen. However, there is an easier way to do this, which is set the auto-props property in your environment.

In folder "C:\Documents and Settings\[your_username]\Application Data\Subversion" you will find a file named config (with no extension). In this file there should be a property "enable-auto-props" commented out. Remove the comment from this line so it looks like this:




### Set enable-auto-props to 'yes' to enable automatic properties
### for 'svn add' and 'svn import', it defaults to 'no'.
### Automatic properties are defined in the section 'auto-props'.
enable-auto-props = yes

Then, on the same file, find the section [auto-props] and add a line at the end. If you want the replacement to happen only in your java files, add this:




*.java = svn:keywords LastChangedDate

Install a jar file into maven's local repository

Sometimes, while using maven to build your projects, it is necessary to add a needed jar file directly into your local repository. This should not be a need if you have a remote repository correctly setup, but it might be useful if it is a too bureaucratic task or any other reason.

It is as simple as this. Having the file to be installed in your local repository in the local folder, issue the command below to install it.

mvn install:install-file -DgroupId=<MVN_GROUPID> -DartifactId=<MVN_ARTIFACTID> -Dversion=<MVN_VERSION> -Dpackaging=jar -Dfile=<JAR_FILE_TO_INSTALL>

Could be useful! ;)

Find the name of your session bean in JBoss

If you are writing JEE applications, you will most likely write a Session Bean to provide your View Tier with the services it need. This Session Bean is reached by the client application through a service called JNDI.

The problem is that each Application Server uses a different JNDI provider and this makes portability very hard to achieve. I wrote the code below to allow me to access the JNDI service and find my Session Bean. Please note that this would be much better placed in the container configuration file and not in the code, as it is here.

protected static Context getInitialContext( ) throws javax.naming.NamingException {
  Properties p = new Properties( );
  p.put(Context.INITIAL_CONTEXT_FACTORY,"org.jnp.interfaces.NamingContextFactory");
  p.put(Context.URL_PKG_PREFIXES,"org.jboss.naming:org.jnp.interfaces");
  p.put(Context.PROVIDER_URL, "jnp://localhost:1099");
  return new javax.naming.InitialContext(p);
}


This method will return a java.naming.Context object which can be used for the lookup on the service, like this:


PatientServices patientServices = (PatientServices)jndiContext.lookup("PatientBean/remote");


And how can you find the name under which your bean has been published on the application server? Well, in JBoss all you need to do is access the jmx-console (default URL is http://localhost:8080/jmx-console/). On the jboss session from this page, find the JNDIView service. Click on it and a new page will display on your browser.
On this new page there will be a java.lang.String list() MBean operation, and clicking on the invoke button the names of all available JNDI names will be shown on a tree-like structure which composes the name under which your Session Bean is registered on the JNDI service.

Maven Profiles

I was struggling with some different configuration files for my development and production environment. As a "weekend-free-time-developer-now-that-I-changed-into-management", my development environment is restricted. So I use the same instance of MySQL for the production database and run some tests on the same server with a different schema and configuration.

Using maven as a build/management tool improved my a lot my performance, but these different environments still gave me some headache. So I decided to leave laziness aside and configure some profiles in my pom files.

Maven profiles allow you to prepare different sets of configuration. There are for different types of profiles, defined in different files and with different purposes:

1. Per Project: Defined in the POM itself (pom.xml).
2. Per User: Defined in the Maven-settings (%USER_HOME%/.m2/settings.xml).
3. Global: Defined in the global maven-settings (%M2_HOME%/conf/settings.xml).
4. Profile descriptor: a descriptor located in project basedir (profiles.xml)

I decided to use the type number 1, which is a Per-Project configuration type, and unlike number 4 (which has a restricted scope) which is also a Per-Project configuration type it has the ability to change a lot of the project settings because it is in the same pom file as the projects' specifications themselves.

For starters, I wanted to have different jboss' data source xml files for production and development environments. As Maven works with a hierarchy of configuration files I figures the less intrusive way to set the build configuration was to have different folders for each environment. So where I previously had /src/main/resources/WEB-INF now I would have /src/main/resources/development/WEB-INF and /src/main/resources/production/WEB-INF. With the original single path, Maven did not need any special configuration to find my data source xml files (I love "convention over configuration"). With the 2 new folders, I had to add another layer to the hierarchy of Maven's configuration files and this layer would be the profiles.

In my pom.xml, I added a profiles section, obviously enough marked by the tag <profiles>. Here is what I added to my original pom.xml.

  <profiles>
    <profile>
      <id>env-dev</id>
      <build>
        <resources>
          <resource>
            <directory>src/main/resources/development</directory>
          </resource>
        </resources>
      </build>
      <activation>
        <property>
          <name>env-dev</name>
        </property>
      </activation>
    </profile>

    <profile>
      <id>env-prod</id>
      <build>
        <resources>
          <resource>
            <directory>src/main/resources/production</directory>
          </resource>
        </resources>
      </build>
      <activation>
        <property>
          <name>env-prod</name>
        </property>
      </activation>
    </profile>
        
  </profiles>


Now, you can tell maven to build based on different profiles. Where you normally would enter a command like mvn install now you should change to:

mvn install -P env-dev for development environment

OR

mvn install -P env-prod for production environment

After doing this, I was wondering... Which profile will maven choose to execute the build if I do not explicitly tell it?

That is very easy to check! Run the command:

mvn help:active-profiles

It will show you that there are no active profiles, but it will (wrongly IMHO) add BOTH (production and development) folders to your final build, and will not realize that those are actual resource folders.

One simple solution for this issue is to tell maven which profile should be used by default. I modified the profiles tag content to use the production environment as the default one, so this will force me during development to always add the "-P env-dev" while I am testing/developing and this should make me used to always tell maven what I really want. The way to tell maven which one is the default active profile is in bold below.

    <profile>
      <id>env-prod</id>
      <build>
        <resources>
          <resource>
            <directory>src/main/resources/production</directory>
          </resource>
        </resources>
      </build>
      <activation>
        <activeByDefault>true</activeByDefault>
        <property>
          <name>env-prod</name>
        </property>
      </activation>
    </profile>


Now, if you run mvn help:active-profiles again you will see that the env-prod is being used, which is the same as running mvn help:active-profiles -P env-prod.

$ mvn help:active-profiles
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO] ----------------------------------------------------------------------------
[INFO] Building Fisio EJB Component
[INFO] task-segment: [help:active-profiles] (aggregator-style)
[INFO] ----------------------------------------------------------------------------
[INFO] [help:active-profiles]
[INFO]
Active Profiles for Project 'com.jc.fisio:fisio-ejb:ejb:0.1-SNAPSHOT':

The following profiles are active:

- env-prod (source: pom)



[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 1 second
[INFO] Finished at: Sun Feb 11 18:13:13 BRST 2007
[INFO] Final Memory: 2M/5M
[INFO] ------------------------------------------------------------------------


Working with profiles is quite interesting, because it allows you to have multiple active profiles at the same time, providing a number of different combinations. It can be used to may purposes, like setting different application servers, web servers, snapshot version etc.