jUUDI and JBoss Intro

After a quick install of JBoss, I drop in the jUDDI application and immediately run into configuration problems that I won’t bore you with now. However, as I start my research, I very quickly discover that jUDDI is integrated into JBoss! So at this point, the folks at JBoss go up a notch in my esteem.

I then drop the standard jUDDI application from JBoss and copy over the juddi-service.sar to my implemented server and fire it up. First thing I notice is that it’s looking for a JNDI datasource, which I had never set up before, but discover it’s quite simple.

Installing a MySQL UDDI Datastore

1. Download and install MySQL
2. Download the 0.9RC4 version of jUDDI
3. Extract the jUDDI zip and look in the sql directory to get the script for setting up the juddi database
4. Make sure you have the jboss-local-jdbc.rar package in your JBoss deploy directory
5. Download the MySQL connector (mysql-connector-java-5.1.5-bin.jar) and put it in the server\lib directory
6. Create a file named juddi-ds.xml in your deploy directory and create your JNDI datasource.
   Listing 1.1

   <datasources>
      <local-tx-datasource>
         <jndi-name>juddiDB</jndi-name>
         <connection-url>jdbc:mysql://{mysql server ip}:3306/juddi</connection-url>
         <driver-class>com.mysql.jdbc.Driver</driver-class>
         <user-name>{username}</user-name>
         <password>{password}</password>
         <min-pool-size>5</min-pool-size>
         <max-pool-size>20</max-pool-size>
      </local-tx-datasource>
   </datasources> 

7. Open up the jboss\server\default\deploy\juddi-service.sar\juddi.war\WEB-INF\jboss-web.xml file and change the jndi-name property to refer to the name you just created

   <?xml version="1.0" encoding="ISO-8859-1"?>
   
   <!DOCTYPE jboss-web PUBLIC
           "-//JBoss//DTD Web Application 2.3V2//EN"
       "http://www.jboss.org/j2ee/dtd/jboss-web_4_0.dtd">
   
   <jboss-web>
       <context-root>juddi</context-root>
       <resource-ref>
           <res-ref-name>jdbc/juddiDB</res-ref-name>
           <jndi-name>java:/juddiDB</jndi-name>
       </resource-ref>
   </jboss-web>

Ok, so now I’ve got a database set up to store all of the UDDI information… now what? Let’s see if jUDDI started up correctly. I hit http://localhost/juddi and – SHAZAM! – it works: I get a standard “Welcome to JBoss JUDDI” screen. Now I try to publish a service to it. How do I do that?

Some more Googling gets me to the Eclipse Web Services Explorer, which is part of the Web Tools Platform. I install all of the packages and launch the explorer. I test a sample WSDL and it works great, so far so good. Then I try to publish a service to the UDDI and I start getting exceptions in the interface. I check the logs and see the following exceptions …

ERROR [JUDDIServlet] java.lang.IllegalStateException: Failed to load javax.xml.soap.MessageFactory: org.jboss.ws.core.soap.MessageFactoryImpl
ERROR [JUDDIServlet] A serious error has occured while assembling the SOAP Fault.

Back to Google I go and 30 minutes later I finally find some relevant discussions and possible resolutions. What it boils down to is you have to override the org.jboss.ws.core.soap.MessageFactoryImpl class with com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl.

How do you do this?

Implementing SOAP with Attachments API for Java (SAAJ)

Go to the SAAJ project site and download the latest SAAJ release. Extract the zip file and copy the two files in the lib directory…

• saaj-api.jar
• saaj-impl.jar

to your deploy\lib directory.

Open the jboss\server\default\deploy\properties-service.xml file and set some system properties.

<mbean code="org.jboss.varia.property.SystemPropertiesService"
	 name="jboss:type=Service,name=SystemProperties">

    
    <attribute name="Properties">
      javax.xml.soap.MessageFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPMessageFactory1_1Impl
      javax.xml.soap.SOAPFactory=com.sun.xml.messaging.saaj.soap.ver1_1.SOAPFactory1_1Impl
    </attribute>
</mbean>

Now restart JBoss and try to publish your service again via the Web Services Explorer (or whatever tool you want to use) and it should work.

1. You want to run PHP and ColdFusion on the same server with minimal headaches
2. You want to host multiple domains on your JBoss instance
3. You need to use complex URI rewriting rules for incoming requests
4. You need to run IIS and JBoss on the same server
5. You just need a solid, lightweight web server

