My Wiki

Very impressed by JUDCon 2012 in Bangalore

2012-01-26T21:15:00.000+05:30

I just returned from the first ever JUDCon event in India which was organized in Bangalore. For those of you who couldn't make it (you really missed a very impressive event) here's an review of the event.

The venue:

It was organized in the Nimhans convention centre in Bangalore on Jan 24th and 25th. The venue had very good WiFi facility (although it did make it's absence felt for a few seconds during Rado's live demo on mod_cluster :) ). I haven't been to previous JUDCon events, so I wasn't aware how good the connectivity usually is at these events. Apparently the connectivity here was among the best as compared to the previous events, as per Galder's review. So a big thank you to the organizers of the event, Saltmarch Media.

Attendance:

To be honest, when I arrived for the event I was expecting an audience of around 100-150 people. I did know that there's a huge number of jboss.org community users from India (like Bruno later showed in his presentation) but I hadn't expected that many would show up at the event especially since it was weekday (for some of the JBUG events that I have organized earlier, I have always been requested that the event be scheduled on a weekend) and also because the event was close to a national holiday on 26th. But to my pleasant surprise the attendance was far more in number, a number that I had never expected. We were told that there were 700+ registrations for the event (remember, this is a paid event so most of them would definitely show up) and we could really see the large numbers during the presentations. Apparently this is the biggest JUDCon in terms of attendance itself. The audience was not just impressive because of the numbers but also because of the knowledge they had about various JBoss projects some of which are very new. We could see that the audience was very well informed based on the questions (a lot of them) they asked after the sessions. So full marks for all those who attended the event and made it a great success.

Sessions:

Before the event started this week, due to some unavoidable last minute changes, a couple of sessions had to be changed. Luckily for me and those from the audience who would have liked to hear about EJB configurations in AS7, the session organizers decided to allow a session titled "Configure and deploy your EJB applications on AS7" on the second day of the event. Since this was a last minute change and because I had already made some arrangements to leave the event sometime in the afternoon on the second day, Satish Kale and Ravi Maurya (who are both from the Red Hat team) volunteered to present the session and I decided to provide them with the necessary help for creating the slides/content. I arrived in Bangalore one day earlier before the event and spent most of the time creating the presentation for the session.

The sessions were divided into 3 tracks: (1) JBoss AS7 (2) OpenShift/Cloud and (3) Rules,Workflow, SOA and EAI. The AS7 sessions were held in the Main Hall which had a very large seating capacity and the other tracks were held in two different halls which were a bit smaller compared to the main hall but still had enough room to accommodate around 100 (or more?) people in the audience. The smaller halls were always packed for whichever session I decided to take a look at. Infact, many of them were even standing due to the full house. You will get to see a proof once the videos and pictures of the event are uploaded at jboss.org :)

I had decided that I would be attending most of the AS7 sessions and the OpenShift ones. The event started on day one at 9 in the morning when Bruno delivered the keynote address to a packed house. Then I attended a couple of more sessions - one by Ales, on Android and the Cloud and the other by Greg Kable (who I finally got to meet!) on the Best Practices for using JPA2 with Hibernate. Like I said, the sessions were well attended and the audience had some very good questions in the end for the speakers. I even got to take home a couple of important best practice suggestions from Greg's presentation. I had always wondered whether field based annotations or property based annotations on entities was a preferred approach. If you too have been wondering about that, then wait for the Greg's video/presentation to be uploaded on jboss.org (I'll actually create a new blog entry once those are uploaded. So you can even watch this blog too).

By the way, speaking of Hibernate, if Steve's reading this blog (Hi Steve! :)) there was one specific question about Hibernate which got asked atleast 3 times during various sessions and once when I was having lunch. Many of you would know that Hibernate recently switched to Gradle as their build system. They were earlier using Maven like many other JBoss projects. Apparently some users are having problems using Gradle to build Hibernate. They mentioned that they had an internal set of testsuites which they run after building Hibernate themselves, before deciding whether or not to use the newer versions of Hibernate. Apparently there's some issue with using Gradle since they say it requires some native .so library which they don't have and that results in failure on their build systems. So the question they had was whether the Hibernate team would have some kind of Maven compatibility for the builds. I don't have any knowledge of Gradle, so all I could suggest was to open a forum thread asking this question and explaining their usecase. So that's a heads up to Steve :)

After those couple of morning sessions, we had a nice lunch at the venue. The food was good. Later during the noon, I attended the session on JBoss AS7 "What's new" by Bruno. Being part of the AS7 team, I already had an idea of what the session was going to cover but I decided to be in the audience to see their reaction to the new changes to AS7 and the feedback they had around it. It was nice to see that there were many users in the audience who had started using AS7 and were aware of many of the new developments around it. The feedback was mostly encouraging although some users did mention that they had some trouble trying to migrate application which had previous JBoss AS specific extensions and descriptors. But overall, they were really happy with AS7 because of the vast amount of improvements it has compared to previous versions.

The session after that, I attended Shane's presentation on Getting Started developing apps with AS7. This was a very technical one with a live demo of how to use the command line interface (introduced in AS7) for deploying/undeploying the applications. The session included quickstarts that are made available publicly here. The session was attended by a packed audience and was well accepted. Those of you who haven't had a chance to look at the quickstarts, then I would very highly recommend taking a look at https://github.com/jbossas/quickstart. It covers a vast range of technologies and has quickstart applications with comprehensive documentation for each of those applications. Thanks to Sande Gilda and Pete Muir for managing the quickstarts and thanks for everyone else that has been contributing. This is a big improvement compared to some of our previous JBoss AS releases which did not have readily usable quickstart examples.

After these sessions, I decided to meet some of the community users and also catch up with some of my JBoss colleagues. It was good to talk to many of the community users some of whom had apparently known me by my name on the community forums.

Later in the evening of day one we had one last event at around 5:30. Although it was the last one of the day, it really turned out to be the best one (in my opinion) and well participated one. The event was "Expert Q&A with the Red Hat team". Ray Ploski (I finally got to meet Ray too!) started off the session by asking some questions to the audience and the on-stage Red Hat team then went on to discuss a wide range of topics covering a lot of JBoss projects. Each of the on-stage Red Hat team members shared their experience on a wide range of topics right from the relevance of Java, post Oracle acquisition of Sun to the very new Ceylon language. There was also discussion around Drools, jBPM, AS7, EAP and other JBoss projects. You could clearly see that the audience was very knowledgeable. This session not just had some serious discussions on a variety of topics but also had its fun moments, thanks to Mike Brock ;) (you'll see it in the video once it's posted, towards the end of the session when one member from the audience asks a question which had something to do with multi-core processors). That session ended a very lively and exciting first day of the event. We then had dinner at the event, where the delegates were invited to join the JBoss team and have a chat with them. I got to meet some delegates who had very interesting experiences to share about JBoss projects. Some of them were curious why there wasn't any session on Arquillian.

That marked the end a very nice day one at the event.

The next day the sessions started at 10 in the morning. The first one, in the AS7 track was by Dimitris, who by the way, told me that he had an exciting first hand experience of the Bangalore traffic - actually, lot of my other team mates had a similar opinion, which was natural :). Ales, I think even has a video. If not, Rado has one for sure :). So back to the sessions - the first one for day two that I attended was by Dimitris titled "JBoss Application Server 7 - Reloaded". I loved this session and I'm sure many who attended it loved it too! Dimitris started off with the history of JBoss AS 2.x, 3.x days and went on explaining the various changes/improvements that had happened all the way till AS7. It was nice to listen to some of the stories behind the previous versions, some of which I wasn't aware of. Later in the session he explained about AS7 and the projects and kernel that make up AS7 and why AS7 performs so fast. He ended that session with a "Thank you" slide which was well appreciated by the audience because he had that slide in Kannada (the language spoken in Bangalore), Hindi, Greek (Dimitris is from Greece) and English!

The next session I attended was by Rado, on mod_cluster. Rado presented on mod_cluster, which although I had some idea about, was new to me. I found the session very informative technical and got to learn some nice facts about the project. Rado even had a live demo of the project against AS7. The session went off well and there were a lot of questions from the audience.

It was then time for lunch on day two. Since I planned to leave the event an hour after lunch, I had just one more session that I had planned to attend. Ales presented a session titled CapeDwarf - Running your Google App Engine applications on JBoss AS7. Being part of the JBoss team, I had heard about the CapeDwarf project a few times from Ales but did not have much idea about what it was all about. So this was my chance to get to understand it better. I attended the session and Ales explained what the project was all about and where it stands currently. He even had a demo where he showed that you could directly deploy your Google App Engine application (an application which uses Google App Engine APIs) against a JBoss AS7 instance enabled with CapeDwarf subsystem and without having to do any changes to your application. It was an impressive demo and presentation and I got to learn what the project was all about.

So that was the last session I could attend that day since I had to leave early. There still were some other sessions that I wished I could attend and even present the "Configuring EJB applications for AS7" but that wasn't to be. Later I got to know that the session on EJB went well, although I still have to catch up with Satish and Ravi to get to know more. A big thanks to Satish and Ravi for presenting this session since it was a last minute decision for them too after the previously decided sessions were cancelled.

I caught up, one last time for this event, with my JBoss colleagues before leaving the event. Turns out I missed getting a JUDCon t-shirt because I left early and forgot to submit the feedback form for the sessions :(

Overall, these 2 days at the event were real exciting and the event was really impressive. I got to meet my JBoss team mates, some of whom I had never met before and also got a chance to meet a lot of community members. I wish we had a few more days of this! A big thank you to all those who attended and made this a success and for those who couldn't attend, keep a watch on this blog - I'll post a link to the event photos/videos once they are uploaded. Also keep an eye on the jboss.org blog feeds where I'm sure you'll see many more reviews of this event.

JBoss AS 7.1.0.CR1 "Flux Capacitor" released

2011-12-23T15:20:00.000+05:30

It's been just one month since we released JBoss AS 7.1.0.Beta1. Within that one month we have been able to fix numerous issues in JBoss AS7, add more features and resolve various other JIRAs. As a result, we now have 7.1.0.CR1 "Flux Capacitor" available for downloads.This new release contains around 378 resolved JIRAs. The highlights of this release include:

EE6 Full Profile support is now feature complete. What this means is - all the features required for EE6 full profile support are now available in AS7.
Various improvements in AS7 management
Clustering improvement:

Stateful session bean replication support
Clustered SSO

So, go get a copy of this release from the downloads page and start using it. Start deploying your applications, for which you have been waiting for full EE6 profile support in AS7 and let us know how it goes. As usual, feel provide us feedback or suggestions or ask for help if you run into any issues, in our user forum. It's just a few more days before we reach 7.1.0.Final, so help us deliver a high quality 7.1.0.Final by trying out 7.1.0.CR1 and reporting any issues.

[AS7 Home] [AS7 JIRA] [AS7 User Forum] [AS7 documentation] [AS7 downloads] [AS7 nightly builds]

JBoss AS 7.1.0.Beta1 "Tesla" released

2011-11-24T23:08:00.001+05:30

Two months after we released 7.0.2 "Arc", we now have JBoss AS 7.1.0.Beta1 "Tesla" available for use. It's available for download at the usual location here.

Apart from the regular bug fixes, 7.1.0 Beta1 has a whole lot of new features. This includes increased support for Java EE technologies. Here's the main set of features that have been included in this release:

A significant portion of EE full profile capabilities

Remote EJB over Remoting
Remote EJB over IIOP
CMP & BMP
EJB 2.x support
App Client
JSR-88

A number of management improvements
Management is now secure by default

Although with local user transparent auth for CLI and Java API tools
Console will "guide" you through creating a user

Numerous component updates

The entire list of bug fixes and improvements is available here

Let's briefly see some of the main features:

Standalone server configurations

7.1.0.Beta1 ships with a standalone.xml and a standalone-full.xml configurations. The standalone.xml supports web-profile technologies plus some additional technologies like javamail and full EJB3 support including remote EJB invocations. It however doesn't contain the messaging (i.e. HornetQ), Jacorb and CMP subsystem. The standalone-full.xml configuration, on the other hand contains support for all the technologies that have been implemented in AS7 so far.

By default, the standalone server starts up using the standalone.xml. If you want to use the other configuration then just use the following command:

 ./standalone.sh -server-config=standalone-full.xml

or if you are on Windows OS

 ./standalone.bat -server-config=standalone-full.xml

EJB 2.x support

Ever since AS 7.0.0 (which had web profile support) was released community users have been asking for EJB2.x support and support for invocations on EJB from remote clients. The plan was to have that support available in our early 7.1 Alpha/Beta releases. That has worked out as per the plan and users can now start deploying their EJB2.x applications on AS7.

Remote client invocations on EJB

For those of you who are interested in knowing about or trying out EJB invocations from a remote client, we have updated our AS7 documentation to have a chapter on EJB invocations from a remote client using JNDI. We already have some users who have started trying out and providing feedback in the user forum.

7.1.0 Beta1 is secured by default

Starting this version, the server is configured to be secured by default. What this means is that users wont have access to management operations (either via CLI or admin console) without authentication first. This wiki article is a must read to understand the finer (and well explained) details about this.

As you can see we have made some very good progress in the last couple of months since 7.0.2 was released. We hope to continue with the same speed for the upcoming 7.1.0.CR1. Try out this new version and let us know how it goes. Feedback is always welcome in our forums.

[AS7 Home] [AS7 JIRA] [AS7 User Forum] [AS7 documentation] [AS7 downloads] [AS7 nightly builds]

JBoss AS 7.0.2 "Arc" released!

2011-09-23T19:34:00.001+05:30

More good news on the JBoss AS7 front. JBoss AS 7.0.2.Final "Arc" has been released today! It's been one month since AS 7.0.1 was released. Within this short period of time there have been numerous bugs fixed and more features and improvements implemented. All these bug fixes and features have been included in this 7.0.2 release. This new release mainly consists of the following features/improvements:

JSF 2.1Async
EJB support
Resurrected -b option for command line binding
SSO support
JNDI memory footprint improvement
Limited support for Hibernate 3.3

Let's quickly look at one of these improvements. Those of you who have been using previous versions of JBoss AS would know that starting JBoss AS 4.2.x, JBoss by default binds its services to localhost for security reasons. These previous versions of JBoss AS allowed a command line option "-b" to allow binding the services to a different IP. AS 7.0.0 and 7.0.1 did not have this feature. Users could still bind to an IP of their choice but that required editing a xml file. Starting 7.0.2 release, we have now enabled this -b option (and also introduced a "-bmanagement" option) to allow you to bind your server to a IP/host of your choice. So let's quickly see how it's done.

Download the server binary from here and extract it to a folder of your choice. Start the standalone server using the standalone.sh (standalone.bat for Windows OS) script available in JBOSS_HOME/bin folder:

 jpai@jpai-laptop:bin$ ./standalone.sh  
 ...  
 18:45:36,893 INFO [org.jboss.as.remoting] (MSC service thread 1-3) Listening on /127.0.0.1:9999  
 18:45:37,030 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080

In the logs you'll notice that the server is being bound to 127.0.0.1 IP (by default). What this means is that all your services including the web access won't be accessible remotely from a different machine via the IP address or hostname of your machine.

As a quick check, access the following pages:

http://localhost:8080
http://localhost:9990

The first one is the default home page of your server and the second URL is the admin console. Now try accessing them using your machine's IP or hostname instead of localhost and you'll notice that they aren't accessible. Now let's see how we can enable access via your machine's IP or hostname.

Stop your running server and start it with the following command:

 jpai@jpai-laptop:bin$ ./standalone.sh -b 10.67.2.193  
 ...  
 18:47:24,588 INFO [org.jboss.as.remoting] (MSC service thread 1-1) Listening on /127.0.0.1:9999  
 18:47:24,818 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-2) Starting Coyote HTTP/1.1 on http--10.67.2.193-8080

Now you'll notice that the http interface (for your web applications) is now bound to 10.67.2.193 (the IP you passed). However, the management interface (on which the admin console is exposed) still binds to localhost. So now, you'll be able to access the AS home page (and your applications) at http://10.67.2.193:8080 and the admin console at http://localhost:9990

If you want to change the binding address for your management interface too, then you'll have to additionally use the -bmanagement option as follows:

 jpai@jpai-laptop:bin$ ./standalone.sh -b 10.67.2.193 -bmanagement 10.67.2.193  
 ...  
 18:48:56,295 INFO [org.jboss.as.remoting] (MSC service thread 1-2) Listening on /10.67.2.193:9999  
 18:48:56,654 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-1) Starting Coyote HTTP/1.1 on http--10.67.2.193-8080

As you can see the http interface and the management interface are now both bound to the IP address that you passed as a option to the startup script. So you'll now be able to access the home page at http://10.67.2.193:8080 and the admin console at http://10.67.2.193:9990. That's it!

So go get a fresh copy of 7.0.2 and start using it. If you run into any issues are have any suggestions, feel free to report them in our user forum.

[AS7 Home] [AS7 JIRA] [AS7 User Forum] [AS7 documentation] [AS7 downloads] [AS7 nightly builds]

Deploy a Java EE application on OpenShift Express (with AS7 support)

2011-08-20T21:27:00.004+05:30

During the past few years, I've been hearing about "cloud" services more and more. Initially I wasn't really curious to try them out. But a few months (a year?) back, I decided to see what it was all about. I have been involved with Java EE development for more than 7 years now, so I decided to see what it takes to deploy my Java EE application to the cloud. I set out looking for documentation and other usual blog articles and such. At that point, whichever cloud services I thought of trying out, would require me to provide my credit card details even to try out a trial application. I wasn't too keen to provide my credit card details just to try out a few applications of mine. So I kind of gave up on trying out my applications on cloud, although I kept reading about what other developers were doing to deploy their applications on cloud.

At about the same time, I came across this elaborate writeup on how one of the developers had setup his application involving Weld and JSF, on Google App Engine - Part1, Part2. The blog was well written and explained what was required to get your Java EE application up and running on a cloud service. But the important piece of information in those articles was that, users who had an application which was implemented as per Java EE standards (to be portable) had to change many of the application parts just to get them running on cloud. This was because many of the Java EE technologies weren't supported by the cloud service provider. This didn't look appealing to me. After all, what would I gain by doing that. So at that point, I as a Java EE developer, wasn't too interested in experimenting with deploying my application on cloud.

Enter OpenShift!

