Latest Activity

Blog Article Index

Glen Mazza - Tue, 09/06/2011 - 13:00

Here's a collection of blog and external links for easy reference by topic.

CXF and Metro Web Services:

Other Topics:

  1. Using Perl to modify Java source files
  2. Using Perl to filter server log files
  3. Updating multiple XML documents using Ant and XSLT
  4. Processing XML documents with Woodstox (StAX), Maven and Eclipse
  5. Working with Apache Derby
  6. Apache Derby in Network Server Mode
  7. Docbook Resources and Usage Tips
Categories:

Maven Archetype Plugin 2.1 very useful feature

Olivier Lamy - Mon, 09/05/2011 - 08:59
Maven Archetype Plugin 2.1 has just been released and contains a very (IMHO) useful feature.
Usually when you use this plugin with generate goal, you have a very huge list of available archetypes (a non human readable list :-) ).

mvn archetype:generate
here the output :
.....
444: remote -> se.vgregion.javg.maven.archetypes:javg-minimal-archetype (-)

Yes around 450 possible archetypes. Do you have configured enough scrolling in your console to review all ?: -).
So now with 2.1 release it's possible to apply some filtering :

  • with a mojo parameter

  • in the prompt


You can filter on the groupId and/or the artifactId.
The documentation is available here.
My bad !. The official documentation has a typo.
You must read : mvn archetype:generate -Dfilter=org.apache:struts (and not mvn archetype:generate -Dorg.apache:struts).
So this feature is pretty cool to reduce the archetypes list when you know a part of what type of project type you want to create.
A sample, you want to create a gwt project.
So simply use :

mvn archetype:generate -Dfilter=:gwt
The output list is reduce :
Choose archetype:
1: remote -> net.kindleit:gae-archetype-gwt (-)
2: remote -> net.sf.mgp:maven-archetype-gwt (An archetype which contains a sample Maven GWT project.)
3: remote -> org.codehaus.mojo:gwt-maven-plugin (Maven plugin for the Google Web Toolkit.)
4: remote -> org.codehaus.sonar.archetypes:sonar-gwt-plugin-archetype (-)
5: remote -> org.geomajas:geomajas-gwt-archetype (-)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): :

Note you can enter an other filter to reduce the list

Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): : maven
Choose archetype:
1: remote -> net.sf.mgp:maven-archetype-gwt (An archetype which contains a sample Maven GWT project.)
2: remote -> org.codehaus.mojo:gwt-maven-plugin (Maven plugin for the Google Web Toolkit.)
Choose a number or apply filter (format: [groupId:]artifactId, case sensitive contains): :


You can filtering on groupId.
I want an artifact with gwt coming from codehaus :

mvn archetype:generate -Dfilter=org.codehaus:gwt
The output list :
Choose archetype:
1: remote -> org.codehaus.mojo:gwt-maven-plugin (Maven plugin for the Google Web Toolkit.)
2: remote -> org.codehaus.sonar.archetypes:sonar-gwt-plugin-archetype (-)


Have Fun !

Apache Maven, Maven, Apache are trademarks of The Apache Software Foundation.


Categories: Olivier Lamy

Web Services Links (4 September 2011)

Glen Mazza - Sun, 09/04/2011 - 13:00
Categories:

Monitoring CXF and Metro services with JMX MBeans

Glen Mazza - Thu, 09/01/2011 - 13:00

Both CXF and Metro expose JMX MBeans for remote monitoring and management of web service providers, as discussed in the CXF and Metro documentation. MBean data (attributes) can be viewed by using a JMX monitoring tool such as JConsole available in the Oracle Java SE Development Kit or with the open source/commercial hybrid Hyperic HQ. For example, three calls of my DoubleIt web service on WebLogic using CXF shows the following metrics in JConsole:

Metro presently doesn't offer such performance statistics within its MBeans, but they (like CXF) do provide an ability to view and modify several deployment parameters of the web service provider:

Application Server-specific configuration information for viewing MBean data:

  • Tomcat: If Tomcat is on a different machine than the one you will be monitoring it from, you'll need to activate its remote JMX administration port by modifying the Tomcat machine's CATALINA_OPTS environment variable:

    export CATALINA_OPTS="...whatever you presently have plus: -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9004 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"

    I'm arbitrarily choosing port 9004 above without authentication. For production you'll most probably want to configure authentication requirements.

    MBean data is immediately available with Metro deployments. For CXF you'll need to add the InstrumentationManager and (if you want to see performance data) CounterRepository beans to your Spring configuration file (for my basic DoubleIt web service tutorial, that would be the cxf-servlet.xml file).

    To see the MBean data, start up JConsole ($JAVA_HOME/bin/jconsole) and connect to Tomcat via local process (org.apache.catalina.startup.Bootstrap start) or remotely (service:jmx:rmi:///jndi/rmi://localhost:9004/jmxrmi) and then select the MBean tab.

  • Oracle WebLogic: Although the Metro web service itself was operative, I was unable to see the Metro MBeans in JConsole. Lacking any apparent configuration ability, the Metro MBeans are apparently viewable OOTB (Tomcat) or not (Weblogic). For CXF, after installing the web service on WebLogic I was able to access the CXF MBeans using JConsole with a local (same-machine) connection to WebLogic without any special configuration needed. For making a remote connection to WebLogic, I first made the following changes from the WebLogic Console:

    • Activate Listener Ports: base-domain->servers->{choose server}->Configuration->General: Listen Port Enabled, Listen Address, and Listen Port chosen
    • Activate IIOP: base-domain->servers->{choose server}->Protocols->IIOP->Enable IIOP

    ...and then followed this blog entry closely. My command to activate JConsole was:

    jconsole -J-Djava.class.path=$JAVA_HOME/lib/jconsole.jar:$JAVA_HOME/lib/tools.jar:$WL_HOME/server/lib/wljmxclient.jar -J-Djmx.remote.protocol.provider.pkgs=weblogic.management.remote -debug

    with a JConsole remote connection URL of:

    service:jmx:iiop://localhost:7001/jndi/weblogic.management.mbeanservers.runtime
  • IBM WebSphere App Server V8: Unfortunately I could not get the JConsole from either the Oracle or IBM JDK (packaged by WebSphere) to be able to connect to WebSphere, so I couldn't read any MBeans, web service related or otherwise. First, trying the Oracle JConsole, I read Andreas Veithen's blog entry and converted his Windows script to Linux form:

    export CP=$JAVA_HOME/lib/jconsole.jar export CP=$CP":"$JAVA_HOME/lib/tools.jar export CP=$CP":"$WAS_HOME/runtimes/com.ibm.ws.admin.client_8.0.0.jar export CP=$CP":"$WAS_HOME/runtimes/com.ibm.ws.ejb.thinclient_8.0.0.jar export CP=$CP":"$WAS_HOME/runtimes/com.ibm.ws.orb_8.0.0.jar $JAVA_HOME/bin/jconsole -J-Djava.class.path=$CP service:jmx:iiop://localhost:9100/jndi/JMXConnector

    Where $WAS_HOME was /opt/IBM/WebSphere/AppServer for my particular machine. The exception messages returned:

    Sep 3, 2011 10:27:50 AM com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl WARNING: "IOP00410201: (COMM_FAILURE) Connection failure: socketType: IIOP_CLEAR_TEXT; hostname: localhost; port: 0" org.omg.CORBA.COMM_FAILURE: vmcid: SUN minor code: 201 completed: No at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2200) at com.sun.corba.se.impl.logging.ORBUtilSystemException.connectFailure(ORBUtilSystemException.java:2221) at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.(SocketOrChannelConnectionImpl.java:205) at com.sun.corba.se.impl.transport.SocketOrChannelConnectionImpl.(SocketOrChannelConnectionImpl.java:218) at com.sun.corba.se.impl.transport.SocketOrChannelContactInfoImpl.createConnection(SocketOrChannelContactInfoImpl.java:101) at com.sun.corba.se.impl.protocol.CorbaClientRequestDispatcherImpl.beginRequest(CorbaClientRequestDispatcherImpl.java:152) at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.request(CorbaClientDelegateImpl.java:118) at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:211) at com.sun.corba.se.impl.protocol.CorbaClientDelegateImpl.is_a(CorbaClientDelegateImpl.java:221) ... at org.omg.CORBA.portable.ObjectImpl._is_a(ObjectImpl.java:112) at com.ibm.WsnBootstrap.WsnNameServiceHelper.narrow(WsnNameServiceHelper.java:63) at com.ibm.ws.naming.util.WsnInitCtxFactory.getWsnNameService(WsnInitCtxFactory.java:1504) at com.ibm.ws.naming.util.WsnInitCtxFactory.getRootContextFromServer(WsnInitCtxFactory.java:1038) at com.ibm.ws.naming.util.WsnInitCtxFactory.getRootJndiContext(WsnInitCtxFactory.java:960) at com.ibm.ws.naming.util.WsnInitCtxFactory.getInitialContextInternal(WsnInitCtxFactory.java:612) at com.ibm.ws.naming.util.WsnInitCtx.getContext(WsnInitCtx.java:128) at com.ibm.ws.naming.util.WsnInitCtx.getContextIfNull(WsnInitCtx.java:765) at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:164) at com.ibm.ws.naming.util.WsnInitCtx.lookup(WsnInitCtx.java:179) at javax.naming.InitialContext.lookup(InitialContext.java:392) at javax.management.remote.rmi.RMIConnector.findRMIServerJNDI(RMIConnector.java:1886) at javax.management.remote.rmi.RMIConnector.findRMIServer(RMIConnector.java:1856) at javax.management.remote.rmi.RMIConnector.connect(RMIConnector.java:257) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:248) at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:207) at sun.tools.jconsole.ProxyClient.tryConnect(ProxyClient.java:336) at sun.tools.jconsole.ProxyClient.connect(ProxyClient.java:296) at sun.tools.jconsole.VMPanel$2.run(VMPanel.java:280) Caused by: java.net.ConnectException: Connection refused at sun.nio.ch.Net.connect(Native Method) at sun.nio.ch.SocketChannelImpl.connect(SocketChannelImpl.java:507) at java.nio.channels.SocketChannel.open(SocketChannel.java:146)

    Some blogs indicated I would have more success with the IBM JDK JConsole than with the Oracle version, however. Switching to IBM's JConsole following this blog entry raised segmentation errors at startup, as the IBM JConsole cannot work for some reason on my Ubuntu machine.

    Script I used to activate the IBM JDK JConsole:

    export JAVA_HOME=$WAS_HOME/java export CP=$WAS_HOME/java/lib/jconsole.jar export CP=$CP":"$WAS_HOME/lib/tools.jar export CP=$CP":"$WAS_HOME/runtimes/com.ibm.ws.admin.client_8.0.0.jar export CP=$CP":"$WAS_HOME/runtimes/com.ibm.ws.ejb.thinclient_8.0.0.jar export CP=$CP":"$WAS_HOME/runtimes/com.ibm.ws.orb_8.0.0.jar $JAVA_HOME/bin/jconsole -J-Djava.class.path=$CP service:jmx:iiop://localhost:9100/jndi/JMXConnector

    Error results:

    Unhandled exception Type=Segmentation error vmState=0x00000000 J9Generic_Signal_Number=00000004 Signal_Number=0000000b Error_Value=00000000 Signal_Code=00000001 Handler1=00007F903D1D0870 Handler2=00007F903CE7BD70 InaccessibleAddress=000000004AF24FBF RDI=000000004AF24FBF RSI=00007F901817E071 RAX=00007FFF4AF24FBF RBX=00007F901817E071 RCX=0000000000000007 RDX=0000000000000000 R8=0000000000000000 R9=0000000000000000 ... Module=/lib/libc.so.6 Module_base_address=00007F903E104000 Target=2_60_20110418_080450 (Linux 2.6.32-33-generic) CPU=amd64 (4 logical CPUs) (0x1e4724000 RAM)

    As for server configuration to get either JConsole option to work, I tried various combinations of the following:

    Note the ORB_LISTENER_ADDRESS mentioned in both blog entries is viewable from the WebSphere Admin Console (left side menu: select Servers -> Server Types -> WebSphere application servers, select the server and it will be listed on the main page under Communications: Ports).

    Anyone has better luck, please leave a comment!