The reasons I chose to use Apache to act as the web server for my JBoss servers were 1 and 2. I eventually needed to do a little bit of 3. I temporarily had to do number 4, and how easily I have been able to do all of this led me to believe number 5.

Preparing JBoss

The only thing you need to change on JBoss to have Apache act as a proxy to it is ensure that is it not listening on port 80 (which you may have set if it was acting as your web server). Read step 5 in my standalone primer article for instructions on how to change your HTTP port if you haven’t done this before.

Install Apache

I downloaded version 2.0.58 which works just fine for my purposes. However, by the time you read this article, there may be a much better and/or feature-rich version of Apache available. Just download the version you feel best suits your purposes based on your needs.

Configure Apache

Find the ‘Listen’ section of in the \Apache\conf\httpd.conf file and specify the IP address and port on which Apache is listening.

Listen <server ip address>:80

Next, you need to tell Apache where to direct traffic coming in on port 80 on that IP address. For this, we use Virtual Hosts.

NameVirtualHost <server ip address>:80

Now that Apache is prepared to accept request for multiple domain names, we need to set up each of those domains using the <virtualhost> tag. All you need to specify is the ServerName property, which the the base URL of the domain, and the ProxyPass property which simply tells Apache where to redirect the original request.

If your JBoss server is internal only and not public facing, you’ll have to use the IP address from Apache since that’s the designator for it.

<virtualhost>
    ServerName www.orbwave.com
    ProxyPass / http://{jboss server IP}:8080/
</virtualhost>

<virtualhost>
    ServerName www.fusioncube.net
    ProxyPass / http://{jboss server IP}:8080/
</virtualhost>

If you have both Apache and JBoss sitting on your public web server, you’ll need to use the domain name instead of the IP address.

<virtualhost>
    ServerName www.orbwave.com
    ProxyPass / http://www.orbwave.com:8080/
</virtualhost>

<virtualhost>
    ServerName www.fusioncube.net
    ProxyPass / http://www.fusioncube.net:8080/
</virtualhost>

Configure JBoss to accept requests for multiple domains

What you need to do is create a seperate Host configuration for the edach domain in the server definition file which is located at \jboss\server\default\deploy\jbossweb-tomcat55.sar\server.xml.

Open that file and you’ll see a Host configuration already for localhost. This is the default host meaning that all traffic directed via your web server port (8080) will be directed to your root application. This will be your default domain, meaning the one for which you don’t define a Host.

Now let’s create a new Host designation that will direct requests for two new domain names.

<Host name="domain2 {this can be whatever you want}" autoDeploy="false" deployOnStartup="false" deployXML="false">
    <Alias>www.second-domain-name.com</Alias>

    <Valve className="org.apache.catalina.valves.AccessLogValve"
        prefix="things" suffix=".log" pattern="common"
        directory="${jboss.server.home.dir}/log"/>

    <DefaultContext cookies="true" crossContext="true" override="true"/>
</Host>

<Host name="domain3 {this can be whatever you want}" autoDeploy="false" deployOnStartup="false" deployXML="false">
    <Alias>www.third-domain-name.com</Alias>

    <Valve className="org.apache.catalina.valves.AccessLogValve"
        prefix="things" suffix=".log" pattern="common"
        directory="${jboss.server.home.dir}/log"/>

    <DefaultContext cookies="true" crossContext="true" override="true"/>
</Host>

Define Virtual Hosts for Applications

The last step is to modify the jboss-web.xml file for each application. We’ve set up a brand new Host designation, so now each application can be set up as another root application, except now it sits in its own Host space rather than in the one set up for localhost.

So open up the jboss-web.xml file of the application that will be running for second-domain-name.com. Change the context-root definition to root (/) and then match it up with one of the Host entries you made in the server.xml file.

<jboss-web>
    <context-root>/</context-root>
    <virtual-host>domain2</virtual-host>
</jboss-web>

Similarly for another application that will be served for third-domain-name.com

<jboss-web>
    <context-root>/</context-root>
    <virtual-host>domain3</virtual-host>
</jboss-web>

All you need to do is start/restart your Jboss instance and request for both domain names will now be redirected to the appropriate application. Just be sure that you have made the requisite changes to your DNS records and they have propagated.

I downloaded CF8 and followed my typical procedures for deploying on JBoss. Everything worked fine. JBoss started up without any errors and I could hit my applications. Then I decided to see if I could still customize the deployment by moving the core ColdFusion files outside the deployment directory and that went without a hitch. I don’t know why, but I was concerned that they might take that option away.

