Skip to content

Archive

Category: Programming

There is not a whole lot of documentation out there on this subject out on the Web.  Nevertheless, there is one document that is available on the Jive Software community which gives a real good start.

https://community.jivesoftware.com/docs/DOC-28795

This actually is a much better document than came with the 4.0 Jive SBS Developer’s Traning Course which gave me a broken build which crashed the server when deployed.  Still, some items are left out of this document leaving.  I hope to fill the void with this document.

The first thing you need to do is to create a generic maven structured plugin – a process not covered in this document. Nevertheless, I will include the contents of my POM file here.

<?xml version=”1.0″ encoding=”UTF-8″?>
<!–
  ~  $Revision: 96475 $
  ~  $Date: 2009-11-02 16:51:02 -0800 (Mon, 02 Nov 2009) $
  ~
  ~  Copyright (C) 1999-${YEAR} Jive Software. All rights reserved.
  ~
  ~  This software is the proprietary information of Jive Software. Use is subject to license terms.
  –>
<project xmlns=”http://maven.apache.org/POM/4.0.0” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance
         xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd“>
    <!–
     These parameters were pased in via the commandline when this pom was created by the archetype.
      –>
    <modelVersion>4.0.0</modelVersion>
    <groupId>JiveWebServiceDemo</groupId>
    <artifactId>JiveWebServiceDemo</artifactId>
    <name>JiveWebServiceDemo</name>
    <version>1.0</version>
    <packaging>jar</packaging>
    <url>http://www.jivesoftware.com</url>

    <build>
        <finalName>${final.name}</finalName>
        <plugins>
            <!– For compilation–>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>2.3.2</version>
                <configuration>
                    <source>1.6</source>
                    <target>1.6</target>
                </configuration>
            </plugin>
            <!– Weave transactions into the plugin –>
            <plugin>
                <groupId>org.codehaus.mojo</groupId>
                <artifactId>aspectj-maven-plugin</artifactId>
                <version>1.3</version>
                <configuration>
                    <aspectLibraries>
                        <aspectLibrary>
                            <groupId>org.springframework</groupId>
                            <artifactId>spring-aspects</artifactId>
                        </aspectLibrary>
                    </aspectLibraries>
                    <source>1.6</source>
                </configuration>
                <executions>
                    <execution>
                        <goals>
                            <goal>compile</goal>
                        </goals>
                    </execution>
               </executions>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-assembly-plugin</artifactId>
                <version>2.2</version>
                <executions>
                    <execution>
                        <id>assembly</id>
                        <phase>package</phase>
                        <goals><goal>single</goal></goals>
                        <configuration>
                            <appendAssemblyId>false</appendAssemblyId>
                            <descriptors>
                                <descriptor>${basedir}/src/main/assembly/assembly-plugin.xml</descriptor>
                            </descriptors>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId> org.apache.maven.plugins</groupId>
                <artifactId>maven-antrun-plugin</artifactId>
                <version>1.6</version>
                <executions>
                    <execution>
                        <!– Unpackages this SBS plugin.  That way it can be used in conjunction with the -DpluginDirs= property, which
                             bypasses the standard plugin installation (which happens via the admin console), by pointing to exploded plugin jar created by this. –>
                        <id>explode-sbs-plugin</id>
                        <phase>package</phase>
                        <goals>
                            <goal>run</goal>
                        </goals>
                        <configuration>
                            <tasks>
                               <mkdir dir=”${basedir}/target/${final.name}” />
                               <unjar src=”${basedir}/target/${final.name}.jar” dest=”${basedir}/target/${final.name}” />
                            </tasks>
                        </configuration>
                    </execution>
                </executions>
            </plugin>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-source-plugin</artifactId>
                <version>2.1.2</version>
                <executions>
                    <execution>
                        <id>attach-sources</id>
                        <phase>verify</phase>
                        <goals>
                            <goal>jar</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
            <!– For unit testing –>
            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.6</version>
                <configuration>
                    <excludes>
                        <exclude>**/selenium/*Test.java</exclude>
                    </excludes>
                    <argLine>-Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=512m</argLine>
                </configuration>
            </plugin>

        </plugins>
    </build>
    <dependencies>
       <dependency>
           <groupId>com.jivesoftware</groupId>
           <artifactId>jive-sbs-public</artifactId>   
           <version>4.5.5.2</version>
           <type>jar</type>
           <scope>provided</scope>
       </dependency>
       <dependency>
           <groupId>com.jivesoftware</groupId>
           <artifactId>jive-sbs-public-all</artifactId>
           <version>4.5.5.2</version>
           <type>pom</type>
           <scope>provided</scope>
       </dependency>
       <dependency>
           <groupId>javax.servlet</groupId>
           <artifactId>servlet-api</artifactId>
           <version>2.3</version>
           <type>jar</type>
           <scope>provided</scope>
       </dependency>
       <dependency>
           <groupId>junit</groupId>
           <artifactId>junit</artifactId>
           <version>4.4</version>
           <scope>test</scope>
       </dependency>
       <dependency>
           <groupId>org.objenesis</groupId>
           <artifactId>objenesis</artifactId>
           <version>1.0</version>
           <scope>test</scope>
       </dependency>
       <dependency>
           <groupId>cglib</groupId>
           <artifactId>cglib</artifactId>
           <version>2.1</version>
           <scope>test</scope>
       </dependency>
       <dependency>
           <groupId>org.jmock</groupId>
           <artifactId>jmock-junit4</artifactId>
           <version>2.4.0</version>
           <scope>test</scope>
   </dependency>
      <dependency>
           <groupId>org.powermock</groupId>
           <artifactId>powermock-module-junit4</artifactId>
           <version>1.4.8</version>
           <scope>test</scope>
 </dependency>
 <dependency>
          <groupId>org.powermock</groupId>
          <artifactId>powermock-api-mockito</artifactId>
          <version>1.4.8</version>
          <scope>test</scope>
 </dependency>
 <dependency>
          <groupId>org.mockito</groupId>
          <artifactId>mockito-all</artifactId>
     <version>1.8.5</version>
     <scope>test</scope>
 </dependency>
 <dependency>
         <groupId>log4j</groupId>
         <artifactId>log4j</artifactId>
         <version>1.2.14</version>
    </dependency>
 <dependency>
   <groupId>org.codehaus.jra</groupId>
   <artifactId>jra</artifactId>
   <version>1.0-alpha-4</version>
    </dependency>
           
          
   </dependencies>
    <!–
     This is where you set the Jive SBS version your plugin is compiled against.
      –>
    <properties>
        <sbs.version>4.5.5.2</sbs.version>
        <final.name>${project.artifactId}-${project.version}-${sbs.version}</final.name>
        <build.number>${env.BUILD_NUMBER}</build.number>
        <build.project.name>${env.TEAMCITY_PROJECT_NAME}</build.project.name>       
    </properties>
</project> 

 

The Struts file needs not additions or changes.  The webservices do not make use of the struts.xml file.  The plugin.xml file needs to be updated as any other Jive plugin needs updated.  The schema.xml file also is not needed unless database changes are being done.

The spring.xml file does need modifications.  Here is a working spring file for this demo.

<?xml version=”1.0″ encoding=”UTF-8″?>
<beans xmlns=”http://www.springframework.org/schema/beans
       xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance
       xmlns:jaxws=”http://cxf.apache.org/jaxws
       xmlns:util=”http://www.springframework.org/schema/util
       xsi:schemaLocation=”
        http://www.springframework.org/schema/util
        http://www.springframework.org/schema/util/spring-util-2.5.xsd  
        http://www.springframework.org/schema/beans
        http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://cxf.apache.org/jaxws
        http://cxf.apache.org/schemas/jaxws.xsd“  
       default-autowire=”no” default-init-method=”init” default-destroy-method=”destroy”>
    <bean id=”demoServiceImpl”>
      <property name=”communityManager” ref=”communityManager” />
      <property name=”documentManager” ref=”documentManager” />
      <property name=”wsUtil” ref=”wsUtil” />
    </bean>
    <jaxws:endpoint id=”demoRestService”
                    address=”/rest/demoService”
                    bindingUri=”http://apache.org/cxf/binding/http“>
        <jaxws:implementor>
            <ref bean=”demoServiceImpl” />
        </jaxws:implementor>
         <jaxws:serviceFactory>
            <ref bean=”wrappedServiceFactory” />
         </jaxws:serviceFactory>
    </jaxws:endpoint>
</beans>
 
 
 
 

 

 

With this spring.xml file properly in place, now we need to create an interface and a class that will define the webservice calls.

 

 

package com.jivesoftware.community.webservices;
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.WebParam;
import org.codehaus.jra.*;
import java.util.List;
@WebService(portName=”DemoServicePort”, serviceName = “DemoService”,
 targetNamespace = “http://jivesoftware.com/clearspace/webservices“)
public interface DemoService {
 
    /**
 * http://alvjpxw05:8080/rpc/rest/demoService/GetReply
    */
 @WebMethod
 @Get
 @HttpResource(location=”/GetReply”)
 public String getMyReply();

    /**
 * Use Groovy Script to access
    */
 @WebMethod
 @Put
 @HttpResource(location=”/MyDocumentService”)
 public List<WSDocument> getMyDocumentsFromCommunity(@WebParam(name = “community_id”)int community_id);
}

 

 

 

 

