My Wiki

$JAVA_HOME/bin/jconsole

On the JConsole menu let's again select the "Remote process" option and use the following URL in the URL text box:

service:jmx:http-remoting-jmx://localhost:9990

Note: For JBoss AS 7.x and JBoss EAP 6.x, the vendor specific protocol is remoting-jmx and the port for communication is 9999. So the URL will be service:jmx:remoting-jmx://localhost:9999

In the username and password textboxes, use the same user/pass that you newly created. Finally, click on Connect. What do you see? It doesn't work! The connection fails. So what went wrong?

$JAVA_HOME/bin/jconsole -J-Djava.class.path=$JAVA_HOME/lib/tools.jar:$JAVA_HOME/lib/jconsole.jar:/opt/wildfly-8.2.0.Final/bin/client/jboss-cli-client.jar

(Note that for Windows the classpath separator is the semi-colon character instead of the colon)

Note, the server specific jar for JBoss AS 7.x and JBoss EAP 6.x is named jboss-client.jar and is present at the same JBOSS_HOME/bin/client directory location.

So we are passing -Djava.class.path as the parameter to the jconsole Java runtime, using the -J option. Notice that we have specified more than just our server specific jar in that classpath. That's because, using the -Djava.class.path is expected to contain the complete classpath.  We are including the jars from the Java JDK lib folder that are necessary for JConsole and also our server specific jar in that classpath.

Running that command should bring up JConsole as usual and let's go ahead and select the "Remote process" option and specify the same URL as before:

service:jmx:http-remoting-jmx://localhost:9990

and the same username and password as before and click Connect. This time you should be able to connect and should start seeing the MBeans and others services exposed over JMX.

$JBOSS_HOME/bin/jconsole.sh

Posted by Jaikiran at 11:16 AM 4 comments 👁 Image

Labels: as7, JBoss, jbossas, jconsole, jmx, wildfly

I guess by now everyone is aware that the community JBoss AS server has been renamed to WildFly. The WildFly team has been busy pushing out releases of the 8.0 series during the past few months. It's been a month now since the 8.0 CR1 version of WildFly was released. This is a significant release since the 8.0 CR1 version passes the Java EE7 TCK 100%. The Final version of 8.0 is expected any time soon http://lists.jboss.org/pipermail/wildfly-dev/2014-January/001458.html.

Along with this good news about the WildFly 8.0 series nearing the final version, the other good news is that there's now a WildFly 8 administration guide available for purchase. The author of the book is Francesco Marchioni, who in the past has authored books on the JBoss AS series.

Brief review of the WildFly 8 book

Posted by Jaikiran at 7:29 PM 0 comments 👁 Image

Labels: javaee, javaee7, JBoss, jbossas, wildfly

A week back we released WildFly 8.0.0.Alpha3 version. As usual the download is available on WildFly downloads page. This release comes within a month of the 8.0.0.Alpha2 release. Keeping up with the goals of WildFly 8, this new release contains additional EE7 support, certain bug fixes and also some WildFly specific features. The entire release notes are available here.

In this article, I'll provide some details about one of the WildFly features which has made into this release.

WildFly ports

HTTP Upgrade support in Undertow

EJB invocation over HTTP

Posted by Jaikiran at 5:28 PM 5 comments 👁 Image

Labels: javaee, javaee7, JBoss, jbossas, wildfly

Every year, JBoss community members are rewarded for their work in the community as part of the JBoss Community Recognition Awards (JBCRA). This year we have 2 community members from the WildFly project (previously known as JBoss Application Server) who have been nominated in 3 different categories.

Nicklas Karlsson has been nominated in the Issue/JIRA category and Stephen Coy has been nominated in 2 categories - Community Leadership and New Features. Please do vote for them here https://www.jboss.org/jbcra/vote.html - it's just one page and takes less than a minute to vote. It's one way of thanking them for the help they have been providing in the community. Remember that these nominees are volunteers and are not Red Hat/JBoss employees so their contributions are that much more valuable.

The voting ends on July 26 2013. Don't wait for that date, vote now! :)

Posted by Jaikiran at 8:31 PM 0 comments 👁 Image

Labels: as7, JBoss, jbossas, jbossas7, wildfly

