Creating JAX-WS webservice using Service Data Objects (SDO) instead of JAXB-bound POJOs

If you need to invoke a logic using Service Data Objects (SDOs) from a JAX-WS webservice under Websphere 7 without the SCA Feature Pack, it is possible to do it similarly to the old approach of generating a JAX-RPC webservice from a WSDL with an SDO facade (actually building on it).

The steps are:

1. Use RAD to generate a JAX-RPC webservice from a WSDL with an SDO facade.
2. Implement a JAX-WS webservice accessing directly its input as XML data (i.e. implement is as a WebServiceProvider for message payload)
   • Use Transformer and StreamSource/Result to convert from/to String containing XML
3. Copy the SDO-related classes from the JAX-RPC webservice to the JAX-WS one, exclude just the JAX-RPC webservice interface and implementation
4. Adjust the generated EMFSOAPElementUtil – change (de)serialize methods to expect/produce a String instead of SOAPElement
5. Put it all together in the WS implementation class created in #2
6. Finishing touches – add conversion of org.eclipse.emf.ecore.xml.type.internal.XMLCalendar to javax.xml.datatype.XMLGregorianCalendar

Tip: Multiple webservice implementation classes available at the same time under WAS7

If you want to experiment with webservices by providing several alternative implementations of the same webservice (represented by the <wsdl:service> element), each having its own URL, and you’re using Websphere 7 and JAX-WS, then:

1. For each alternative implementation, add <wsdl:port> with a unique name under the <wsdl:service> element in the WSDL file. Beware: This is essential to enable multiple implementations.
2. For each alternative implementation, define a servlet and servlet mapping in web.xml like this:

   <servlet id="$IMPLEMENTATION_CLASS_NAME$">
   		<servlet-name>$IMPLEMENTATION_CLASS_NAME$</servlet-name>
   		<servlet-class>$IMPLEMENTATION_CLASS_NAME$</servlet-class>
   		<load-on-startup>1</load-on-startup>
   	</servlet>
   	<servlet-mapping>
   		<servlet-name>$IMPLEMENTATION_CLASS_NAME$</servlet-name>
   		<url-pattern>/$DESIRED_UNIQUE_URL$</url-pattern>
   	</servlet-mapping>

3. Create the implementations – likely as POJOs denoted with the @WebService annotation – and set the corresponding portName for each of them (@WebService(portName=”<unique port name>”, …))
4. Deploy and use

File-based User Authentication under WebSphere 6

When developing a web application for the WebSphere Application Server you sometimes need to enable security because the application expects HttpServletRequest.getUserPrincipal() to be non-null. While in the production environment you will likely configure WAS to delegate the authentication to an LDAP server, during development you would likely prefer to use a simpler method that doesn’t depend on an external service (and thus functions even when offline) and doesn’t force you to use some real confidential credentials.

The solution is to use the sample custom file-based user registry, which is shipped with WebSphere 6.x and which enables you to define your groups and users in two files. The steps to configure it are quite simple.

1. Open the WAS administration console

2. Configure the custom user registry under Security – Global security – Custom:
2.a Define basic properties:

2.b Define location of the user and group files:

3. Enable security and select the configured custom user registry:

4. ? Add self to the allowed console users (I’m not sure whether this is necessary):

5. Create the users and groups files defined in the step 2.b:
jh_user.props:
# jh_user.props file (user name, password, unique user id, group id, user label)
jholy@at.ibm.com:password:123:567:Jakub Holy

jh_group.props:
# jh_group.props file (group name, unique group id, comma-separated member list,
# a label)
AutomatedBridge_admins:567:jholy@at.ibm.com:AB Admins

6. Restart WAS

7. Log in to the admin console with the credentials you’ve configured (id jholy@at.ibm.com above).

WAS 6.0 ant tasks: Install an app with an external Ant

There are special ant taks to install/start/.. an application to a
WebSphere App Server 6.0. It’s easy to run them with WAS’s ant script
(<was>/bin/was_ant.bat) but not so trivial to get them working with an
external ant, which may be necessary because WAS has an old version of ant.
So lets see how to do it.