And here is the class which implements the interface.

package com.jivesoftware.community.webservices;

import javax.jws.WebParam;
import javax.jws.WebService;
import javax.jws.WebMethod;
import javax.jws.soap.SOAPBinding;
import org.apache.log4j.LogManager;
import org.apache.log4j.Logger;
import org.codehaus.jra.Get;
import org.codehaus.jra.HttpResource;

import java.util.*;

import com.jivesoftware.community.*;
import com.jivesoftware.base.User;
import com.jivesoftware.community.webservices.server.WSUtil;
import com.jivesoftware.community.proxy.DocumentProxy;
import static com.jivesoftware.community.renderer.impl.v2.JAXPUtils.toXmlString;
import com.jivesoftware.util.StringUtils;
import com.jivesoftware.community.renderer.impl.v2.JAXPUtils;
@WebService(portName=”DemoService”, serviceName = “DemoService”, targetNamespace = “http://jivesoftware.com/clearspace/webservices“)
@SOAPBinding(style = SOAPBinding.Style.RPC, use = SOAPBinding.Use.LITERAL, parameterStyle = SOAPBinding.ParameterStyle.WRAPPED)
public class DemoServiceImpl implements DemoService {
  
    private static final Logger log = LogManager.getLogger(DemoServiceImpl.class);
    private CommunityManager communityManager;
    private DocumentManager documentManager;
    private WSUtil wsUtil;

 
    @WebMethod
    public String getMyReply() {
     return “My answers are limited, you must ask the right question.”;
    }

   
 @WebMethod
    public List<WSDocument> getMyDocumentsFromCommunity(@WebParam(name = “community_id”)int community_id) {
       List<WSDocument> list = new Vector<WSDocument>();
       Community community = null;
       try {
          community =  communityManager.getCommunity(community_id);
       }catch (Exception e)
       {
          log.info(e);  
       }
    
       if(community!=null){
         for (Document d :  documentManager.getDocuments(community)) {
            DocumentType dt = d.getDocumentType();
            DocumentProxy dp = (DocumentProxy)d;
            DocumentAttributes attributes = dp.getDocumentAttributes();
            boolean isPublished = attributes.isPublished();
            if(isPublished)
            { 
               list.add(wsUtil.convert(d));
            }
         }
      }
      return list; 
   }

   public void setCommunityManager(CommunityManager communityManager) {
      this.communityManager = communityManager;
   }

   public void setDocumentManager(DocumentManager documentManager) {
      this.documentManager = documentManager;
   }

   public void setWsUtil(WSUtil wsUtil) {
      this.wsUtil = wsUtil;
   }
}

Now compile the plugin and install it into Jive.

To see that the webservice exists, go to the following URL.

There is a URL to know if the webservice exists.

You can use this as a url for the first method which uses GET.
http://myjivesbsserver/rpc/rest/demoService/GetReply

You can use a groovy script to access the second one using the PUT method.

I recently had the task of creating a webservice in Java. I was disappointed at how difficult it was and how incomplete and error prone the available documentation is. Creating a webservice in Java is not a trivial exercise. There are a lot of little steps. Miss one and it does not work.

Here are a couple of URLs that I found useful:
http://ws.apache.org/axis/java/user-guide.html

http://axis.apache.org/axis2/java/core/docs/pojoguide.html

I will now try to explain the greater concepts and give adequate details for you to get it to work.

Proper Setup on Tomcat
Webservices do not run as part of the rest of your web application. They run in thier own servlet space. You will be able to use all of the libraries in your base application and I will later explain how to do this.

You need to download AXIS which after being unzipped gives you your own webapps directory with its own WEB-INF directory. Go ahead and take the time to set this up in Maven so that you can easily compile your war file.  You have to use the WEB-INF directory that comes with the AXIS download.

In my application, I have a war file for ROOT called ROOT.war, and a war file for webservices called axis.war.

Here is my pom.xml file for convenient compilation using maven including all of the dependencies needed for the webservice.
<code><project xmlns=”http://maven.apache.org/POM/4.0.0” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance” xsi:schemaLocation=”http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd“>
<modelVersion>4.0.0</modelVersion>
<groupId>WebServices</groupId>
<artifactId>WebServices</artifactId>
<version>1.0.0</version>
<packaging>war</packaging>
<name>WebServices</name>
<build>

<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>2.1</version>
<configuration> <source>1.6</source> <target>1.6</target> </configuration>
</plugin>
</plugins>
</build>

<dependencies>
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.3</version>
<type>jar</type>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>log4j</groupId>
<artifactId>log4j</artifactId>
<version>1.2.14</version>
</dependency>
<dependency>
<groupId>com.opensymphony</groupId>
<artifactId>xwork-core</artifactId>
<version>2.1.6</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>ognl</groupId>
<artifactId>ognl</artifactId>
<version>2.7.3</version>
<type>jar</type>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>freemarker</groupId>
<artifactId>freemarker</artifactId>
<version>2.3.9</version>
<scope>compile</scope>
</dependency>
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<version>4.8.1</version>
</dependency>
<dependency>
<groupId>commons-fileupload</groupId>
<artifactId>commons-fileupload</artifactId>
<version>1.2.1</version>
</dependency>
<dependency>
<groupId>commons-io</groupId>
<artifactId>commons-io</artifactId>
<version>20030203.000550</version>
</dependency>
<dependency>
<groupId>org.apache.struts</groupId>
<artifactId>struts2-core</artifactId>
<version>2.1.8.1</version>
</dependency>
<dependency>
<groupId>commons-httpclient</groupId>
<artifactId>commons-httpclient</artifactId>
<version>3.1</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring</artifactId>
<version>2.5.5</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-webmvc-struts</artifactId>
<version>2.5.5</version>
</dependency>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-struts</artifactId>
<version> 3.0.5.RELEASE</version>
</dependency>

<dependency>
<groupId>javax.persistence</groupId>
<artifactId>persistence-api</artifactId>
<version>1.0</version>
</dependency>
<dependency>
<groupId>wsdl4j</groupId>
<artifactId>wsdl4j</artifactId>
<version>1.5.1</version>
</dependency>

<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.ws.commons.axiom</groupId>
<artifactId>axiom-impl</artifactId>
<version>1.2.9</version>
</dependency>
<dependency>
<groupId>org.apache.ws.commons.axiom</groupId>
<artifactId>axiom-api</artifactId>
<version>1.2.9</version>
</dependency>
<dependency>
<groupId>org.apache.neethi</groupId>
<artifactId>neethi</artifactId>
<version>2.0.4</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-adb</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-adb-codegen</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-ant-plugin</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-clustering</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-codegen</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-corba</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-fastinfoset</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-jaxbri</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-jaxws</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-jibx</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-json</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-xmlbeans</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>org.apache.axis2</groupId>
<artifactId>axis2-mtompolicy</artifactId>
<version>1.5.5</version>
</dependency>
<dependency>
<groupId>com.sun.xml.ws</groupId>
<artifactId>jaxws-rt</artifactId>
<version>2.1.4</version>
</dependency>
<dependency>
<groupId>com.sun</groupId>
<artifactId>tools</artifactId>
<version>1.5.0</version>
<scope>system</scope>
<systemPath>${java.home}/../lib/tools.jar</systemPath>
</dependency>
</dependencies>
</project>

Go ahead and build your war file using the mvn install command.  If you are not familiar with this, then spend time learning Maven from the offical Maven Apache site.

Now, go ahead and deploy it on Tomcat so that you can see that your website works at http://mydomain.com/axis/. You should see a nice splash page that looks like this.

axis-home-page

Create the POJO
This apache website at http://axis.apache.org/axis2/java/core/docs/pojoguide.html gives a framework of a webservice with the Weather webservice. I found that certain dependencies did not work so I could not get the example working.  Nevertheless, the concepts of the framework are helpful.

Create your service classes such as WeatherService.java, CalculatorService, or any other service or services you need. These classes becomes the basis of your webservices which will eventually be called with URLs such as http://mydomain.com/axis/services/WeatherService/, or http://mydomain.com/axis/services/CalculatorService.

These service classes are to be basic classes.  They can be placed in your normal package structure such as in the com.trisummit.webservices package.  You can add all sorts of dependencies for all available libraries such as logging, jdbc abstraction layers, libraries in your base application, etc.  Your class will need to have a parameterless constructor.  Your class will have public and private methods. Public methods will be exposed in the webservice.  Private methods will not be exposed in your webservice but are available for your programming pleasure to assist in the logic of your public methods.  Your methods can take in whatever parameters you need and return whatever values or classes you want them to return - even container classes of your own creation or just plain Strings.  If you want binary content to be part of your return, return a byte array.

Prepare the WEB-INF Directory

In the maven /src/main/webapp/WEB-INF directory, add a directory called services and add the package directory structure of your Service classes.

WEB-INF/services/WeatherService/net/trisummit/webservices/
WEB-INF/services/CalculatorService/net/trisummit/webservices/

You also need to add a META-INF directory with an appropriate services.xml file for each webservice.

WEB-INF/services/WeatherService/META-INF/
WEB-INF/services/CalculatorService/META-INF/

Here is an example of the services.xml file.

<service name=”CalculatorService” scope=”application”>
<description>
Authentication POJO Service
</description>
<messageReceivers>
<messageReceiver   mep=”http://www.w3.org/2004/08/wsdl/in-only” />
<messageReceiver   mep=”http://www.w3.org/2004/08/wsdl/in-out“  />
</messageReceivers>
<parameter name=”ServiceClass”>
net.trisummit.webservices.CalculatorService
</parameter>
</service>

Now create the deploy.wsdd file in the services directory at

WEB-INF/services/deploy.wsdd

Here is a sample:

<deployment xmlns=”http://xml.apache.org/axis/wsdd/” xmlns:java=”http://xml.apache.org/axis/wsdd/providers/java“>
<service name=”WeatherService” provider=”java:RPC”>
<parameter name=”className” value=”net.trisummit.webservices.WeatherService”/>
<parameter name=”allowedMethods” value=”*”/>
</service>
<service name=”CalculatorService” provider=”java:RPC”>
<parameter name=”className” value=”net.trisummit.webservices.CalculatorService”/>
<parameter name=”allowedMethods” value=”*”/>
</service>
</deployment>

Now you can go ahead and compile the application using the mvn install command.

Restructure and Rebuild

Now you have two more tasks to do before you can send it to the server.  And I already know what your are thinking when you read this…You have got to be kidding.   You need to place the compiled webservice classes into the target  sections of your maven build.

myapplication/target/mywebservices-app-name/WEB-INF/services/net/trisummit/webservices/WeatherService.class

myapplication/target/mywebservices-app-name/WEB-INF/services/net/trisummit/webservices/CalculatorService.class

Next, you need to take the classes of your dependencies, zip them up, change the extension of the zip file to jar, and copy this jar file in the the target lib directory.

myapplication/target/mywebservices-app-name/WEB-INF/classes/ZIP UP EVERYTHING AFTER THIS AND RENAME TO BE A JAR FILE.

Move your new jar file into the lib directory at myapplication/target/mywebservices-app-name/WEB-INF/lib/

Now rebuild your application again using the mvn install command to create your war file and name your war file axis.war.

Now drop your war file on Tomcat and restart your Tomcat App Server.

Start your Webservice

Just putting this on the webserver does not activate the webservice.  You have one more very unusual step to take.  You have to explicitely start the webservice with a complex command line call which has a significant number of java dependencies.

Create a directory for your webservices dependency jar files – not your webservices, but the dependencies needed for running any and all webservices.

D:\axis\lib

Drop in all of your axis related jar files – in fact, add all jar files related to your project including all dependencies.  Then from the command line, execute this command from your services directory, ie D:\Tomcat 7.0\webapps\axis\WEB-INF\services\

java -cp D:\axis\lib\axis2-1.5.5.jar;D:\axis\lib\axis.jar;D:\axis\lib\axis2-saaj-1.5.5.jar;D:\axis\lib\commons-discovery.jar;D:\axis\lib\commons-logging-1.1.jar;D:\axis\lib\jaxrpc.jar;D:\axis\lib\log4j-1.2.14.jar;D:\axis\lib\xerces.jar;D:\axis\lib\xercesImpl.jar;D:\axis\lib\xml-apis.jar;D:\axis\lib\log4j.properties;  org.apache.axis.client.AdminClient -lhttp://localhost:8080/axis/services/AdminService deploy.wsdd

If you get this message – <Admin>Done processing</Admin> – you did well.

Now test your URLs to see that everything works right.  Go to the axis main page and you should see and be able to test everything you need including links to the wsdl of your webservices.

http://mydomain.com/axis/

I used the wsdl2java functionality build the necessary classes for communication with a particular webservice. However, when the webservice stub was called to perform the communication, I was given this error.

java.lang.reflect.InvocationTargetException – full stack trace given below.

In digging through trying to determine the cause of the problem, I recalled having something like this happen 2 years ago and what I did to fix the problem. It had to do with not having all of the latest jar files installed to match the AXIS jar files used in the generation of the wsdl2java generated code. In may latest encounter of this problem, it had to do with not having the latest version of the AXIOM jar file.

I had to change my maven POM file from this:



org.apache.ws.commons.axiom
axiom-api
1.2.8

to
org.apache.ws.commons.axiom
axiom-api
1.2.9

Here is the full stack trace I encountered.

java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:441)
at com.opensymphony.xwork2.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:280)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:243)
at com.opensymphony.xwork2.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:165)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:252)
at org.apache.struts2.interceptor.validation.AnnotationValidationInterceptor.doIntercept(AnnotationValidationInterceptor.java:68)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.ConversionErrorInterceptor.intercept(ConversionErrorInterceptor.java:122)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.ParametersInterceptor.doIntercept(ParametersInterceptor.java:195)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.StaticParametersInterceptor.intercept(StaticParametersInterceptor.java:179)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at org.apache.struts2.interceptor.MultiselectInterceptor.intercept(MultiselectInterceptor.java:75)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at org.apache.struts2.interceptor.CheckboxInterceptor.intercept(CheckboxInterceptor.java:94)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at org.apache.struts2.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:235)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.ModelDrivenInterceptor.intercept(ModelDrivenInterceptor.java:89)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.ScopedModelDrivenInterceptor.intercept(ScopedModelDrivenInterceptor.java:130)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at org.apache.struts2.interceptor.debugging.DebuggingInterceptor.intercept(DebuggingInterceptor.java:267)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.ChainingInterceptor.intercept(ChainingInterceptor.java:126)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.PrepareInterceptor.doIntercept(PrepareInterceptor.java:138)
at com.opensymphony.xwork2.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:87)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.I18nInterceptor.intercept(I18nInterceptor.java:165)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at org.apache.struts2.interceptor.ServletConfigInterceptor.intercept(ServletConfigInterceptor.java:164)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.AliasInterceptor.intercept(AliasInterceptor.java:179)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at com.opensymphony.xwork2.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:176)
at com.opensymphony.xwork2.DefaultActionInvocation.invoke(DefaultActionInvocation.java:237)
at org.apache.struts2.impl.StrutsActionProxy.execute(StrutsActionProxy.java:52)
at org.apache.struts2.dispatcher.Dispatcher.serviceAction(Dispatcher.java:488)
at org.apache.struts2.dispatcher.ng.ExecuteOperations.executeAction(ExecuteOperations.java:77)
at org.apache.struts2.dispatcher.ng.filter.StrutsPrepareAndExecuteFilter.doFilter(StrutsPrepareAndExecuteFilter.java:91)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:185)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:151)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)
at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:929)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:405)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:269)
at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:515)
at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:300)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: java.lang.NoClassDefFoundError: org/apache/axiom/om/util/StAXParserConfiguration
at org.apache.axis2.builder.SOAPBuilder.processDocument(SOAPBuilder.java:64)
at org.apache.axis2.transport.TransportUtils.createDocumentElement(TransportUtils.java:197)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:145)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:108)
at org.apache.axis2.transport.TransportUtils.createSOAPMessage(TransportUtils.java:67)
at org.apache.axis2.description.OutInAxisOperationClient.handleResponse(OutInAxisOperation.java:354)
at org.apache.axis2.description.OutInAxisOperationClient.send(OutInAxisOperation.java:417)
at org.apache.axis2.description.OutInAxisOperationClient.executeImpl(OutInAxisOperation.java:229)
at org.apache.axis2.client.OperationClient.execute(OperationClient.java:165)
at com.quest.QuestSSOServicesSSOServiceStub.getUser(QuestSSOServicesSSOServiceStub.java:5299)
at com.quest.action.RetrieveWebserviceCall.authenticateWithAWS(RetrieveWebserviceCall.java:240)
at com.quest.action.RetrieveWebserviceCall.execute(RetrieveWebserviceCall.java:134)
… 69 more
Caused by: java.lang.ClassNotFoundException: org.apache.axiom.om.util.StAXParserConfiguration
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1678)
at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1523)
… 81 more