It's been around 2 weeks now since we released WildFly 8.0.0.Alpha1 version. The download is available on the WildFly downloads page. I'm sure many of you might be wondering what WildFly is and some of you who are aware of what it is, might not be aware that there has been a release. I'll try and answer some of these questions and also add some details about what this release contains.

So what's WildFly?

Why did we change the name?

So what happens to the "JBoss" name in JBoss EAP?

How does WildFly 8.0.0.Alpha1 release relate to the previous JBoss AS7 releases?

Is WildFly 8.0.0.Alpha1 a release of a new project?

What's new in 8.0.0.Alpha1 release?

What's next for WildFly?

By the way, what's that image at the beginning of this article?

Posted by Jaikiran at 4:56 PM 1 comments 👁 Image

Labels: javaee, javaee7, JBoss, jbossas, wildfly

 Update (June 10 2013): JBoss AS is now known as WildFly. This post was written before WildFly 8.0.0.Alpha1 was released. Any references to JBoss AS8 in this article should be considered as a reference to WildFly 8. Read my next article here http://jaitechwriteups.blogspot.in/2013/06/wildfly-release-and-history-behind-the-release.html which explains what WildFly is and why JBoss AS was renamed to WildFly.

Some of you might be aware that the Public Final Draft version of Java EE 7 spec has been released. Among various other new things, this version of Java EE, brings in EJB 3.2 version of the EJB specification. EJB 3.2 has some new features compared to the EJB 3.1 spec. I'm quoting here the text present in the EJB 3.2 spec summarizing what's new:

The Enterprise JavaBeans 3.2 architecture extends Enterprise JavaBeans to include the following new functionality and simplifications to the earlier EJB APIs:

• Support for the following features has been made optional in this release and their description is moved to a separate EJB Optional Features document:
• EJB 2.1 and earlier Entity Bean Component Contract for Container-Managed Persistence
• EJB 2.1 and earlier Entity Bean Component Contract for Bean-Managed Persistence
• Client View of an EJB 2.1 and earlier Entity Bean
• EJB QL: Query Language for Container-Managed Persistence Query Methods
• JAX-RPC Based Web Service Endpoints
• JAX-RPC Web Service Client View


• Added support for local asynchronous session bean invocations and non-persistent EJB Timer Service to EJB 3.2 Lite.


• Removed restriction on obtaining the current class loader; replaced ‘must not’ with ‘should exercise caution’ when using the Java I/O package.


• Added an option for the lifecycle callback interceptor methods of stateful session beans to be executed in a transaction context determined by the lifecycle callback method's transaction attribute.


• Added an option to disable passivation of stateful session beans.


• Extended the TimerService API to query all active timers in the same EJB module.


• Removed restrictions on javax.ejb.Timer and javax.ejb.TimerHandle references to be used only inside a bean.


• Relaxed default rules for designating implemented interfaces for a session bean as local or as remote business interfaces.


• Enhanced the list of standard activation properties.


• Enhanced embeddable EJBContainer by implementing AutoClosable interface.

As can be seen, some of the changes proposed are minor. But there are some which are useful major changes. We'll have a look at a couple of such changes in this article.

1) New API TimerService.getAllTimers()

EJB 3.2 version introduces a new method on the javax.ejb.TimerService interface, named getAllTimers. Previously the TimerService interface had (and still has) a getTimers method. The getTimers method was expected to return the active timers that are applicable for the bean on whose TimerService, the method had been invoked (remember: there's one TimerService per EJB).

In this new EJB 3.2 version, the newly added getAllTimers() method is expected to return all the active timers that are applicable to *all beans within the same EJB module*. Typically, an EJB module corresponds to a EJB jar, but it could also be a .war deployment if the EJBs are packaged within the .war. This new getAllTimers() method is a convenience API for user applications which need to find all the active timers within the EJB module to which that bean belongs.

2) Ability to disable passivation of stateful beans

Those familiar with EJBs will know that the EJB container provides passivation (storing the state of the stateful bean to some secondary store) and activation (loading the saved state of the stateful bean) capability to stateful beans. However, previous EJB versions didn't have a portable way of disabling passivation of stateful beans, if the user application desired to do that. The new EJB 3.2 version introduces a way where the user application can decide whether the stateful bean can be passivated or not.

