Working currently on an RelaxNG project, I needed to automate conversion of RNG schemas to a W3C compliant schema in NetBeans. The tool I used to perform the transform is Trang. I added this macro to the build.xml file:

All necessary libraries reside in the ./resources/tools directory. Now, in order to use this macro on a number of RNG files, I decided to use the <for> directive from ant-contrib. James Allen has good instructions on how to integrate ant-contrib within NetBeans (or arbitrary ant environments) without having to drop the ant-contrib Jar into the ant/NetBeans installation.

Obviously, these XSDs can then be used with any other tools, such as JAXB.

For our current internal project, I needed a way to display images within a Java Swing application. There are probably as many solutions to this out, as there are swing programmers, but here is a quick way to get this done, that solves my two major issues:

Resizable, i.e. when the panel changes in size, the image changes along.

Integratable with NetBeans, especially with the Matisse component designer.

This worked for me:

            
              public
              class ImagePanel extends JPanel
{ private Image
image; private Image
displayImage; public ImagePanel()
{ super();
} public ImagePanel(Image
image) { super(); this.image = image; this.displayImage = image;
} @Override publicvoid paintComponent(Graphics
g) { fitImage(); while (!g.drawImage(displayImage,
0, 0, null))
{ } } @Override publicvoid setSize(Dimension
d) { super.setSize(d);
} private synchronized void fitImage()
{ if (image
!=null)
{ int imageHeight = image.getHeight(null); int imageWidth = image.getWidth(null);
double ratio = ((double)
imageHeight) / ((double) imageWidth); Dimension d =this.getSize();
double height = d.getHeight();
double width = d.getWidth(); if (height
== 0 || width == 0) { height =this.image.getHeight(null);
width =this.image.getWidth(null);
} else {
double tempH = Math.floor(ratio
* width); double tempW = Math.floor(height
/ ratio); if (tempH + 1
> height) { width = tempW;
} else {
height = tempH;
} } displayImage = image.getScaledInstance((int)
Math.floor(width), (int)
Math.floor(height), Image.SCALE_DEFAULT); } } public Image
getImage() { return image;
} publicvoid setImage(Image
image) { this.image = image;
fitImage(); }
          

Note the while-loop in the paintComponent() method. Without this, you will only get partial image updates, since the drawImage() method on Graphics runs in the background. For very large images or latency sensitive applications this might be an issue, but for my application this is quite acceptable.

In order to integrate this class with NetBeans, you create a Swing JPanel with the graphical designer, and set the "Custom Creation Code" for that panel to be your ImagePanel. Within the code, you can now easily cast to ImagePanel, thus giving you the full image functionality, while not sacrificing visual design.

tags:javaswingimagepanelNetBeans

Marc recently published a short tutorial on how to use Apache Abdera with Apache Abdera with our reference implementation of JAX-RS, Jersey. His code is server side, i.e. it explains using Jersey and Abdera for creating RESTful web services with Atom payload^[1]. In this article I will give an example on how the Jersey client API can be used to consume such a service with realitve ease.

It is hopefully known that Jersey contains a very simple, yet effective HTTP client API. Core to it is the heavy use of the builder pattern for creating and configuring requests. For our example, I start with creating the client:

           Client
c = Client.create();
WebResource r = c.resource(new URI(someLocation));
        

We can now get the InputStream from the WebResource to read the Atom feed into an Abdera Feed:

           InputStream
is = (InputStream)
r.get(InputStream.class);
Document<Feed> doc = Abdera.getNewParser().parse(is);
Feed feed = doc.getRoot(); for (Entry
entry : feed.getEntries()) { 


doSomething(entry); 


}
        

Now let's say we want to post an entry to the resource in Marc's article. In this case we would also have to use his AbderaSupport class, which implementes the proper MessageBodyReader and MessageBodyWriter interfaces for the Abdera objects. On the server side providing these interfaces is enough, but on the client side we need to configure the Jersey client. The following code helps doing this:

          
            public
            static
            class AbderaClientConfig extends DefaultClientConfig
{ @Override public Set<Class<?>>
getProviderClasses() { Set<Class<?>> classes =new HashSet<Class<?>>();
classes.add(AbderaSupport.class); return classes;
} } Thus completing our sample app: 