The requirement to move content from an external system into Jive SBS is very common. You have discussion forum content and blog content in whatever system (Wordpress, Jive Integrated, Teligent, Dot Net Nuke, PHPBB, etc.) and you need to get it into Jive SBS. And then complicating the situation further is that Jive SBS may be in a hosted environment where firewalls will prevent any form of external database connections.

While working with Quest Software, I started the process of doing migrations about one year ago. Prior to speaking with Jive Professional Services, we looked mostly at three options.

1. Use webservices such as REST and SOAP to push in the content.

2. Transfer the content from the originating database into XML. Place the files in a location accessible to Jive SBS such as an external webserver. Then transfer the content in using a custom plugin to parse the XML and use POJOs to push in content into Jive SBS using the various managers made accessible in Jive.

3. Use a plugin and establish a JDBC connection from the old system and the new Jive SBS database. Use application logic in the plugin to prepare the content for entry into the Jive SBS database.

My first experiments were with option 1. There were questions of whether or not one administrator could push in content for any user. It did appear to work successfully – and that was without rewriting an authentication filter for the webservices. Nevertheless, the slowness of the webservices appeared to be a serious issue. Each call to the REST api took more than a second, and if we were to migrate a very large forum, that would mean the process may need to run for a very long time. It also had the problem of sending out emails to subscribers. Once having an opportunity to discuss migrations with Jive Professional Services, we all agreed that this was not the best approach.