By default, the stateful bean is considered to be "passivation capable" (like older versions of EJB). However, if the user wants to disable passivation support for certain stateful bean, then the user has the option to either disable it via annotation or via the ejb-jar.xml deployment descriptor.

Doing it the annotation way is as simple as setting the passivationCapable attribute on the @javax.ejb.Stateful annotation to false. Something like:

 @javax.ejb.Stateful(passivationCapable=false) // the passivationCapable attribute takes a boolean value 
 public class MyStatefulBean { 
 .... 
 } 

Doing it in the ejb-jar.xml is as follows:

 <?xml version="1.0" encoding="UTF-8"?> 
 <ejb-jar xmlns="http://xmlns.jcp.org/xml/ns/javaee" 
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
 xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee 
 http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd" 
 version="3.2"> 
 <enterprise-beans> 
 <session> 
 <ejb-name>foo-bar-bean</ejb-name> 
 <ejb-class>org.myapp.FooBarStatefulBean</ejb-class> 
 <session-type>Stateful</session-type> 
 <!-- passivation-capable element takes either a true or a false value --> 
 <passivation-capable>false</passivation-capable>  
 </session> 
 ... 
 </enterprise-beans> 
 </ejb-jar> 

Two important things to note in that ejb-jar.xml are the version=3.2 attribute (along with the http://xmlns.jcp.org/xml/ns/javaee/ejb-jar_3_2.xsd schema location) on the ejb-jar root element and the passivation-capable element under the session element.

So, using either of these approaches will allow you to disable passivation on stateful beans, if you want to do so.

Java EE 7 and EJB 3.2 support in JBoss AS8:

JBoss AS8 has been adding support for Java EE 7 since the Public Final Draft version of the spec has been announced. Support for EJB 3.2 is already added and made available. Some other Java EE 7 changes have also made it to the latest JBoss AS 8 builds. To keep track of the Java EE 7 changes in JBoss AS8, keep an eye on this JIRA https://issues.jboss.org/browse/AS7-6553.

To use the already implemented features of Java EE 7 in general or EJB 3.2 in particular, you can download the latest nightly build/binary of JBoss AS from here. Give it a try and let us know how it goes. For any feedback, questions or if you run into any kind of issues, feel free to open a discussion thread in our user forum here.

Posted by Jaikiran at 3:47 PM 7 comments 👁 Image

Labels: as7, EJB, ejb 3.2, javaee7, JBoss, jbossas, jbossas7, jbossas8, wildfly

It's been a while since I last blogged. I keep thinking of blogging something technical but end up getting busy with other things. This last week there was a very interesting discussion at the coderanch forums. It was even more interesting because it involved JBoss :)

Developers familiar with Java EE web applications would know that the web application deployment descriptor (web.xml) allows you to specify "error pages" which the container will display when a specific exception (class) or a error code is thrown by the server for a web request. Here's a quick example of how it looks like:

 <web-app>  
   ...  
   <!-- A custom error page for error code == 500 -->  
   <error-page>   
     <error-code>500</error-code>   
     <location>/my-foo-bar-500-page.html</location>   
   </error-page>   
     
   <!-- A custom error page for exception type org.myapp.foo.bar.MyException -->  
   <error-page>   
     <exception-type>org.myapp.foo.bar.MyException</exception-type>   
     <location>/my-foo-bar-exception-page.html</location>   
   </error-page>   
   ...  
     
 </web-app>  
   

Simple enough - a couple of custom error pages defined for a specific error code and an exception type respectively. All of this works fine.

In current days, more and more programming models and frameworks come into picture while developing web applications. CDI and JSF are some of those. CDI has this concept of scopes (ex: request scope, session scope, application scope, conversation scope). We won't go into the details of what those are and when those are used, but let's consider conversation scope in this blog since that's what the discussion was about in the forum thread that prompted this blog.

So CDI allows multiple requests to be part of a "conversation scope". A conversation has a "start" and an "end", both of which can be managed by the application. When the application involves JSF, any conversation (id) gets auto-propagated to the JSF request(s). Apart from an explicit start/end demarcation of conversations, a conversation can also timeout. A request which refers to a conversation which has ended or timed out will run into an exception.

So we know have a bit of background on CDI conversation scope. So let's consider a case where the application wants to present a good looking page when the "conversation no longer present" exception is thrown (maybe because of a timeout). We have seen how to write a web.xml for error-page configurations - it would be as simple as:

 <web-app>  
   ...  
     
   <!-- A custom error page for exception type org.jboss.weld.context.NonexistentConversationException -->  
   <error-page>   
     <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>   
     <location>/my-foo-bar-exception-page.html</location>   
   </error-page>   
   ...  
     
 </web-app>  
   

Simple enough. The org.jboss.weld.context.NonexistentConversationException is the exception class type which gets thrown when the conversation has timed out (note that we are assuming that the web application is relying on Weld as the CDI spec implementation library). The above configuration works fine. The my-foo-bar-exception-page.html gets displayed when the org.jboss.weld.context.NonexistentConversationException is thrown.

BUT, let's now consider that we want to involve JSF in the error page just like the other parts of our application. So let's point the error-page to a URL pattern which maps to the JSF servlet:

 <web-app>  
   ...  
     
   <!-- A custom error page for exception type org.jboss.weld.context.NonexistentConversationException -->  
   <error-page>   
     <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>   
     <location>/my-foo-bar-exception-page.xhtml</location>   
   </error-page>   
   ...  
     
 </web-app>  
   

Note that we changed the error page mapping to my-foo-bar-exception-page.xhtml (notice the xhtml extension) from my-foo-bar-exception-page.html. We'll again assume that the .xhtml resources are mapped to the JSF servlet so those requests are considered as JSF requests.

With this change to the web.xml, you'll notice that the my-foo-bar-exception-page.xhtml will no longer be displayed in you see a big stacktrace with repeatedly shows org.jboss.weld.context.NonexistentConversationException exception in the stacktrace thus giving an impression that the error-page configuration went wrong.

So what did we do wrong? Well, remember that earlier I mentioned that for JSF requests the conversation id gets propagated automatically. That's exactly what's happening here. The server notices the org.jboss.weld.context.NonexistentConversationException exception and then tries to render the error-page which is backed by JSF and since the conversation id gets propagated the server tries to find that non-existent conversation and ends up failing with the same org.jboss.weld.context.NonexistentConversationException and ultimately fails to render the error page. It's like going in circles to render that error page.

So how does one get past it? Keeping aside all the technical details, the obvious thing would be to not propagate the non-existent conversation id while rendering the (JSF backed) error page. So that's what we are going to do. CDI 1.1 (and Weld 1.1.2 and later) allows you to explicitly specify that a conversation shouldn't be propagated for a particular request. You can do this by passing along a parameter named "nocid" within that request. With that knowledge, let's now modify our web.xml to do the necessary changes so that our error page gets rendered properly:

 <web-app>  
   ...  
     
   <!-- A custom error page for exception type org.jboss.weld.context.NonexistentConversationException.  
     Notice the "nocid" parameter being passed to make sure that the non-existent conversation id  
     isn't passed to the error page  
   -->  
   <error-page>   
     <exception-type>org.jboss.weld.context.NonexistentConversationException</exception-type>   
     <location>/my-foo-bar-exception-page.xhtml?nocid=true</location>   
   </error-page>   
   ...  
     
 </web-app>  
   

Notice that we are passing the "nocid" parameter as part of the query string of the error page location. The value for "nocid" parameter really doesn't matter but for the sake of keeping that value logical, we have used the value "true" here. Once this change is done, you'll start noticing that the error page (backed by JSF) now renders correctly!

It took a while for us to get to this solution in that forum thread because it looked so simple that it should have "just worked", but it didnt' Here's the forum thread at coderanch that I've been talking about. Credit goes to Greg Charles for figuring out how to pass that nocid parameter.

Posted by Jaikiran at 7:15 PM 4 comments 👁 Image

Labels: cdi, javaee6, JBoss, jbossas, jbossas7, jsf

Those of you who missed this year's JavaOne event and still haven't heard about it, here's some news that all JBoss AS followers should be aware of - your favourite application server, JBoss AS, is being renamed.

JBoss AS or just JBoss, as we have all called it since the 3.x days will now be called something else. The reasons for the rename have been explained in this "Why rename JBoss AS, FAQ?". Mark Little has blogged about the this rename in his posts here and here. Read through those pages to understand what's being proposed.

So what's the new name going to be for the JBoss AS project? We don't know yet. In fact, the name will be picked by the community. Everyone is allowed to submit a name of their choice and those names will go through a voting process and one out of those names will be chosen. So if you can think of a name for JBoss AS then go suggest it here before the 14th of this month. Don't leave it for later, this is your chance to be known as the one who chose the new name!

Posted by Jaikiran at 9:34 PM 0 comments 👁 Image

Labels: as7, JBoss, jboss_application_server7, jbossas, jbossas7

After just about more than a year of development on JBoss AS7, we have now released 7.1.0.Final "Thunder"! The download is available at the usual place here. This is a really big achievement for the JBoss AS7 team and we are really proud about this release.

This release contains numerous bug fixes from 7.1.0.CR1b which was released a few months back. But the biggest news about this release is that JBoss AS 7.1.0.Final is Java EE 6 Full Profile certified! I'm sure a lot of our users will be very happy about this news. AS 7.0.x was Web Profile certified but I have seen in the forums that many of you were waiting for the Full Profile certification to happen. So here's a very good reason to start using JBoss AS7, if you haven't done yet.

Apart from the Full Profile certification, AS 7.1.0.Final contains a lot of bug fixes and other JIRA issues resolved. The entire release notes can be found here.

Like in some of my previous posts on AS7 releases, in this post I'll explain atleast one new feature of this release. Many of you would know that JBoss AS7 is very different compared to the previous JBoss AS versions, on various counts. One prominent difference is that we no longer have numerous XML files in the distribution, configuring various services. Instead we just have *one* single configuration file which governs the entire server. Furthermore, unlike previous JBoss AS versions, JBoss AS7 (prior to 7.1.0.Final) did not allow *deploying* XML files to configure datasources and JMS queues. However, the community members have been repeatedly asking for this feature and JBoss AS 7.1.0.Final now allows deploying of datasources and JMS queues via application specific XML files (in addition to configuring them centrally in the domain/standalone configuration file). So let's take a quick look at how it's done in 7.1.0.Final.

Deploying datasource via -ds.xml files in JBoss AS 7.1.0.Final

The datasource file is expected to end with the -ds.xml suffix, like in previous JBoss AS releases. You can place the *-ds.xml file in the JBOSS_HOME/standalone/deployments folder or even package it in the application under the META-INF folder of the application. If it's a .war application, then the *-ds.xml is expected to be right under the WEB-INF folder of the .war.

The *-ds.xml is expected to follow the jboss-as-datasources xsd which looks like this. So you have a datasources element under which you can define multiple datasource elements. In this example, we'll try and create a MySQL datasource and deploy it as  mysql-ds.xml.

Before creating the datasource, we first have to install the database driver. AS7 allows you install the database driver either as a deployment or as JBoss Module. For more details on this, see this article. In this post, we'll deploy the driver as a JBoss Module.

Create and install the database driver

As a first step, we'll require the MySQL driver jar file. I downloaded the driver jar from the MySQL download site here. The step to create the JBoss Module for this driver involves creating a module.xml which looks like this and is named module.xml:

 <module xmlns="urn:jboss:module:1.1" name="mysql"> 
 
 <resources> 
 <resource-root path="mysql-connector-java-5.1.18-bin.jar"/> 
 </resources> 
 <dependencies> 
 <module name="javax.api"/> 
 <module name="javax.transaction.api"/> 
 </dependencies> 
 </module> 

We place the mysql-connector-java-5.1.18-bin.jar and this module.xml file in JBOSS_HOME/modules/mysql/main folder (you'll have to create the mysql/main folder). That completes the JBoss Module creation for the MySQL driver. Now let's install this driver so that it gets registered in the standalone/domain configurations. In this example, we'll be using the standalone server. So let's start the server using:

 ./standalone.sh 

Once the server is up, let's open the Command Line Interface (CLI) utility which is shipped in AS7. The CLI startup script is in the JBOSS_HOME/bin folder and can be started as follows (more details about the CLI can be found here)

 ./jboss-cli.sh --connect 

Once connected successfully, we'll add the jdbc-driver using the following command:

 /subsystem=datasources/jdbc-driver=mysql-5-driver:add(driver-name=mysql-5-driver, driver-class-name=com.mysql.jdbc.Driver, driver-module-name=mysql) 

So here we are naming the driver as "mysql-5-driver" (you can name it anything). The driver-module-name points to the "mysql" JBoss Module that we created in previous step. The driver-class-name is the fully qualified classname of the MySQL driver. In this case, it's com.mysql.jdbc.Driver.

A successful execution of that command will show the output as success:

 [standalone@localhost:9999 /] /subsystem=datasources/jdbc-driver=mysql-5-driver:add(driver-name=mysql-5-driver, driver-class-name=com.mysql.jdbc.Driver, driver-module-name=mysql) 
 {"outcome" => "success"} 
 

The installation will be persisted in the configuration file which was used to start the server. In this case it's the standalone.xml and this is how it looks like after the driver has been installed:

 <subsystem xmlns="urn:jboss:domain:datasources:1.0"> 
 ... 
 <drivers> 
 ... 
 <driver name="mysql-5-driver" module="mysql"> 
 <driver-class>com.mysql.jdbc.Driver</driver-class> 
 </driver> 
 </drivers> 
 </datasources> 
 </subsystem> 

We are now done with the driver installation. Now let's move on and create the mysql-ds.xml file.

Create the mysql-ds.xml file

As previously mentioned, the mysql-ds.xml should follow the jboss-as-datasources xsd. Here's how the file looks like in our case:

 <?xml version="1.0" encoding="UTF-8"?> 
 <datasources> 
 <datasource jndi-name="java:jboss/datasources/MySQLDS" enabled="true" use-java-context="true" 
 pool-name="MySQLDS"> 
 <connection-url>jdbc:mysql://localhost:3306/test</connection-url> 
 <driver>mysql-5-driver</driver> 
 <security> 
 <user-name>foo</user-name> 
 <password>bar</password> 
 </security> 
 </datasource> 
 </datasources> 

Let's see what that xml file contains. The "jndi-name" is the name to which the datasource will be bound to (you can use a name of your choice. Ideally, it would be good to bind them in java:jboss/datasources/ namespace). The "enabled=true" indicates that the datasource should be enabled after being deployed. The "use-java-context" attribute is used to indicate that the JNDI name should be bound under the java: namespace. The "connection-url" is the URL to be used for connecting to the MySQL database (check MySQL documentation for more details about the connection-url). The "driver" element points to the installed JDBC driver that we created in the previous step. In our example, we named it mysql-5-driver and that's what we use here. Finally, the "security" section contains the username and password information for connecting to the database. Make sure you use the appropriate values for all these configurations.

So now let's place this mysql-ds.xml in the JBOSS_HOME/standalone/deployments folder and see JBoss AS7 hot deploy it (if the server is already running). The logs will show the following on successful deployment:

 14:05:55,829 INFO [org.jboss.as.server.deployment] (MSC service thread 1-3) JBAS015876: Starting deployment of "mysql-ds.xml" 
 14:05:55,847 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-2) JBAS010400: Bound data source [jboss/datasources/MySQLDS] 
 

So that's it! We have successfully deployed the MySQL datasource through a -ds.xml file in 7.1.0.Final!

So download this new version and start deploying your applications and start using these features. We'll be blogging more about the features in this release, in the upcoming days (after the AS7 developers get some much needed sleep :) ). So keep an eye on the jboss.org blogs. If you run into any issues with AS7, feel free to visit our user forum and ask for help.

Posted by Jaikiran at 3:11 PM 11 comments 👁 Image

Labels: as7, Java, javaee6, JBoss, jboss_application_server7, jbossas, jbossas7

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.

Posted by Jaikiran at 9:15 PM 4 comments 👁 Image

Labels: as7, event, JBoss, jbossas, jbossas7, judcon, judcon2012

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.

 

Posted by Jaikiran at 3:20 PM 0 comments 👁 Image

Labels: as7, javaee, javaee6, JBoss, jboss_application_server7, jbossas, jbossas7

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

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

Posted by Jaikiran at 11:08 PM 0 comments 👁 Image

Labels: as7, javaee6, JBoss, jboss_application_server7, jbossas, jbossas7

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

Posted by Jaikiran at 9:27 PM 10 comments 👁 Image

Labels: as7, as7_openshift, javaee, javaee6, JBoss, jboss_application_server7, jbossas, jbossas7, openshift, openshift_express