Notes:

  1. Apache-licensed Talend ESB Standard Edition, Version 5, presently at Milestone 3, in its examples folder provides JMX monitoring examples of CXF, Camel, and Karaf, from Tomcat and OSGi container deployment perspectives. Download now!

  2. See my blog index for more web service-related resources and articles.

Categories:

Deploying CXF- or Metro-based web services to IBM WebSphere Application Server

Glen Mazza - Tue, 08/30/2011 - 13:00

I just updated the instructions in the CXF User's Guide for deploying a CXF web service on IBM WebSphere Application Server, mostly by just referencing Nikhil Thaker's helpful article. Although he explains usage of CXF and Axis only, I found the CXF deployment instructions to work with Metro as well. I tested both stacks on the free WebSphere App Server Developer Version 8.

To modify the DoubleIt WSDL-first tutorial to deploy on WebSphere, just follow the Oracle WebLogic tutorial with these changes:

  • In Step #3, you'll need to modify the configuration of the maven-war-plugin to add a manifest entry to shut off activation of IBM WSAS' JAX-WS engine for this particular web service. (Thaker's article describes two options for shutting off the IBM JAX-WS engine, module-level as done here and server-level for all hosted web services.) Add the following manifestEntries element to the maven-war-plugin configuration given in the WebLogic article:

    <plugin> <artifactId>maven-war-plugin</artifactId> ... <configuration> ... <archive> <manifest> ... </manifest> <manifestEntries> <DisableIBMJAXWSEngine>true</DisableIBMJAXWSEngine> </manifestEntries> </archive> </configuration> </plugin>
  • In Step #4, change the endpoint URL port from 7001 to WebSphere's default of 9080 (or whatever you've configured WebSphere to use).
  • After deploying the web service using the WebSphere management console, you'll need to stop it and change its classloading policy before restarting it, as described in Thaker's article. Specifically, the class loader order will need to switch from "Classes loaded with parent class loader first" to "Classes loaded with local class loader first (parent last)".

During deployment you may need to check the server log files for any web service stack errors returned. The SystemOut.log log file is probably the most useful, which for my default installation on Ubuntu was located in /opt/IBM/WebSphere/AppServer/profiles/AppSrvXX/logs/server1. For example, an error message I received prior to changing the class loader order as described above was:

org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'doubleit': Invocation of init method failed; nested exception is java.lang.NoSuchFieldError: org/apache/ws/commons/schema/XmlSchemaForm.QUALIFIED at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.initializeBean(AbstractAutowireCapableBeanFactory.java:1420) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.doCreateBean(AbstractAutowireCapableBeanFactory.java:519) at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.createBean(AbstractAutowireCapableBeanFactory.java:456) ... at org.apache.cxf.transport.servlet.CXFServlet.createSpringContext(CXFServlet.java:114) at org.apache.cxf.transport.servlet.CXFServlet.loadBus(CXFServlet.java:55) at org.apache.cxf.transport.servlet.CXFNonSpringServlet.init(CXFNonSpringServlet.java:56) at com.ibm.ws.webcontainer.servlet.ServletWrapper.init(ServletWrapper.java:329) at com.ibm.ws.webcontainer.servlet.ServletWrapperImpl.init(ServletWrapperImpl.java:168) at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:577) ...