Option 3 was immediately tossed out as an option as Jive SBS was in a hosted environment and firewalls prevented any sort of JDBC connections between the two systems. Furthermore, it is not recommended to do straight dumps into the database of Jive SBS as certain meta-data may not be properly pushed in and the content may not be checked for validity and could cause serious issues in the application.

Option 2 was the perfect solution and in my assessment, even the best solution even when the environment is not hosted. By exporting content into XML, content could be safely and easily smoothed prior to the push. By using the managers made available by jive accessible in doing plugin development, all data can be pushed in using the same methods as used by someone posting direct in the application.

I proceeded and wrote a migration tool to push in wordpress blog content. I completed the blog migration tool and successfully used the tool. Afterwards, I was 2/3 complete with adding functionality to push in discussion forums when a decision from management was made to engage Jive Professional Services to build a reusable utility for migrating discussion forums. Since we had about 30 forums to migrate, management felt the engagement was justified. The cost was $60,000. I frankly opposed the expense as being unnecessary.

I will now proceed to describe both tools and the differences between the two tools.

Tool 1 (Brian’s Solution):
A console java application is used to push all content into multiple files.

ids.html – a plain text html file with a line by line list of all thread ids from the external system was created as a master file.
So for this simple example, the ids.html file would simply look like:

24
25
29

