As part of the Service Oriented Architecture (SOA) that I’m implementing at work, I wanted to investigate setting up a private UDDI so that developers across the country could publish and find any core services. The first hit on Google when searching on the subject is Apache jUDDI, so I started to investigate that (since I love ASF). First thing I notice is that it’s a WAR file, but our platform here is based on ColdFusion, and the standalone installation used in the company couldn’t support implementing it. First thing that pops into my head, of course, is “Let’s look at my old friend, JBoss”.

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.

I won’t go heavily into the reasons why you would want to use Apache as your proxy to JBoss, but I’ll give some popular ones here so you can see if any of the areas interest you.

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.

Been putting this post off for a long time. Well, not exactly putting it off, but since all my hardware and backups were still in Pittsburgh, I didn’t have my blog up, so my hands were tied.

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.

Even though it was glossed over during Ben’s presentation at the Nashville CFUG, I was very pleased to see that Adobe will now be supporting JBoss as an application server for ColdFusion.  I spent the last 2.5 years figuring out the best ways to get ColdFusion apps to run on JBoss AS and I’ve found it far more flexible and more easily configurable than running on the native JRun AS – I’m also not an expert on JRun, so I may be a bit biased.

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

Tonight I’m attending my first Nashville CFUG meeting, and what a fortuitous time to move to Nashville. Ben Forta, a product evangelist for ColdFusion, is coming in for the meeting to do a presentation on the next release of the ColdFusion line – called Scorpio.

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