But this month, the OpenShift announcement about being able to deploy your JBoss AS7 Java EE applications to cloud, caught my eye. By the way, I do work for RedHat and am part of the JBoss AS7 team, but I wasn't keeping a watch on what the OpenShift team was upto, so this announcement came as a pleasant surprise! So I decided to give it a try. After reading some of the documentation on the project site, I found out that OpenShift offers two different services. One was "OpenShift Express" and the other "OpenShift Flex". OpenShift Express is free to use (that was one more good news for me) while OpenShift Flex requires your Amazon EC2 credentials and you'll be charged for the EC2 usage (there's however a free trial going on currently). I decided to give OpenShift Express a try since it was free and suits my current needs of just trying out a quick and simple Java EE application deployment and access to that application.

So here's what I did to be able to deploy my Java EE application which uses the technologies available in Java EE6 webprofile and which deploys fine on my local AS7 instance, to OpenShift Express. You might have already guessed that I'm no expert about OpenShift (or cloud services in general), so in this article doesn't have any advanced technical details, but contains more of a how-to on deploying Java EE applications to OpenShift Express.

So let's start then.

Sign up

The first step is to sign up here to create an account for yourself. The sign up just requires a valid email address to which your account details will be dispatched. On signing up, you'll receive a mail which contains a link to activate your account and will take you to the login screen. Login using the email id and password that you used to register.

Get Access to OpenShift Express

So let's got the OpenShift Express page. On that page you will notice a "Get Access to Express" button on left hand side. Click on it to get access to "Express". You'll be notified (immediately) through a mail to the email id which you registered. Check the mail which will contain a link to a quick start guide, to help you get started with OpenShift Express.

Install client tools

The quick start contains the instructions to get you started with the installation procedure. The first step includes installing a few client tools on your system to help you interact with OpenShift. Follow those instructions to install the client tools (I won't repeat them here, since it's well explained in that guide).

Create a domain

Now once we have the client tools, we are now ready to setup our "domain" on the OpenShift cloud. Setting up a domain will create a unique domain name that you can use for your applications. The domain name will be part of the URL which you will use to access the application and which you'll publish to your users for access. The command to create the domain is easy:

 rhc-create-domain -l <email-id-you-registered-with> -n <domain-name-of-your-choice>

Running that command will ask you for the password that you used to register. Enter that password and let the command complete (a few seconds).

The "rhc-create-domain" is part of the client tool that you installed earlier. If you haven't yet installed those tools, then you won't be able to use these commands, so don't miss that step! The "rhc-create-domain" accepts a few more optional parameters. To see the list of accepted parameters, you can run the following command:

 rhc-create-domain --help

Create a jbossas-7.0 application

Once you have successfully create a domain, your next step is to create an "application". Currently OpenShift Express supports different "types" of applications, each of them backed by Git (which is a version control system). At the point of writing this post, the supported application types are jbossas-7.0, perl-5.10, rack-1.1, wsgi-3.2 and php-5.3. I'm interested in deploying a Java EE application, so I'll be creating a "jbossas-7.0" application. This type of application provides you a JBoss AS 7.0.0 instance in the OpenShift cloud to which you can deploy your applications. So let's now create an application of type jbossas-7.0.

Note that the term "application" can be a bit confusing (atleast I found it a bit confusing) because all you are doing at this point is setting up JBoss AS7 server.

The command to create an application is rhc-create-app. The rhc-create-app accepts multiple options. For a complete list of options run:

 rhc-create-app --help

To create a jbossas-7.0 application, we'll run the following command:

 rhc-create-app -a <application-name> -l <email-id-you-used-to-register> -t jbossas-7.0 -r <path-on-local-filesystem-for-the-repository>

Running that command will ask you for the password that you used to register. Enter that password and let the command complete (a few seconds).

The -a option lets you specify the name for your application. This name will be part of the URL that you use to access your application. If your application name is "foo" and (the previously created) domain name is "bar", then the URL to access your application will be http://foo-bar.rhcloud.com/.

The -t option in that command, specifies the application type. In our case, we are interested in jbossas-7.0

The other option of importance is the -r option which you'll use to point to a folder on your local filesystem where OpenShift will store all the data related to your application. Part of that data will be a local copy of the git repo (version control system). We'll see this in more detail later on in this blog.

Access your server URL

So once you run the command and it successfully completes, it will print out the URL where the application is available. You can (immediately) use that URL to access the application. On accessing that URL you'll notice a welcome page, which is an indication that the application has been installed successfully and available for access. For me, the URL to the newly created application was http://jaikiran-jbossas.rhcloud.com/.

So at this point, we have created a domain and then an application and have made sure that it's accessible to the world. In short, your cloud server is up and running and you can now deploy your Java EE applications to that server.

Create and deploy a Java EE application

So let's now move to the step of creating and deploying a Java EE application. I didn't have any specific application in mind, but wanted to deploy an application which would involve accessing a database. Instead of creating a brand new application, I decide to use one of the quick start applications that come with JBoss AS7. The quick start applications for JBoss AS7 are available for download here. Once you have downloaded the quick start archive, unzip it to a location of your choice. Building the quick start examples will require Maven build tool be installed on your system. The details about the quick start applications and how to build them can be found here. Those interested in trying it out themselves, might want to look at that guide.

I chose the "kitchensink" application from those quick starts. The kitchensink application uses Java Persistence API (JPA) for persistence and by default uses the java:jboss/datasources/ExampleDS which is shipped by default by JBoss AS7. The ExampleDS uses H2 as its database.This is how the persistence.xml looks like:

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

 <persistence version="2.0"  

   xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  

   xsi:schemaLocation="  

     http://java.sun.com/xml/ns/persistence  

     http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">  

   <persistence-unit name="primary">  

    <!-- If you are running in a production environment, add a managed   

      data source, the example data source is just for proofs of concept! -->  

    <jta-data-source>java:jboss/datasources/ExampleDS</jta-data-source>  

    <properties>  

      <!-- Properties for Hibernate -->  

      <property name="hibernate.hbm2ddl.auto" value="create-drop" />  

      <property name="hibernate.show_sql" value="false" />  

    </properties>  

   </persistence-unit>  

 </persistence>

That's enough for me now, to show how to deploy the application and also show the DB support available in OpenShift Express.

After building the application, the deployable war is named jboss-as-kitchensink.war and is available on my local file system. My next step would be to deploy it my JBoss AS7 server which we have setup on the OpenShift Express cloud. Let's see how that's done.

Deploy the application to OpenShift Express

Remember, while creating the "application" using the rhc-create-app command, we used the -r option to point to a folder on our local file system to create a local copy of the application repository. That's the place which will be used now for deploying our applications. In my case, I used /home/jpai/OpenShift/myapps/demo as the repo location. This is how that folder looks like:

 demo  

 |  

 |--- deployments  

 |  

 |--- pom.xml  

 |  

 |--- README  

 |  

 |--- src

There's more than one way to deploy your application to OpenShift Express. One way is to write your code and commit the source code within the src folder of your local repository and then push your changes to the remote git repository. This will then trigger a Maven build for your project on the remote repository. More details about this approach is available in this blog.

In our case, we'll focus on how to deploy an already built Java EE application to your OpenShift Express cloud server. In the previous step, we built the jboss-as-kitchensink.war. Now, copy that war file to the "deployments" subfolder of your local git repository. In this case, it's /home/jpai/OpenShift/myapps/demo/deployments:

 cp /home/jpai/jboss-as-quickstarts-7.0.0.Final/kitchensink/target/jboss-as-kitchensink.war /home/jpai/OpenShift/myapps/demo/deployments

Once you have copied it here, your next step is to "commit" this change using the git commit command:

 jpai@jpai-laptop:demo$ git add deployments/jboss-as-kitchensink.war  

 jpai@jpai-laptop:demo$ git commit -m "Deploy kitchensink application" deployments/jboss-as-kitchensink.war  

 [master 1637c21] Deploy kitchensink application  

  1 files changed, 0 insertions(+), 0 deletions(-)  

  create mode 100644 deployments/jboss-as-kitchensink.war

So at this point your kitchensink application has been commited to your local git repo. Next we should "push" this commit to the remote git repo:

 jpai@jpai-laptop:openshift$ git push origin master  

 Counting objects: 6, done.  

 Delta compression using up to 2 threads.  

 Compressing objects: 100% (4/4), done.  

 Writing objects: 100% (4/4), 393.71 KiB, done.  

 Total 4 (delta 1), reused 0 (delta 0)  

 remote: Stopping application...  

 remote: done  

 remote: Found .openshift/config/standalone.xml... copying to ...  

 ....  

 ....  

 ....  

 remote: Starting application...done  

 To ssh://6a7ff43a6c2246999de28219a5aaa4ae@jaikiran-jbossas.rhcloud.com/~/git/jaikiran.git/  

   6e57976..1637c21 master -> master

(trimmed some logs from the above output).

So with this "push" we have now deployed our application to the remote OpenShift Express JBoss AS7 server. The jboss-as-kitchensink.war will be deployed at the "jboss-as-kitchensink" web application context. So the URL to access the application will be http://jaikiran-jbossas.rhcloud.com/jboss-as-kitchensink. Go ahead and access that URL. The application does nothing fancy - it allows you to add a user name, email and phone number which will then be stored in the database.

Like I mentioned earlier, the kitchensink application uses ExampleDS datasource which is backed by H2 database. So all the data will be stored remotely in the H2 database.

Using the MySQL database available in OpenShift Express

OpenShift Express sets up a MySQL datasource template for you when you create a jbossas-7.0 application type. The details of the database can be found in the <path-to-local-repo>/.openshift/config/standalone.xml:

 <subsystem xmlns="urn:jboss:domain:datasources:1.0">  

      <datasources>  

           <datasource jndi-name="java:jboss/datasources/ExampleDS" enabled="true" use-java-context="true" pool-name="H2DS">  

                <connection-url>jdbc:h2:${jboss.server.data.dir}/test;DB_CLOSE_DELAY=-1</connection-url>  

                <driver>h2</driver>  

                <pool></pool>  

                <security>  

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

                     <password>sa</password>  

                </security>  

                <validation></validation>  

                <timeout></timeout>  

                <statement></statement>  

           </datasource>  

           <datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="false" use-java-context="true" pool-name="MysqlDS">  

                <connection-url>jdbc:mysql://127.1.1.1:3306/mysql</connection-url>  

                <driver>mysql</driver>  

                <security>  

                 <user-name>admin</user-name>  

                 <password>changeme</password>  

                </security>  

           </datasource>  

           <drivers>  

                <driver name="h2" module="com.h2database.h2">  

                     <xa-datasource-class>org.h2.jdbcx.JdbcDataSource</xa-datasource-class>  

                </driver>  

                <driver name="mysql" module="com.mysql.jdbc">  

                     <xa-datasource-class>com.mysql.jdbc.jdbc2.optional.MysqlXADataSource</xa-datasource-class>  

                </driver>  

           </drivers>  

      </datasources>  

 </subsystem>

You'll notice that apart from the ExampleDS that comes by default in AS7, OpenShift Express has setup a MySQL datasource which will be available at java:jboss/datasources/MysqlDS. The important piece to note here is that it is disabled (i.e. enabled=false) by default. Also notice that the password is "changeme". Basically, this datasource configuration for MysqlDS in the standalone.xml is there as a template. In order to enable that datasource, we first have to create a MySQL database for our application. That can be done by using the following command:

 jpai@jpai-laptop:openshift$ rhc-ctl-app -a <application-name> -l <email-id-we-used-to-register> -e add-mysql-5.1

The rhc-ctl-app is passed the application name (which is the one that we used during rhc-create-app) and also our account id. Additionally, we use the -e option to specify what we want to do. In this case, we issue a "add-mysql-5.1" command. Running that command will ask you for your account password and on successful completion will show the output similar to:

 RESULT:  

 Mysql 5.1 database added. Please make note of these credentials:  

 Root User: admin  

 Root Password: as43n34023n  

 Connection URL: mysql://127.1.1.1:3306/

Note down the user name, password and the connection url. Now open the <repo-home>/.openshift/config/standalone.xml in a text editor and update the MysqlDS configuration to use the connection URL, the user name and the new password. Also set the enabled flag to "true" so that the datasource is enabled. Ultimately the datasource configuration will look like:

 <datasource jndi-name="java:jboss/datasources/MysqlDS" enabled="true" use-java-context="true" pool-name="MysqlDS">  

      <connection-url>jdbc:mysql://127.1.1.1:3306/mysql</connection-url>  

      <driver>mysql</driver>  

      <security>  

       <user-name>admin</user-name>  

       <password>as43n34023n</password>  

      </security>  

 </datasource>

Pay attention to the connection-url. It has to be of the format jdbc:mysql://<ip:port>/dbname. Typically, you don't have to touch that connection-url at all, since the rhc-ctl-app add-mysql-5.1 and the datasource template are in sync with the IP/port. The important pieces to change are the password and the enabled flag.

Once this file is updated, save the changes and commit it to your local git repo:

 jpai@jpai-laptop:demo$ git commit -m "Enable the MysqlDS and fix the password" ./  

 [master dd7b58a] Fix the datasource password  

 1 files changed, 1 insertions(+), 1 deletions(-)  

 Push these changes to remote repo:  

 jpai@jpai-laptop:openshift$ git push origin master  

 Counting objects: 9, done.  

 Delta compression using up to 2 threads.  

 Compressing objects: 100% (4/4), done.  

 Writing objects: 100% (5/5), 494 bytes, done.  

 Total 5 (delta 2), reused 0 (delta 0)  

 remote: Stopping application...  

 remote: done  

 ....  

 .....  

 remote: Starting application...done  

 To ssh://6a7ff43a6c2246999de28219a5aaa4ae@jaikiran-jbossas.rhcloud.com/~/git/jaikiran.git/  

 2d38fa8..dd7b58a master -&gt; master

So we now have added MySQL DB and enabled the MysqlDS datasource which is available at java:jboss/datasources/MysqlDS jndi name on the server. So if the kitchensink application has to use MySQL as its database, instead of H2, then all it has to do is use the java:jboss/datasources/MysqlDS. Let's now edit the persistence.xml file that we saw earlier and use the MysqlDS instead:

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

 <persistence version="2.0"  

   xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"  

   xsi:schemaLocation="  

     http://java.sun.com/xml/ns/persistence  

     http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">  

   <persistence-unit name="primary">  

    <!-- Changed to use MysqlDS -->  

    <jta-data-source>java:jboss/datasources/MysqlDS</jta-data-source>  

    <properties>  

      <!-- Properties for Hibernate -->  

      <property name="hibernate.hbm2ddl.auto" value="create-drop" />  

      <property name="hibernate.show_sql" value="false" />  

    </properties>  

   </persistence-unit>  

 </persistence>

Additionally, just to "show" that this new application has been updated to use MySQL database, I also edited the index.xhtml page of the kitchensink application, to add a message on that page about MySQL database being used:

 <h3>  

       <span style="color: red;">  

            This application uses MySQL database as its persistence store  

        </span>  

 </h3>

Next, I'll build the kitchensink application locally using Maven, to reflect these changes and generate the new jboss-as-kitchensink.war. Once built, let's now again copy it to our local git repo and then commit the change and push it to the remote git repo:

 jpai@jpai-laptop:kitchensink$ cp target/jboss-as-kitchensink.war /home/jpai/OpenShift/myapps/demo/deployments

 jpai@jpai-laptop:demo$ git commit -m "Use MySQL database for kitchensink application" ./  

 [master ded2445] Use MySQL database for kitchensink application  

 1 files changed, 0 insertions(+), 0 deletions(-)

 jpai@jpai-laptop:openshift$ git push origin master  

 Counting objects: 7, done.  

 Delta compression using up to 2 threads.  

 Compressing objects: 100% (4/4), done.  

 Writing objects: 100% (4/4), 1.35 KiB, done.  

 Total 4 (delta 2), reused 0 (delta 0)  

 remote: Stopping application...  

 remote: done  

 remote: Found .openshift/config/standalone.xml... copying to...  

 ...  

 ...  

 ...  

 remote: Starting application...done  

 To ssh://6a7ff43a6c2246999de28219a5aaa4ae@jaikiran-jbossas.rhcloud.com/~/git/jaikiran.git/  

 1637c21..ded2445 master -&gt; master  

 jpai@jpai-laptop:demo$

(trimmed some logs from the output)

So at this point we have now changed our kitchensink application to use MySQL database and have deployed it to our OpenShift Express AS7 server. So let's access the application URL again http://jaikiran-jbossas.rhcloud.com/jboss-as-kitchensink. As you see, that page now prominently displays our message about MySQL DB being used. Go ahead and try out that app by adding some dummy user information.

That's it! We have successfully deployed our application to OpenShift Express server and the application is available for use.

Summary

It's been a pleasant experience so far with OpenShift. I plan to try out a few more things with OpenShift, in the coming days and blog about any interesting details.

Useful resources

While working on deploying this application, I had to use some documents and help from the OpenShift community to understand how this is all setup,. Here's a list of useful resources related to OpenShift in general:

OpenShift Express User guide
OpenShift forums
OpenShift IRC #openshift on irc.freenode.net. The folks here are very helpful!
Scott Stark's blog. Scott's blogs contain a lot of useful information about AS7 on OpenShift and OpenShift in general. Scott's blog is definitely a must read!

Where to look for help

OpenShift questions in general are answered in the OpenShift forums. For questions around AS7 on OpenShift, the best place to ask questions is the JBoss Cloud Group.

[AS7 + OpenShift] [OpenShift Home] [AS7 Home] [JBoss Cloud Group] [Scott Stark's blog]

JBoss AS 6.1.0 released

2011-08-19T16:35:00.000+05:30

This week at JBoss, we not only saw JBoss AS 7.0.1 being released but there also was the release of JBoss AS 6.1.0, a few days earlier. The download is available here. JBoss AS 6.1.0 is mainly is bug fix release. This release is mainly for those users who haven't yet migrated to AS7. Release notes are available here.

One of the highlights of this release, is that this was mainly driven by the community members.Many of the JBoss AS developers were busy with AS7 activities, so we had asked for community members to volunteer for providing fixes for 6.1.0. Shelly led the 6.1.0 release efforts (like she did with 6.0.0). We had some great help from the community for this release, notably from Daniel Bevenius who helped fix a number of issues. Thanks to Shelly, Daniel and other community members for making this release possible!

So, AS6 users, download this new release and give it a try! As always, if you have any questions or run into any issues, please visit our user forum and start a discussion.

JBoss AS 7.0.1 - Configuring EJB3 Pools

2011-08-19T14:01:00.003+05:30

Now that AS 7.0.1 has been released, let's take a look at what new EJB3 features are available. Like I mentioned in my previous post AS 7.0.1 now allows you to configure pools for your stateless session beans and MDBs. Currently we allow configuring the pools at the subsystem level, which means that the pool will be applicable for all the beans deployed on the server. In some upcoming release, we'll allow configuring the pools at individual deployment and individual bean level. Let's, for now, see how the configuration looks like at the subsystem level.

In my previous post I mentioned that AS 7.0.1 has 2 distributions. One which is purely webprofile and the other (named "everything") has additional EE features like support for MDBs. In this post, I'll be using the "Everything" distribution and the JBOSS_HOME/standalone/configurations/standalone-preview.xml for explaining the configurations.

Before we begin with the configurations, for those of you who are new to AS7, let's just see how to start the server using a specific configuration file. First, download the server and the unzip the binary in a folder of your choice. Then from the command prompt, move to the "bin" folder of the installation. Within this folder, you will see a standalone.bat/standalone.sh and domain.bat/domain.sh. We'll be concentrating on the standalone server in this post, but the same applies to the EJB3 subsystem in the domain configurations.

Starting the standalone server

So let's start the server. I'm on a Linux system, so I'll use the standalone.sh file. Those of you on Windows, will have to use standalone.bat.

 jpai@jpai-laptop:bin$ ./standalone.sh

Within around a couple of seconds, you'll see the server is up and running:

 jpai@jpai-laptop:bin$ ./standalone.sh  

 =========================================================================  

  JBoss Bootstrap Environment  

  JBOSS_HOME: /NotBackedUp/jpai/jboss-as-7.0.1.Final  

  JAVA: /opt/Java/SunJava-6/jdk1.6.0_21//bin/java  

  JAVA_OPTS: -server -Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true -Dorg.jboss.resolver.warning=true -Dsun.rmi.dgc.client.gcInterval=3600000 -Dsun.rmi.dgc.server.gcInterval=3600000 -Djboss.modules.system.pkgs=org.jboss.byteman  

 =========================================================================  

 09:30:31,537 INFO [org.jboss.modules] JBoss Modules version 1.0.1.GA  

 09:30:31,765 INFO [org.jboss.msc] JBoss MSC version 1.0.0.GA  

 09:30:31,818 INFO [org.jboss.as] JBoss AS 7.0.1.Final "Zap" starting  

 09:30:32,618 WARN [org.jboss.as] No security realm defined for native management service, all access will be unrestricted.  

 09:30:32,693 INFO [org.jboss.as] creating http management service using network interface (management) port (9990)  

 09:30:32,694 WARN [org.jboss.as] No security realm defined for http management service, all access will be unrestricted.  

 09:30:32,703 INFO [org.jboss.as.logging] Removing bootstrap log handlers  

 09:30:32,720 INFO [org.jboss.as.connector.subsystems.datasources] (Controller Boot Thread) Deploying JDBC-compliant driver class org.h2.Driver (version 1.2)  

 09:30:32,739 INFO [org.jboss.as.clustering.infinispan.subsystem] (Controller Boot Thread) Activating Infinispan subsystem.  

 09:30:32,905 INFO [org.jboss.as.naming] (Controller Boot Thread) Activating Naming Subsystem  

 09:30:32,915 INFO [org.jboss.as.naming] (MSC service thread 1-1) Starting Naming Service  

 09:30:32,918 INFO [org.jboss.as.osgi] (Controller Boot Thread) Activating OSGi Subsystem  

 09:30:32,940 INFO [org.jboss.as.security] (Controller Boot Thread) Activating Security Subsystem  

 09:30:32,957 INFO [org.jboss.remoting] (MSC service thread 1-4) JBoss Remoting version 3.2.0.Beta2  

 09:30:32,968 INFO [org.xnio] (MSC service thread 1-4) XNIO Version 3.0.0.Beta3  

 09:30:32,982 INFO [org.xnio.nio] (MSC service thread 1-4) XNIO NIO Implementation Version 3.0.0.Beta3  

 09:30:33,182 INFO [org.apache.catalina.core.AprLifecycleListener] (MSC service thread 1-4) The Apache Tomcat Native library which allows optimal performance in production environments was not found on the java.library.path: /opt/Java/SunJava-6/jdk1.6.0_21/jre/lib/i386/server:/opt/Java/SunJava-6/jdk1.6.0_21/jre/lib/i386:/opt/Java/SunJava-6/jdk1.6.0_21/jre/../lib/i386:/usr/java/packages/lib/i386:/lib:/usr/lib  

 09:30:33,203 INFO [org.jboss.as.jmx.JMXConnectorService] (MSC service thread 1-2) Starting remote JMX connector  

 09:30:33,209 INFO [org.jboss.as.remoting] (MSC service thread 1-1) Listening on /127.0.0.1:9999  

 09:30:33,232 INFO [org.jboss.as.ee] (Controller Boot Thread) Activating EE subsystem  

 09:30:33,390 INFO [org.apache.coyote.http11.Http11Protocol] (MSC service thread 1-4) Starting Coyote HTTP/1.1 on http--127.0.0.1-8080  

 09:30:33,512 INFO [org.jboss.as.connector] (MSC service thread 1-1) Starting JCA Subsystem (JBoss IronJacamar 1.0.3.Final)  

 09:30:33,554 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-4) Bound data source [java:jboss/datasources/ExampleDS]  

 09:30:33,919 INFO [org.jboss.as.deployment] (MSC service thread 1-4) Started FileSystemDeploymentService for directory /NotBackedUp/jpai/jboss-as-7.0.1.Final/standalone/deployments  

 09:30:33,931 INFO [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.1.Final "Zap" started in 2636ms - Started 93 of 148 services (55 services are passive or on-demand)

Using a different server configuration file

The standalone.sh command by default uses a configuration file named "standalone.xml" which is present in JBOSS_HOME/standalone/configuration folder. The command also allows you to specify a different configuration file, to start the server. Like I mentioned, earlier, I'll be using the standalone-preview.xml in this post. So let's start the server using the standalone-preview.xml.

 jpai@jpai-laptop:bin$ ./standalone.sh -server-config=standalone-preview.xml

As you see, we pass the -server-config parameter with standalone-preview.xml as the parameter value. By default, the file is looked for in the JBOSS_HOME/standalone/configuration folder. The server starts up in around 3.5 seconds:

 09:35:59,694 INFO&nbsp; [org.jboss.as] (Controller Boot Thread) JBoss AS 7.0.1.Final "Zap" started in 3586ms - Started 125 of 184 services (59 services are passive or on-demand)

EJB3 subsystem configurations

Now that we have seen how to startup the server, let's move on to see the configurations. In the standalone-preview.xml, look for the EJB3 subsystem which looks like this:

 <subsystem xmlns="urn:jboss:domain:ejb3:1.1" >  

      <timer-service>  

           <thread-pool core-threads="1" max-threads="4" />  

           <data-store path="timer-service-data" relative-to="jboss.server.data.dir" />  

      </timer-service>  

      <!-- EJB3 pools -->  

      <pools>  

           <bean-instance-pools>  

                <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5"  

                                     instance-acquisition-timeout-unit="MINUTES"/>  

                <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5"  

                                     instance-acquisition-timeout-unit="MINUTES"/>  

           </bean-instance-pools>  

      </pools>  

      <!-- Default MDB configurations -->  

      <mdb>  

           <resource-adapter-ref resource-adapter-name="hornetq-ra"/>  

           <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>  

      </mdb>  

      <!-- Session bean configurations -->  

      <session-bean>  

           <stateless>  

                <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>  

           </stateless>  

      </session-bean>  

 </subsystem>

This is where the EJB3 subsystem level configurations are present. Let's quickly see what some of those are. The first piece of configuration is for EJB3 timerservices. We won't go into too much details of that in this post.

EJB3 Pools

The next piece of configuration is the "pools":

 <!-- EJB3 pools -->  

 <pools>  

      <bean-instance-pools>  

           <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5"  

                                instance-acquisition-timeout-unit="MINUTES"/>  

           <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5"  

                                instance-acquisition-timeout-unit="MINUTES"/>  

      </bean-instance-pools>  

 </pools>

This is where you configure the pools used by EJB3. Within the "pools" element, you can configure the bean instance pools using the "bean-instance-pools" element. In AS 7.0.1, we only support "strict-max-pool" as a bean instance pool.

A strict max pool allows you to configure a maximum upper limit for the pool. At runtime, when all the bean instances from the pool are in use and a new bean invocation request comes in, the pool blocks the request till the next bean instance is available or till a timeout (set in instance-acquisition-timeout) is reached. Each pool has a unique name. The configurations above show 2 strict max pools named "slsb-strict-max-pool" and "mdb-strict-max-pool". You can add a new strict max pool in there and set a unique name of your choice to it. You can either edit the xml by hand (when the server is down) to add a new strict max pool or you can use the Command Line Client (CLI) that comes with AS7. We'll see how to use the CLI, later in this post.

Message driven bean configurations

Let's now move to the next configurations in that EJB3 subsystem:

 <!-- Default MDB configurations -->  

 <mdb>  

      <resource-adapter-ref resource-adapter-name="hornetq-ra"/>  

      <bean-instance-pool-ref pool-name="mdb-strict-max-pool"/>  

 </mdb>

This section configures the MDB with the defaults.

Default resource adapter for MDBs

The "resource-adapter-ref" element specifies the default resource-adapter which will be used by the MDBs. In this example, it shows that we use hornetq-ra as the default RA.

Default bean instance pool for MDBs

The bean-instance-pool-ref acts as a reference to a bean-instance-pool, which will be used as the default pool configuration for all MDBs. In this example, we see that it points to "mdb-strict-max-pool" which we saw in the earlier section was configured as a strict max pool with 20 as the upper limit for the pool. If you want to change the default bean instance pool for MDBs, then just change the pool-name attribute of the bean-instance-pool-ref element to some other bean instance pool that's available. You can either do it by editing the xml directly (when the server is down) or use the CLI to do this (we'll see how that's done, later).

Stateless session bean configurations

Moving on to the next section in the EJB3 configurations, you'll see:

 <!-- Session bean configurations -->  

 <session-bean>  

      <stateless>  

           <bean-instance-pool-ref pool-name="slsb-strict-max-pool"/>  

      </stateless>  

 </session-bean>

This is where you configure the defaults for the session beans. Like we saw with MDBs, the above configuration shows how we configure the default bean instance pool for the stateless session beans. Here we see that "slsb-strict-max-pool" is used as the default. Just like for MDBs, you can change the default bean instance pool for Stateless session beans by changing the pool-name attribute of the bean-instance-pool-ref element either directly in the xml or via the CLI.

Using the Command Line Client (CLI)

AS7 comes with a powerful command line client. Check the AS7 documentation on CLI for a quick reference. The command line client tool is started using the jboss-admin.sh/jboss-admin.bat scripts that are available in the JBOSS_HOME/bin folder:

 jpai@jpai-laptop:bin$ ./jboss-admin.sh

On running that script, you will notice the following message which acts you to connect to the server:

 You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands.  

 [disconnected /]

The CLI requires a running server to be able to connect. So if you haven't started the server, then start it first (as explained in one of the sections above). Now let's connect to the server through the command line:

 [disconnected /] connect  

 Connected to standalone controller at localhost:9999  

 [standalone@localhost:9999 /]

So the CLI is now connected to the server which is listening on localhost on port 9999. The CLI can be passed a different hostname and port to connect to, but let's not get into that now.

Once you are connected to the server from the CLI, you can now run operations from the CLI to manage your running server. Let's now see how we can manage the bean instance pool configurations for EJB3 subsystem.

Create a new strict max bean instance pool from the CLI

After you have connected to the server from the CLI, you can create a new strict max bean instance pool as follows:

 [standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=new-pool:add

I would recommend that you read the CLI documentation to understand the command better. But let me just briefly split up the above command and explain what each part does.

An important thing to note is that you don't have to type all of that on the CLI. The CLI provides a very (very) useful tab completion feature! So typing in /subsystem= and pressing the tab will show you the available options.

Understanding the bean instance pool creation command

From the CLI documentation:

An operation request basically consists of three parts: The address, an operation name and an optional set of parameters.

The formal specification for an operation request is:
 [/node-type=node-name (/node-type=node-name)*] : operation-name [( [parameter-name=parameter-value (,parameter-name=parameter-value)*] )]  

In this example, our goal is to create a new strict max bean instance pool. This can be done by issuing a "add" operation. In the command that I posted above, notice the use of ":add" at the end. An operation always starts with a ":" followed by the operation name. So in the example above, we are issuing the ":add" operation.

Now the "add" operation will have to be executed on a particular "resource". i.e. the server has to know what to add and where. This is known as addressing. In order to run an operation, an address needs to be provided (don't confuse this with the hostname/port "address" of the server, that's completely different). In AS7 management terms, the server is made up of manageable "resources" and each resource has a address of its own. For example, each of the subsystems that make up the server configuration can be addressed. To refer to the ejb3 subsystem from the command line client, you use /subsystem=ejb3 (you can use the tab completion).

Let's say our new pool that we are creating is going to be named "new-pool". So ultimately the address at which the "add" operation needs to be carried out would look like:

 /subsystem=ejb3/strict-max-bean-instance-pool=new-pool

Finally, we will combine the address and the operation and run it from the CLI

 [standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=new-pool:add

A sucessful completion of the operation will show you the following output:

 [standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=new-pool:add  

 {"outcome" => "success"}

All management operations are persisted to the server configuration file. In our case it's the standalone-preview.xml, since that's the one we used to start the server.

After running that operation, you can now open the standalone-preview.xml in a text editor and notice that a new strict max bean instance pool, named "new-pool" has been added to the "bean-instance-pools":

 <pools>  

      <bean-instance-pools>  

           <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>  

           <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>  

           <strict-max-pool name="new-pool"/>  

      </bean-instance-pools>  

 </pools>

The max-pool-size and the other attributes haven't been set and the default values will be used. That's because while running the operation, we did not specify any values for those attributes. Let's now try issuing a command to create one more pool (named "take2") with some specific attribute values. The command will now look like:

 [standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=take2:add(max-pool-size=15,timeout=2)

So the command above is similar to the previous one, except that the name of the pool is "take2" and we have additional specified a max-pool-size of 15 and a timeout of 2 and let the timeout-unit be the default. Note that you can use tab completion while writing that command. On running that command, you'll see the following output:

 [standalone@localhost:9999 /] /subsystem=ejb3/strict-max-bean-instance-pool=take2:add(max-pool-size=15,timeout=2)  

 {"outcome" => "success"}

The standalone-preview.xml will now look like:

 <pools>  

      <bean-instance-pools>  

           <strict-max-pool name="slsb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>  

           <strict-max-pool name="mdb-strict-max-pool" max-pool-size="20" instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES"/>  

           <strict-max-pool name="new-pool"/>  

           <strict-max-pool name="take2" max-pool-size="15" instance-acquisition-timeout="2"/>  

      </bean-instance-pools>  

 </pools>

Notice the "take2" pool which has the max-pool-size and instance-acquisition-timeout values set to whatever we specified on the CLI.

So that's how you create a new bean instance pool from the CLI.

Setting/changing the default bean instance pool used by the MDBs and the SLSBs

In the previous section we saw how to create a new bean instance pool. Now if we want this new pool to be our default pool configuration for MDBs and/or SLSBs, then we can use the CLI to do that.

Let's first see how it's done for MDBs:

 [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=default-mdb-instance-pool, value=take2)

So we are issuing a "write-attribute" operation on the /subsystem=ejb3 address to write the attribute named "default-mdb-instance-pool" with a value "take2". Effectively, this command is going to change the default MDB bean instance pool from "mdb-strict-max-pool" (remember, we saw this in the standalone-preview.xml earlier, in the bean-instance-pool-ref section of the MDB) to the "take2" pool that we create a few steps back. Running this command will show you the following output

 [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=default-mdb-instance-pool, value=take2)  

 {"outcome" => "success"}

If you open the standalone-preview.xml in a text editor, you'll now notice that the changes have been done - the MDB configuration now uses "take2" as the default pool configuration for all MDBs (henceforth).

 <mdb>  

      <resource-adapter-ref resource-adapter-name="hornetq-ra"/>  

      <bean-instance-pool-ref pool-name="take2"/>  

 </mdb>

We can do the same for Stateless session bean configuration too. The command is:

 [standalone@localhost:9999 /] /subsystem=ejb3:write-attribute(name=default-slsb-instance-pool, value=new-pool)  

 {"outcome" => "success"}

Here we set the default-slsb-instance-pool to the "new-pool" that we created earlier. The standalone-preview.xml file will now look like:

 <session-bean>  

      <stateless>  

           <bean-instance-pool-ref pool-name="new-pool"/>  

      </stateless>  

 </session-bean>

So that's it! We have now used the CLI to configure/manage our EJB3 pools.

Disabling pooling for MDBs and Stateless Session Beans

We also allow pooling to be disabled for MDBs and SLSBs. However, it's not always recommended since it can have performance impacts. If as a developer, you know that your beans aren't too heavy during construction (i.e. nothing in constructor and nothing in @PostConstruct), then it sometimes help to disable pooling for the beans. Currently the only way to do this, is by removing the <bean-instance-pool-ref> element from the <mdb> and/or <stateless> elements in the EJB3 subsystem configuration. We don't currently have a way to do this via the CLI nor do we have a way to specify this at per deployment or per bean level.

So, if you know disabling the pooling benefits you, then that's how you can disable it.

Summary

I hadn't thought that this blog would get this lengthy. But since most of this is new in AS7, it was worth writing this up. So, in this blog we saw how and where the EJB3 bean instance pools are configured, how to create new bean instance pools, how to change the default bean instance pools for MDBs and Stateless session beans. We also saw how all of this can be done using the CLI in AS7.

I plan to write some more blog posts in the upcoming days, to explain some other features of AS7 and/or EJB3 in AS7. If you have any questions or run into issues, please visit us in our user forums.

[AS7 Home] [AS7 JIRA] [AS7 User Forum] [AS7 documentation] [AS7 downloads] [AS7 nightly builds]

JBoss AS 7.0.1 released!

2011-08-18T16:55:00.002+05:30

JBoss AS 7.0.1 "Zap" has been released today. It's been one month since AS 7.0.0 was released, so this new release has come in quick time. This new release includes a lot of bug fixes (135 issues in total) that have been mainly reported in the community. Apart from the bug fixes the major features/additions to 7.0.1 are as follows:

* Better JPA integration and plug-ability

As many of you might already know, AS 7.0.0 came bundled with Hibernate 4 version. Users could still package Hibernate 3 within their application and use it. But many users reported issues with Hibernate 3 bundled within their application. Moreover, 7.0.0 did not have a way to allow other JPA implementations (like EclipseLink) to be integrated. As such, major changes were implemented in 7.0.1 to introduce better JPA plug-ability. The JPA reference guide for AS7 is good place to look at the details.

* MDB support

AS 7.0.0 had 2 distributions. One, a purely "web-profile" certified distribution which included EJB3.1 "Lite" support (as mandated by webprofile spec). The other distribution (named "everything") had some more features in addition to "web-profile". EJB3.1 "Lite" doesn't include MDB support. So in AS 7.0.0 we didn't have MDB support. Many users in the forums asked for MDB support to be included in the near future. We decided that it would be good to include it in 7.0.1 and as such, we now support MDBs in the "everything" distribution of 7.0.1. We have had some very good community feedback, on the MDB support, while the development was in progress. So thanks to that feedback, we were able to fix some issues with MDB integration, right in time for the 7.0.1.

So try out the MDB support available in the "everything" distribution of AS 7.0.1 and let us know how it goes.

* EJB3 pool configurations

AS 7.0.0 had hardcoded pool configurations for Stateless session beans. There wasn't a way to configure the pool for the beans. In AS 7.0.1 we have introduced a way to configure pools for Stateless session beans and MDBs. We also allow disabling pools for both Stateless session beans and MDBs. Disabling pools benefits in some cases where the bean construction isn't heavy (like not much in @PostConstruct etc...). I'll blog more about the EJB3 pool configurations in a separate post.

* Ability to bundle application specific JSF version

Users can now bundle their own version of JSF in their applications.

7.0.1 (and AS7 in general) has had a huge community feeback and contribution. A lot of the issues that have been fixed, have been raised by our community members. A big thanks to them for helping us all along, towards AS7 efforts!

As always, give the new release a try and let us know how it goes. We are always looking for inputs to make AS7 better. Report any issues or ask for help in our user forum

I plan to write some more posts around 7.0.1 in the coming days. Also, keep a watch on other blogs from JBoss AS developers and community members around AS7.

[AS7 Home] [AS7 JIRA] [AS7 User Forum] [AS7 documentation] [AS7 downloads] [AS7 nightly builds]

Upcoming JBoss AS7 webinars - highly recommended

2011-06-22T16:16:00.006+05:30

JBoss AS7 has almost arrived! For those of you who haven't been following the latest news about JBoss AS7, here's a quick overview http://www.dzone.com/links/jboss_as7_is_coming.html. JBoss AS 7.0 CR1 will be released sometime this week and then the Final version will be released within a couple of weeks after that.

AS7 is drastically different from the previous versions of JBoss AS, even when it comes to the directory layout and how deployments are managed. Furthermore, it now has inbuilt support for managing multiple servers as a "domain". Developing against AS7 is vastly more productive than the previous versions, since AS7 now boots in just around 3 seconds. There are lots of other features and changes, like a new feature-rich admin console, a lightweight command line client and much muhc more.

Naturally, with these many changes and the nature of these changes, it becomes important that we demonstrate these new features and explain each of them to our users. As such, we have arranged for Webinars around JBoss AS7 in the coming week (June 29 2011 to July 1 2011).

For any JBoss AS user or enthusiast, I would strongly recommend that you register for these webinars and see what's new in AS7. Registration is simple and just requires a email address, to which the demo/live meeting details will be mailed. To find more details about the Webinars, take a look at http://www.jboss.org/webinars.

Complete details of available webinars : http://www.jboss.org/webinars

JBoss AS7 - Next generation EE6 programming : Register here

JBoss AS7 - Management & Clustering : Register here

Furthermore, if you are in Asia, there's a Asia timezone friendly timing of the Webinars:

JBoss AS7 - Next generation EE6 programming (Asia timezone) : Register here

JBoss AS7 - Management & Clustering (Asia timezone): Register here

JBoss Community Recognition Awards 2011 - Winners announced

2011-04-10T19:08:00.001+05:30

In my previous post I blogged about the JBoss Community Recognition Awards 2011, for which voting was in progress. Thanks to all those who participated in the voting process. The winners have now been announced. Congratulations to all the winners! :)

JBoss Community Recognition Awards 2011 - voting in progress

2011-02-28T16:11:00.000+05:30

Like the previous year, this year too the polls for various categories under JBoss Community Recognition Awards for 2011 have begun. The awards have been categorized into 5 categories. You can vote for the nominees in each of the following categories:

Poll : New Features category
Poll : Bug fixes category
Poll : Issue/JIRA category
Poll : Wiki category
Poll : Documentation category

So go ahead and cast your vote! This is one way of thanking the community members for the help/support they have been providing. For more about JBoss Community Recognition Awards (JBCRA) read this http://www.jboss.org/jbcra and to read more about the nominees see this http://www.jboss.org/jbcra/nominees.html

@Resource and the new lookup attribute - How to avoid compilation and runtime problems

2011-02-09T14:13:00.000+05:30

More and more users have started moving to Java EE6 functionality and one of the common question that keeps coming up in the forums these days is about the use of the "lookup" attribute of the @Resource annotation. Java EE6 introduced this new attribute to the @javax.annotation.Resource annotation (javadoc). In the previous version, this attribute wasn't available. So now users can start using this attribute as follows:

package org.myapp;

import javax.annotation.Resource;
import javax.ejb.Stateless;
import javax.sql.DataSource;

/**
 * Author: Jaikiran Pai
 */
@Stateless
public class SimpleSLSB
{

   @Resource(lookup = "test")
   private DataSource dataSource;


   public void doNothing()
   {
      // nothing!
   }
}

Simple enough! However, the problem arises when you try to compile this code or even run it. Compiling this code with JDK 1.6 leads to this compile time error:

[ERROR] /NotBackedUp/jpai/business/me/resource-lookup/src/main/java/org/myapp/SimpleSLSB.java:[36,13] cannot find symbol
[ERROR] symbol  : method lookup()
[ERROR] location: @interface javax.annotation.Resource

The root cause of this issue is that the standalone JDK itself ships its own version of @javax.annotation.Resource which doesn't have this lookup attribute (javadoc). The compiler ends up using the version shipped in the JDK.

So how do we get past this problem. The solution is simple - all you have to do is set the -Djava.endorsed.dirs system property to point to the folder containing the jar which has the new @javax.annotation.Resource annotation. The -Djava.endorsed.dirs needs to be set while compiling the program as well as while running the program. Depending on what tool you use to compile the program, there are different ways to set this system property. Let's see how we handle this in a Maven project.

Building through Maven:

Maven is a build tool which is used in many project these days. Maven uses a build file named pom.xml which can be used to setup the dependencies of the project as well as other build related configurations. I'll assume that those of you who are using Maven, already know all these details and just want to see how to get the @Resource(lookup="") working within a Maven project. So here it is:

1) Use the maven-dependency-plugin to "copy" the jar containing the new javax.annotation.* classes into some folder within your project. In this example, I'm copying it over to a folder named "endorsed" within the project's build directory:

   <build>
      <plugins>

         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>2.1</version>
            <executions>
               <execution>
                  <goals>
                     <goal>copy</goal>
                  </goals>
                  <configuration>
                     <!-- Configure the plugin to copy the jar containing javax.annotation.*
                        to a folder named "endorsed" within the project's build directory -->
                     <artifactItems>
                        <artifactItem>
                           <groupId>org.jboss.spec.javax.annotation</groupId>
                           <artifactId>jboss-annotations-api_1.1_spec</artifactId>
                        </artifactItem>
                     </artifactItems>
                     <outputDirectory>${project.build.directory}/endorsed</outputDirectory>
                  </configuration>
               </execution>
            </executions>
         </plugin>

       ...

2) Now let's instruct the compiler plugin and the surefire plugin (which runs your unit tests) to use the jar from the project's endorsed folder. As I said eariler, we just need to set the -Djava.endorsed.dirs property to make this happen. So here's how we do it for these 2 plugins:

...
<!-- Setup the compiler plugin to use the endorsed directory containing
          our javax.annotation.* classes -->
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>2.3.2</version>
            <configuration>
               <source>1.6</source>
               <target>1.6</target>
               <!-- Setup the compiler plugin to use the endorsed directory containing
               the jar for javax.annotation.* classes. Remember that we setup this folder
               via the maven-dependency-plugin configuration, above. -->
               <compilerArgument>-Djava.endorsed.dirs=${project.build.directory}/endorsed</compilerArgument>
            </configuration>
         </plugin>

         <!-- Setup surefire plugin to use the endoresed directory containing our javax.annotation.* classes -->
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.5</version>
            <configuration>
               <!-- Setup the surefire plugin to use the endorsed directory containing
               the jar for javax.annotation.* classes. Remember that we setup this folder
               via the maven-dependency-plugin configuration, above. -->
               <argLine>-Djava.endorsed.dirs=${project.build.directory}/endorsed</argLine>
            </configuration>
         </plugin>

      </plugins>
   </build>

That's it! We now have setup our project to use the correct endorsed jars. Here's the complete pom.xml for this sample project:

<?xml version="1.0" encoding="UTF-8"?>
<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/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>

    <groupId>jaikiran</groupId>
    <artifactId>resource-lookup</artifactId>
    <version>1.0</version>

   <build>
      <plugins>

         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-dependency-plugin</artifactId>
            <version>2.1</version>
            <executions>
               <execution>
                  <goals>
                     <goal>copy</goal>
                  </goals>
                  <configuration>
                     <!-- Configure the plugin to copy the jar containing javax.annotation.*
                        to a folder named "endorsed" within the project's build directory -->
                     <artifactItems>
                        <artifactItem>
                           <groupId>org.jboss.spec.javax.annotation</groupId>
                           <artifactId>jboss-annotations-api_1.1_spec</artifactId>
                        </artifactItem>
                     </artifactItems>
                     <outputDirectory>${project.build.directory}/endorsed</outputDirectory>
                  </configuration>
               </execution>
            </executions>
         </plugin>

         <!-- Setup the compiler plugin to use the endorsed directory containing
          our javax.annotation.* classes -->
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-compiler-plugin</artifactId>
            <version>2.3.2</version>
            <configuration>
               <source>1.6</source>
               <target>1.6</target>
               <!-- Setup the compiler plugin to use the endorsed directory containing
               the jar for javax.annotation.* classes. Remember that we setup this folder
               via the maven-dependency-plugin configuration, above. -->
               <compilerArgument>-Djava.endorsed.dirs=${project.build.directory}/endorsed</compilerArgument>
            </configuration>
         </plugin>

         <!-- Setup surefire plugin to use the endoresed directory containing our javax.annotation.* classes -->
         <plugin>
            <groupId>org.apache.maven.plugins</groupId>
            <artifactId>maven-surefire-plugin</artifactId>
            <version>2.5</version>
            <configuration>
               <!-- Setup the surefire plugin to use the endorsed directory containing
               the jar for javax.annotation.* classes. Remember that we setup this folder
               via the maven-dependency-plugin configuration, above. -->
               <argLine>-Djava.endorsed.dirs=${project.build.directory}/endorsed</argLine>
            </configuration>
         </plugin>

      </plugins>
   </build>

    <dependencies>
       <!-- EJB API dependency -->
       <dependency>
          <groupId>org.jboss.spec.javax.ejb</groupId>
          <artifactId>jboss-ejb-api_3.1_spec</artifactId>
          <version>1.0.0.Final</version>
       </dependency>

       <!-- javax.annotation.* dependency -->
       <dependency>
          <groupId>org.jboss.spec.javax.annotation</groupId>
          <artifactId>jboss-annotations-api_1.1_spec</artifactId>
          <version>1.0.0.Final</version>
       </dependency>
    </dependencies>
</project>

Running "mvn clean install" will now show a build success:

[INFO] --- maven-compiler-plugin:2.3.2:compile (default-compile) @ resource-lookup ---
[WARNING] File encoding has not been set, using platform encoding UTF-8, i.e. build is platform dependent!
[INFO] Compiling 1 source file to /NotBackedUp/jpai/business/me/resource-lookup/target/classes
[INFO] 
[INFO] --- maven-resources-plugin:2.4.3:testResources (default-testResources) @ resource-lookup ---
[WARNING] Using platform encoding (UTF-8 actually) to copy filtered resources, i.e. build is platform dependent!
[INFO] skip non existing resourceDirectory /NotBackedUp/jpai/business/me/resource-lookup/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:2.3.2:testCompile (default-testCompile) @ resource-lookup ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-surefire-plugin:2.5:test (default-test) @ resource-lookup ---
[INFO] No tests to run.
[INFO] 
...
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 6.087s
[INFO] Finished at: Wed Feb 09 13:02:02 IST 2011
[INFO] Final Memory: 9M/129M
[INFO] ------------------------------------------------------------------------

Although it did not involve much to set this up in Maven, it did however require setting it up with the use of 3 separate plugins. It would have been far more easier if there was a way in Maven where we could just add a "dependency" to the endorsed dir and let all the relevant plugins use it without the developer having to configure each of those separately. But anyway, we got what we were after - a successful compilation of that class using @Resource(lookup="").

JBoss AS 6.0 Final released

2010-12-28T22:06:00.000+05:30

JBoss AS 6.0.0.Final has just been released. The release notes are here and the download is available from the JBoss AS download page here.

I'll blog more about this in the days to come. For now, to summarize what's new in 6.0.0 Final - there have been numerous bug fixes for issues reported by the community. Furthermore from a EJB3.1 point of view, we now have EJB3.1 Embedded support and a far better support for EJB3.1 @Asynchronous functionality.

As usual, give it a try and feel free to ask any questions or report any issues, in our user forums:

JBoss AS user forum: http://community.jboss.org/en/jbossas?view=discussions
EJB3 user forum: http://community.jboss.org/en/ejb3?view=discussions

JBoss AS 6.0 CR1 released

2010-11-29T15:48:00.000+05:30

JBoss AS 6.0 CR1 was released last week and I'm bit late on writing this blog :) I'll briefly summarize what 6.0 CR1 contains, mainly from EJB3.1 point of view.

Like I mentioned in my previous blog entry, this latest release of AS now has support for EJB3.1 spec mandated JNDI naming scheme for EJBs. It also contains various bug fixes in JBoss EJB3 implementation that were reported by the community in the previous versions of JBoss AS. We are now left with just a couple of EJB3.1 features - support for EJB3.1 Embedded and a full fledged support for EJB3.1 @Asynchronous invocations. These 2 features will make it to 6.0 Final version of JBoss AS, which is planned during December 2010.

Apart from EJB3.1, the other set of new features and bug fixes in 6.0 CR1 have been listed here. Shelly has blogged about this release and the upcoming 6.0 Final release here.

So go download the latest release and give it a try. As usual, feel free to report any issues (so that they get fixed in 6.0 Final) in our user forums. Some useful links are provided below:

JBoss AS Download page : http://www.jboss.org/jbossas/downloads.html

JBoss AS user forum : http://community.jboss.org/en/jbossas?view=discussions

JBoss EJB3 user forum : http://community.jboss.org/en/ejb3?view=discussions

JBoss AS JIRA (bug tracking system) : https://jira.jboss.org/browse/JBAS

EJB3.1 Global JNDI Access - A portable jndi naming scheme for EJBs

2010-10-10T12:50:00.000+05:30

Many of you, who have been using EJBs would know that one of the pain points, with respect to portability, is the JNDI names of the beans. As you all will be aware, prior to EJB3.1 spec, there wasn't a standard portable JNDI naming scheme for EJBs. Each application server had its own JNDI naming scheme, which would often mean that you either had to include a server specific deployment descriptor (jboss.xml for JBoss AS) or use annotations to override the JNDI names (for EJB3.0). So while migrating our project to some other application server, you almost always would end up with NameNotFoundException, if you forgot to configure/change the JNDI names to match the application server you are deploying to.

However, starting EJB3.1, the spec now mandates portable JNDI names for EJBs. The compliant application servers are now expected to bind the EJBs at some pre-defined portable JNDI names. Effectively, when you deploy the same EJB jar into a different compliant application server, you will no longer have to change/configure the JNDI names, if you use the portable JNDI names during lookup.

Syntax of portable JNDI names:

The EJB3.1 spec (section 4.4 "Global JNDI Access") explains the syntax of the portable JNDI names. It's actually more than a couple of lines, with examples. So quoting that section here would be a waste of space. Its better to just download the spec and read through it. But I'll just show some examples of the portable JNDI names, in the next section.

Example of the new JNDI naming scheme:

Let's assume you have the following Stateless EJB:

 
package org.myapp.ejb.impl;

@Stateless
@Remote(Echo.class)
@LocalBean
public class SimpleSLSB implements Echo
{
...
}

The SimpleSLSB exposes a remote business interface view and also (explicitly) marks the bean for the no-interface view. So this bean now has 2 views - the remote business interface view and the no-interface view.

Let's further assume that we are packaging this bean in a simple .jar file and deploying it to the application server. Let's name the jar file myejb3.jar.

As per the EJB3.1 spec, global jndi naming scheme, this bean will now be available at (all of the) following JNDI names:

java:global/myejb3/SimpleSLSB!org.myapp.ejb.impl.Echo
java:global/myejb3/SimpleSLSB!org.myapp.ejb.impl.SimpleSLSB
java:app/myejb3/SimpleSLSB!org.myapp.ejb.impl.Echo
java:app/myejb3/SimpleSLSB!org.myapp.ejb.impl.SimpleSLSB
java:module/SimpleSLSB!org.myapp.ejb.impl.Echo
java:module/SimpleSLSB!org.myapp.ejb.impl.SimpleSLSB

#1 above exposes the remote business interface view in the java:global namespace and #2 exposes the no-interface view (remember, we explicitly marked our bean as @LocalBean) in the java:global namespace. As can be seen, the JNDI name is composed of a namespace (for example java:global), a app/module name (for example myejb3), the bean name, which by default is the unqualified name of the bean implementation class (for example SimpleSLSB) and finally the fully qualified name of the business interface being exposed (for example, org.myapp.ejb.impl.Echo). In case of no-interface view, the final part of the JNDI name is the fully qualified name of the bean implementation class.

The rest of the JNDI names follow the same naming scheme, except that they are available in a different JNDI namespace. More details can be found in the EJB3.1 spec (section 4.4 "Global JNDI Access").

Support for EJB3.1 global JNDI names in JBoss AS:

The current JBoss AS trunk supports this new JNDI naming scheme. So the upcoming JBoss AS 6.0.0.CR1 release will have support for this feature. However, if you want to try it out before JBoss AS 6.0.0.CR1 is released, then you can download the nightly build of JBoss AS from here and give it a try.

Reporting issues:

If you have any questions or run into issue while testing this, then feel free to bring it up in our EJB3 user forum.

JBoss AS 6.0.0.M5 released

2010-09-25T20:56:00.000+05:30

JBoss AS 6.0.0.M5 has just been released. This is mainly a bug fix release, in preparation for the upcoming 6.0.0.CR1 release.

What are the JBoss EJB3 changes in JBoss AS 6.0.0.M5:

There have been many user reported and other EJB3.x bug fixes that have been included JBoss AS 6.0.0.M5. Other than the bug fixes, there has been one important change to the way we deploy (our internal) JBoss EJB3.x timerservice. This change involves deploying (our internal) timerservice implementation "lazily". The timerservice is deployed only when the server has any EJB3.x deployments. The change was done to improve the JBoss AS boot time. The complete details of the change can be found here

Download:

So as always, go download the server from here and give it a try! Any issues/questions can always be asked in our user forum here

Release Notes:

You can find the release notes of JBoss AS 6.0.0.M5 here.

JBoss AS6 FAQ:

JBoss AS6 specific FAQ can be found here

MySQL installation error - Neither host nor 'localhost' could be looked up

2010-08-22T14:03:00.000+05:30

While trying to install MySQL 5.1 on my Ubuntu system recently, I ran into an annoying error. I call it annoying because the error message turned out to be a bit misleading. I'll first mention the steps that I followed to install MySQL and the error that I ran into and finally the "fix" to get past the error.

System details:

- Ubuntu 10.04 Operating System

- MySQL 5.1.x downloaded from the official site here http://dev.mysql.com/downloads/mysql/ and selected the "Compressed TAR Archive" (mysql-5.1.50-linux-i686-glibc23.tar.gz to be precise) under the "Linux - Generic" platform

Installation steps:

- Extracted the .tar.gz locally to /home/jpai/MySQL/mysql-5.1.50-linux-i686-glibc23. In the rest of this article, I'll refer to this path as

- From the command prompt, "cd" to

(Some steps mentioned in the /INSTALL-BINARY file are skipped in this article, since they aren't relevant here)

- Run the scripts/mysql_install_db command from the command prompt:


jpai@jpai-laptop:mysql-5.1.50-linux-i686-glibc23$ scripts/mysql_install_db

Error:

Running that above command threw up the following error message:


jpai@jpai-laptop:mysql-5.1.50-linux-i686-glibc23$ scripts/mysql_install_db 
Neither host 'jpai-laptop' nor 'localhost' could be looked up with
/usr/bin/resolveip
Please configure the 'hostname' command to return a correct
hostname.
If you want to solve this at a later stage, restart this script
with the --force option

That message looked strange because I was able to ping those hostnames and was sure that I had my hostname setup properly. So I decided to see why "usr/bin/resolveip" can't resolve those hostnames. So from the command prompt, I tried running the following command:


jpai@jpai-laptop:~$ /usr/bin/resolveip --help

This threw up an error:


jpai@jpai-laptop:~$ /usr/bin/resolveip --help
bash: /usr/bin/resolveip: No such file or directory

So obviously, /usr/bin/resolveip command doesn't exist at all. So why was the MySQL installation trying to use this non-existent command? I then decided to take a look at the scripts/mysql_install_db script under . The lines, in that script, from where this error is being thrown are as follows:


# Check if hostname is valid
if test "$cross_bootstrap" -eq 0 -a "$in_rpm" -eq 0 -a "$force" -eq 0
then
  resolved=`$extra_bindir/resolveip $hostname 2>&1`
  if test $? -ne 0
  then
    resolved=`$extra_bindir/resolveip localhost 2>&1`
    if test $? -ne 0
    then
      echo "Neither host '$hostname' nor 'localhost' could be looked up with"
      echo "$extra_bindir/resolveip"
      echo "Please configure the 'hostname' command to return a correct"
      echo "hostname."
      echo "If you want to solve this at a later stage, restart this script"
      echo "with the --force option"
      exit 1
    fi
    echo "WARNING: The host '$hostname' could not be looked up with resolveip."
    echo "This probably means that your libc libraries are not 100 % compatible"
    echo "with this binary MySQL version. The MySQL daemon, mysqld, should work"
    echo "normally with the exception that host name resolving will not work."
    echo "This means that you should use IP addresses instead of hostnames"
    echo "when specifying MySQL privileges !"
  fi
fi

The important part from those lines are:


resolved=`$extra_bindir/resolveip $hostname 2>&1`

and


resolved=`$extra_bindir/resolveip localhost 2>&1`

As can be seen the script tries to infer the location of "resolveip" command through the $extra_bindir variable. This variable gets set earlier in that script, based on various conditions. Some of the relevant lines are these:


# Now we can get arguments from the groups [mysqld] and [mysql_install_db]
# in the my.cfg file, then re-run to merge with command line arguments.
parse_arguments `$print_defaults $defaults mysqld mysql_install_db`
parse_arguments PICK-ARGS-FROM-ARGV "$@"

# Configure paths to support files
if test -n "$srcdir"
then
  basedir="$builddir"
  bindir="$basedir/client"
  extra_bindir="$basedir/extra"
  mysqld="$basedir/sql/mysqld"
  langdir="$srcdir/sql/share/english"
  pkgdatadir="$srcdir/scripts"
  scriptdir="$srcdir/scripts"
elif test -n "$basedir"
then
  bindir="$basedir/bin"
  extra_bindir="$bindir"
  mysqld=`find_in_basedir mysqld libexec sbin bin`
  if test -z "$mysqld"
  then
    cannot_find_file mysqld $basedir/libexec $basedir/sbin $basedir/bin
    exit 1
  fi
  langdir=`find_in_basedir --dir errmsg.sys share/english share/mysql/english`
  if test -z "$langdir"
  then
    cannot_find_file errmsg.sys $basedir/share/english $basedir/share/mysql/english
    exit 1
  fi
  pkgdatadir=`find_in_basedir --dir fill_help_tables.sql share share/mysql`
  if test -z "$pkgdatadir"
  then
    cannot_find_file fill_help_tables.sql $basedir/share $basedir/share/mysql
    exit 1
  fi
  scriptdir="$basedir/scripts"
else
  basedir="."
  bindir="./bin"
  extra_bindir="$bindir"
  mysqld="./bin/mysqld"
  pkgdatadir="./share"
  scriptdir="./bin"
fi

In short, those lines check for the presence of "default" values for some variables like "basedir" in MySQL configuration files (from earlier installations) under some known locations like /etc/my.cnf or the /etc/mysql. Incidentally, I had one such file /etc/mysql/my.cnf with one of the lines being:


...
basedir  = /usr
...

So effectively, MySQL ended up picking up "basedir" as /usr and ultimately the following lines in the script:


...
  bindir="$basedir/bin"
  extra_bindir="$bindir"
...

set extra_bindir to /usr/bin.

Now that explained why the MySQL installation ending up using /usr/bin/resolveip while resolving the hostname:


resolved=`$extra_bindir/resolveip $hostname 2>&1`

Solution:

For those who are just looking for a solution to get past this error, I'll just quickly explain what needs to be done. The scripts/mysql_install_db script allows for explicitly specifying the basedir to use during the installation. So the solution is to pass the as the value of basedir from the command prompt while running that script. Here's how you do it:


jpai@jpai-laptop:mysql-5.1.50-linux-i686-glibc23$ scripts/mysql_install_db --basedir=.

(Remember that we are running this command from the , so the relative path "." works fine for the basedir).

By passing the value for basedir we have now made sure that MySQL picks up the "resolveip" command from the correct location, which is /bin/resolveip. Yes, "resolveip" is indeed shipped as part of the MySQL download.

What's annoying about this error:

I earlier mentioned that I found this error annoying because of the misleading error message. As we saw, the real problem was that the installation script was trying to use an non-existent command (due to incorrect path). The reason why it used the incorrect path was mainly my fault, because I ignored a part in the INSTALL_BINARY file which mentioned:


Warning

   If you have previously installed a MySQL installation using your
   operating system native package management system, such as yum or
   apt-get, you may experience problems installing using a native
   binary. Make sure your previous MySQL previous installation has
   been removed entirely (using your package management system), and
   that any additional files, such as old versions of your data
   files, have also been removed. You should also check the existence
   of configuration files such as /etc/my.cnf or the /etc/mysql
   directory have been deleted.

*But* the error message should really have printed out a message which could probably have said:


"/usr/bin/resolveip" command not found. 
Make sure basedir (and other variables) point to the right location. 
Tip: resolveip can be located in the bin folder of MySQL download location.

This would have made it real easy for the user to fix the issue instead of trying to figure out what's wrong with their hostname.

EJB3.1 TimerService in JBoss AS 6.0.0.M4

2010-07-27T23:41:00.000+05:30

For those of you, who have been waiting for more of EJB3.1 features in JBoss AS, here's some good news! JBoss AS 6.0.0.M4 which will be released in a day or two, introduces support for EJB3.1 Timer Service and EJB3.1 Asynchronous invocations. In this article, we'll see some examples on EJB3.1 timer service features.

Download JBoss AS:

Before, starting with the example, let's first download JBoss AS 6.0.0.M4. You can download it from here. After downloading the AS, start and stop it once to make sure it boots without any issues.

In the next steps we will see a simple EJB3.1 timerservice example (mainly the calendar expression support)

EJB3.1 Timer Service:

Note that the examples shown below are just for the sake of illustrating the usage of timerservice API and as such don't hold much meaning.

Let's consider a very simple stateless session bean which exposes a remote business interface view:

 
package org.jboss.ejb3.timerservice.example;

public interface TimerOps
{

   /**
    * Schedules a timer for the passed calendarSchedule
    *   
    * @param calendarSchedule The calendar expression based schedule
    * @param taskName The name of the task, which will be passed an a info to the {@link Timer}
    * 
    */
   void scheduleTask(ScheduleExpression calendarSchedule, String taskName);
   
   
}

 
package org.jboss.ejb3.timerservice.example;

import java.util.Date;

import javax.annotation.Resource;
import javax.ejb.Remote;
import javax.ejb.ScheduleExpression;
import javax.ejb.Stateless;
import javax.ejb.Timeout;
import javax.ejb.Timer;
import javax.ejb.TimerConfig;
import javax.ejb.TimerService;

import org.jboss.ejb3.annotation.RemoteBinding;

@Stateless
@Remote (TimerOps.class)
@RemoteBinding (jndiBinding = "timerservice-example-scheduler-remote")
public class Scheduler implements TimerOps
{

   @Resource
   private TimerService timerService;
   
   @Override
   public void scheduleTask(ScheduleExpression calendarSchedule, String taskName)
   {
      // TimerConfig can be passed to the timer service, during timer creation,
      // to specify whether the timer is persistent and also pass any additional
      // Serializable info. 
      TimerConfig timerConfig = new TimerConfig();
      
      // by default, timers are persistent. So we don't really have to
      // set the persistence property on the TimerConfig. It's done here,
      // just to demonstrate the usage
      timerConfig.setPersistent(true);
      
      // set the "info" to be passed to the timers
      timerConfig.setInfo(taskName);
      
      // Now, use the injected timerservice to create a timer instance,
      // for the passed schedule and the timer config
      Timer timer = this.timerService.createCalendarTimer(calendarSchedule, timerConfig);
      
      // that's it, we are done. The timer is now created and started (on successful completion
      // of this method). When the scheduled timeout occurs, a method in this bean which is marked
      // as the timeout callback method will be invoked. 
   }
   
   /**
    * This method will be invoked by the server when a scheduled timeout occurs for timer(s)
    * created through the timerservice corresponding to this bean.
    * 
    * @param timer The {@link Timer} for which the timeout occurred
    */
   @Timeout
   private void onTimeout(Timer timer)
   {
      // do some task here. for now, let's just print out to System.out
      System.out.println("Timeout method invoked at " + new Date() + " for bean " + this.getClass().getSimpleName());
   }

}

So in the example above, we have a TimerOps interface which is exposed as the remote view for the Scheduler Stateless session bean. The TimerOps interface allows scheduling timers based on a javax.ejb.ScheduleExpression. This ScheduleExpression is used to express calendar based timeout expressions. We will see more of it, later in this article.

Moving on to the Scheduler SLSB, you will notice that it expects the TimerService to be injected:

 

   @Resource
   private TimerService timerService;

The injection of timer service into beans, requires no more than annotating that field with the @javax.annotation.Resource annotation. The bean will then use the injected timerservice to create and operate on the timers.

Let's look at the scheduleTask method in that bean:

 
 @Override
   public void scheduleTask(ScheduleExpression calendarSchedule, String taskName)
   {
      // TimerConfig can be passed to the timer service, during timer creation,
      // to specify whether the timer is persistent and also pass any additional
      // Serializable info. 
      TimerConfig timerConfig = new TimerConfig();
      
      // by default, timers are persistent. So we don't really have to
      // set the persistence property on the TimerConfig. It's done here,
      // just to demonstrate the usage
      timerConfig.setPersistent(true);
      
      // set the "info" to be passed to the timers
      timerConfig.setInfo(taskName);
      
      // Now, use the injected timerservice to create a timer instance,
      // for the passed schedule and the timer config
      Timer timer = this.timerService.createCalendarTimer(calendarSchedule, timerConfig);
      
      // that's it, we are done. The timer is now created and started (on successful completion
      // of this method). When the scheduled timeout occurs, a method in this bean which is marked
      // as the timeout callback method will be invoked. 
   }

It doesn't do much, actually. It first creates (an optional) javax.ejb.TimerConfig to pass during timer creation. The TimerConfig, is where you specify whether the timer has to be persistent and/or any additional Serializable "info" that needs to be associated with the Timer, so that it is available in the timeout callback method.

In our example, above, we set the timer to be persistent (that's the default anyway) and also set the "info" to the taskName that was passed. This can be any Serializable info. Here we are just passing around some dummy String, for the sake of demonstrating the API usage.

Then, we use the injected timerservice to create a calendar timer. A calendar timer is a Timer which is created based on a calendar schedule expression. A calendar schedule expression is represented by a ScheduleExpression which expresses a schedule based on the following attributes:

 
 1) dayOfMonth :  Specifies the day of month when the timeout should occur
  Default Value = "*" (which means, any day of month)
  Example values = Last, 1, 2, 31, 28 etc...
 
 2) dayOfWeek : Specifies the day of week when the timeout should occur
  Default Value = "*" (which means, any day of month)
  Example values = Sun, Wed, 2, 7 etc...

    3) hour : Specifies the hour when the timeout should occur
  Default Value = "0" 
  Example values = 12, 23, 18, 2 etc...
  
 4) minute : Specifies the minute when the timeout should occur
   Default value = "0"
   Example values = 10, 12, 35, 59 etc...
   
 5) second : Specifies the second when the timeout should occur
  Default Value = "0";
  Example values = 10, 15, 20 etc...
  
 6) month : Specifies the month when the timeout should occur
  Default value = * (any month)
  Example values = Jan, Mar, 4, 6 etc...
  
 7) year : Specifies the year when the timeout should occur
  Default value = * (any year)
  Example values = 2010, 2020 etc...