Then (a thread id).xml file for each thread (or blog post id) would be created to hold the content of each thread or blog post including comments or follow-on treaded discussion messages for the thread.

Example file names would be:

24.xml
25.xml
29.xml

By using this approach there would never be any scalability issues as no XML file would ever be too large for the plugin to handle.

The files would all get placed onto a webserver where a plugin on JiveSBS could reach into them over the web and stream in the content.

The plugin would grab the accessible managers that are available to all plugin developers and push in the content one message at a time.

Images and attachments would be streamed in. This is done by parsing out source information in the content and reading in the binary stream over the internet and saving it to the system.

A dictionary is established to record all operations. The dictionary is used to create 301 redirects after the fact in an external redirects server. The application could have gone one step further with the dictionary and used to rollback the content in the event of a failure anywhere in the process.

There was one downside to the application which I never resolved was that the smtp mail server would need to be renamed to a non-existent location while the process ran. Not doing so would result in spamming the end users with migration related emails. On the down side, this also meant that users would not receive emails during the time of the migration. Otherwise, the process worked smoothly and quickly. Migrations could be done in quick bursts preferably during non peak hours and not take much time at all.

Tool 2 (Jive PS Solution):
Jive Professional Services put this application together using preexisting code long standing on the Jive team. Thier solution used a groovy script to generate xml files that were placed in a handful of subfolders.