           ClientConfig
cf =new AbderaClientConfig();
Client c = Client.create(cf);
WebResource r = c.resource(new URI(someLocation));
Entry entry = AbderaSupport.getAbdera().newEntry();
entry.setTitle(...); entry.setContent(...); ClientResponse cr = r.type(MediaType.APPLICATION_XML).put(ClientResponse.class,
entry); 
        

[1] Tim pointed out that this style should properly called "AtomPub", and not APP, AtomPub/Sub or similar.

This is seriously groundbreaking: Clemens (also here) just finished an example of a Metro client accessing Microsoft's BizTalk Services (aka Internet Service Bus). "Well", you might ask, "what is so groundbreaking about this? Isn't this what this whole web services thingy was supposed to achieve? Interoperability?!"

Yes, indeed. However, this is the first time ever (to my knowledge) that Microsoft is releasing JEE code, built with Metro within NetBeans, as part of an SDK. Getting there took quite a while, and was largely enabled by Sun and Microsoft working very closely together in a series of interop-plugfests. The latest installment of these got (especially) WS-Trust interoperability to a point where you can now use the client implementation in Metro to access the STS provided by the .NET Framework.

Congrats to Clemens, but also the Metro team (namely Jiandong and Harold).

tag: Interoperability, WS-Trust, Metro, BizTalk Services

When you are working with Glassfish (like I am doing now), you might need to capture your HTTPS traffic. In an earlier post, I explained how to capture and decrypt any SSL/TLS traffic, as long as you have the server private key.

While this method is quite effective and universal, it is still a little cumbersome, especially since the actual SSL decoder in Wireshark is not yet fully integrated into the analyzer itself.

For Sun's Glassfish application server, there is a fairly simple way to monitor any web services HTTPS traffic:

simply go into the domain.xml file of your domain and add the following <jvm-options>:

<jvm-options>-DWSIT_HOME=${com.sun.aas.installRoot}</jvm-options>
<jvm-options>-Dcom.sun.xml.ws.transport.http.HttpAdapter.dump=true</jvm-options> <jvm-options>-Dcom.sun.xml.ws.transport.http.client.HttpTransportPipe.dump=true</jvm-options>

The server.log (in <installRoot>/domains/domain1/logs) will then contain the fully assembled web services exchanges.

tag: glassfish, java, wsit, SSL, HTTPS

keytool is a useful utility for dealing with Java keystores, but it has a significant disadvantage: you can not export private keys with a certificate using keytool. Therefore, the only thing you can so is to add the certificate as a trustedCert into the keystore, but not as a keyEntry.

Obviously, this is easily possible through the programmatic interface, but that can be hasslesome at times. At http://couchpotato.net/pkeytool/ you can find a really nice little tool that allows you to extract the private key in a separate file, and then re-import the private key file and the cert into a new keystore.

tag: security, java, keytool

In order to go through some exercise here, I recently needed to create a few Java classes from XSD schema. "Well," I thought, "JAXB with its integrated XJC is your friend!" And so it is, but you might have to dig a little deeper.

The problem I was facing was a schema that had references to WS-Security, XML Encryption and XML Signature. As such, it imported all these schemas from the web using <xsd:import namespace="..." schemaLocation="http://..." />. Since xjc is pretty flexible, accessing these schemas on the web was a charm, even through the firewall. After all, this is much better than downloading all the referenced schemas (and all schemas they reference) and edit the imports to point to the right location in the file system.

Well, not so quick. In their infinite wisdom and foresight, the schema developers at OASIS and W3C decided to use different schema locations for XML Dsig. They reference the same schema (with identical namespace, obviously), but import through different schemaLocation URIs. That confuses xjc to no end, since it detects a re-definition of the same object and gives up.

In order to resolve this problem, you can create an XML Catalog, that allows you to rewrite (or redefine) URLs referenced in you schema. Here is an example:

This simple catalog redefines the URI used by the XML encryption schema to point to the one used by OASIS. The XML Catalog specification provides many more options, and it is good to know that xjc supports this.

While this is quite simple, I found it relatively hard to find concrete examples on how to use this mechanism.

tag: XML Catalog, XML Schema, XSD, JAXB, XJC, Data Binding

tag:AJAX, jMaki, Silverlight, Interoperability

Now - here is something quite interesting about Java directions: I was only remotely aware of JSR 277 - Java Modules - and took really no big interest in it. However, this effort might solve some of the self-inflicted problems that I had to deal with regarding OSGi bundles.

JSR 277 (which is currently in early draft) aims at provinding a simple class versioning mechanism that allows some of the features of OSGi bundles. Stanley Ho has written some explanatory material on this JSR - from what I could gather, it should be - at least principally - not too hard for OSGi to deal with Java Modules. Now if we only could get it working the other way round ...

David Chappell made some interesting remarks on Java and NetFX during his TechEd session and on his blog. He compares the creation of SCA by IBM, BEA and some others to the creation of the .NET Framework in 2000.

I would put this somewhat differently: .NET in 2000 was a (somewhat late) reaction to the success of the Java platform. As .NET evolved, itwent - essentially - through the same issues as Java: 1.0 was essentially unusuable, 1.1 kinda worked, and 2.0 (or 1.2 in Java) is/was the first truely usable platform. In this sense, SCA is comparable to the announcement of the Longhorn pillars, at best.

In his TechEd session this morning, David was trying to compare SCA with WCF. He noted that while WCF is in its final beta stages, SCA is just starting with the definition. This is certainly true. However, there are other simplifying APIs (such as EJB3, JBI/OpenESB, WSIT) that have a similar architectural scope as WCF and are in final beta as well. I strongly recommend reading the comment section of David's blog article as well, since it contains a lot of interesting pointers.

At this time, most of you have probably heard about the Web Services Interoperability Toolkit for Java (a.k.a. Project Tango), which enables maximal interoperability between the upcoming Windows Communication Foundation on .NET and the Java world. If not, go see http://wsit.dev.java.net/ ASAP.

WSIT will be tightly integrated with the Glassfish Sun Application Server, which also features full FastInoset support. In fact, Glassfish will - based on the HTTP header content type - automatically switch between text+xml and application/fastinfoset.

Now, with the WCF integration that FIFI will deliver, you will be able to configure an Indigo client at deploy time (or even after) to use the by far more efficient FI encoding. And this (re)configuration will only take a change in a single line in the .config file of that client (assuming that you are using a CustomBinding in the first place ;-)).