Please refer to the EJB3.1 spec for more details on ScheduleExpression.

So, for example, if we want to schedule a timer to fire every Monday at 3:30 in the morning, then we can create the following ScheduleExpression:

 
 ScheduleExpression everyMondayThreeThirty = new ScheduleExpression();
 everyMondayThreeThirty.dayOfWeek("Mon").hour(3).minute(30);

Okay, so let's back to our Scheduler bean now. This is where we create the timer in the bean:

 
Timer timer = this.timerService.createCalendarTimer(calendarSchedule, timerConfig);

So once the Scheduler bean's schedule method completes, the timer will be started (remember, timers are transactional, so the timer start waits for the transaction to complete). Once the timeout occurs for the timer, the server will invoke the timeout callback method on the bean. In our example, we have annotated our onTimeout() method as the timeout callback method (note the @Timeout annotation):

 
   /**
    * This method will be invoked by the server when a scheduled timeout occurs for timer(s)
    * created through the timerservice corresponding to this bean.
    * 
    * @param timer The {@link Timer} for which the timeout occurred
    */
   @Timeout
   private void onTimeout(Timer timer)
   {
      // do some task here. for now, let's just print out to System.out
      System.out.println("Timeout method invoked at " + new Date() + " for bean " + this.getClass().getSimpleName());
   }