/users/users.xml
/community/community.xml
/msg/msg.xml
/msgcontent/msgcontent.xml
/attachments/ – a list of xml files specially named including the messageid with the binary value of the attachment stored in the <data> section of the xml.
/images/ – a list of xml files specially named including the messageid with the binary value of the image stored in the <data> section of the xml.

The files would need to be placed physically on the server with Jive on all nodes of the operating systems, and application logic from the plugin would pull in the content and push it in. The dictionary was used also in this process for the later construction of 301 redirects.

There were some major “gotcha’s” with the application.

1. Once the plugin is installed, the entire Jive SBS system is placed in read only mode resulting in downtime for the application – something that I believe is very undesireable for an external facing enterprise application. A maintenance page is best put up during this time to avoid end user confusion. Without the maintenance page, users can see content but when they attempt to post content, they recieve a frustrating error message.

2. Each individual subspace has to run as a separate batch. Following the run, the application is required to go through the app restart process which takes ten minutes each time in the hosted environment.

3. Jive Hosting support is required during the migration times for placing files on the Jive server.

4. The application is very finiky and easily breaks over unexpected and difficult to troubleshoot issues usually regarding attachments.

With these constraints, all migrations must be done on Saturdays. And some migrations may take even 8 hours to complete depending on how many subspaces are touched in the process.