All in all, nothing has changed as far as deployment procedures. I suppose the only change is that now Adobe will answer your phone call if you deploy on JBoss!

Now for upgrading.

The most obvious change is in the web.xml file that comes with ColdFusion. All of the parameter id’s have changed names from macromedia_xxx to coldfusion_xxx.

<context-param id="coldfusion_context_2">
        <param-name>coldfusion.compiler.outputDir</param-name>
        <param-value>/WEB-INF/cfclasses</param-value>
        <description>This is the directory where we will place compiled
            pages. It must be relative to the webapp root.</description>
</context-param>

Therefore, if you have added anything in your web.xml – security, custom servlets, etc. – it’s best that you copy your custom definitions to the default ColdFusion web.xml rather than trying to update yours to match all the new names.

As always, ColdFusion does not come with a jboss-web.xml file, so make sure that you have that in place for each application again.

I was also pleased to see that Scorpio will be shipped with the 1.6 JDK as the default.  This means that I can now use all the latest framework and Java libraries (such as JAI, however much of my work with that has been made obsolete by the new CFIMAGE tag) without ColdFusion yelling at me.

I’d love to describe all of my favorite features, but since many of them have been blogged about already…

• Javascript style operators
• AJAX controls and JSON serialization
• Argument collections
• Syndication with CFFEED
• Server monitoring

I hope to get into the Beta problem quickly so that I can get it all running on the latest JBoss AS release and see how well it all performs (a.k.a. beat the crap out of it).

I’m looking forward to meeting some of the people behind the names that I see pop up on the CF-Talk list and getting to know my peers in my new hometown.

Unfortunately, I didn’t get in on the Scorpio Beta like I did for CFMX 7 so all of this material will be new to me, and I’m hoping that there are features that we can use with some applications at work. Of course, I’m especially anxious to see if Adobe added JBoss to the list of supported servers for the new version and what version of Java will be supported.

It was interesting to see what other people wanted to be included with Scorpio.

technorati tags:cfug, nashville, scorpio, coldfusion, ben, forta, jboss

In Java application servers, there’s an order in which applications are deployed. In JBoss, the default is alphabetical order inside the server directory. Let’s assume you have an app called BaseballStats stored in baseball.war. Then another application, such as the JMX Console that comes with JBoss, is in jmx-console.war.

The baseball.war application is deployed first with the commons-logging.jar file in ColdFusion’s classpath (WEB-INF\cfusion\lib) which is version 1.0.2, I believe. Then the jmx-console application tries to deploy and it needs version 1.0.7 located in jboss\server\default\deploy\lib.

This type of situation leads to CLASSPATH exceptions such as –

• org.apache.commons.logging.LogConfigurationException: java.lang.ClassCastException
• You have more than one version of ‘org.apache.commons.logging.Log’ visible

What you need to do in situations like this is ensure that ColdFusion loads the latest version of the Apache Commons Logging library available to it before it attemtps to load the one with which it shipped. You designate this in your web.xml file. Search for the text cf.class.path in this file and ensure that the location of the latest Commons Logging library is the first entry in the classpath.

For example, if you need to use the one shipped with your version of JBoss, an sample entry would look like this. I added the path to the JBoss lib directory before the references to the ColdFusion lib directory. This ensures that it will look at JBoss first to find a library before it looks in its own collection.

<-- Comma-delimited list of classpath locations relative to app root  -->
<context-param id="macromedia_context_88">
	<param-name>cf.class.path</param-name>
	<param-value>
		../../lib,
		./WEB-INF/cfusion/lib/updates,
		./WEB-INF/cfusion/lib,
		./WEB-INF/cfusion/gateway/lib.,
		./WEB-INF/cfform/jars
	</param-value>
</context-param>

This post is going to cover how to set up your server to run the JBoss Application Server – parsing ColdFusion code in its web apps. Future posts will cover how to set up JBoss AS/Apache/ColdFusion, and JBoss AS/JBoss WS/ColdFusion.

Step 1: ColdFusion Installer

The first thing you need to do is download and/or run the ColdFusion installation package. During the installation wizard, ensure that you choose to install the J2EE/WAR installation type. When the installer is done, go to the installation directory in which you will see a cfusion.war file.

A WAR file (Web Application aRchive) is simply a ZIP archive, which means you can use whichever program you have for unzipping files. Simply unzip the archive into any location you choose. When done, you will have three directories:

• META-INF
• WEB-INF
• CFIDE

The only two you will be interested in are the WEB-INF and CFIDE directories. You can safely delete the META-INF directory.

Step 2: Install JBoss

Now you can download and install the version of JBoss that you want to run your applications. Installation is as easy as unzipping the downloaded ZIP file to the directory from which you want to run JBoss. When done, you’ll have the following directory structure:

Step 3: Creating Your Application Structure

Notice the SAR and WAR directories under the deploy directory. You need to create one for your new web application. For example, if your application is the website for www.widgets.com, simply create a widgets.war directory.

Remember the WEB-INF and CFIDE directories you unpacked previously, well now we need them. Copy them from their current location to your new widgets.war web application directory. Amazingly, you are almost done! These two directories are all that is needed to get a JBoss web app to parse ColdFusion files.

Step 4: Telling JBoss You’re Alive

Now, here’s where you need to determine how JBoss is going to serve your Widgets application. This is done by creating a jboss-web.xml file inside the widgets.war\WEB-INF directory.

If the Widgets application is the only application you want to server from JBoss, or it is going to be your root application – in both cases, what you want served when someone hits www.widgets.com – you specify this application as the root application. This is what the jboss-web.xml file would look like.

However, if you want this application to be a subdirectory off of your root, you would specify that subdirectory name in the jboss-web.xml file.

Step 5: Serving Your Application

The last thing you might need to do – if JBoss is functioning as your main web server – is change the port on which JBoss is listening. For this, you need to look inside the deploy\jbossweb-tomcat50.sar\server.xml file.

The very first setting in this file is the port on which Tomcat is listening for HTTP requests. The default value is 8080, but if JBoss is your default web and application server, you will need to change the port attribute value to 80.

Conclusion

This is the most basic configuration for JBoss / ColdFusion. After completing these steps, you can start your JBoss instance and hit your designated URL and ColdFusion files will light up.

For more advanced configurations of JBoss, here are some links to other relevant posts.
Running multiple ColdFusion instances
Securing your JBoss web applications
Hosting multiple domains in JBoss
Flexible ColdFusion deployment – serving from anywhere

Now that I think about it, it wasn’t “ridiculously” easy because I had a problem with IIS and JBoss attempting to listen on the same IP address even though I went into IIS and changed the configuration. Luckily this was a documented issue and I found the resolution easily (more info below).

Step 1 – Install Apache

I downloaded version 2.0.58 which works just fine for my purposes.

Apache Configuration

Find the ‘Listen’ section of in the \Apache\conf\httpd.conf file and specify the IP address and port on which Apache is listening.

Listen 192.168.1.200:80

Now, since I’m hosting multiple domains on my system, I need Apache’s virtual hosts to match up with each JBoss virtual host. You can read my article on hosting multiple domains with JBoss for more information on that. the first thing to do is tell Apache that this IP/Port will be using Named Virtual Hosts instead of IP Virtual Hosts.

NameVirtualHost 192.168.1.200:80

Now that Apache knows the it’s going to be accepting request for multiple domain names, we need to set up each of those domains using the <virtualhost> tag. All you need to specify is the ServerName property, which the the base URL of the domain, and the ProxyPass property which simply tells Apache where to redirect the original request.

<virtualhost>
ServerName www.orbwave.com
ProxyPass / http://www.orbwave.com:8080/
</virtualhost>

<virtualhost>
ServerName www.fusioncube.net
ProxyPass / http://www.fusioncube.net:8080/
</virtualhost>

JBoss Configuration

As you can see above, if you’ve got JBoss listening on port 80, it will conflict with Apache and you need to reset it to listen on port 8080. Then Apache redirects the request to port 8080 to be fulfilled by JBoss.

IIS Configuration

Now here’s the tricky part. IIS can’t listen to requests on the same IP address as Apache or it tries to hijack all requests by default. Therefore, you need two IP addresses to be assigned to the server accepting these HTTP requests. Two ways to do that:

1. Install another network adapter, assign is a distinct, static IP address and plug it into the network.
2. Assign another IP address to the network adapter you’re already using.

Now you have to disable socket pooling in IIS. You have to use a utility called Httpcfg.exe to disable it. This utility is found in the /Support/Tools folder on your Windows Server 2003 CD.

Open a command prompt and type httpcfg set iplisten -i w.x.y.z:n to set the new IP address (w.x.y.x) you added to your network card and port number on which you want IIS to listen. This inclusion list specifies which IP addresses http.sys listens on and is initially empty by default, which means that IIS listens to all IP addresses.