So that was our bean and its remote interface. Now let's take a quick look at our client code which looks up the bean and schedules the timer:

 
package org.jboss.ejb3.timerservice.example.client;
 
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import org.jboss.ejb3.timerservice.example.*;
 
public class Client
{
   public static void main(String[] args) throws Exception
   {
 
      Context ctx = new InitialContext();
      // lookup the bean
      TimerOps scheduler = (TimerOps) ctx.lookup("timerservice-example-scheduler-remote");
      
      // create a schedule
      // Let's say, we want to fire a timeout every Monday at 3, 6 and 9 in the morning
      ScheduleExpression everyMonAtThreeSixAndNineAM = new ScheduleExpression();
      everyMonAtThreeSixAndNineAM.dayOfMonth("Mon").hour("3,6,9");
      
      // schedule our task
      scheduler.scheduleTask(everyMonAtThreeSixAndNineAM, "Hello World Timer");
      
   }
 
}

In the client code, we first lookup the TimerOps remote business view of the bean. We then create a calendar schedule which is expected to fire on every Monday at 3, 6 and 9 in the morning. We then use the bean to schedule the task. That's it. On Monday, every morning 3AM, 6AM and 9AM, you will see the timeout being fired.

What next?

The above example was just one part of the new features in EJB3.1 timer service. Here's another - let's assume that you want to avoid having an additional method on the bean just to create a timer. Let's say that you want a timer to be created and scheduled to fire every day at 8:30 in the morning, from the time the bean is deployed. EJB3.1 timer service allows that to be done! They are known as auto timers. Here's an example of the same (using annotations):

 
package org.jboss.ejb3.timerservice.example;

import javax.ejb.Schedule;
import javax.ejb.ScheduleExpression;
import javax.ejb.Stateless;
import javax.ejb.Timeout;
import javax.ejb.Timer;
import javax.ejb.TimerConfig;
import javax.ejb.TimerService;
import javax.naming.Context;
import javax.naming.InitialContext;

@Stateless
public class AutoScheduler 
{

   /**
    * This method will be invoked every day at 8:30:00 in the morning
    * @param timer The timer instance
    */
   @Schedule (hour = "8", minute = "30")
   private void executeEveryDayAtEightThirty(Timer timer)
   {
      // do some task here. for now, let's just print out to System.out
      System.out.println("(Auto) timer method invoked at " + new Date() + " for bean " + this.getClass().getSimpleName());
      
   }

}

As you can see we have a Stateless (no-interface view) bean which just has this executeEveryDayAtEightThirty method. The important bit here is the @javax.ejb.Schedule annotation which is used on that method. The Schedule annotation is used to create auto timers. The server will look for methods on the bean with the @Schedule annotation and automatically create the timers when the bean is deployed. The schedule for the timers is passed through the annotation's attribute values. The method on which the @Schedule is used, is considered as the timeout callback method for that auto timer and will be invoked when the timeout occurs.

In our example above, we are creating an auto-timer which will fire every day at 8:30 in the morning and the executeEveryDayAtEightThirty method will be called.

Want some more?