My end assessment regarding the Jive migration tool from Jive Professional Services is as follows:
If you are okay with spending $60,000 for a tool that requires significant amounts of down time – then go to Jive Professional Services for your migration tool. The tool will work for you if you do.

Optionally, you can spend significantly less money, and I could build the tool for you which is equally as effective and requires no more downtime than one or two cycles of application restart for plugin installation and plugin unistallation when complete.

So there you have it – the big picture of two workable systems used to migrate content into Jive SBS.

This is an easy one. If you need to remove all of the tabs in your Mediawik Wiki site, just go into the css page and modify it as follows:

.pBody {
font-size: 95%;
background-color: white;
color: black;
border-collapse: collapse;
border: 1px solid #aaa;
padding: 0 .8em .3em .5em;
display:none;
}

Of course, it is the display:none; that removes them from the display. They are still there, you just can’t see them anymore.

I am using Maven to do my builds for Jive SBS; however, I needed to add the Axis2 jar files to commucate with the Single Sign-on Server. I added all that were needed to do the perform the wsdl2java functionality. Here are the dependencies that I added to the pom.xml to grab all of the jar files.

Please substitute your version with the version number I have included in the POM.


<!--Begin added for Axis -->
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-adb</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-adb-codegen</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-ant-plugin</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-clustering</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-codegen</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-corba</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-fastinfoset</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-jaxbri</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-jaxws</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-jibx</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-json</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-xmlbeans</artifactId> 
  <version>1.5.1</version> 
</dependency>
<dependency>
  <groupId>org.apache.axis2</groupId> 
  <artifactId>axis2-mtompolicy</artifactId> 
  <version>1.5.1</version> 
</dependency>
<!--End added for Axis -->

Maven is a build tool for Java based web apps – plain and simple.

Before learning about Maven I did my builds using Ant. And when it came to building webapps, I was always frustrated about getting things in source control in such a way that all of the developers could build their apps no matter what IDE they were using. For example, you get some developers using Eclipse and others using Net Beans, and the different IDEs wants things set up their own way.

By using Maven (instead of ANT or batch files), you do your builds independent of the IDE using the command line; nevertheless, the build can still be done using the IDE if you choose to do so. However, by using the command line, you ensure that your IDE isn’t playing tricks on you.

Follow the instructions of the documentation for getting Maven installed on your development machine.

Next run the command from the command line:

mvn archetype:generate -Dfilter=org.apache:struts

This alone will result in the generation of a basic Hello World generic struts application to get you started.

You will be able to further build out your application using the directory structure following the instructions on Maven Directory Structure.

/
+- src/
|  +- main/
|  |  +- java/
|  |  |  +- ...
|  |  +- resources/
|  |     +- ...
|  +- test/
|  |  +- java/
|  |  |  +- ...
|  |  +- resources/
|  |     +- ...
|  +- site/
|     +- xdoc/
|        +- ...
+- target/
|  +- ...
+- project.xml
+- README.txt
+- LICENSE.txt

Directory 1:
src -> main -> java
In this directory, place your java class files. In the basic struts template, you will have the example package stored here.

