First time running he JAXR TCK with a UDDI v3 Registry

I just ran the JAXR TCK tests using Scout-1.2.5 and a jUDDI-3.1.3 instance as the Registry backend. I was pleasantly surprised:

Test results: passed: 1,340; failed: 32

32 fails.. Almost there! Back to bug fix mode.

-----------------------
Update:
It looks like I found one real bug in scout (SCOUT-129) and one issue to with being backwards compatible with UDDI v2 default settings (SCOUT-127). A full run of all the JAXR tests results now in:

Test results: passed: 1,372

no fails, Hurray :)!

Going to prepare Scout-1.2.6.

Using JAXR on JBoss 7.1.1

Introduction
One of the Technologies specified in the JEE6 Specification is the Java API for XML Registries (JSR 93). Apache Scout is the implementation of this specification. This specification is a client side library to interact with an XML Registry. Examples of XML Registries are UDDI and ebXML. To make a long story short, every Application Server needs to ship with a JAXR implementation, and this is what I have been helping out on.

JBoss JAXR module
On and off over the last few months I have been working on a JAXR module for JBoss-AS-7.1. The requirement for it was such that it needed to pass the JEE6 TCK, and that it should be able to interact with both UDDI v2 and v3 registries. Previous version of JBoss-AS have always shipped with a jUDDI v2 registry but, for the time being,  it was decided to ship the client libraries only this time, which is the only JEE6 required component anyway. In other words, you need to have a running instance of jUDDI for the JAXR module to connect to.

How to use it?
Your deployment will only need to depend on the JAXR API, if you are using maven add the following to the dependencies section in your pom:

  
  
    javax.xml
    jaxr-api
    1.0_04
    provided
  

Now you can get a handle to the JAXR ConnectionFactory simply by looking it up in JNDI

 
InitialContext context = new InitialContext();
ConnectionFactory jaxrFactory = (ConnectionFactory) context.lookup("java:jboss/jaxr/ConnectionFactory");
            
Properties properties = new Properties();
...
//set some JAXR properties
...
jaxrFactory.setProperties(properties);

connection = jaxrFactory.createConnection();

//now you can set the credentials on this connection.
PasswordAuthentication passwdAuth = new PasswordAuthentication(userid, passwd.toCharArray());
Set creds = new HashSet();
creds.add(passwdAuth);
connection.setCredentials(creds);

at this point you should be able to execute any JAXR registry command. Make sure to add your own exception handling.

What if I don't want to use the default JAXR module configuration?
The default JAXR configuration lives in the standalone/configuration/standalone.xml:

connection-factory attribute	default value	description	required
jndi-name	-	Name used to bind into JNDI	Y
class	org.apache.ws.scout. registry.ConnectionFactoryImpl	Class name of the JAXR implementation the JAXR module will instantiate	N
property attribute	default value	description	required
name	-	Name of the JAXR property	Y
value	-	Value of the JAXR property	Y

JAXR specifies the following properties:

Figure 1. The JAXR properties as specified in the JAXR specification.

and by default the following properties are set:

JAXR property name	default value
javax.xml.registry.queryManagerURL	http://localhost:8080/juddi/inquiry
javax.xml.registry.lifeCycleManagerURL	http://localhost:8080/juddi/publish

Additionally, when using the Scout implementation is used, the following properties are set by default

Scout property name	default value
scout.proxy.uddiVersion	2.0
scout.proxy.uddiNamespace	urn:uddi-org:api_v2
scout.proxy.transportClass	org.apache.ws.scout.transport.SaajTransport

To use JAXR in the default configuration, simply use a standalone/configuration/standalone.xml with the following jaxr section:

This means that by default Scout connects to the UDDI registry using the UDDI v2 API specification, using the SaajTransport class. It is this configuration that was used for TCK compatibility testing as the JAXR specification has not been updated since the UDDI v3 specification was published.

What if I want to connect to a UDDI v3 Registry?
The Apache Scout implementation supports connecting to a UDDI v3 registry. For this it uses the jUDDI-client library, and the JBoss JAXR module supports using the following configuration in the standalone/configuration/standalone.xml:

Override the properties set in the configuration
In the first code fragment of this blog post it was shown that you can set properties before using the connection, using jaxrFactory.setProperties(properties). This will add these properties, or override the defaults. This way you can override property setting programmatically.

This concludes this post on using JAXR on JBoss-AS7.1. If you would like to add an entry on how to use Scout on another Application Server, then by all means send it to us and we will add it!

 Cheers,

 --Kurt

Release announcement jUDDI-3.1.3 and Scout-1.2.5

The jUDDI team is proud to announce the release of jUDDI-3.1.3 and Scout-1.2.5. Besides bug fixes, the latest release of jUDDI has seen development on the jUDDI client to make it easier to interact with the UDDI Registries. Besides using the client code to access our own Apache jUDDI Registry it has been tested to work with for example Systinet's and SAP's Registries. We added some interesting features to the client such as a clientside cache and the registration of WSDL and BPEL processes according to respectively technote Using WSDL in a UDDI Registry, Version 2.0.2 and Using BPEL4WS in a UDDI registry. More details on how to use this will follow.

On the JAXR front we made sure Scout-1.2.5 passes all tests in the JEE6 TCK. The tests were run using a jUDDI v2 registry, but we plan to make sure they also work using the latest jUDDI v3 registry.

The releases can be downloaded at:
http://juddi.apache.org/scout/releases.html and
http://juddi.apache.org/releases.html

Cheers!

 --Kurt