Those were just some of the examples for EJB3.1 timer service. There's much more you can try out. For example, there's also the @Schedules (note that it's not the same as @Schedule), which can be used to create multiple auto-timers for the same timeout callback method. Furthermore, if you don't want to use annotations, you can as well use the deployment descriptors. We also haven't covered the other APIs on the TimerService or the Timer in these examples. We can go on and on, but let's keep this short for now.
But, do try out these new features and let us know if you run into any issues. Feel free to start a discussion about any issues around this, in our EJB3 User Forum or ping us on IRC.

JBoss AS 6.0.0.M3 released

2010-05-05T21:47:00.000+05:30

6.0.0.M3 version of JBoss AS has just been released. You can find the release notes here and you can download the server from the JBoss AS downloads page

This release in addition to bug fixes and other new features, includes support for EJB3.1 Singleton beans. You can find the details and an example here. So it's time to try out this new feature and report any issues in our EJB3 user forums here!

Ofcourse, any JBoss AS specific issues can be discussed in the JBoss AS user forum.

JBoss getting started, DZone RefCard published

2010-05-04T01:42:00.000+05:30

JBoss EAP5/AS5 DZone RefCard has just been published today. It gives you a quick overview of JBoss server installation, deployment, management and its clustering capabilities.

The RefCard has been authored by Scott Marlow, Shelly McGowan, Brian Stansberry, Len DiMaggio and me. You can get a copy of it from here.

Eclipse Logback Plugin with JBoss AS

2010-04-18T13:28:00.000+05:30

Recently in one of the forum threads an user asked how to use Logback Eclipse Plugin along with slf4j logging framework in JBoss AS. Having been tired of all those logging frameworks out there, I wasn't really too interested in looking at the details. But during this weekend, I had this sudden urge of trying out some simple application on which I wouldn't have to spend too much time or energy. So I decided to see what it takes to get the Logback Eclipse Plugin running against JBoss AS. So here's what it takes (well, nothing much actually - around half an hour or less):

Pre-requisites:

- JBoss Application Server 5.1.0 : Since this is the latest stable version, I decided to use this for testing. I don't see any reason why it shouldn't work against other version of the AS (4.x or 6.x).

- Latest release of slf4j library (1.5.11 at the time of writing this article) : JBoss AS-5 (and even AS-6) already ships with the slf4j jar in its lib folder. But since this is just another third party library, each user app should be able to package their own version of the jar within the app (and apply the usual classloading isolation configurations to the app). You can download slf4j from here

- Logback library version 0.9.9 : The logback library can be downloaded from the download site here. The only important thing to remember is to download version 0.9.9 (and *not* the latest one), because the latest versions of that plugin does not work due to a bug. Version 0.9.9 can be found here

- Eclipse IDE : I am currently on 3.4.1 Eclipse. I don't think the version of Eclipse would matter for this application.

- Logback Eclipse Plugin : The details of this plugin can be found here. It includes information on how to configure the plugin for Eclipse and where to download it from. At the time of writing this article, I found the plugin download here

Sample application:

Now that we have the required libraries and the setup ready, the next step is to write a simple application which makes use of slf4j logging framework backed by logback, to log some messages. Since this article is mainly meant as a quick start of getting logback Eclipse plugin working against JBossAS, I decide to use a simple servlet which does nothing more than log some messages.

The servlet looks like this:

 
package org.myapp.servlet;

import java.io.IOException;

import javax.servlet.ServletException;
import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class SimpleServlet extends HttpServlet
{

   private static Logger slf4jLogger = LoggerFactory.getLogger(SimpleServlet.class);
   
   @Override
   protected void doGet(HttpServletRequest req, HttpServletResponse resp) throws ServletException, IOException
   {
      slf4jLogger.info("******************************************");
      slf4jLogger.info("***Hello World from a simple servlet***");
      slf4jLogger.info("***Let's try out some logging messages***");
      slf4jLogger.info("******************************************");
      
      slf4jLogger.debug("This is DEBUG message");
      slf4jLogger.info("This one is INFO message");
      slf4jLogger.warn("Let's also send out a WARN message");
      slf4jLogger.error("Well, sometimes we run into ERROR messages too");
      try
      {
         throw new Exception("Intentional exception for demo");
      }
      catch (Exception e)
      {
         slf4jLogger.error("Error with stacktrace", e);
      }
      slf4jLogger.info("******************************************");
      slf4jLogger.info("***That's it, folks!!!***");
      slf4jLogger.info("******************************************");
      
   }
   
}

It uses slf4j LoggerFactory to create a Logger and then use that logger to write out some log messages at different log levels. That's it.

The web.xml, just maps this servlet to some URL:



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

<web-app>
  <display-name>Logback example for JBossAS</display-name>
  
    <servlet>
         <servlet-name>SimpleServlet</servlet-name>
         <servlet-class>org.myapp.servlet.SimpleServlet</servlet-class>
     </servlet>
     
     <servlet-mapping>
         <servlet-name>SimpleServlet</servlet-name>
         <url-pattern>invokeServlet</url-pattern>
     </servlet-mapping>
     
</web-app>

Then there's jboss-web.xml for classloading configuration:


<jboss-web>

    <class-loading>
        <loader-repository>
            org.myapp:classloader=logback-example
            <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
        </loader-repository>
    </class-loading>
</jboss-web>

And finally, the important one, the logback.xml file which is responsible for configuring the consolePlugin:



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

<configuration debug="true">

  <consolePlugin />

</configuration>

Yes, that's all you need in the logback.xml to get it working. More details can be found in its documentation here. The above config file creates a SocketAppender which uses port 4321 (by default). The Logback Plugin in Eclipse (also by default) connects to this 4321 to receive the log messages (when they are logged).

Note: The debug="true" in that logback.xml is just to show some debug messages when logback is reading that config file. You can remove that attribute, if you don't need such messages.

So now that we have these files ready, we just need to create a deployable application to test it out. I decided to use a .war file in this demo. You can even use a .ear file. I won't get into the details of how to create the .war file. Use your favourite build tool or an IDE to generate the .war file. The final .war should look like this:


myapp.war
 |
 |--- WEB-INF
 |      |
 |      |--- web.xml
 |      |--- jboss-web.xml
 |      |
 |      |---   lib
 |      |       |
 |      |       |--- logback-classic-0.9.9.jar
 |      |       |--- logback-core-0.9.9.jar
 |      |       |--- slf4j-api-1.5.11.jar
 |      |
 |      |
 |      |--- classes
 |      |       |
 |      |       |--- logback.xml
 |      |       |
 |      |       |---   org
 |      |       |       |--- myapp
 |      |       |       |       |--- servlet
 |      |       |       |       |       |--- SimpleServlet.class

Note that the logback.xml is placed in .war/WEB-INF/classes folder because logback looks for that file in the classpath. Also notice the contents of .war/WEB-INF/lib folder - those are the jars that you'll have to package in your application. logback-classic-0.9.9.jar and logback-core-0.9.9.jar can be found in the logback download (which you did in the pre-requisites section). slf4j-api-1.5.11.jar can be found in the slf4j download.

Place this .war file in JBOSS_HOME/server/< servername>/deploy folder and start the server. Also open Eclipse IDE (if it's not already open) and open the "Logback View". Since we haven't yet logged anything from our application, the view will be empty (see image below).

So now let's invoke our servlet which logs the messages. As shown in the web.xml, I have mapped the servlet to the "invokeServlet" URL. So from my web browser, I access http://localhost:8080/myapp/invokeServlet

That's it, the servlet starts logging the messages and in the "Logback View" of Eclipse you will see the logged messages (see image below).

You have now successfully configured Logback Eclipse Plugin to work against JBoss AS. Did not take long to get it working!

EJB3.1 Singleton Bean support now available in JBoss AS trunk

2010-04-06T22:07:00.000+05:30

For those, who have been waiting for EJB3.1 Singleton bean support in JBoss AS, here's some good news. This week, we updated the AS trunk to include support for singleton beans. JBoss AS 6.0.0 M3 will be released in the next few weeks. In the meantime, those of you who want to try out this feature, can follow the instructions here

Feel free to report any issues, in our EJB3 user forum

JBoss AS 6.0.0.M2 released

2010-02-17T15:32:00.000+05:30

JBoss AS 6.0.0.M2 has been released yesterday. This is the second milestone release of the JBoss AS-6 series. You can download it from here.

Brian's blog contains details about what this new release contains. From the EJB3.1 point of view, this release contains the initial EJB3.1 support. See this wiki for more details.

Other than the new features that have been added to 6.0.0.M2, you will also notice that this new version boots faster than the earlier 5.x and 6.0.0.M1 versions. There have been numerous (valid) complaints about slow boot time with AS-5.x and 6.0.0.M1. Although there have been performance improvements after 5.1.0 release, they weren't too noticeable. However, in this version of AS, there have been numerous performance fixes within the JBoss Microcontainer (JBoss MC) project and various other places which ultimately has resulted in a better boot time for JBoss AS. For those who believe in numbers, here's the boot time comparison on my local system:

JBoss AS-5.1.0 "default" server config:


21:02:56,538 INFO  [ServerImpl] JBoss (Microcontainer) [5.1.0.GA (build: SVNTag=JBoss_5_1_0_GA date=200905221053)] Started in 42s:792ms

JBoss AS 6.0.0.M1 "default" server config:


21:08:42,775 INFO  [AbstractServer] JBossAS [6.0.0.M1 (build: SVNTag=JBoss_6_0_0_M1 date=200911281333)] Started in 36s:156ms

JBoss AS 6.0.0.M2 "default" server config:


15:22:01,708 INFO  [org.jboss.bootstrap.impl.base.server.AbstractServer] JBossAS [6.0.0.20100216-M2 (build: SVNTag=JBoss_6_0_0_20100216-M2 date=20100216)] Started in 22s:311ms

So a boot time improvement of 20 seconds from 5.1.0 and 14 seconds from 6.0.0.M1.

One important thing that users must be aware is that, JBoss AS 6.0.0.M2 has introduced the notion of lazy deployment of applications. While working on improving the boot time of AS, it was noticed that the admin-console (JBOSS_HOME/server/< servername>/deploy/admin-console.war) adds almost 25 to 30 seconds to the boot time of the AS. Obviously this isn't good. Furthermore, not many developers really use admin-console, atleast not very frequently while developing and testing their application. So deploying the admin-console (and any other such application) by default isn't of any value for such users. So it was decided that the notion of lazy deployments would be introduced.

To put it in simple terms - although the admin-console.war, jmx-console.war and jbossws-console.war will be shipped by default in the AS, they will no longer be *deployed* by default. The first access to any of these applications is going to deploy them. The complete set of details can be found in this forum thread. So in AS 6.0.0.M2, you will notice that these applications have now been moved to JBOSS_HOME/common/deploy folder. Note that, the admin-console is still a bit of heavy beast during deployment - you will see a slow response during admin-console deployment (so first access to this application is going to be slow). But this will no longer add to the boot time. There are plans to further improve the boot time of the AS in the next coming M3 release. So this is not the end of boot time performance improvements, but definitely a good start!

So, go download the newly released version and try it out! Let us know of any issues you run into in our AS user forum. And if you have run into any EJB3(.1) issues, or have any questions around it, then feel free to ping us on #jboss-ejb3 (irc.freenode.net) or even vist our EJB3 user forum

EJB3.1 initial support in JBoss AS

2010-01-20T20:26:00.000+05:30

Good news for those waiting for EJB3.1 support in JBoss AS :) The upcoming JBoss AS 6.0.0.M2 will have the initial EJB3.1 support. The AS release is scheduled a few weeks from now. Last weekend we added some of the EJB3.1 support to the JBoss AS trunk. This includes the no-interface view for EJBs and also deployment of EJBs through .war files. So in it's present state, the AS trunk has these EJB3.1 features available.

Those of you who want to try this out and provide feedback/bug reports etc... please follow this thread in the EJB3 user forum. Good luck and let us know, in the forums, how it goes!

JBoss Community Asylum - Cool place to get JBoss Community podcasts

2009-09-25T19:22:00.000+05:30

It's been a while since i last blogged. Mainly because there wasn't anything interesting/useful that was worth sharing here. However, one of the news worth sharing, is the launch of JBoss Community Asylum. It's been started by Max R Andersen (JBoss tooling), Emmanuel Bernard (Hibernate team) and Michael Neale (Drools team) and will be sharing podcasts related to JBoss Community and its projects: news, interviews etc.

The first podcast has already been uploaded. So for those who missed the recent JBoss World event, this first podcast is an summary of what happened there. So don't miss it, you can get it here

And stay tuned to that site for more such podcasts in the near future!

JBossAS now has an admin-console!

2009-04-30T12:32:00.000+05:30

JBoss AS users have always asked why JBoss does not have an admin console. Personally, i have always liked working directly on the configuration files without needing any web application or any other tool for doing the same. That's because i like spending more and more time on the AS. But for users who want to just get things done without having to worry about how it is done or which file gets placed where and want to manage the deployments through a web application, a decent admin console was always a neccessity. Its good news now for all JBoss AS users - starting 5.1.0.CR1 version, JBoss AS now has an excellent admin console!

I decided to give it a try, during this weekend, to see what features it provides. This article is just to give you some idea about what the admin-console has. The best place to look for all other details and feature list of the admin-console, is the Embedded Jopr project page. So here's an account of what i found about the admin-console.

The admin console is available by default in the "default" and "all" server configurations. The application is available as a WAR file "admin-console.war" in the deploy folder of these configurations. You can access the admin-console at the following URL http://localhost:8080/admin-console. By default, the username for the application is "admin" and the password is "admin".

Once you login to the admin-console, you will notice a list of menu items on the left hand side of the screen. The right hand side of the screen is a multi-tabbed details page. So let's click on the "Applications" menu item on the left hand side menu. This shows a list of all applications on the server. Each of these applications is categorized based on the type of the application. Some of the categories are : EJB2.x application, EJB3.x application, WAR, EAR, MC beans. There's also Embedded WARs - these are WAR files which are deployed within an EAR file. Apart from applications, the admin-console also displays resources like JMS factories, JMS destinations (queues/topics), datasources. For each of these applications and resources, the admin-console shows the status (UP/DOWN) of those applications/resources. You can delete existing resources or applications by clicking on the "Delete" button on the details page.

The admin-console allows you to deploy new applications (WAR, EAR etc...) and also add new resources. So let's see how to deploy an EAR file. On the left hand side menu, click on the Enterprise Application (EARs) link under the Applications. Then on the details page, you will notice a "Add a new resource" button. Click on it. Use the Browse button to select the EAR you want to deploy. This page also gives you an option to deploy the EAR either as an archive or in a exploded format. Select appropriate option and click Continue. That's it, if the application is deployed successfully, you will see an appropriate message and also the status of the application will be shown as "UP". For all those who want to deploy applications in the traditional way (copying to deploy folder), you can still do it. The admin-console dynamically updates it list of deployed applications and on the next refresh, you will notice your application being listed.

As i mentioned earlier, the details page is a multi-tabbed page. It has a Metrics tab, Control tab, Configuration tab etc... So let's see what the "Control" tab can be used for. Select the Enterprise Application link (from the left hand menu) and drill down to the application of your choice. Then click on the "Control" tab. You will notice options to "Start", "Stop" and "Restart" the application. The other tabs like "Configuration", "Metrics" show many details about the selected application or resource.

Overall, the admin-console is a great addition to JBoss AS and provides that you expect from a decent admin-console. Users who have long waited for such an admin-console in JBoss will finally get what they asked for! So go to the JBossAS download page and get the latest 5.1.0.CR1 version and start playing with the console.

As always, if you have any suggestions or issues to report, feel free to do so in the Embedded Jopr forum.

JBoss EJB3 tutorials and docs

2009-04-07T13:39:00.000+05:30

I thought i will blog this, since i have been seeing many of the community members looking for some documentation or tutorials for EJB3 on JBoss. Obviously, for anyone who's trying to learn a new technology, the best place to start will be the tutorials. Many of you might be already aware that the new JBossAS-5.x series have been released to the community. Just recently we uploaded a completely new set of EJB3 tutorials and reference documentation targeted for JBossAS-5. These tutorials and reference documentation is available here. The earlier set of tutorials which are targeted for AS-4.x are available here.

The new set of tutorials have been modified to work against AS5. The changes mainly include changes to deployment descriptors or any JBoss specific EJB3 features. The complete source code for the tutorials is available for download at the same URL.

The important point to note is that these tutorials will be maintained to work against the latest release of EJB3 plugin. So what is EJB3 plugin? JBossAS-5 ships with EJB3 support by default. As you all know, the JBoss EJB3 project and the JBoss AS project are maintained separately and as such have their own release cycles. So what happens if we introduced something new in EJB3 or do a major bug fix for the community in EJB3 project? How do we make it available to the community who use EJB3 support provided by AS5? That's where the EJB3 plugin comes in picture. The EJB3 plugin provides a mechanism where you can patch newer versions of EJB3 into AS5. This way, if there are any major bug fixes or enhancements you are waiting for from the EJB3 community, then you can use the EJB3 plugin to patch it in AS5.

The next question would be, when and where do i get the EJB3 plugin for the AS. EJB3 project has come up with a release cycle where, every 2nd and 4th Friday of the month there will be a EJB3 release. These releases are downloadable at the JBoss EJB3 download page . So how do you use this plugin against the AS? It's pretty simple. All you need is:

- JBossAS-5 installation
- Ant 1.7

Download the plugin which is nothing but a jar file and run the following command


java -jar jboss-ejb3-plugin-x.x.x-installer.jar < path to JBossAS5.x >

Note that jboss-ejb3-plugin-x.x.x-installer.jar is the name of the jar file you downloaded.

So that gives you an idea about what the plugin is. Coming back to the EJB3 tutorials, I mentioned earlier that these tutorials are maintained to work against the latest release of EJB3 plugin. What this means is, you won't find a tutorial in a broken state (tutorials that are no longer running). The tutorials are tested against every release of the EJB3 plugin. So if something in the tutorials breaks, then that's fixed at the right place before they are released to the community.

If anyone has any suggestions or questions about the tutorials or the EJB3 docs, feel free to start a discussion in the JBoss EJB3 forum

JBossAS 5.0.1 GA released

2009-02-24T14:24:00.000+05:30

JBossAS-5.0.1 GA has been released today. The download is available on the JBoss download site. One of the major issues that has been fixed in this release is the one that was reported in the community and was related to "tmp" file handling of deployments by VFS.

Recognition to community contributors - JBoss Community Leadership Awards

2009-01-14T17:34:00.000+05:30

It's a well known fact that community support for an open source project is always necessary for the growth of the project. Support can be in any form - documentation, bug fixes, feature enhancements, active participation in the forums etc... JBoss has taken the initiative to recognize such community users who have contributed in a great way, towards the growth of various projects hosted at JBoss. The JBoss Community Leadership Awards aims at recognizing such community members. There are various categories for the awards - checkout the poll page. You can cast your vote under any of those categories. This is a chance to cast your vote for those who might have helped you, in some way or the other, while using projects hosted at JBoss :)

JBossAS-5.0 goes GA

2008-12-06T19:39:00.000+05:30

JBossAS-5.0 GA community edition has been released a few days back!!! Many of you might be knowing that the JBoss-5.0 development was going on for a few years now. After 4 Betas and 2 CRs the application server is now GA. JBossAS-5.0 GA complies with JavaEE5.

Some of you who keep an watch on the JBoss forums and mailing lists, might already be aware that JBoss-5 was completely rearchitectured. There have been a variety of architectural changes that have been introduced in JBoss-5. So what does this mean to a developer who's been using JBoss-4.x so far? The purpose of this article is to highlight the changes that have come in as part of JBoss-5. I won't be dwelling a lot into the technical details (i will leave it to the experts), but will try to give an overview of changes in this version from JBoss-4.x. This article is aimed at making you aware about things to keep in mind when you start using JBoss-5.

So let's start!

1) Additional server profiles/configurations :

JBoss-4.x AS community users will be used to seeing 3 server profiles being shipped by JBoss in the %JBOSS_HOME%/server folder. The "all", "default" and the "minimal". JBoss-5.0 GA adds couple of more profiles to this. Now in JBoss-5 you have "all", "default", "minimal", "web" and "standard".

* The "web" profile is meant to contain services which will allow simple web applications (servlet, jsps) to be deployed. It also has support for JTA, JCA and JPA. Some of you might ask how is it different from the "minimal" configuration. If you look in the deployers folder of "minimal" profile, you will find that there are no deployers available in the "deployers" folder nor any applications in the "deploy" folder. The "minimal" profile is mainly meant for letting the developers decide what services they want to be available. The "minimal" is just an empty profile which the users can build upon depending on their needs, whereas the "web" is a subset of the "default" and allows deploying web applications.

* The "standard" profile is the one against which the tests for JavaEE support were run against.

2) Separation of "deployers" and "deploy" :

If you look in the "deploy" folder of a JBoss-4.x system, you will notice that it contains two types of deployables. Some of the deployables are meant to deploy other applications. For example: The jbossweb.deployer in the deploy folder is actually used for deploying web applications (WAR). With JBoss-5, there is now a clear separation between the deployer and the deployable. You will notice that in JBoss-5, there is a "deployers" folder under each server profile %JBOSS_HOME%/server/< serverName>/deployers. The jbossweb.deployer, which i used as an example earlier, is now in this "deployers" folder along with various other deployers. The actual applications that are to be deployed reside in the "deploy" folder %JBOSS_HOME%/server/< serverName>/deploy.

3) Libraries are now moved to a common/lib folder:

In JBoss-4.x, you will notice that the lib folder under each server profile contains almost the same set of jar files. This obviously leads to increased disk space usage. In JBoss-5.0 GA, these common jar files which are required by all these server profiles is now moved to %JBOSS_HOME%/common/lib folder. This common/lib will act as a parent to all server/< serverName>/lib folders. If you want to add any jar for a specific server profile, then you can add it to the %JBOSS_HOME%/server/< serverName>/lib folder. For example: The database drivers that are required by the datasources can be placed in the server profile specific lib folder (%JBOSS_HOME%/server/< serverName>/lib). With the addition of this new common/lib folder, two new JBoss system properties have been introduced:


 * jboss.common.base.url - This evaluates to ${jboss.home.url}/common
 * jboss.common.lib.url - This evaluates to ${jboss.common.base.url}/lib

All other JBoss system properties available in JBoss-4.x http://www.jboss.org/community/docs/DOC-10730 continue to remain in JBoss-5.

4) For Windows users, its now one step easier to run JBoss as a service :

For JBoss-4.x Windows users, running the server as a service required downloading an appropriate version of JBoss Native and then using the service.bat in the JBoss Native to install the service. In JBoss-5.0 GA, its now one step less. JBossAS comes with JBoss Native installed by default. This way, the user no longer has to download the JBoss Native package separetely. The service.bat for installing the service can be found in the %JBOSS_HOME%/bin folder.

5) New jmx-console :

The jmx-console now comes with a better "professional looking" look :-)

As i mentioned earlier, in this article, i'am going to leave out all the technical details about the changes that have come in JBoss-5. I'll leave it for my next articles, which i plan to do pretty soon after spending some time on this new GA version :-) But in the meantime, JBossAS enthusiasts can start playing with the GA version by downloading it from here

And yes, if you run into any issues using JBossAS-5, feel free to post in the AS-5 dedicated forum here

How to upgrade Hibernate in JBoss

2008-08-20T13:56:00.000+05:30

JBoss comes shipped with Hibernate by default. Upgrading Hibernate is similar to upgrading any other 3rd party library in your application deployed on JBoss. As long as you understand how the classloading works in JBoss, the upgrading should be pretty straightforward.

For a brief (well not so brief) background about classloaders in JBoss, have a look at these wiki articles:

How classloading works in JBoss

How to configure classloaders in JBoss

Once you read through these wiki articles, you will understand that if your application needs to have its own version of a library (does not matter if it is Hibernate or some other 3rd party library), you will have to configure classloader scoping through the xml file.

So why am i writing this stuff all over again, when these two wiki articles have enough details about classloading scoping? Its mainly because of some tricky issues, which have been reported in the JBoss forums, with upgrading Hibernate (specifically to Hibernate version 3.2.6) on JBoss-4.2.x (specifically JBoss-4.2.2 GA). The rest of the article tries to explain these issues and way to fix them. Though this is written to be more oriented towards upgrading Hibernate, whatever has been explained here will apply to almost every 3rd party library upgrade on JBoss.

So let's start then!

Details about the default installation of JBoss-4.2.2 GA:

JBoss-4.2.2 GA ships with

 

Hibernate EntityManager 3.2.1.GA
Hibernate Annotations 3.2.1.GA
Hibernate 3.2.4.sp1

What we intend to do is, upgrade Hibernate to use 3.2.6 GA. Let's assume, we have an EAR which will be deployed to JBoss:



MyApp.ear
 |
 |--- META-INF
 |      |
 |      |
 |      |--- application.xml
 |      | 
 |      |--- jboss-app.xml
 |
 |
 |--- lib
 |    |
 |    |--- [some jar files required by my app]
 |
 |
 |--- MyApp.war

So first step would be package the upgraded Hibernate jar files in the application (MyApp.ear). Its crucial to understand that you have to be absolutely sure that you have packaged all the required hibernate jars and the correct versions of those jars in your application. This Hibernate compatibility matrix will help you in picking up the correct versions. However, you still have to know "which" hibernate jars you need to package in the application.

Based on what i have seen in the forums, the issues faced while upgrading Hibernate were more related to users missing out certain dependent hibernate jar files. Debugging such issues was not very easy since, the errors that got thrown were not simple ClassNotFoundException (which you usually associate with a missing jar). Various errors like ClassCastException, NoSuchMethodException were thrown mainly because Hibernate in this version (3.2.6 GA) refactored a lot of their code to move them to different "projects". For example, the org.hibernate.search package was earlier in the "Hibernate Annotations" project (hibernate-annotations.jar) but with this new release, it was moved to a separate "Hibernate Search" project (hibernate-search.jar). Same applies to org.hibernate.validator package which earlier was in the "Hibernate Annotations" project (hibernate-annotations.jar) but with this new release, it was moved to a separate "Hibernate Validator" project.

So how does it matter if those hibernate packages were moved to a different project (jar)? Here's a very brief explanation of what happens:

- JBoss, in its lib folder, has an older version of Hibernate (3.2.4) and other hibernate related jar files, including the hibernate-annotations.jar. In this version, the hibernate-annotations.jar contained the org.hibernate.search and org.hibernate.validator and various other packages.

- You decide to upgrade Hibernate in your application by packaging the hibernate jars in your application and enabling classloader configuration. You package *only* the latest version of core hibernate jar, the hibernate-annotations.jar and maybe even the hibernate-entitymanager.jar.
Note: You have NOT packaged the hibernate-validator.jar nor the hibernate-search.jar.

- You start JBoss and the server tries to deploy your application. While deploying, for configuring Hibernate, various Hibernate classes are used, which includes the classes belonging to core hibernate jar and also org.hibernate.validator and org.hibernate.search packages.

- Since you have configured classloader scoping for your application, JBoss loads the hibernate core classes, the hibernate entitymanager classes and the hibernate annotation classes from the upgraded jars packaged in your application.