Note: For those trying to install WSAS on Ubuntu Linux, which I understand is not supported by IBM, I needed to temporarily switch the default Ubuntu shell from dash to bash as described in Step #5 here before starting the WebSphere installation process.

Categories:

This Week's Links (28 August 2011)

Glen Mazza - Sun, 08/28/2011 - 13:00
Categories:

Apache Karaf Cave preview

Jean-Baptiste Onofré - Thu, 08/25/2011 - 22:36
During the Karaf birthday concall, the Karaf team launched the idea of implementing an easy to use OBR (OSGi Bundle Repository) server, and extending it to provide a Karaf Features Repository (KFR). Welcome to Apache Karaf Cave Cave is an Apache Karaf sub-project. The core OBR is a service (RepositoryAdmin service) that can automatically install [...]
Categories: Jean-Baptiste Onofré

Understanding and Refactoring the architecture of camel-core

Christian Schneider - Wed, 08/24/2011 - 17:46

Blog post added by Christian Schneider

I am currently working on an important part of the upcoming Apache Camel 2.9 and 3.0 versions the refactoring of camel-core to make it ready for future growth. So you may ask why refactor something that is working so well. From the user perspective you are right.Camel is easy to use and on first sight the architecture of the core is quite clear.

So let´s first look at the architecture. There are several packages in camel with certain responsibilities:

  • org.apache.camel : Camel API. Almost everyone will use this
  • spi : Service provider interfaces. This is for third party extensions that want to hook into camel to change functionality like jmx management
  • model: This is where the biggest part of the Java DSL lives
  • builder: Builder pattern implementations for the Java DSL
  • components: Several components that are shipped with camel-core like file and bean component
  • impl: Implementation classes
  • processor: Runtime elements of camel routes that do the processing. They are created by the model classes
  • management: JMX management functionality
  • converter: Type converters
  • util: Utility packages that work on the API and provide convenience methods

So as I said the architecture looks quite sound. Almost everything has its place.

There are three main problems though:

  1. The camel-core grows quite a lot. While camel-core had about 30k lines of code in 2008 it now (2011) has about 70k lines of code
  2. There are no rules in place which packages in camel-core may use which other packages
  3. Probably mainly as a consequence of 2 there are a lot of cyclic dependencies in camel-core

So I started by anaylizing the current state of camel-core with a tool called structure 101. When given jars or a classes directory it can visualize dependencies and compute a metric calles XS (Excess). The higher the number the worse the code is. It also allows to dig into each dependency and see exactly which classes and methods are involved. So for each dependency you can drill down to the code line that causes it.

So camel 2.8 looks like this on the top level of packages:

The nodes of this graph are the packages. The edges are dependencies from one class in package A to another class in package B. A dependency cycle means that package A depends (possibly transitively) on package B while package B also depends on package A. A dependency cycle means that you can not understand or change one package independently from the other as the dependencies may cause unwanted effects in the other package.
In case of camel the whole top level packages are involved in a dependency cycle. This means that all packages depend on all others in some way. While this was tolerable when camel was smaller the current size and growth rate mean that it is becoming ever harder to change something without breaking another functionality.

I have also attached the completestructure 101 report of camel 2.8 that shows the XS number and some details how it is composed. The excess value in camel 2.8 is about 43.000 or 28% and the top level packages are 10% entangled.

So facing this situation I have several goals:

  • Overall the goal is to have less coupling in camel between modules and higher coherence inside a module
  • Create a small API that is independent of the rest of camel-core. This API should contain everything a component developer needs to create a component
  • Propose dependency rules for camel-core that make sure that no tangles will be created
  • Split up camel-core  into several projects with clear unidirectional dependencies
  • Camel 2.9 should be very compatible to Camel 2.8
  • Camel 3.0 should get rid of deprecated packages but else have only few incompatibilities

To reach these goals it is necessary to disentangle the current packages by doing refactorings.

I already started these refactorings in camel 2.9-SNAPSHOT. The first big steps where:

  • refactor the management code to remove cycles inside the code. In 2.8 it contained API as well as implementation. This is nicely split up now
  • Introduce a support package to contain base classes that implement the API and are expected to be extended by many other classes. They form some kind of extended API. I already moved some important classes there

So after these steps the cycles in camel-core are still present but are much weaker now. A first small cycle that is really removed is with the main package which is now not referenced by any other package anymore.

This improvement is also supported by the structure 101 report for the snapshot. It shows that the excess value dropped to 33.000 (22%) and the camel-core top level packages are now only 7% entangled. So this already shows a big drop in complexity. At the same time the current refactorings are using stub classes at the old places that are marked @Deprecated so the upcoming camel 2.9.0 should still be highly compatible with camel 2.x.
During the next time I continue to work on the refactoring with the goal to at least remove the dependency cycle from the camel API to the rest of camel. This would then allow to have a separate camel-api jar that components could be based on.