Then restart IIS because http.sys reads this list only on startup. You don’t have to restart all IIS services, only the HTTP Service.

Summary

It takes a little work, but it’s not difficult as long as you have all the information. I now have PHP, ColdFusion and ASP sites running happily on the same server thanks to this setup and I (and a few clients) couldn’t be happier.

Here we go, from scratch. I’ll give a simple sample scenario to make things easier.

You have one JBoss server running on your machine. You have two applications running under JBoss:

1. widgets.war
2. thingamabobs.war

You also have registered two domain names:

1. widgets.biz
2. thingamabobs.biz

You also have set up your DNS to have both domain names point to your server.

How do you get widgets.biz to point to widgets.war and thingamabobs.biz to point to thingamabobs.war? Let’s assume that you have widgets.war mapped as the root application and thingsmabobs.war mapped as thingamabobs.

widgets.war jboss-web.xml
———————————–

<jboss-web>
   <context-root>/</context-root>
</jboss-web>

thingamabobs.war jboss-web.xml
———————————–

<jboss-web>
   <context-root>/thingamabobs</context-root>
</jboss-web>

What you need to do is create a seperate Host configuration for the thingamabobs.war application in Tomcat’s server.xml file which is located at \jboss\server\default\deploy\jbossweb-tomcat55.sar\server.xml.

Open that file and you’ll see a Host configuration already for localhost. This is the default host meaning that all traffic directed via your web server port – which is 8080 by default, but I have mine set at 80 – will be directed to your root application. In our scenario, this is the widgets.war application.

Now let’s create a new Host designation that will direct requests for www.thingamabobs.biz to the thingamabobs.war application instead. Here’s what it would look like.

<Host name="thingies" autoDeploy="false" deployOnStartup="false" deployXML="false">
   <Alias>www.thingamabobs.biz</Alias>

   <Valve className="org.apache.catalina.valves.AccessLogValve"
         prefix="things" suffix=".log" pattern="common"
         directory="${jboss.server.home.dir}/log"/>

   <DefaultContext cookies="true" crossContext="true" override="true"/>
</Host>

The only things different about this Host entry is the name attribute and an additional Alias property. You can set the NAME attribute to whatever you like. The ALIAS property is the domain name that you want assigned to this Host designation. You can have multiple aliases per host. For example, if you want thigamabobs.widgets.biz to be redirected you could add that Alias in there as well (as long as you also set your DNS record for that domain as well).

We’re almost home and this is where the documentation wasn’t clear enough for me. The last step is to modify the jboss-web.xml file for thingamabobs.war. We’ve set up a brand new Host designation, so now thingamabobs.war can be set up as another root application, except now it sits in its own Host Space – called thingies – rather than in the one set up for localhost.

Here’s what the file should look like now.

<jboss-web>
   <context-root>/</context-root>
   <virtual-host>thingies</virtual-host>
</jboss-web>

You can see now that the new Host name we set up in Tomcat’s server.xml file – “thingies” – is the virtual host for the thingamabobs.war application, and it is now the root for that Host.

Now just restart your JBoss instance, and if your DNS changes have been made live, going to www.thingamabobs.biz will be redirected to the thingamabobs.war application, while www.widgets.biz will still be directed to the widgets.war application.

The best part is that it provides a breakdown of each memory space so that I can tweak the settings when I watch the application perform under load. Notice in the screenshot below the five green bars in the lower-right hand corner. That is each memory space (Eden Space, Survivor Space, Tenured Gen, Code Cache, and Permanent Gen) updated real time with how much allocated memory is being used.

To get your app enabled to be monitored by jconsole, though, is very arduous and time consuming. Here are the steps.

1. Add the following system properties to your JVM startup command.

2. Restart your instance.

See how hard that was? You broken a sweat yet? No? Ok well there’s more work involved. Now you have to open up a command prompt and type the command ‘jconsole’. If your JDK’s bin directory is not on your path, either add it or open your command prompt in that path.

When the console fires up, go to the remote tab and fill in your IP address and the port number that you specified above, and then click Connect. You’ll then see the summary screen shown here.

If you have broken a sweat by now, then you either need to turn the heat down or stop typing so hard. I couldn’t believe how easy it was to finally get a tool to monitor an application!

For an exhaustive review of jconsole’s features, visit Sun’s reference page