src -> main -> java -> example -> ExampleSupport.java
src -> main -> java -> example -> Login.java
src -> main -> java -> example -> HelloWorlds.java

Directory 2:
src -> main -> resources
In this directory, place your resource files.

src -> main -> resources -> example.xml
src -> main -> resources -> struts.xml
src -> main -> resources -> NOTICE.txt
src -> main -> resources -> LICENSE.txt
src -> main -> resources -> example -> Login-validation.xml
src -> main -> resources -> example -> package.properties
src -> main -> resources -> example -> package_es.properties

Directory 3
src -> main -> webapp
Location for the jsp files

src -> main -> webapp -> example -> HelloWorld.jsp
src -> main -> webapp -> example -> Login.jsp
src -> main -> webapp -> example -> Menu.jsp
src -> main -> webapp -> example -> Missing.jsp
src -> main -> webapp -> example -> Register.jsp
src -> main -> webapp -> example -> Welcome.jsp
src -> main -> webapp -> WEB-INF -> web.xml

Directory 4
Now set up a place for your unit tests. This is actually not part of the basic struts application but could be if test cases are added by the developers.

src -> test -> java -> example -> ExampleSupportTest.java
src -> test -> java -> example -> LoginTest.java
src -> test -> java -> example -> HelloWorldsTest.java

POM File
A lot of additional configurations are placed in the POM file. Follow the Maven documentation for specifics. However, for beginners, you will want to use Eclipse or some other tool to build your base pom.xml file held at the root to the app. I added the jar files used by struts in the maven dependencies sections and it automatically filled out the appropriate sections of the POM.xml file.

My beginning POM file looks like this.

  4.0.0
  trisummit
  trisummit
  0.0.1-SNAPSHOT
war
  trisummit

    Jira
    http://applications.trisummit.net/jira/

    Bamboo
    http://applications.trisummit.net/bamboo/

   Brian Nettles
      svn://trisummit.net:3690/trisummit/

    Trismmit Technologies
    http://trisummit.net

          org.apache.maven.plugins
         maven-compiler-plugin
         2.1
                  1.6 1.6 

      com.opensymphony
      xwork-core
      2.1.6
      jar
      compile

      ognl
      ognl
      2.7.3
      jar
      compile

      freemarker
      freemarker
      2.3.9
      compile

                junit
                junit
                4.8.1

      commons-fileupload
      commons-fileupload
      1.2.1

      commons-io
      commons-io
      20030203.000550

      org.apache.struts
      struts2-core
      2.1.8.1

        ip-97-74-115-5.ip.secureserver.net
        ip-97-74-115-5.ip.secureserver.net-releases
        http://applications.trisummit.net/artifactory/libs-releases-local

Now open the command line and from the root of the application, type:

mvn compile

This will compile your application

Now type

mvn war:war

This will create your war file complete with the jar files included and place it in the target directory. Your jar files are managed from the repositories and not stored in your source control.

Now go deploy your war file on Tomcat.

This should be a very simple problem, but finding the solution does not always jump out at you based on the tutorials out there.

When doing a JDBC connection for SQL Server you may have the following line of code:


String sqlServerConnectionString = "jdbc:sqlserver://10.0.0.233:1433; 
databaseName=mydatabasename;user=sa;password=mypassword";
Connection con = DriverManager.getConnection(sqlServerConnectionString);

Then you go to run it and run into the following:
java.sql.SQLException: No suitable driver

Actually, the problem is very simple. Earlier on, you may have forgotten this:


try
{
    Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
} catch (ClassNotFoundException e)
{
    System.out.println(e);
}
try
{
    Class.forName("com.microsoft.sqlserver.jdbc.SQLServerDriver");
} catch (ClassNotFoundException e)
{
    System.out.println(e);
}

//Now run the code you originally ran:
String sqlServerConnectionString = "jdbc:sqlserver://10.0.0.233:1433;
databaseName=mydatabasename;user=sa;password=mypassword";
Connection con = DriverManager.getConnection(sqlServerConnectionString);

That should either solve your problem or at least give you a hint of what to do next.

Here it is 2009 and we have finally confronted this problem. We had some users trying to upload Office 2007 files into the Jive application and the uploads were not sticking. After researching the problem, I determined the problem had to do with the content types being named something larger than the varchar2(50) in the database was able to handle so I had to increase the size of the field. In doing the research, I came across a good posting which lists all of the content-types used by Microsoft Office 2007 applications. This is the URL:

http://www.bram.us/2007/05/25/office-2007-mime-types-for-iis/

So if you need to know all of the content-types for some odd reason, there you go.

This one stumped me for some time. I was trying to simply install the Sun version of the JDK onto a VMWare instance of Red Hat ES4 and I kept coming upon this error. I initially figured it must be a dependency issue and I tried all sorts of things to get it to work. Later in the day, I tried downloading the JDK without the Enterprise Edition version of Java. This time when I ran the executable to install the JDK it worked perfectly. Evidently, the JDK with the EE attached does not want to install on Red Hat ES4. Hopefully, you won’t need it and the JDK without the EE serves you fine. What a nasty hidden bug.