If you want to dig into the structure of camel yourself you can get an evaluation version of structure 101 at headways software. If you are a committer in an apache project you can get a free license of structure 101. Many thanks to headways for sponsoring apache projects in this way.

I would be very interested in dicussing proposals for further refactorings and how the future architecture of Apache Camel should look like.

View Online | Add Comment
Categories: Christian Schneider

Use Camel, CXF and Karaf to implement batches

Jean-Baptiste Onofré - Tue, 08/23/2011 - 22:15
Introduction Apache Camel has not be designed to be used for implementing batch tasks. For instance, if your Camel route has a consumer endpoint polling files in a directory, Camel will periodically and indefinitely monitor the folder and poll any new incoming files. It’s not a batch behavior: in batch mode, we want to run [...]
Categories: Jean-Baptiste Onofré

Deploying CXF- or Metro-based web services to Oracle WebLogic Server

Glen Mazza - Tue, 08/23/2011 - 13:00

Deploying a CXF- or Metro-based web service to Oracle WebLogic Server has never been easier--I was able to get the WAR generated by the WSDL-first DoubleIt tutorial to work on Oracle WebLogic 10.3.5 out of the box, using either web service stack. However, due to potential classloader conflicts you may wish to deploy an EAR to WebLogic following the instructions below. By default, WebLogic uses its own JARs before those that you include within the WAR, which can create version mismatches and other runtime problems. The weblogic-application.xml configuration file stored within the EAR gets around this problem by allowing developers to specify the Java packages that need to loaded from the EAR instead of from WebLogic's default classloader.