So, at the end of the day, you can start you deployment of SOAP and RESTful Web Services with angle brackets and as soon as you need a more efficient encoding, you switch to FI by simply setting the right config parameter in the WCF client. Can it be less painful?

You might know that StAX (JSR 173) and the System.Xml.XmlReader/Writer classes are quite similar, at the very least in scope. A very interesting difference (that gave me a lot of grief in porting/implementing these APIs) is the way namespace attributes are being treated.

In StAX, namespace attributes are typically dealt with through different calls than those used for 'normal' attributes. This special treatment also comes with a table, where defined namespaces can be stored and referenced. In .NET, a namespace attribute is just another attribute, but they also have an XML namespace table, managing prefixes and scope.

While the differences are only significant on layer 8 and 9 of the ISO stack (politics and religion), porting from one to the other API is quite interesting and - at times - forces you to think about the infoset in new ways.

On May 17, 2006 at 9:30pm Paul, Santiago and I will host a BOF on "Project FIFI - Bridging the Interoperability Chasm". FIFI (Fast Infoset For Indigo) is a prototype project that aims at bringing the Fast InfosetITU-T/ISO standard to the .NET 2.0 platform and furthermore integrating it with the upcoming Windows Communication Framework (WCF - aka Indigo).

BOF 2535: Project FIFI - Bridging the Interoperability Chasm
Track: Web Tier
Room: Hall E 135
Date: 17-MAY-06
Start Time: 21:30

Stay tuned for more.

Fresh from Washington state: Indigo to support POX in TextEncoder

Combine this with Marc Hadley's adventures with REST in JAX-WS, and you might actually get something interoperable .. ;-)

Today, Sun opens their Enterprise tools to the NetBeans community. This is really good news for Java developers, since they now get a truly modular, extensible, easy-to-use and easy-to-install IDE, that features:

• UML modelers (both ways)
  
• XML tools
• SOAP orchestration
  

This is obviously in addtition to the Matisse UI builder, the profiler, the J2ME development tools etc. Also, the NetBeans platform is now also being used for non-development applications (see e.g. the Stocktrader application).

Marc is working on a nice and *clean* web application description language (WADL) that can be used for non-SOAP web services as well.

For an introduction to RESTful web services with JAX-WS, please take a look at his recent post. It might be an interesting excercise to get this to work with Clemens' RESTful extension for WCF.

It's a little geeky and doesn't carry much importance, but I just liked it from a political point of view...

NetBeans 5.0 Beta on Windows Vista September 2005 CTP:

I used the 1.5.0 update 5 JDK (from http://java.sun.com/) and the recently released NB installer ... worked like a charm and even the bugs are the same as under 2003 and XP. The icons in the file chooser dialog were also matched to the new Vista UI .. looked nice.

The new NetBeans web services client is quite nice. It is now almost as easy as with Visual Studio to integrate a web service into your application: After pointing the IDE to the WSDL, it generates the necessary proxies and you can then integrate them by right clicking your methods in the source editor and add web operations:

This works right out of the box with ASP.NET 2.0 web services, although it has some issues with complex types (like e.g. an ArrayList). Those get deserialized as SOAPElements which is workable, but requires some SOAP DOM coding.

Indigo (WCF) web services seem to have more issues - I guess this is related to Microsoft splitting up the WSDL into some smaller files (wsdl1, xsd0, etc.)

If you are looking for a Java IDE, please take a look at the latest Netbeans 5.0 beta: http://www.netbeans.org/

Some of the new features:

• Support for Tomcat, Sun Application Server, BEA WebLogic and JBoss
• Massively improved GUI builder (Matisse)
• Web Services client support built-in
• Web Frameworks (JSF or Struts), including palette drag-and-drop

I will post more about this a little later.