- But when a class belonging to org.hibernate.validator or org.hibernate.search package is being requested for, JBoss sees that these classes are not present the jars packaged in your application. So it delegates the classloading to the parent classloader which looks for the classes in the jar files present in the JBoss lib folder (%JBOSS_HOME%/server/< serverName>/lib folder). Here it finds that these packages are present in the hibernate-annotations.jar (older version) and loads those classes from there. While doing so, it also loads the related classes from various other hibernate packages (which might already have been loaded by a different classloader - remember the classes loaded from the jars in your application). Ultimately, this results to the same classes being loaded twice by different classloaders. Later on when you access these classes in your application you might run into ClassCastExceptions.

This is just one example of what might go wrong. Infact, you might not get a clear picture based on this brief explanation. So if you are interested in understanding better (and have some time), then go through these forum discussions which have a lot more details (and which actually made me come up with this article):

ClassCastException for org.hibernate.search.event.FullTextIndexEventListener

Again the ClassCastException for org.hibernate.search.event.FullTextIndexEventListener

This time a NoSuchMethodException: org.hibernate.validator.ClassValidator.

So now that we have seen what kind of issues you might run into while upgrading, let's now come back to our original plan of upgrading hibernate :)

1) Enable classloader scoping through jboss-app.xml:



<jboss-app>

<loader-repository>
   org.myapp:loader=SomeClassloader
   <loader-repository-config>
      java2ParentDelegation=false
   </loader-repository-config>
 </loader-repository> 

  
</jboss-app>

Note: The string org.myapp:loader=SomeClassloader is any unique ObjectName

2) Include the following jar files in the application package:



Hibernate Core jar (3.2.6 GA)
Hibernate Annotations jar (3.2.x or 3.3.x)
Hibernate EntityManager jar (3.2.x or 3.3.x)
Hibernate Validator jar (3.0.x)
Hibernate Search jar (3.0.x)
and maybe even Lucene Core jar (lucene-core-2.2.0.jar)

Note: Please follow this page for downloading and figuring out the correct version of hibernate jars required (compatibility matrix).

So this is how your application packaging will look like finally:



MyApp.ear
 |
 |--- META-INF
 |     |
 |     |
 |     |--- application.xml
 |     | 
 |     |--- jboss-app.xml
 |
 |
 |--- lib
 |     |
 |     |--- [some jar files required by my app]
 |     |
 |     |--- hibernate3.jar (the hibernate core jar)
 |     | 
 |     |--- hibernate-annotations.jar 
 |     |
 |     |--- hibernate-entitymanager.jar 
 |     |  
 |     |--- hibernate-validator.jar 
 |     |
 |     |--- hibernate-search.jar 
 |     |
 |     |--- lucene-core-2.2.0.jar
 | 
 |
 |--- MyApp.war

That's it! The upgrade itself is simple enough. Note that, in this article, i have used an EAR as an example, but this applies to WAR files too. In WAR files, the jars will be placed in the WEB-INF/lib folder and the classloader configuration will be done through the jboss-web.xml file which will be in WEB-INF folder.

SyntaxHighlighter - Great and simple to use javascript utility

2008-07-12T10:53:00.000+05:30

This had been on my todo list for a long time now. I finally got the SyntaxHighlighter integrated in this blog.

Most of my posts in this blog include java code or xml content. And i always used to spend most of my time formatting the way the java code was rendered in the blog. I wont have to worry about that anymore. I am very much impressed by this excellent yet simple piece of utility! I have edited some of my earlier posts in the blog to make use of the SyntaxHighlighter. Editing wasn't a big deal. It was as simple as adding a "name" and "class" attribute to the "pre" tags.

How do i use my own log4j properties or xml file in JBoss

2008-04-19T16:20:00.000+05:30

This article is mainly for those who had a hard time configuring "their own" log4j.properties or log4j.xml within their application on JBoss. For a brief background on this, please read through this JBoss wiki. As explained in that wiki, JBoss uses its own version of log4j.xml and log4j jar, making it difficult to use your own version of the log4j properties/xml files. The wiki also lists down the steps required to configure your application to use its own log4j config file. However, i have seen people complain in the forums that those steps either dont work for them or the steps are too involved and not worth a try.

People at JBoss had taken note of these issues (see the related JIRA) and starting JBoss-4.2.x, the steps involved to configure your own log4j config file in JBoss are pretty simple and straight-forward. In this example, i will try to explain these steps for a EAR file as well as a WAR file. The version that i am using here is JBoss-4.2.2GA (which is the latest stable version at this point). In the examples here, i use a log4j.properties file. The steps are the same even for a log4j.xml.

So here's what is required to get it working in a EAR file:

1) Create a log4j.properties and package it with your application and make it available in the classpath (i placed the log4j.properties file at the root of the EAR file).

2) Also package the appropriate version of log4j jar with your application (this step and the next step are important because you will have to ensure that log4j initializes separately for your application and picks up the log4j.properties file). Place this log4j jar file in the application package so that it is made available in the classpath (i placed it in a folder named lib of the EAR file - remember that any jars in the lib folder of the EAR are by default added to the classpath and made available to the entire application, starting JBoss-4.2.x version).

3) Enable classloader isolation for your application. This is necessary as explained in step#2. You will have to create a jboss-app.xml file and place it in the META-INF folder of the EAR. The jboss-app.xml looks like:


<jboss-app>
 <loader-repository>
   org.myapp:loader=MyClassLoader
   <loader-repository-config>
      java2ParentDelegation=false
   </loader-repository-config>
 </loader-repository>
   
</jboss-app>

This is how the EAR file would look like:



myApp.ear
  |
  |--- log4j.properties
  |
  |--- META-INF
  |     |
  |     |--- application.xml
  |     |
  |     |--- jboss-app.xml
  |
  |--- lib
  |     |
  |     |--- log4jxxx.jar

That's it! Your application now will use it own version of log4j config file as well log4j jar.

Steps involved for a WAR file are similar (If the WAR file is part of an EAR file, then you don't have to follow the steps below. The steps mentioned above for an EAR file are sufficient for a WAR inside an EAR):

1) Create a log4j.properties and package it with your application and make it available in the classpath (i placed the log4j.properties file in the WEB-INF/classes folder of the WAR).

2) Also package the appropriate version of log4j jar with your application (this step and the next step are important because you will have to ensure that log4j initializes separately for your application and picks up the log4j.properties file). Place this log4j jar file in the application package so that it is made available in the classpath (i placed it in a WEB-INF/lib of the WAR file).

3) Enable classloader isolation for your application. This is necessary as explained in step#2. You will have to create a jboss-web.xml file and place it in the WEB-INF folder of the WAR. The jboss-web.xml looks like:



<jboss-web>
    <class-loading java2ClassLoadingCompliance="false">
 <loader-repository>
 org.myapp:loader=MyClassLoader
 <loader-repository-config>java2ParentDelegation=false</loader-repository-config>
 </loader-repository>
 </class-loading>
</jboss-web>

This is how the WAR file would look like:


myApp.war
  |
  |--- WEB-INF
  |     |
  |     |--- web.xml
  |     |
  |     |--- jboss-web.xml
  |     |
  |     |--- classes
  |     |     |
  |     |     |--- log4j.properties
  | 
  |
  |--- lib
  |     |
  |     |--- log4jxxx.jar

Why do i get NameNotFoundException while doing a JNDI lookup?

2007-10-06T13:37:00.001+05:30

Many a times when you are doing a lookup in the JNDI tree, you see javax.naming.NameNotFoundException. A simple code that does the lookup will look something like:


Context ctx = new InitialContext();
Object obj = ctx.lookup("somepath/somename");

This code just looks up the JNDI tree to get an object bound by the name "somepath/somename". Looks simple. However, chances are that you might even see this exception:


javax.naming.NameNotFoundException: somepath not bound
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:529)
 at org.jnp.server.NamingServer.getBinding(NamingServer.java:537)
 at org.jnp.server.NamingServer.getObject(NamingServer.java:543)
 at org.jnp.server.NamingServer.lookup(NamingServer.java:267)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)
 at sun.rmi.server.UnicastServerRef.dispatch(UnicastServerRef.java:294)
 at sun.rmi.transport.Transport$1.run(Transport.java:153)
 at java.security.AccessController.doPrivileged(Native Method)
 at sun.rmi.transport.Transport.serviceCall(Transport.java:149)
 at sun.rmi.transport.tcp.TCPTransport.handleMessages(TCPTransport.java:460)
 at sun.rmi.transport.tcp.TCPTransport$ConnectionHandler.run(TCPTransport.java:701)
 at java.lang.Thread.run(Thread.java:595)
 at sun.rmi.transport.StreamRemoteCall.exceptionReceivedFromServer(StreamRemoteCall.java:247)
 at sun.rmi.transport.StreamRemoteCall.executeCall(StreamRemoteCall.java:223)
 at sun.rmi.server.UnicastRef.invoke(UnicastRef.java:126)
 at org.jnp.server.NamingServer_Stub.lookup(Unknown Source)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:625)
 at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:587)
 at javax.naming.InitialContext.lookup(InitialContext.java:351)

Look closely at the stacktrace. It shows that while looking up the JNDI tree it could not find the jndi name "somepath" (this name may vary). The reason is simple, the JNDI tree does not have any object bound by this name.

To quote the javadocs of this exception "This exception is thrown when a component of the name cannot be resolved because it is not bound."

So how do i know, what's the name to which my object is bound? Each application server, usually provides a JNDI view which can be used to see the contents of the JNDI tree. If you know what object you are looking for (ex: the name of the bean), then you can traverse this JNDI tree to see what name it is bound to. The JNDI view is specific to every application server.

To give an example, JBoss provides its JDNI tree view, through the JMX console. Here are the steps, one has to follow to check the JNDI tree contents on JBoss:

- Go to http://< server>:< port>/jmx-console (Ex: http://localhost:8080/jmx-console)
- Search for service=JNDIView on the jmx-console page
- Click on that link
- On the page that comes up click on the Invoke button beside the list() method
- The page that comes up will show the contents of the JNDI tree.

Here's an sample of how the output looks like(just a small part of the entire output):


java: Namespace

  +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  +- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)
  +- SecurityProxyFactory (class: org.jboss.security.SubjectSecurityProxyFactory)
  +- DefaultJMSProvider (class: org.jboss.jms.jndi.JNDIProviderAdapter)
  +- comp (class: javax.naming.Context)
  +- JmsXA (class: org.jboss.resource.adapter.jms.JmsConnectionFactoryImpl)
  +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
  +- jaas (class: javax.naming.Context)
  |   +- dukesbank (class: org.jboss.security.plugins.SecurityDomainContext)
  |   +- HsqlDbRealm (class: org.jboss.security.plugins.SecurityDomainContext)
  |   +- jbossmq (class: org.jboss.security.plugins.SecurityDomainContext)
  |   +- JmsXARealm (class: org.jboss.security.plugins.SecurityDomainContext)
 

Global JNDI Namespace

  +- ebankTxController (proxy: $Proxy79 implements interface com.sun.ebank.ejb.tx.TxControllerHome,interface javax.ejb.Handle)
  +- ebankAccountController (proxy: $Proxy75 implements interface com.sun.ebank.ejb.account.AccountControllerHome,interface javax.ejb.Handle)
  +- TopicConnectionFactory (class: org.jboss.naming.LinkRefPair)
  +- jmx (class: org.jnp.interfaces.NamingContext)
  |   +- invoker (class: org.jnp.interfaces.NamingContext)
  |   |   +- RMIAdaptor (proxy: $Proxy48 implements interface org.jboss.jmx.adaptor.rmi.RMIAdaptor,interface org.jboss.jmx.adaptor.rmi.RMIAdaptorExt)
  |   +- rmi (class: org.jnp.interfaces.NamingContext)
  |   |   +- RMIAdaptor[link -> jmx/invoker/RMIAdaptor] (class: javax.naming.LinkRef)
  +- HTTPXAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  +- ConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
  +- ebankCustomer (proxy: $Proxy67 implements interface com.sun.ebank.ejb.customer.LocalCustomerHome)
  +- UserTransactionSessionFactory (proxy: $Proxy14 implements interface org.jboss.tm.usertx.interfaces.UserTransactionSessionFactory)
  +- ebankCustomerController (proxy: $Proxy77 implements interface com.sun.ebank.ejb.customer.CustomerControllerHome,interface javax.ejb.Handle)
  +- HTTPConnectionFactory (class: org.jboss.mq.SpyConnectionFactory)
  +- XAConnectionFactory (class: org.jboss.mq.SpyXAConnectionFactory)
  +- TransactionSynchronizationRegistry (class: com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionSynchronizationRegistryImple)
  +- ebankAccount (proxy: $Proxy68 implements interface com.sun.ebank.ejb.account.LocalAccountHome)
  +- UserTransaction (class: org.jboss.tm.usertx.client.ClientUserTransaction)
  +- UILXAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
  +- UIL2XAConnectionFactory[link -> XAConnectionFactory] (class: javax.naming.LinkRef)
  +- queue (class: org.jnp.interfaces.NamingContext)
  |   +- A (class: org.jboss.mq.SpyQueue)
  |   +- testQueue (class: org.jboss.mq.SpyQueue)
  |   +- ex (class: org.jboss.mq.SpyQueue)
  |   +- DLQ (class: org.jboss.mq.SpyQueue)
  |   +- D (class: org.jboss.mq.SpyQueue)
  |   +- C (class: org.jboss.mq.SpyQueue)
  |   +- B (class: org.jboss.mq.SpyQueue)

Let's see what this tells us. Let's consider the Global JNDI Namespace first. It contains (among other things) the following:


+- ebankTxController (proxy: $Proxy79 implements interface com.sun.ebank.ejb.tx.TxControllerHome,interface javax.ejb.Handle)

This tells me that an object which implements com.sun.ebank.ejb.tx.TxControllerHome and javax.ejb.Handle interfaces is bound to the JNDI tree by the jndi-name "ebankTxController". So if at all i have to lookup this object, my lookup code would be something like:


Context ctx = new InitialContext();
ctx.lookup("ebankTxController");

Similarly in the same Global JDNI Namespace, we see :


+- queue (class: org.jnp.interfaces.NamingContext)
  |   +- A (class: org.jboss.mq.SpyQueue)

Make note of the nesting of the names here. This tells me that an object of type org.jboss.mq.SpyQueue is bound by the name "A under the path queue". So your lookup for this object should look like:


Context ctx = new InitialContext();
ctx.lookup("queue/A");

Now let's move on to the java: namespace in the JNDI tree view above. The difference between a Global JNDI namespace and the java: namespace is that, the object bound in the java: namespace can be looked-up ONLY by clients within the SAME JVM. Whereas, in case of Global JNDI namespace, the objects bound in this namespace can be looked-up by clients, even if they are not in the same JVM as the server. One would ask, how does this matter? Consider a standalone java program(client) which tries to lookup some object on the server (running in its own JVM). Whenever a standalone client is started (using the java command), a new JVM is instantiated. As a result, the server (which is started in its own JVM) and the client are running on different JVMs. Effectively, the client will NOT be able to lookup objects bound in the java: namespace of the server. However, the client can lookup the objects present in the Global JNDI namespace of the server.

So, why are we discussing these details, in a topic which was meant to explain the NameNotFoundException? Let's consider the java: namespace output above. There's a


+- DefaultDS (class: org.jboss.resource.adapter.jdbc.WrapperDataSource)

This tells me that there's an object bound to the name DefaultDS in the java: namespace. So my lookup code would be:


Context ctx = new InitialContext();
ctx.lookup("java:/DefaultDS");

As explained above, this code is going to return you the object, if this piece of code runs in the same JVM as the server. However, if this piece of code is run from a client in different JVM (maybe a standalone client), then it's going to run into NameNotFoundException. The reason i explained the java: and the Global JNDI namespace is that, sometimes people are surprised that even though the JNDI view shows that the object is bound in the java: namespace(with the same name as the one they pass to the lookup method), they still run into NameNotFoundException. The probable reason might be, the client is in a different JVM.

Webservice client using dynamic proxy

2007-04-18T16:29:00.000+05:30

In one of my previous posts, i explained how to create a WebService and access it from a simple client. If you look at the client code which accesses the webservice, you will find that the client is using the stubs that were created at deploy time. Such clients which use "static stubs" for accessing webservices are known as "Static Stub Clients". In such approach, the clients will have to have the stubs in their classpath.

Another approach of accessing the webservices is through Dynamic Proxies where the proxies are generated at runtime. I will be showing a simple client which uses dynamic proxies to access an webservice. I wont be explaining the steps to deploy the webservice (which i have already done in my other post). This example assumes that the webservice is already deployed on the server.

The client code will be accessing the HelloWorld service and invoking the sayHelloTo method on that service (Refer my other post to see how the service has been deployed onto the server)

Here's the code for the client:


package org.myapp.service.client;

import java.net.MalformedURLException;
import java.net.URL;

import javax.xml.namespace.QName;
import javax.xml.rpc.Service;
import javax.xml.rpc.ServiceException;
import javax.xml.rpc.ServiceFactory;

import org.myapp.service.HelloWorldService;

/**
 * Simple webservice client which uses dynamic proxy
 *
 * @author Jaikiran Pai
 */
public class DynamicProxyClient {

    public static void main(String args[]) {

        try {
            
            // ServiceFactory instance
            ServiceFactory serviceFactory = ServiceFactory.newInstance();
            System.out.println("Got the service factory");
            String wsdlURLString = "http://localhost:8080/axis/services/HelloWorld?wsdl";
            URL wsdlURL = new URL(wsdlURLString);
            String serviceName = "HelloWorldServiceService";
            String nameSpaceURI = "http://jaikiran.com";
            String portName = "HelloWorld";
            // get hold of the service by passing the URL of the wsdl and the
            // service name
            Service service = serviceFactory.createService(wsdlURL, new QName(
                    nameSpaceURI, serviceName));
            System.out.println("Got the service: " + service);
            // create the service proxy
            HelloWorldService serviceProxy = (HelloWorldService) service
                    .getPort(new QName(nameSpaceURI, portName),
                            HelloWorldService.class);
            System.out.println("Got the service proxy: " + serviceProxy);
            System.out.println("Invoking method on service proxy........");
            System.out.println(serviceProxy.sayHelloTo("Dynamic user"));

        } catch (ServiceException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        } catch (MalformedURLException e) {
            // TODO Auto-generated catch block
            e.printStackTrace();
        }
    }

}

1) Our first step would be to create a ServiceFactory instance, using which we can get access to a deployed service.


ServiceFactory serviceFactory = ServiceFactory.newInstance();

2) Once the ServiceFactory has been created, we will be getting hold of the service which is deployed on the server. To do this, we require
a) The url of the wsdl of the deployed service. In this example it will be http://localhost:8080/axis/services/HelloWorld?wsdl

b) The namespace uri. In this example it will be http://jaikiran.com (You can get this uri from the wsdl file)

c) The name of the service which you want to access. In this example it will be HelloWorldServiceService


String wsdlURLString = "http://localhost:8080/axis/services/HelloWorld?wsdl";
URL wsdlURL = new URL(wsdlURLString);
String serviceName = "HelloWorldServiceService";
String nameSpaceURI = "http://jaikiran.com";

// get hold of the service by passing the URL of the wsdl and the
// service name
Service service = serviceFactory.createService(wsdlURL, new QName(
                    nameSpaceURI, serviceName));

3) At this point you have got access to the service. But in order to invoke an method on the service, you will have to create a proxy (dynamic proxy) from this service. The Service class, has an API getPort, which creates the proxy. In order to create the proxy, we will have to pass the portName of the service (again, this can be obtained in the wsdl file), the namespace uri and the class type of the service. In this example the service interface is org.myapp.service.HelloWorldService, so we will be passing this as the class as follows:


String portName = "HelloWorld";
// create the service proxy
HelloWorldService serviceProxy = (HelloWorldService) service
                    .getPort(new QName(nameSpaceURI, portName),
                     org.myapp.service.HelloWorldService.class);

4) At this point we have got the service proxy which is of type org.myapp.service.HelloWorldService. We can now invoke our sayHelloTo method on this proxy:


System.out.println(serviceProxy.sayHelloTo("Dynamic user"));

Simple, isnt it? You have successfully invoked the webservice through a standalone client using dynamic proxy.

How to read a properties file in a web application

2007-01-04T19:31:00.000+05:30

The code to do this is pretty simple. But going by the number of people who keep asking this question, i thought i would post the code over here. Let's consider that you have a war file named SampleApp.war which has a properties file named myApp.properties at it's root :



SampleApp.war
   |
   |-------- myApp.properties
   |
   |-------- WEB-INF
                |
                |---- classes
                         |
                         |----- org
                                 |------ myApp
                                           |------- MyPropertiesReader.class

Let's assume that you want to read the property named "abc" present in the properties file:

----------------
myApp.properties:
----------------


abc=some value
xyz=some other value

Let's consider that the class org.myApp.MyPropertiesReader present in your application wants to read the property. Here's the code for the same:



package org.myapp;

import java.io.IOException;
import java.io.InputStream;
import java.util.Properties;

/**
 * Simple class meant to read a properties file
 * 
 * @author Jaikiran Pai
 * 
 */
public class MyPropertiesReader {

    /**
     * Default Constructor
     * 
     */
    public MyPropertiesReader() {

    }

    /**
     * Some Method
     * 
     * @throws IOException
     * 
     */
    public void doSomeOperation() throws IOException {
        // Get the inputStream
        InputStream inputStream = this.getClass().getClassLoader()
                .getResourceAsStream("myApp.properties");

        Properties properties = new Properties();

        System.out.println("InputStream is: " + inputStream);

        // load the inputStream using the Properties
        properties.load(inputStream);
        // get the value of the property
        String propValue = properties.getProperty("abc");

        System.out.println("Property value is: " + propValue);
    }

}

Pretty straight-forward. Now suppose the properties file is not at the root of the application, but inside a folder (let's name it config) in the web application, something like:



SampleApp.war
   |
   |-------- config
   |           |------- myApp.properties   
   |           
   |
   |-------- WEB-INF
                |
                |---- classes
                         |
                         |----- org
                                 |------ myApp
                                           |------- MyPropertiesReader.class

There will just be one line change in the above code:



  public void doSomeOperation() throws IOException {
        //Get the inputStream-->This time we have specified the folder name too.
        InputStream inputStream = this.getClass().getClassLoader()
                .getResourceAsStream("config/myApp.properties");
        
        Properties properties = new Properties();
         
        System.out.println("InputStream is: " + inputStream);
        
        //load the inputStream using the Properties
        properties.load(inputStream);
        //get the value of the property
        String propValue = properties.getProperty("abc");
        
        System.out.println("Property value is: " + propValue);
    }

That's all that is required to get it working.

Simple Webservice on JBoss using Axis

2006-12-10T15:37:00.000+05:30

Download the latest stable version of Axis from Axis Releases

1) Deploying Axis web application on JBoss:

I used Axis 1.4 on JBoss-4.0.4 GCA. Assuming you downloaded Axis to D: , copy the "axis" folder present in D:\Axis-1.4\webapps folder to %JBOSS_HOME%\server\default\deploy folder. The "axis" folder that you copied is nothing but an web application (containing of some servlets and jsps provided by Axis). In JBoss for a web application to be deployed, it has to be named *.war, so rename the "axis" folder in %JBOSS_HOME%\server\default\deploy to axis.war. At this point, the axis web application is ready to be deployed on JBoss. But before starting JBoss, delete the commons-logging-x.x.x.jar and log4j-x.x.x.jar present in %JBOSS_HOME%\server\default\deploy\axis.war\WEB-INF\lib directory, since JBoss maintains its own versions of these jars and packaging these jars in your application will throw exceptions of JBoss startup. After you have deleted these jars, start the JBoss server using the run.bat present in %JBOSS_HOME%\bin folder.

2) Verify Axis web application is deployed and running:

After JBoss has started successfully, go to the following URL to check whether axis is deployed properly:

http://localhost:8080/axis

If Axis was deployed successfully, you will see a welcome page which will have a few links, one of them named "List" which can be used to view the already deployed webservices. Axis by default comes with a few sample webservices which you can see on clicking the "List" link.

3) Writing our own webservice:

3a - The Java classes/interfaces:

Lets create a simple webservice which will echo a message to the user who passes his name. We will have an interface named HelloWorldService:


package org.myapp.service;

public interface HelloWorldService {
    
    public String sayHelloTo(String userName);

}

And here's the implementing class:


package org.myapp.service;

public class HelloWorldServiceImpl implements HelloWorldService {

    public String sayHelloTo(String userName) {
 
 //message
        String hello = "Hello " + userName + ". You are being watched";

        System.out.println(hello);
        
 //return the message
        return hello;
    }

}

Do you see anything special in this class or the interface? No, you wont. So how do you convert these into webservices? Read on...

3b - Create a wsdl file:

Now that we have the interface and the class ready, lets create a wsdl file out of these java classes. Axis comes with utilities which allow you to create the wsdl file from a java file. I wrote a small ant target which will do this for me:


<!--  Sets classpath for build  -->
<path id="classpath">
 <pathelement path="${java.class.path}" />
 <fileset dir="${lib}">
  <include name="**/*.jar" />
 </fileset>
 <pathelement path="${classes.dir}" />
</path>

<taskdef name="axis-java2wsdl" classname="org.apache.axis.tools.ant.wsdl.Java2WsdlAntTask" >
         <classpath refid="classpath"/>
</taskdef>

<target name="generateWSDL" description="Generates wsdl files from the java service interfaces">
 <mkdir dir="${wsdl.dir}"/>
 <axis-java2wsdl classpathref="classpath"
   output="${wsdl.dir}/HelloWorld.wsdl"
   location="http://localhost:8080/axis/services/HelloWorld"
   namespace="http://jaikiran.com"
   classname="org.myapp.service.HelloWorldService">

  <mapping namespace="http://jaikiran.com" package="org.myapp.service"/>
 
 </axis-java2wsdl>
</target>

Note: You can find the entire build.xml, that i used, at the end of this article.

You will require the org.apache.axis.tools.ant.wsdl.Java2WsdlAntTask class which is provided by axis to be in the classpath of Ant. This class comes bundled in the axis-ant.jar which i have included in the classpath of this task using the classpathref.

In this target you specify parameters like:
location - this is where the webservice will be deployed.
namespace - the namespace for your webservice
classname - the fully qualified name of the interface which you wrote in step 3a, above.
and also a mapping between the webservice namespace and your application packages.

This target will generate the wsdl file named HelloWorld.wsdl in the directory which you specified in the 'output' parameter of the target.

3c - Create the deploy.wsdd, undeploy.wsdd and the stubs:

Now that you have created a wsdl for your webservice, lets go ahead and create the deploy.wsdd (used for deploying a webservice on the server), undeploy.wsdd (used for undeploying a webservice from the server) and the required stubs for invoking the webservice from a java client.
Again, Axis provides utilities for creating these files. Axis accepts the wsdl file, which we created in step 3b as an input to create these files. Here's the Ant target which does this for us:


<taskdef name="axis-wsdl2java" classname="org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask" >
 <classpath refid="classpath"/>
</taskdef>
 
<target name="generateWSDD" description="Generates wsdd files from the wsdl files">
 <mkdir dir="${wsdd.dir}"/>
 <axis-wsdl2java
       output="${wsdd.dir}"
       deployscope="Application"
       serverside="true"
       url="${wsdl.dir}\HelloWorld.wsdl">
 </axis-wsdl2java>
</target>

This single target creates the deploy.wsdd, undeploy.wsdd and the stubs. As already mentioned, this target takes the wsdl file as an input which we have specified in the 'url' parameter of the axis-wsdl2java target. The files will be created in the directory mentioned in the 'output' parameter of this target. The deploy.wsdd file that gets generated will contain something like:


<!-- Use this file to deploy some handlers/chains and services      -->
<!-- Two ways to do this:                                           -->
<!--   java org.apache.axis.client.AdminClient deploy.wsdd          -->
<!--      after the axis server is running                          -->
<!-- or                                                             -->
<!--   java org.apache.axis.utils.Admin client|server deploy.wsdd   -->
<!--      from the same directory that the Axis engine runs         -->

<deployment
    xmlns="http://xml.apache.org/axis/wsdd/"
    xmlns:java="http://xml.apache.org/axis/wsdd/providers/java">

  <!-- Services from HelloWorldServiceService WSDL service -->

  <service name="HelloWorld" provider="java:RPC" style="rpc" use="encoded">
      <parameter name="wsdlTargetNamespace" value="http://jaikiran.com"/>
      <parameter name="wsdlServiceElement" value="HelloWorldServiceService"/>
      <parameter name="wsdlServicePort" value="HelloWorld"/>
      <parameter name="className" value="com.jaikiran.HelloWorldSoapBindingImpl"/>
      <parameter name="wsdlPortType" value="HelloWorldService"/>
      <parameter name="typeMappingVersion" value="1.2"/>
      <operation name="sayHelloTo" qname="operNS:sayHelloTo" xmlns:operNS="http://jaikiran.com" returnQName="sayHelloToReturn" returnType="rtns:string" xmlns:rtns="http://www.w3.org/2001/XMLSchema" soapAction="" >
        <parameter qname="in0" type="tns:string" xmlns:tns="http://www.w3.org/2001/XMLSchema"/>
      </operation>
      <parameter name="allowedMethods" value="sayHelloTo"/>
      <parameter name="scope" value="Application"/>

  </service>
</deployment>

You might notice that during all these steps we never mentioned our implementing class (HelloWorldServiceImpl) in any of the targets. As you can see above in the deploy.wsdd, Axis has created its own implementing class for the HelloWorldService and provided default implementations in that class. In the deploy.wsdd file, it mentioned the implementation class as follows:

<parameter name="className" value="com.jaikiran.HelloWorldSoapBindingImpl"/>

The reason why Axis created this implementing class is that it never knew that we had created our own implementation. The input that we provided to Axis for generating the wsdd files was a wsdl file through which Axis could never have known that we already have a implementation class.

Our next step would be to modify the deploy.wsdd file to mention our implementation class, in place of Axis'. So let's change the 'className' parameter to:

<parameter name="className" value="org.myapp.service.HelloWorldServiceImpl"/>

3d - Deploy the webservice onto the server:

Now we are almost ready to deploy the webservice onto the server. But before doing that, we will have to make the HelloWorldService.class and HelloWorldServiceImpl.class available in the server's classpath so that when we use this webservice, the server wont throw ClassNotFoundException. So let's compile these 2 classes and place the class files in the %JBOSS_HOME%\server\default\deploy\axis.war\WEB-INF\classes folder. Here's the Ant target that i used to compile these classes:


<target name="compile" description="Compiles java source code">
 <mkdir dir="${classes.dir}"/>
 <javac destdir="${classes.dir}" classpathref="classpath" fork="true" srcdir="${compile.src}" excludes="org/myapp/service/client/**/*.java"/>
</target>

Once this is done, we are ready to deploy the webservice onto the server. Axis again provides a utility to do this. Here's the target for deploying the service onto the server. This target just invokes the org.apache.axis.client.AdminClient java class passing it the deploy.wsdd file as an argument.


<target name="deployWebservice" description="Deploys the webservice onto the server, using the wsdd file and Axis' AdminClient">
 <java classname="org.apache.axis.client.AdminClient" classpathref="classpath" fork="true">
  <arg value="${wsdd.dir}/com/jaikiran/deploy.wsdd"/>
 </java>
</target>

Now that we have deployed the webservice, lets verify whether its deployed successfully. Let's again go to http://localhost:8080/axis . Here again lets click the "List" link to see all the available webservices. This time you will notice that our HelloWorld service is also listed over here. You can view the wsdl of this webservice, by clicking the wsdl link next to it. Our webservice has been deployed at http://localhost:8080/axis/services/HelloWorld as you can see from the wsdl contents. So let's hit this url. You will see a message like:

HelloWorld

Hi there, this is an AXIS service!
Perhaps there will be a form for invoking the service here...

4) Java client for accessing the webservice that we created:

Let's now create a simple java client which accesses the webservice that we just deployed on the server.
You might remember that in step 3c, we even created the stubs required to access the webservice. We will use these stubs in our java client to access the webservice. Here's the simple java client:


package org.myapp.service.client;

import com.jaikiran.HelloWorldService;
import com.jaikiran.HelloWorldServiceServiceLocator;

public class ServiceClient {

    /**
     * @param args
     */
    public static void main(String[] args) {

        try {
        
            //Get hold of the webservice using the locator provided by Axis  
            HelloWorldService helloWorldService = new HelloWorldServiceServiceLocator().getHelloWorld();

     //Invoke the method on the webservice  
            String message = helloWorldService.sayHelloTo("someUserName");
            
            System.out.println("Client received: " + message);
            
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

}

In this class you will notice that we are using HelloWorldServiceServiceLocator and the HelloWorldService which Axis generated for us. Running this client will invoke the webservice deployed on the server.

5) Ant build file

Here's the complete build.xml that i used as part of this example:


<?xml version="1.0" encoding="UTF-8"?>
<project name="MyApp" basedir=".." default="compile">
 
  <property name="conf.dir" location="${basedir}/conf" />
  <property name="build.dir" location="${basedir}/build"/>
  <property name="classes.dir" location="${build.dir}/classes" />
  <property name="compile.src" location="${basedir}/src" />
  <property name="lib" location="${basedir}/lib" />
  <property name="wsdl.dir" location="${build.dir}/wsdl" />
  <property name="wsdd.dir" location="${build.dir}/wsdd" />

  
  <!--  Sets classpath for build  -->
  <path id="classpath">
   <pathelement path="${java.class.path}" />
   <fileset dir="${lib}">
    <include name="**/*.jar" />
   </fileset>
   <pathelement path="${classes.dir}" />
  </path>

 
 
 <taskdef name="axis-java2wsdl" classname="org.apache.axis.tools.ant.wsdl.Java2WsdlAntTask" >
         <classpath refid="classpath"/>
   </taskdef>
 
 <taskdef name="axis-wsdl2java" classname="org.apache.axis.tools.ant.wsdl.Wsdl2javaAntTask" >
          <classpath refid="classpath"/>
 </taskdef>
 
 <target name="clean-all" description="Cleans(Deletes) the contents of all output directories">
  <delete dir="${classes.dir}"/>
  <delete dir="${wsdl.dir}"/>
  <delete dir="${wsdd.dir}"/>
 </target>
 
 <target name="build-all" description="Builds the entire project" depends="clean-all,compile,generateWSDL,generateWSDD,compileStubs,compile-client">
 
 </target>

 <target name="compile" description="Compiles java source code">
  <mkdir dir="${classes.dir}"/>
  <javac destdir="${classes.dir}" classpathref="classpath" fork="true" srcdir="${compile.src}" excludes="org/myapp/service/client/**/*.java"/>
 </target>
 
 <target name="compile-client" description="Compiles the webservice client" depends="compile">
  <mkdir dir="${classes.dir}"/>
  <javac destdir="${classes.dir}" classpathref="classpath" fork="true" srcdir="${compile.src}" includes="org/myapp/service/client/**/*.java"/>
 </target>
 
 <target name="generateWSDL" description="Generates wsdl files from the java service interfaces">
  <mkdir dir="${wsdl.dir}"/>
  <axis-java2wsdl classpathref="classpath"
           output="${wsdl.dir}/HelloWorld.wsdl"
           location="http://localhost:8080/axis/services/HelloWorld"
           namespace="http://jaikiran.com"
           classname="org.myapp.service.HelloWorldService">
     <mapping namespace="http://jaikiran.com" package="org.myapp.service"/>
  </axis-java2wsdl>
 </target>
 
 <target name="generateWSDD" description="Generates wsdd files from the wsdl files">
  <mkdir dir="${wsdd.dir}"/>
  <axis-wsdl2java
        output="${wsdd.dir}"
        deployscope="Application"
        serverside="true"
        url="${wsdl.dir}\HelloWorld.wsdl">
  </axis-wsdl2java>
 </target>
 
 <target name="compileStubs" description="Compiles the java classes(stubs) generated by Axis using the wsdl2java task">
  <mkdir dir="${classes.dir}"/>
  <javac destdir="${classes.dir}" classpathref="classpath" fork="true" srcdir="${wsdd.dir}"/>
 </target>
 
 <target name="deployWebservice" description="Deploys the webservice onto the server, using the wsdd file and Axis' AdminClient">
  <java classname="org.apache.axis.client.AdminClient" classpathref="classpath" fork="true">
   <arg value="${wsdd.dir}/com/jaikiran/deploy.wsdd"/>
  </java>
 </target>
 
 <target name="undeployWebservice" description="Undeploys webservice using the wsdd file and the Axis' AdminClient">
  <java classname="org.apache.axis.client.AdminClient" classpathref="classpath" fork="true">
   <arg value="${wsdd.dir}/com/jaikiran/undeploy.wsdd"/>
  </java>
 </target>
 
 <target name="runWebserviceClient" description="Executes the java client which access the webservice">
   <java classname="org.myapp.service.client.ServiceClient" classpathref="classpath" fork="true"/>
 </target>
  
</project>

6) The project directory structure

This is how my project's directory structure looks like (just in case you want to create a similar one):


Sample Webservice
 |
 |
 |------------- src
 |               | 
 |               |---- org
 |                      |--- myapp
 |                             |---- service
 |                                     |------- HelloWorldService.java
 |                                     |
 |                                     |------- HelloWorldServiceImpl.java
 |                                     |
 |                                     |----- client
 |                                              |-------- ServiceClient.java
 |
 |
 |------------- build
 |                |----- build.xml
 |
 |
 |------------- lib
                 | 
                 |----- activation.jar
                 |----- axis.jar
                 |----- axis-ant.jar
                 |----- commons-discovery-0.2.jar
                 |----- commons-logging-1.0.4.jar
                 |----- jaxrpc.jar
                 |----- mailapi_1_3_1.jar
                 |----- saaj.jar
                 |----- wsdl4j-1.5.1.jar

How to package an application into a ear file

2006-10-31T11:31:00.000+05:30

This is for those who want to know the ideal and most common way an application is packaged in the form of an ear file. Here's how the application structure will look like:


myApp.ear
 |
 |--------- META-INF
 |            |
 |            |---------- application.xml
 |
 |--------- myEJB.jar
 |            |
 |            |--------- META-INF
 |            |            |
 |            |            |-------- ejb-jar.xml  
 |            |
 |            |------ org
 |            |         |----- myApp
 |            |                 |------- ejb
 |                                        |-------- *.class
 |
 |---------- myWeb.war
 |              |
 |              |----- WEB-INF
 |                      |------ web.xml
 |                      |
 |                      |------ jsp
 |                               |---- *.jsp
 |
 |---------- commonUtil.jar
               |
               |--------- org
                           |----- myApp
                                    |------ common
                                             |----- *.class

The application.xml present in the META-INF folder of the ear will contain the following:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE application PUBLIC "-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN" "http://java.sun.com/dtd/application_1_3.dtd">
<application>
 <display-name>helloworld</display-name>
 
 <module>
  <java>commonUtil.jar</java>
 </module>
 
 <module>
  <web>
   <web-uri>myWeb.war</web-uri>
   <context-root>/myWeb</context-root>
  </web>
 </module>
 
 <module>
  <ejb>myEJB.jar</ejb>
 </module>
 
</application>

inverse attribute in Hibernate - What does it mean?

2006-08-24T21:05:00.000+05:30

This is the best explanation, that i have seen till date, about Hibernate's "inverse" attribute:
Meaning of "inverse" in Hibernate

Evict collection from Hibernate second level cache

2006-08-24T18:00:00.000+05:30

Hibernate allows persistent objects to be cached in its second level cache(The first level cache in Hibernate is the Session object which is ON by default). Applications can switch on the second level cache. When a object is being retrieved by the application through Hibernate, Hibernate first checks in its Session cache and then the Second level cache to see if the object has be retrieved already. If it finds it either the Session cache or the Second level cache, it will NOT fire a query to the database.
While configuring second level cache, the object can be cached and also the collections contained in the object can be cached. Have a look at the following example:


<hibernate-mapping default-lazy="false" > 
 <class name="org.myapp.ho.Parent" table="Parent"> 
    <b><cache usage="read-only" /> </b>
    <id name="id" type="Integer" column="ID" /> 
  <set name="myChildren"> 
     <b> <cache usage="read-only"/> </b>
     <one-to-many class="org.myapp.ho.Child"/> 
  </set> 
 </class> 
</hibernate-mapping>


<hibernate-mapping default-lazy="false" > 
   <class name="org.myapp.ho.Child" table="Child">
      <b><cache usage="read-only" /></b>
      <id name="id" type="Integer" column="ID" /> 
   </class> 
</hibernate-mapping>

Note that we have used the cache setting at 3 places:
1) The org.myapp.ho.Parent object
2) The "myChildren" collection in the org.myapp.ho.Parent object
3) The org.myapp.ho.Child object
When you configure a collection to be second level cached in Hibernate, it internally maintains a SEPERATE cache for these collection than the one which it uses to cache the parent objects. So in the example above, the “myChildren” will be cached separately than the org.myapp.ho.Parent object.
There might be cases where applications would want to evict objects from the cache. If its the Session cache from which the application has to evict the object then the call to Session.evict will cascade even to collections and will evict the collection from the *Session cache*. However, if the object(and the collections contained in it) have to be evicted from the second level cache, then the application has to *explicitly* call the evictCollection method on the SessionFactory to remove the *collection* contained in the Parent object. The reason behind this is, as already mentioned, the collections are cached separately, than the parent objects, in the second level cache.
So, in our example above, if we have to evict the Parent with id 500 and its collection from the second level cache, then here’s what has to be done:


SessionFactory sf = MyUtil.getSessionFactory();
//this will evict the Parent Object from the second level cache
sf.evict(org.myapp.ho.Parent.class,new Integer(500)); 
//this will evict the collection from the second level cache for the Parent with id=500
sf.evictCollection(org.myapp.ho.Parent.class.getName() +  ".myChildren", new Integer(500));

The first parameter to the evictCollection method is the ‘roleName’ of the collection. The roleName is formed as follows:

roleName = NameOfTheParentClass + "." + NameOfTheCollectionInsideTheParent

The second parameter the evictCollection method is the id of the parent object, to which this collection belongs.

Custom reverse engineering strategy in Hibernate

2006-08-24T17:29:00.000+05:30

Hibernate has tools to create mapping files(hbm files) and domain model classes from database schemas(reverse engineering). can be used as part of ant task to do this. Hibernate creates the property names using its default reverse engineering strategy. Hibernate also, provides a way through which the user can specify his own custom reverse engineering strategy through which he can follow his own naming conventions etc…

There is a reversestrategy attribute which can be set to some custom class, which implements org.hibernate.cfg.reveng.ReverseEngineeringStrategy, in the . Here’s an example:


<jdbcconfiguration configurationfile="hibernate.cfg.xml"  

    packagename="${package.name}"  

    revengfile="hibernate.reveng.xml"  

    reversestrategy="org.myapp.hibernate.tool.SampleReverseEngineeringStrategy"/>

The org.myapp.hibernate.tool.SampleReverseEngineeringStrategy is our own custom class which implements org.hibernate.cfg.reveng.ReverseEngineeringStrategy. In this example, our SampleReverseEngineeringStrategy, overrides the columnToPropertyName(TableIdentifier table, String column) method to provide a custom implementation for generating property names out of a column name. Here’s the SampleReverseEngineeringStrategy code:


package org.myapp.hibernate.tool;  

import java.util.regex.Matcher;  
import java.util.regex.Pattern;  
import org.hibernate.cfg.reveng.DelegatingReverseEngineeringStrategy;  
import org.hibernate.cfg.reveng.ReverseEngineeringStrategy;  
import org.hibernate.cfg.reveng.TableIdentifier;  
/**  
 *  
 * @author Jaikiran Pai  
 *  
 */  
public class SampleReverseEngineeringStrategy extends DelegatingReverseEngineeringStrategy {  
/**  
  * Constructor  
  *  
  * @param delegate {@link org.hibernate.cfg.reveng.ReverseEngineeringStrategy}  
  */  
 public SampleReverseEngineeringStrategy(ReverseEngineeringStrategy delegate) {  
  super(delegate);  
 }  

/**  
  * Changes the default behaviour of naming the property. 
  
  * Does the following replacements(not neccessarily in the order) and returns the resulting  
  * {@link String} as property name:
  *  - Converts the first letter of the column to uppercase
  *  - Converts the letters following a ‘_’ character to uppercase in the column  
  *  - Removes any underscores present from column  
  *  
  * @see org.hibernate.cfg.reveng.DelegatingReverseEngineeringStrategy  
  * @see org.hibernate.cfg.reveng.ReverseEngineeringStrategy  
  *  
  * @param table {@link TableIdentifier}  
  * @param column  
  * @return Returns the propert name after converting it appropriately  
  */  
public String columnToPropertyName(TableIdentifier table, String column) {  

  String replacedColumn = replaceFirstLetterToUpperCase(column);  
   
   replacedColumn = removeUnderScoresAndConvertNextLetterToUpperCase(replacedColumn);  

   if (anyReplacementsMadeToOriginalColumnName(column,replacedColumn)) {  
  
  return replacedColumn;  

   }  

   /*  
    * Let DelegatingReverseEngineeringStrategy handle this  
    */  
   return super.columnToPropertyName(table, column);  
 }  

 /**  
  *  
  * Returns true if the originalString and replacedString are NOT equal  
  * (meaning there was some replacement done to the original column name). Else returns false.
  *  
  * @param originalString The original column name  
  * @param replacedString The column name after doing necessary replacements  
  * @return Returns true if the originalString and replacedString are NOT equal  
  * (meaning there was some replacement done to the original column name). Else returns false.  
  *   
  * @throws {@link NullPointerException} if originalString is null.  
  */  
 protected boolean anyReplacementsMadeToOriginalColumnName(String originalString, String replacedString) {  
  if (originalString.equals(replacedString)) {  
    return false;  

   }  

   return true;  
 }  

 /**  
  * Converts the first letter of the input to uppercase and  
  * returns the resultant {@link String}.  
  *   
  * Ex: If the input is startDate then the resulting {@link String}  
  * after replacement will be StartDate  
  *  
  * @param input The {@link String} whose contents have to be replaced  
  * @return Returns a {@link String} after doing the appropriate replacements  
  */  
 protected String replaceFirstLetterToUpperCase(String input) {  

   /*  
    * The pattern to match a String starting with lower case  
    */  
   final String startsWithLowerCasePattern = "^[a-z]";  
   
   Pattern patternForReplacingLowerCase = Pattern.compile(startsWithLowerCasePattern);  
   Matcher regexMatcher = patternForReplacingLowerCase.matcher(input);  

 /*  
  * This will hold the replaced contents  
  */  
 StringBuffer replacedContents = new StringBuffer();  

 /*  
  * Check whether the first letter starts with lowercase.  
  * If yes, change it to uppercase, else pass on the control to  
  * DelegatingReverseEngineeringStrategy  
  *  
  */  
 if (regexMatcher.find()) {  

  String firstCharacter = regexMatcher.group();  
  /*  
   * Convert it to uppercase  
   */  
  regexMatcher.appendReplacement(replacedContents,firstCharacter.toUpperCase());  
  regexMatcher.appendTail(replacedContents);  
  regexMatcher.reset();  
  
  /*  
   * Return the replaced contents  
   */  
    return replacedContents.toString();  

   }  

        //no replacements to do, just return the original input  
        return input;  

 }  