Steps involved in moving the DoubleIt tutorial from a WAR-based Tomcat deployment to an EAR-based WebLogic one are as follows:

  1. Download the source code from the DoubleIt tutorial. The download uses CXF by default; make sure you have made the necessary web.xml and Maven pom file changes as explained in that tutorial if you're using Metro instead. If you haven't already, you may wish to follow that tutorial to confirm it is working on Tomcat for you before proceeding.

  2. Create a new "ear" Maven submodule for the project. This will be the project's fourth submodule, alongside client, service, and war. Make sure it has the following subfolders:

    DoubleIt/ear/src/main/application/META-INF

    Place the following weblogic-application.xml file under META-INF:

    <?xml version="1.0" encoding="UTF-8"?> <weblogic-application xmlns="http://xmlns.oracle.com/weblogic/weblogic-application” xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance xsi:schemaLocation=”http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.0/weblogic-application.xsd"> <application-param> <param-name>webapp.encoding.default</param-name> <param-value>UTF-8</param-value> </application-param> <prefer-application-packages> <!--package-name>com.mycompany.util.*</package-name--> </prefer-application-packages> </weblogic-application>

    Note for DoubleIt there are presently no overrides declared under prefer-application-packages. However, if WebLogic reports classloading issues for your own web services, you may need to declare Java packages under this element to ensure those declared within the EAR are activated before any WebLogic-stored libraries are used.

  3. Update the POM files to accommodate the new ear module. In the trunk/pom.xml file, add the ear submodule:

    <modules> <module>service</module> <module>war</module> <module>ear</module> <module>client</module> </modules>

    Place the following pom.xml file in the ear folder:

    <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> <parent> <groupId>org.gmazza.blog.basic-doubleit</groupId> <artifactId>basic-doubleit</artifactId> <version>1.0-SNAPSHOT</version> </parent> <artifactId>service-ear</artifactId> <name>EAR file for WebServiceSample</name> <packaging>ear</packaging> <dependencies> <dependency> <groupId>org.gmazza.blog.basic-doubleit</groupId> <artifactId>service-war</artifactId> <version>1.0-SNAPSHOT</version> <type>war</type> </dependency> <dependency> <groupId>org.gmazza.blog.basic-doubleit</groupId> <artifactId>service-bundle</artifactId> <version>1.0-SNAPSHOT</version> </dependency> </dependencies> <build> <defaultGoal>package</defaultGoal> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-ear-plugin</artifactId> <version>2.6</version> <configuration> <!-- Places jars in a lib subdirectory of the EAR (for readability) --> <defaultJavaBundleDir>lib/</defaultJavaBundleDir> <modules> <webModule> <groupId>org.gmazza.blog.basic-doubleit</groupId> <artifactId>service-war</artifactId> <contextRoot>doubleit</contextRoot> </webModule> </modules> </configuration> </plugin> </plugins> </build> </project>

    Note that service-war already has a dependency on service-bundle, but for some reason I couldn't get transitive dependencies to work with the maven-ear-plugin, so I explicitly listed service-bundle as a dependency in this POM file.

    Finally, in the service-war's POM, the WAR-building process needs to be modified to no longer copy the JARs into the WEB-INF/lib directory, as explained here. (Maven's ear plugin automatically copies dependencies to the EAR, even if they are already in the WAR's WEB-INF/lib directory. Removing them from the WEB-INF/lib directory therefore prevents duplication of JARs.) Modify the war submodule's maven-war-plugin configuration to the following: <build> ... <plugins> <plugin> <artifactId>maven-war-plugin</artifactId> <version>2.1.1</version> <configuration> <packagingExcludes>WEB-INF/lib/*.jar</packagingExcludes> <webXml>src/main/webapp/WEB-INF/web.xml</webXml> <webResources> <resource> <directory>../service/src/main/resources</directory> <targetPath>WEB-INF/wsdl</targetPath> <includes> <include>*.wsdl</include> </includes> </resource> </webResources> <archive> <manifest> <addClasspath>true</addClasspath> <classpathPrefix>lib/</classpathPrefix> </manifest> </archive> </configuration> </plugin> ... </plugins> ... </build>

  4. Update the soap:address URL in the WSDL file. The SOAP client relies on this address when making the web service call. In the doubleit.wsdl file, update the soap:address in the wsdl:service section to http://localhost:7001/doubleit/services/doubleit or similar (depending on your WebLogic HTTP port configuration.) Alternatively you can have the SOAP client route to the WebLogic URL by setting the ENDPOINT_ADDRESS_PROPERTY as shown in the SOAP client tutorial.

  5. Create the EAR. From the command prompt within the project base directory, enter mvn clean install. Once done, the EAR file to be uploaded to WebLogic will be located in the ear/target directory.

  6. Import the EAR into WebLogic Console and activate it. This process is the same as for any other EAR or WAR import. Make sure you can see the service WSDL at http://localhost:7001/doubleit/services/doubleit?wsdl before proceeding.

  7. Confirm that the SOAP client can access the WebLogic-hosted web service. Run the client as described in Step #10 of the DoubleIt tutorial to make sure that SOAP calls are working properly.

Additional Resources

Categories:

JAX-RS services using CXF and Karaf

Jean-Baptiste Onofré - Fri, 08/19/2011 - 22:28
Apache CXF provides a really great layer to implement JAX-RS services. Especially, it fully supports OSGi, including Blueprint. It means that you can very easily create and deploy your REST services in a Apache Karaf container. In this example, we will see how to list all Karaf features via a REST service. This exemple is [...]
Categories: Jean-Baptiste Onofré

Apache WSS4J 1.5.12 and 1.6.2 released

Colm O hEigeartaigh - Thu, 08/18/2011 - 15:21
Apache WSS4J 1.5.12 and 1.6.2 have been released.

WSS4J 1.5.12 is a bug-fix release, which fixes some problems relating to future-dated Timestamps, fixes a bug with deriving keys from UsernameTokens, and fixes a concurrency issue with EnvelopeIdResolver, amongst other things.

WSS4J 1.6.2 contains some enhancements for SAML Token creation, fixes a bug with deriving keys from UsernameTokens, adds initial support for the Kerberos Token Profile 1.1, and fixes some problems relating to signature verification in certain containers.
Categories: Colm O hEigeartaigh

SAML token creation in Apache WSS4J 1.6

Colm O hEigeartaigh - Tue, 08/16/2011 - 20:10
WSS4J 1.6 uses Opensaml2 to create and parse SAML Assertions. WSS4J ships with a library that wraps the Opensaml API to greatly simplify the process of creating a SAML Assertion. The user implements a CallbackHandler instance which must be able to handle a WSS4J SAMLCallback object. and set certain properties on this object. WSS4J then parses the properties that were set on the object and creates a SAML Assertion accordingly. In this blog post we will examine the process of creating a SAML Assertion by populating a SAMLCallback object in more detail.

1) Obtain a SAMLCallback object

First off, a SAMLCallback object must be obtained in the CallbackHandler implementation, e.g.:

if (callbacks[i] instanceof SAMLCallback) {
    SAMLCallback callback = (SAMLCallback) callbacks[i];
    ....
}

2) Set the SAML Version

The first thing to do is to set the desired SAML Version of the Assertion you want to create on the SAMLCallback object, e.g.:

callback.setSamlVersion(SAMLVersion.VERSION_11);

This method takes an org.opensaml.common.SAMLVersion object. For normal purposes, it will be one of the following:
  • SAMLVersion.VERSION_11
  • SAMLVersion.VERSION_20
The default value in SAMLCallback is VERSION_11.

3) Set the Issuer

The next thing to do is to set the issuer (String) name of the token, e.g.:

callback.setIssuer("sts");

4) Set the Subject

The next thing to do is to set the Subject of the Assertion. WSS4J defines a SubjectBean which encapsulates a SAML Subject. The Subject Name, NameQualifier, NameIDFormat and ConfirmationMethod Strings can be set on the SubjectBean instance. The NameIDFormat and ConfirmationMethod values that can be set are largely defined in the SAML1Constants and SAML2Constants classes. The default value for the SubjectBean NameIDFormat is SAML1Constants.NAMEID_FORMAT_UNSPECIFIED. Both constants classes contain the following values that can be used for the ConfirmationMethod value:
  •  SAML[1|2]Constants.CONF_BEARER
  •  SAML[1|2]Constants.CONF_HOLDER_KEY
  •  SAML[1|2]Constants.CONF_SENDER_VOUCHES
In addition to this, WSS4J defines a KeyInfoBean that can be set on the SubjectBean, which represents a KeyInfo structure that will be embedded in a SAML Subject. There are a number of different ways to set the KeyInfo value:
  • A DOM element can be defined for a pre-existing KeyInfo element
  • A PublicKey object can be used
  • An X.509 Certificate can be used
For the latter two cases, the KeyInfoBean contains a CERT_IDENTIFIER enum which defines how the PublicKey or X.509 Certificate will be output. The following values can be configured:
  • X509_CERT: An X509Certificate element will be output
  • X509_ISSUER_SERIAL: An X509 IssuerSerial element will be output
  • KEY_VALUE: A KeyValue element will be output
The default value in the KeyInfoBean is X509_CERT. Here is a sample that shows how to create a SubjectBean:

SubjectBean subjectBean = new SubjectBean();
subjectBean.setSubjectName("uid=joe");
subjectBean.setSubjectNameQualifier("apache.org");
subjectBean.setSubjectConfirmationMethod(
     SAML1Constants.CONF_SENDER_VOUCHES
);
KeyInfoBean keyInfo = new KeyInfoBean();
keyInfo.setCertificate(cert);
subjectBean.setKeyInfo(keyInfo);

Finally, it remains to store the SubjectBean instance in the SAMLCallback object. A SAML 2.0 Assertion contains a single Subject, and so for this case the SubjectBean instance can be set directly on the SAMLCallback, e.g.:

callback.setSubject(subjectBean);

For a SAML 1.1 Assertion, the Subject can be in a SubjectStatement (in which case it can be set directly on the SAMLCallback), or it can be embedded in one of the other statements which we will cover next.

5) Create and set a Statement

WSS4J contains a number of beans to create Statements for SAML Assertions, that can be set on a SAMLCallback object. They can be used in either SAML 1.1 or SAML 2.0 Assertions, with the caveat that SubjectBean instances are not used with statements in SAML 2.0.

a) Attribute Statements

WSS4J contains an AttributeStatementBean for creating Attribute statements. This contains a SubjectBean (for the SAML 1.1 case), and a list of AttributeBean objects. An attribute simple name, qualified name, and name format Strings can be set on the AttributeBean, as well as a list of attribute value Strings. Here is an example of creating and adding an AttributeStatement to a SAMLCallback object:

AttributeStatementBean attrBean = new AttributeStatementBean();
attrBean.setSubject(subjectBean);
AttributeBean attributeBean = new AttributeBean();
attributeBean.setSimpleName("role");
attributeBean.setAttributeValues(Collections.singletonList("user"));
attrBean.setSamlAttributes(Collections.singletonList(attributeBean));
callback.setAttributeStatementData(Collections.singletonList(attrBean));

b) Authentication Statements

WSS4J contains an AuthenticationStatementBean for creating Authentication statements. For SAML 1.1 a SubjectBean instance can be set on this object. In addition to this, an authentication instant and authentication method can be set, as well as a SubjectLocalityBean object and a session index String. Various authentication method Strings are defined in the SAML1Constants and SAML2Constants given above. Here is an example:

AuthenticationStatementBean authBean = new AuthenticationStatementBean();
authBean.setSubject(subjectBean);
SubjectLocalityBean subjectLocality = new SubjectLocalityBean();
subjectLocality.setIpAddress(subjectLocalityIpAddress);
subjectLocality.setDnsAddress(subjectLocalityDnsAddress);
authBean.setSubjectLocality(subjectLocality);
authBean.setAuthenticationMethod("Password");     callback.setAuthenticationStatementData(Collections.singletonList(authBean));

c) Authorization Decision Statements

WSS4J contains an AuthDecisionStatementBean for creating Authorization Decision Statements. For SAML 1.1 a SubjectBean instance can be set on this object. A Decision enum can be set (PERMIT, INDETERMINATE, DENY), as well as a resource String, evidence Object, and a list of ActionBeans, which in turn contain an action namespace and action contents. Here is an example:

AuthDecisionStatementBean authzBean = new AuthDecisionStatementBean();
authzBean.setSubject(subjectBean);
ActionBean actionBean = new ActionBean();
actionBean.setContents("Read");
authzBean.setActions(Collections.singletonList(actionBean));
authzBean.setResource("endpoint");
authzBean.setDecision(AuthDecisionStatementBean.Decision.PERMIT);
authzBean.setResource(resource);  callback.setAuthDecisionStatementData(Collections.singletonList(authzBean));
 
6) Create a Conditions object

Finally, a ConditionsBean object can be used to specify a set of Conditions on the SAML Assertion. This is optional, as by default a Conditions element will be generated with a NotBefore value of the present instant and a NotOnOrAfter value corresponding to 5 minutes into the future. This can be changed by creating a ConditionsBean and specifying either "notBefore" and "notAfter" dates, or else a token period in minutes in which the token is valid. It is also possible to specify an audience restriction URI on the ConditionsBean object. Here is an example:

ConditionsBean conditions = new ConditionsBean();
conditions.setTokenPeriodMinutes(10);
conditions.setAudienceURI("http://ws.apache.org/wss4j");
callback.setConditions(conditionsBean);

For some examples of CallbackHandlers used to create SAML Assertions, check out the following CallbackHandlers used in the WSS4J unit tests - SAML1AuthnHOKHandler, SAML1CallbackHandler and SAML2CallbackHandler.
Categories: Colm O hEigeartaigh

WS-Trust 1.4 support in CXF

Colm O hEigeartaigh - Mon, 08/15/2011 - 17:43
Apache CXF has had support for sending a WS-Trust 1.4 ActAs element as part of a RequestSecurityToken call to a Security Token Service (STS) since the 2.2.10 release. To quote from the WS-Trust 1.4 specification:
/wst:RequestSecurityToken/wst:ActAs
 
This OTPIONAL (sic) element indicates that the requested token is expected to contain information about the identity represented by the content of this element and the token requestor intends to use the returned token to act as this identity. The identity that the requestor wants to act-as is specified by placing a security token or <wsse:SecurityTokenReference> element within the <wst:ActAs> element.The object to be placed in an ActAs element can be set by the SecurityConstants tag "STS_TOKEN_ACT_AS" on the Message properties. Prior to Apache CXF 2.4.1 the ActAs object could either be an XML String or else a DOM Element. See the following CXF wiki page for more information.

Several enhancements were made in CXF 2.4.1 as part of this JIRA. First of all, support was added for OnBehalfOf. To quote from the spec again:
/wst:RequestSecurityToken/wst:OnBehalfOf
This OPTIONAL element indicates that the requestor is making the request on behalf of another.  The identity on whose behalf the request is being made is specified by placing a security token, <wsse:SecurityTokenReference> element, or <wsa:EndpointReference> element within the <wst:OnBehalfOf> element. The requestor MAY provide proof of possession of the key associated with the OnBehalfOf identity by including a signature in the RST security header generated using the OnBehalfOf token that signs the primary signature of the RST (i.e. endorsing supporting token concept from WS-SecurityPolicy). Additional signed supporting tokens describing the OnBehalfOf context MAY also be included within the RST security header.The object to be placed in an OnBehalfOf element can be set by the SecurityConstants tag "STS_TOKEN_ON_BEHALF_OF" on the Message properties. Similar to ActAs, this object can be an XML String or a DOM Element. In addition to this, the object for both ActAs and OnBehalfOf can now be a CallbackHandler instance. The CallbackHandler implementation must be able to process a DelegationCallback object, which has access to the current CXF Message, and returns a DOM Element to the STSClient for insertion into either ActAs or OnBehalfOf.

Two sample CallbackHandler implementations are shipped with CXF 2.4.1 that can be used for either OnBehalfOf or ActAs. The ReceivedTokenCallbackHandler obtains the previously received message from the current message property of the DelegationCallback object, and extracts a token that has been received in that message (SAML Token/UsernameToken/BinarySecurityToken). This token is then used as the delegation token. This CallbackHandler implementation is useful as part of an WS-Trust intermediary scenario. Secondly, the WSSUsernameCallbackHandler obtains a username via the jax-ws property "ws-security.username" (SecurityConstants.USERNAME), and creates a wsse:UsernameToken (with no password) to be used as the delegation token.
Categories: Colm O hEigeartaigh

This Week's Links (14 August 2011)

Glen Mazza - Mon, 08/15/2011 - 04:22
Categories:

Use a &#8220;remote&#8221; EJB in Camel routes

Jean-Baptiste Onofré - Tue, 08/09/2011 - 20:18
Introduction You have an existing application, let say developed using J2EE, including EJB (Session). The application is running into a J2EE application server like JBoss, WebSphere or Weblogic. This application “exposes” EJBs to perform some business services. Now, you can to use these “remote” EJBs into Camel routes. Context We want to “expose” the EJB [...]
Categories: Jean-Baptiste Onofré

Apache Karaf Cellar 2.2.2 release

Jean-Baptiste Onofré - Mon, 08/08/2011 - 08:20
What’s new Quite one month ago, we released Karaf Cellar 2.2.1, the first “official” release of the Karaf clustering sub-project. This new Karaf Cellar 2.2.2 release includes bug fixes, especially one bug was a blocker as it was not possible to install Cellar on a Karaf instance running on Equinox OSGi framework. But, it’s not [...]
Categories: Jean-Baptiste Onofré

This Week's Links (7 August 2011)

Glen Mazza - Sun, 08/07/2011 - 13:00

Web Services:

Karaf:

Categories:

Video: Talend Service Factory JAX-RS Advanced Example

Glen Mazza - Thu, 08/04/2011 - 14:11

I created a video for the JAX-RS Advanced Example provided with the free and open source Talend Service Factory. The video first shows how to download and install Talend Service Factory and its examples. Next covered is building and deploying this RESTful service in the Talend Service Factory OSGi container and making calls to that service using a provided REST client. Finally, we look into the Mavenized architecture of the REST service and important aspects of the source code. Enjoy!

Categories:

This Week's Links (31 July 2011)

Glen Mazza - Sun, 07/31/2011 - 13:00
Categories:

Pages

Subscribe to Talend Community Coders aggregator