The important points are:

• Use IBM JRE
  (or use Sun JRE but setup the environment first by running
  <WAS>/profiles/<your profile>/bin/setupCmdLine in the same
  shell/command line you’ll use to start the ant)
• Set the environmental variable
  ANT_OPTS=”-Duser.install.root=<WAS>/profiles/<your profile>”
  Strangely, it seems that no other way of passing it to the was ant tasks
  works.
• Tell Ant where to look for the libraries it needs:
  1. Ant’s own lib/ dir – it must be specified and it must come first
     not to use WAS’ ant
  2. A directory with wsanttasks.jar itself and other jars it depends
     upon (perhaps only wsprofile.jar) – you may specify
     <WAS>/lib
  3. If you want to use scripts in jython, you need to include also
     <WAS>/optionalLibraries

Example:

C:\> set
PATH=C:\development\servers\WebSphere6.0\AppServer\java\jre\bin;%PATH%
C:\> set
JAVA_HOME=C:\development\servers\WebSphere6.0\AppServer\java\jre
C:\> set
ANT_OPTS="-Duser.install.root=C:\development\servers\WebSphere6.0\AppServer/profiles/jh-pokusy"
C:\> c:\apache-ant-1.6.5\bin\ant -verbose -lib ..\apache-ant-1.6.5\lib
-lib c:\development\servers\WebSphere6.0\AppServer\lib -lib
c:\development\servers\WebSphere6.0\AppServer\optionalLibraries -f
myBuild.xml myBuildTarget

myBuild.xml contains:

    <property name="myWas.root"     value="c:\development\servers\WebSphere6.0\AppServer" />

    <taskdef name="wsAdmin"            classname="com.ibm.websphere.ant.tasks.WsAdmin" />
    <taskdef name="wsInstallApp" classname="com.ibm.websphere.ant.tasks.InstallApplication" />
    <taskdef name="wsStartApp" classname="com.ibm.websphere.ant.tasks.StartApplication" />
    <taskdef name="wsUninstallApp" classname="com.ibm.websphere.ant.tasks.UninstallApplication"/>

    <target name="installStartUninstall" depends="_installEarApp,_startEarApp,_uninstallEarApp" />

    <target name="_installEarApp"  description="Deploy the app to WAS 6.0">
                <echo message="Going to deploy '${earToDeploy}' to the server in ${wasroot}..." />
                        <echo message="########## FIRST install ########### ${line.separator}" />
                        <wsInstallApp wasHome="${myWas.root}" conntype="SOAP"
                                      ear="c:\tmp\myApp.ear"
                                      host="localhost" port="8881"
                                      user="me" password="psw"
                                      failonerror="true"
                                      options="-appname MyAppName -verbose true -validateinstall fail -preCompileJSPs true"
                                      />
                        <!-- Note: Anttasks's wsadmin task from was 6.0.0.3 support the attr. profileName="jh-pokusy" -->

                <!-- 1. Ryn my jython script that modifies configuration of the app:
                     (todo: try the atribute: profile="${myWas.root}/bin/setupCmdLine.bat")
                -->
                <wsAdmin wasHome="${myWas.root}" conntype="SOAP" host="localhost" port="8881"
                         host="localhost" port="8881"
                         user="me" password="psw"
                         failonerror="true"
                         script="c:\tmp\configureApplication.jython"
                         lang="jython">
                               <!-- See the script for the arguments it expects -->
                                <arg value="MyAppName"/><!-- app name -->
                </wsAdmin>
        </target>

    <target name="_startEarApp" depends="" description="Start a deployed ear app on the WAS server">
            <wsStartApp wasHome="${myWas.root}" conntype="SOAP"
                        application="MyAppName"
                        host="localhost" port="8881"
                        user="me" password="psw"
                        failonerror="true"
                        />
    </target>

    <target name="_uninstallEarApp" depends="" description="Start a deployed ear app on the WAS server">
            <wsUninstallApp wasHome="${myWas.root}" conntype="SOAP"
                        application="MyAppName"
                        host="localhost" port="8881"
                        user="me" password="psw"
                        failonerror="true"
                        options="-verbose true"
                        />
    </target>