 /**  
  * Converts the letters following a ‘_’ character to uppercase and also removes  
  * the ‘_’ character from the input and returns the resulting {@link String}.   
  * Carries out a 2 pass strategy to do the replacements. During the first pass,  
  * replaces all the letters that immidiately follow a ‘_’ to uppercase.  
  * Ex: If the input is _start_Date__today_ then after the first pass of replacement, the  
  * resultant string will be _Start_Date__Today_  
  *   
  * This replaced {@link String} is then passed ahead for second pass (if no replacements were  
  * done during first pass, then the original {@link String} is passed). During the second pass  
  * the underscores are removed.  
  * Ex: If the input is _start_Date__today_ then after BOTH the passes the  
  * resultant string will be StartDateToday  
  *  
  * @param input The {@link String} whose contents have to be replaced  
  * @return Returns a {@link String} after doing the appropriate replacements  
  */  
 protected String removeUnderScoresAndConvertNextLetterToUpperCase(String input) {  

   /*  
    * The pattern which matches a String that starts with a letter immidiately after  
    * a ‘_’ character  
    */  
   final String stringFollowingUnderScore = "[.]*_[a-zA-Z]+";  

   Pattern patternForReplacingLowerCase = Pattern.compile(stringFollowingUnderScore);  
          Matcher regexMatcher = patternForReplacingLowerCase.matcher(input);  
          /*  
           * This will hold the replaced contents  
           */  
          StringBuffer replacedContents = new StringBuffer();  

          boolean foundAnyMatch = false;  

          while (regexMatcher.find()) {  
   foundAnyMatch = true;  
   String matchedString = regexMatcher.group();  
       /*  
          * The character immidiately following the underscore  
   * Example:  
          * If matchedString is _tMn then originalCharAfterUnderScore will be the  
          * character t  
          */  

        char originalCharAfterUnderScore = matchedString.charAt(1);  
         /*  
          * Convert the character to uppercase  
          */  

        String replacedCharAfterUnderScore = String.valueOf(originalCharAfterUnderScore).toUpperCase();  

        /*  
          * Now place this replaced character back into the matchedString  
          */  

        String replacement = matchedString.replace(originalCharAfterUnderScore,replacedCharAfterUnderScore.charAt(0));  

        /*  
   * Append this to the replacedColumn, which will be returned back to the user  
          */  
  regexMatcher.appendReplacement(replacedContents,replacement);  

     } //end of while  

        regexMatcher.appendTail(replacedContents);  
 regexMatcher.reset();  
 
 /*  
         * Now the input string has been replaced to contain uppercase letters after the underscore.  
         * Ex: If input string was "_start_Date_today" then at this point after the above processing,  
        * the replaced string will be "_Start_Date_Today"  
  * The only thing that remains now is to remove the underscores from the input string.  
        * The following statements do this part.  
        *  
        */  

      if (foundAnyMatch) {  
       return removeUnderScores(replacedContents.toString());  
       
   } else {  
     return removeUnderScores(input);  
     
   }  

 }  

 /**  
  * Removes any underscores present from input and returns the  
  * resulting {@link String}  
  * Ex: If the input is _start_Date__today_ then the resulting {@link String}  
  * after replacement will be startDatetoday  
  *
  * @param input The {@link String} whose contents have to be replaced  
  * @return Returns a {@link String} after doing the appropriate replacements  
  */  
 protected String removeUnderScores(String input) {  

   /*  
  * Pattern for matching underscores  
     */  
  Pattern patternForUnderScore = Pattern.compile("[.]*_[.]*");  

    Matcher regexMatcher = patternForUnderScore.matcher(input);  
  /*  
      * This will hold the return value  
   */  
    StringBuffer returnVal = new StringBuffer();  
       boolean foundAnyMatch = false;  
   
     while (regexMatcher.find()) {  
        foundAnyMatch = true;  

     String matchedString = regexMatcher.group();  

     /*  
       * Remove the underscore  
   */  
     regexMatcher.appendReplacement(returnVal,"");  

      }  

      regexMatcher.appendTail(returnVal);  
 regexMatcher.reset();  

      /*  
        * If any match was found(and replaced) then return the replaced string.  
        * Else return the original input.  
  */  
      if (foundAnyMatch) {  
        return returnVal.toString();  

      }  
 return input;  

 }  

}

In the example above, the columnToPropertyName method is overridden to do the following:

- Creates property names that start with a Capital case(By default, Hibernate creates property names in camel-case)
- Converts the letter, that follows a ‘_’ (underscore character) to uppercase in the property name
- Removes any underscores in the property name

Ex: If the column name is start_Date_today, then the resulting property name after using the SampleReverseEngineeringStrategy would be StartDateToday.

Here’s a documentation from Hibernate about Controlling Reverse Engineering

Convert exception stacktrace to String object

2006-08-24T17:17:00.000+05:30

Usually whenever a exception occurs, we use the method printStackTrace() on the exception object to display the stacktrace. However, if the stacktrace has to be stored into a String object then the following piece of code will prove handy:


  /**
     * Creates and returns a {@link java.lang.String} from t’s stacktrace 
     * @param t Throwable whose stack trace is required
     * @return String representing the stack trace of the exception
     */
    public String getStackTrace(Throwable t) {
        StringWriter stringWritter = new StringWriter();
        PrintWriter printWritter = new PrintWriter(stringWritter, true);
        t.printStackTrace(printWritter);
        printWritter.flush();
        stringWritter.flush(); 

       return stringWritter.toString();
    }

Lookup an EJB from a different application, deployed on the same server, in JBoss

2006-08-24T16:42:00.000+05:30

Question:
I have a web application through which i want to access an EJB which is deployed as a separate appliaction on the same server. How do i do it?
Answer:
In the web.xml of your war(the web application through which you want to access the EJB), have the following entry:



<ejb-ref>

<ejb-ref-name>GiveAnNameByWhichYouWouldLikeToReferTheBeanInYourWebApp</ejb-ref-name>
    <ejb-ref-type>session</ejb-ref-type>
    <home>packageName.ClassNameOfTheHomeObjectOfTheBeanYouWantToRefer</home>
    <remote>packageName.ClassNameOfTheRemoteObjectOfTheBeanYouWantToRefer</remote>
  </ejb-ref>

In the jboss-web.xml of your war, have the following entry:



  <ejb-ref>
      <!--The ejb-ref-name should be same as the one given in the web.xml above -->
      <ejb-ref-name>GiveANameByWhichYouWouldLikeToReferTheBeanInYourWebApp</ejb-ref-name>
      <!--Example:somecontext/somejndiName.YouWillFindThisJndiNameInTheJboss.xmlOfTheEJB-->
      <jndi-name>TheJndiNametoWhichTheBeanIsBound</jndi-name>
   </ejb-ref>

For more info, have a look at the dtds of web.xml (http://java.sun.com/dtd/web-app_2_3.dtd) and jboss-web.xml(http://www.jboss.org/j2ee/dtd)
In your code, do the lookup as:

 
Context ic = new InitialContext();
Object home=ic.lookup("java:comp/env/TheNameThatYouHadGivenInEjb-ref-nameTagOfJbossWeb.xml");

Here’s an example:

web.xml:


<ejb-ref>
    <ejb-ref-name>MyTestBean</ejb-ref-name>
    <ejb-ref-type>session</ejb-ref-type>
    <home>com.test.ejb.MyBeanHome</home>
    <remote>com.test.ejb.MyBeanRemote</remote>
  </ejb-ref>

jboss-web.xml:


 <ejb-ref>
   <ejb-ref-name>MyTestBean</ejb-ref-name>
   <jndi-name>myejb/test/MyTestBean</jndi-name>
  </ejb-ref>

Lookup code:


Context ic = new InitialContext();
  Object ejbHome = ic.lookup("java:comp/env/MyTestBean");

How to create a Queue/Topic in JBoss?

2006-08-24T16:29:00.000+05:30

Queues/Topics are known as administered objects and in jboss they can be deployed through ServiceDotXml files. Let’s name our file, myapp-destination-service.xml. The contents of the file should look like:



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

<server>
   <!--My queue, named: myAppQueue -->
  <mbean code="org.jboss.mq.server.jmx.Queue"
  name="jboss.mq.destination:service=Queue,name=myAppQueue">
    <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
  </mbean>
   <!-- My topic, named: myAppTopic -->
  <mbean code="org.jboss.mq.server.jmx.Topic"
  name="jboss.mq.destination:service=Topic,name=myAppTopic">
    <depends optional-attribute-name="DestinationManager">jboss.mq:service=DestinationManager</depends>
  </mbean>
    
  </server>

Place this file in your %JBOSS_HOME%/server/default/deploy directory and start the server.
(Note: If you are using the ‘all’ configuration or the ‘minimal’ configuration then you will have to place this file in the %JBOSS_HOME%/server/all/deploy or %JBOSS_HOME%/server/minimal/deploy directory, as appropriate).

The above queue/topic will be bound to the jndi name: queue/myAppQueue and topic/myAppTopic respectively.

Note:

1) The above file is meant for JBoss-3.2.3. Though there might be slight changes to later versions of JBoss, the basic configuration mechanism remains the same.

2) JBoss also comes with preconfigured queues/topics. These configurations can be found in the jbossmq-destinations-service.xml file which is present in %JBOSS_HOME%/server/default/deploy/jms directory

Update:

For JBoss AS 6.x see this FAQ for more details on how to configure JMS queue/topics

How to enable Garbage Collection (GC) logs

2006-08-24T16:23:00.000+05:30

To enable GC logs, the -Xloggc:logFileName option will have to be passed when java command is being executed. Additionally if the detailed log of the GC is required, then an additional -XX:+PrintGCDetails option will have to be passed.

Example: java -Xloggc:D:/log/myLogFile.log -XX:+PrintGCDetails myProg

Create your own logging level in log4j

2006-07-12T14:52:00.000+05:30

If you need to add your own logging level in log4j, then you can do it as follows. You will have to create your own class which will extend from Level. Here's a sample code for the same:

MyTraceLevel.java:


package org.myapp.log;

import org.apache.log4j.Level;
/**
 * My own {@link org.apache.log4j.Level} for logging. 
 * 
 * @author Jaikiran Pai 
 * 
 */ 
public class MyTraceLevel extends Level { 

 /** 
  * Value of my trace level. This value is lesser than 
  * {@link org.apache.log4j.Priority#DEBUG_INT} 
  * and higher than {@link org.apache.log4j.Level#TRACE_INT} 
  */ 
 public static final int MY_TRACE_INT = DEBUG_INT - 10; 
 
 /** 
  * {@link Level} representing my log level 
  */ 
 public static final Level MY_TRACE = new MyTraceLevel(MY_TRACE_INT,"MY_TRACE",7);

     /**
       * Constructor
        *
       * @param arg0
       * @param arg1
       * @param arg2
        */
     protected MyTraceLevel(int arg0, String arg1, int arg2) {
         super(arg0, arg1, arg2);

     }

     /**
      * Checks whether sArg is "MY_TRACE" level. If yes then returns 
      * {@link MyTraceLevel#MY_TRACE}, else calls 
      * {@link MyTraceLevel#toLevel(String, Level)} passing it 
      * {@link Level#DEBUG} as the defaultLevel.
       *
       * @see Level#toLevel(java.lang.String)
       * @see Level#toLevel(java.lang.String, org.apache.log4j.Level)
       *
       */
     public static Level toLevel(String sArg) {
         if (sArg != null && sArg.toUpperCase().equals("MY_TRACE")) {
             return MY_TRACE;
         }
         return (Level) toLevel(sArg, Level.DEBUG);
     }

     /**
      * Checks whether val is {@link MyTraceLevel#MY_TRACE_INT}. 
  * If yes then returns {@link MyTraceLevel#MY_TRACE}, else calls 
  * {@link MyTraceLevel#toLevel(int, Level)} passing it {@link Level#DEBUG}
  * as the defaultLevel
  *
       * @see Level#toLevel(int)
       * @see Level#toLevel(int, org.apache.log4j.Level)
       *
       */
     public static Level toLevel(int val) {
         if (val == MY_TRACE_INT) {
             return MY_TRACE;
         }
         return (Level) toLevel(val, Level.DEBUG);
     }

     /**
      * Checks whether val is {@link MyTraceLevel#MY_TRACE_INT}. 
      * If yes then returns {@link MyTraceLevel#MY_TRACE},
      * else calls {@link Level#toLevel(int, org.apache.log4j.Level)}
      *
      * @see Level#toLevel(int, org.apache.log4j.Level)
      */
     public static Level toLevel(int val, Level defaultLevel) {
         if (val == MY_TRACE_INT) {
             return MY_TRACE;
         }
         return Level.toLevel(val,defaultLevel);
     }

     /**
      * Checks whether sArg is "MY_TRACE" level. 
  * If yes then returns {@link MyTraceLevel#MY_TRACE}, else calls
  * {@link Level#toLevel(java.lang.String, org.apache.log4j.Level)}
  *
  * @see Level#toLevel(java.lang.String, org.apache.log4j.Level)
  */
 public static Level toLevel(String sArg, Level defaultLevel) {     
        if(sArg != null && sArg.toUpperCase().equals("MY_TRACE")) {
            return MY_TRACE;
        }
        return Level.toLevel(sArg,defaultLevel);
 }
}

Now, you will have to configure your log4j.xml:


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE log4j:configuration SYSTEM "log4j.dtd"> 
<log4j:configuration xmlns:log4j="http://jakarta.apache.org/log4j/"debug="false"> 
<!-- ================================= --> 
<!-- Preserve messages in a local file --> 
<!-- ================================= --> 
<!-- A size based rolling appender --> 
<appender name="FILE" class="org.apache.log4j.FileAppender"> 
<param name="File" value="D:/log/myLogFile.log"/> 
<param name="Append" value="false"/> 
<layout class="org.apache.log4j.PatternLayout"> 
<param name="ConversionPattern" value="%d{ISO8601} %-5p [%c] %m%n"/> 
</layout> 
</appender> 
<!-- ============================== --> 
<!-- Append messages to the console --> 
<!-- ============================== --> 
<appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender"> 
<param name="Target" value="System.out"/> 
<param name="Threshold" value="INFO"/> 
<layout class="org.apache.log4j.PatternLayout"> 
<!-- The default pattern: Date Priority [Category] Message\n --> 
<param name="ConversionPattern" value="%d{ISO8601} %-5p [%c{1}] %m%n"/> 
</layout> 
</appender> 
<!-- ================ --> 
<!-- Limit categories --> 
<!-- ================ --> 
<category name="org.myapp"> 
<priority value="MY_TRACE" class="org.myapp.log.MyTraceLevel" /> 
<appender-ref ref="FILE"/> 
</category> 
<!-- ======================= --> 
<!-- Setup the Root category --> 
<!-- ======================= --> 
<root> 
<appender-ref ref="CONSOLE"/> 
</root> 
</log4j:configuration>

Here's a test program which can be used for testing whether the new log level that you introduced is being identified or not:

TestMyLogLevel.java:


package org.myapp.core; 

import org.apache.log4j.Level; 
import org.apache.log4j.Logger; 
import org.myapp.log.MyTraceLevel; 

/** 
 * Tests whether the new log level {@link org.myapp.log.MyTraceLevel#MY_TRACE} 
 * is working 
 * 
 * @author Jaikiran Pai 
 * 
 */ 
public class TestMyLogLevel { 

 /** 
  * Writes a log message with {@link org.myapp.log.MyTraceLevel#MY_TRACE} 
  * and another message with {@link Level#DEBUG}
       *
       * @param args
       */
 public static void main(String[] args) {
  Logger logger = Logger.getLogger(TestMyLogLevel.class);
  logger.log(MyTraceLevel.MY_TRACE,"I am MY_TRACE log");
  logger.log(Level.DEBUG ,"I am a debug message");
 }
}

Finally, here's the log file that got generated:


2006-07-12 13:45:40,633 MY_TRACE [org.myapp.core.TestMyLogLevel] I am MY_TRACE log 
2006-07-12 13:45:40,633 DEBUG [org.myapp.core.TestMyLogLevel] I am a debug message

Points to note:

- The int value that you specify for your log level is important. Here i have defined "MY_TRACE" log level is to be higher than the DEBUG level but lower than the TRACE level provided by log4j. So whenever you have set a priority level to DEBUG on the category(in your log4j.xml file), the MY_TRACE level logs will *NOT* make it to the log file.

I get "log4j:WARN No appenders could be found for logger" message

2006-07-05T20:27:00.000+05:30

While using log4j in your application, sometimes you might encounter the following message:

log4j:WARN No appenders could be found for logger(somePackageName.someClassName).
log4j:WARN Please initialize the log4j system properly.

The reason why you see this message is that your log4j configuration file(i.e. log4j.xml or log4j.properties) is NOT found in the classpath. Placing the log4j configuration file in the applications classpath should solve the issue. If you want to find out how log4j tries to configure itself, have a look at my earlier post :

Know how log4j tries to configure itself

Know how log4j tries to configure itself

2006-07-04T15:14:00.000+05:30

Large number of applications use log4j for logging. Sometimes you may encounter cases where you sense that log4j is using some other configurations, other than the one that you expected it to use. You can debug the same by switching on the debug flag on log4j. Here's how you can do it:

Add -Dlog4j.debug to the command line. log4j will output info to std. out. telling you how it tries to configure itself.

Accessing a secure EJB through a standalone java client

2006-07-04T13:40:00.000+05:30

To access a secure resource(may be a EJB), from a standalone client, you need to do a JAAS login. Here's an simple example which shows how to implement the same. But before going to the example, here's the reason why we need to do a login. Consider a secured EJB "MyTestEJB", deployed on a app server. The normal proceedure that you follow in a web-application to lookup the EJB and invoke a method on the same is as follows:


Context context = new InitialContext(); 
//lookup the home object 
Object lookupObj = context.lookup("MyTestEJBHomeJndiName"); 
MyTestEJBHome home = (MyTestEJBHome) PortableRemoteObject.narrow(lookupObj, MyTestEJBHome.class); 
//create the bean object from the home object 
MyTestEJB myBean = home.create(); 
//invoke the method on the bean 
myBean.someMethod();

In the steps above, when the method create is called on the home object, the app server internally checks whether the user who is doing this operation, is authenticated and authorised to do the same. If not, it will throw a SecurityException. The above statements will usually work in a web-application where usually you have a login page to carry out the login process.

Now, consider the case with a standalone java client which has just got a main method and which needs to invoke the secure bean. The application server will have no knowledge about which user is trying to do the operations on the bean(is he authenticated or authorised?). This is the reason why the standalone client needs to do a JAAS login, to let the application server know which user is trying to do the operation on the bean. Now lets look at the code for doing the same. Here we have a standalone java client with a main() method:


package myapp;

import javax.ejb.CreateException;
import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;
import javax.rmi.PortableRemoteObject;
import javax.security.auth.login.LoginContext;
import javax.security.auth.login.LoginException;
import java.io.Serializable;
import java.rmi.RemoteException;

/**
 *
 * Stand-alone client invoking a method on a secure EJB
 *
 */
public final class SomeStandAloneClient {


 /**
  * Default constructor
  *
  */
 public SomeStandAloneClient() {

 }

 /**
  * Main method
  *
  * @param args Command line arguments
  */
 public static void main(String[] args) {

  //obtain the username and password which are passed as part of command line arguments
  String userName = args[0];
  String password = args[1];

  System.out.println("Logging in user: " + userName);

  /*
   * The name of the file which will contain the login configurations
   */
  final String authFile = "someFilename.someExtension";

  /*
   * Set the filename above, as part of system property, so that while doing a login,
   * this file will be used to check the login configurations
   */
  System.setProperty("java.security.auth.login.config", authFile);

  /*
   * During the login process(i.e. when the login() method on the LoginContext is called),
   * the control will be transferred to a CallbackHandler. The CallbackHandler will be
   * responsible for populating the Callback object with the username and password, which
   * will be later on used by the login process
   *
   * The "MyCallbackHandler" is your own class and you can give any name to it. MyCallbackHandler
   * expects the username and password to be passed through its constructor, but this is NOT
   * mandatory when you are writing your own callback handler.
   *
   *
   */
  MyCallbackHandler handler = new MyCallbackHandler(userName,password);

  try {

   /*
    * Create a login context. Here, as the first parameter, you will specify which
    * configuration(mentioned in the "authFile" above) will be used. Here we are specifying
    * "someXYZLogin" as the configuration to be used. Note: This has to match the configuration
    * specified in the someFilename.someExtension authFile above.
    * The login context expects a CallbackHandler as the second parameter. Here we are specifying
    * the instance of MyCallbackHandler created earlier. The "handle()" method of this handler
    * will be called during the login process.
    */
   LoginContext lc = new LoginContext("someXYZLogin",handler);

   /*
    * Do the login
    */
   lc.login();

   System.out.println("Successfully logged in user: " + userName);


  } catch (LoginException le) {

   System.out.println("Login failed");
   le.printStackTrace();
   return;
  }

  try{

   /*
    * Now that the user has logged in, invoke the method on the EJB
    */

   Context context = new InitialContext();

   //lookup the home object
   Object lookupObj = context.lookup("MyTestEJBHomeJndiName");
   MyTestEJBHome home = (MyTestEJBHome) PortableRemoteObject.narrow(lookupObj, MyTestEJBHome.class);

   //create the bean object from the home object
   MyTestEJB myBean = home.create();

   //invoke the method on the bean
   myBean.someMethod();


  } catch (RemoteException re) {

   System.out.println("Remote exception: ");
   re.printStackTrace();
   return;
 
  } catch (NamingException ne) {

   System.out.println("NamingException: ");
   ne.printStackTrace();
   return;
 
  } catch (CreateException ce) {
 
   System.out.println("CreateException: ");
   ce.printStackTrace();
   return;
  }


 } //end of main()

} //end of SomeStandAloneClient

Now the CallbackHandler:


package myapp;

import java.io.IOException;

import javax.security.auth.callback.Callback;
import javax.security.auth.callback.CallbackHandler;
import javax.security.auth.callback.NameCallback;
import javax.security.auth.callback.PasswordCallback;
import javax.security.auth.callback.UnsupportedCallbackException;

/**
 *
 * CallbackHandler which will be invoked by the login module during the login
 * process of the client. This is a simple CallbackHandler which sets the username
 * and password, which will be later used by the Login module for authorizing the
 * subject. This class only handles NameCallback and PasswordCallback. It throws
 * an UnsupportedCallbackException, if the Callback is other than the two mentioned
 * above.
 * The username and password are provided as input to this class through its constructor.
 *
 *
 */
public class MyCallbackHandler implements CallbackHandler {

 /**
  * Username which will be set in the NameCallback, when NameCallback is handled
  */
 private String username;

 /**
  * Password which will be set in the PasswordCallback, when PasswordCallback is handled
  */
 private String password;

 /**
  * Constructor
  * @param username The username
  * @param password The password
  */
 public MyCallbackHandler(String username, String password) {
  this.username = username;
  this.password = password;
 }

 /** 
  * @param callbacks Instances of Callbacks 
  * @throws IOException IOException 
  * @throws UnsupportedCallbackException If Callback is other than NameCallback or PasswordCallback 
  */ 
 public void handle(Callback callbacks[]) throws IOException, UnsupportedCallbackException {

  for(int i = 0; i < callbacks.length; i++) {
      if(callbacks[i] instanceof NameCallback) {
   NameCallback nc = (NameCallback)callbacks[i];
   nc.setName(username);
      } else if(callbacks[i] instanceof PasswordCallback) {
   PasswordCallback pc = (PasswordCallback)callbacks[i];
   pc.setPassword(password.toCharArray());
      } else {
   throw new UnsupportedCallbackException(callbacks[i], "Unrecognized Callback");
      }

  }
 }
}

The file containing the login configuration(in our case "someFilename.someExtension"):

someXYZLogin{
org.jboss.security.ClientLoginModule required;
};

Remember, the someXYZLogin configuration name is the same that i provided to the constructor of the LoginContext. The contents of the above file let the LoginContext know, which class will be actually responsible for doing the login. In this case, since i am using jboss, we have specified "org.jboss.security.ClientLoginModule" as the class.

Please make sure that the login configuration file is under the same directory from where you will be running your client.

The command to run your client is the same that you would use to run a normal java class:

java SomeStandAloneClient someUsername somePassword

The someUsername and somePassword will be the arguments that you will pass to the main() method.

This is just a simple example. Internally, there are a lot of things, that go on as part of login. The following link has a great explanation about the same(JAAS related things are explained starting from the "An Introduction to JAAS" section in that article). I highly recommend, to go through it atleast once:

Article on Security

Introductory post

2006-07-03T15:39:00.000+05:30

Thought of putting in one place, all the technical stuff that i get to learn while working as a software developer in J2EE field.