Information

• host/port for the connection method: see
  <WAS>\profiles\<profile
  name>\properties\wsadmin.properties
• paths to files (ear, script to execute) – must be absolute!!! – the was
  ant tasks change the working directory => relative paths won’t
  work

RAD, WAS 6 Test Env and J2EE security: getting rid of “No received or invocation credential exist on the thread”

Recently I started a new J2EE project that required j2ee security. Unfortunately Rational app. Developer 6 seemed to have some problems running a WAS Test Environment in this way, at least with the default setup. I encountered 2 problems:

1. RAD wasn’t able to connect to the server at all, throwing some security exceptions.
   The solution (or rather work-around) was to switch the “Server connection type..” in the server’s configuration in RAD from RMI to SOAP. It seems that RMI doesn§t support authetification.
2. After that, everything seemed to be ok, but an error was logged every few seconds with the cause “No received or invocation credential exist on the thread“. The stack trace pointed to a MBean (a part of JMX) being contacted via RMI.
   Work-around: Disable an RMIConnector for JMX in WAS Console: log in, go to
   Application servers > server1 > Administration  > Administration Services > JMX connectors
   And delete the RMIConnector – make first sure that you don’t need it.

BTW, to enable the security, I enabled it first on the server via WAS admin console and then I created a new server configuration in RAD and set it to use security.

Stack trace for issue 2:
com.ibm.ws.security.role.RoleBasedAuthorizerImpl.checkAccess(RoleBasedAuthorizerImpl.java(Compiled Code)) at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1696) at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1603) at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1533) at com.ibm.ws.management.AdminServiceImpl.preInvoke(AdminServiceImpl.java:1506) at com.ibm.ws.management.AdminServiceImpl.getAttribute(AdminServiceImpl.java:501) at com.ibm.ws.management.connector.AdminServiceDelegator.getAttribute(AdminServiceDelegator.java:99) at com.ibm.ws.management.connector.rmi.RMIConnectorService.getAttribute(RMIConnectorService.java:123) at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie.getAttribute(_RMIConnectorService_Tie.java:193) at com.ibm.ws.management.connector.rmi._RMIConnectorService_Tie._invoke(_RMIConnectorService_Tie.java:87) at com.ibm.CORBA.iiop.ServerDelegate.dispatchInvokeHandler(ServerDelegate.java:608) at com.ibm.CORBA.iiop.ServerDelegate.dispatch(ServerDelegate.java:461) at com.ibm.rmi.iiop.ORB.process(ORB.java:432) at com.ibm.CORBA.iiop.ORB.process(ORB.java:1728) at com.ibm.rmi.iiop.Connection.doWork(Connection.java:2229) at com.ibm.rmi.iiop.WorkUnitImpl.doWork(WorkUnitImpl.java:65) at com.ibm.ejs.oa.pool.PooledThread.run(ThreadPool.java:95) at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java(Compiled Code)) . 

RAD, WebSphere and changing the classloader mode

I’ve spent hours trying to change the classloader mode for a .war include in an .ear application and deployed to the WebSphere Portal v5.1 Test Environment by means of Rational Application Developer’s server configuration editor. I was able to change to for the EAR, but when I changed the mode for a WAR of the EAR from PARENT_FIRST to PARENT_LAST and saved the configuration, I was required to republish, after doing this RAD promted me to reload the configuration from the disk because it has changed. I did so – and my change to parent_last was gone.

Finally i discovered that if I stop the server, remove the application (EAR), republish (?), add the application, change the classloader mode of all WARs in question (and perhaps the EAR as well), save the config. and republish, the change will really apply.

I’m looking forward to have even more fun with WebSphere and RAD… 😉

RAD 6.0
WebSphere Portal v5.1 Test Environment