Tuesday, November 8, 2011

Easy XSLT without installing anything


Sometimes you need to apply an XSLT to some XML, and there are (at least) a couple of ways to do it:

(a) Install a processor like Saxon and run it through the command line;
(b) Reference an XSLT from your XML file, and then open it in a browser;

Both are somewhat problematic - the first one requires installing and running something, and the second requires modifications to the XML. I propose a useful and effective alternative, which I've been using successfully for quite a while. The idea is as following: you simply open a special HTML in a browser. This HTML contains a JavaScript that loads both XML and XSLT files, applies the transform and renders the result into its own DOM. Here is the HTML I use, it is really simple and works in both IE and Mozilla. All you need to do is replace the filenames (input.xml and template.xsl):
<html>
<head>
<script>
function loadXMLDoc(fname)
{
var xmlDoc;
if (window.ActiveXObject)
{
xmlDoc = new ActiveXObject("Microsoft.XMLDOM");
}
else if (document.implementation && document.implementation.createDocument)
{
xmlDoc = document.implementation.createDocument("","",null);
}
else
{
alert('Your browser cannot handle this script');
}
xmlDoc.async = false;
xmlDoc.load(fname);
return(xmlDoc);
}

function displayResult()
{
xml = loadXMLDoc("input.xml");
xsl = loadXMLDoc("template.xsl");
if (window.ActiveXObject)
{
ex = xml.transformNode(xsl);
document.getElementById("content").innerHTML = ex;
}
else if (document.implementation && document.implementation.createDocument)
{
xsltProcessor=new XSLTProcessor();
xsltProcessor.importStylesheet(xsl);
resultDocument = xsltProcessor.transformToFragment(xml,document);
document.getElementById("content").appendChild(resultDocument);
}
}
</script>
</head>
<body onLoad="displayResult()">
<div id="content" />
</body>
</html>

A sample use case: you have an application which logs some data into an XML file at a given location. You write an XSLT that filters errors in this log, and adjust the filenames inside the HTML above. You save this HTML on your Desktop, and every time you open or refresh it, it shows you the current errors in the log. It is easier and more user-friendly than running BAT-files saving output of transform into some temporary HTML and then opening it.

Friday, January 14, 2011

Meet Flowkeeper, a new open-source software timer for Pomodoro Technique

I want to present you the very first version of Flowkeeper - yet another free software timer for Pomodoro Technique. Initially it was designed as a desktop UI for Pomodoro Server - my another project supporting teamwork for PT. Despite the almost-ready-for-production state of the latter one, I decided to implement both online and offline modes in Flowkeeper, and release offline-only version first. So here it is, ready for download :)

Some of its features:
  • Your plans are persistent and can be viewed after the program is closed;
  • Configurable timer sounds and system tray notifications;
  • Some basic single-day statistics;
  • Supported platforms: Windows (with installer), Linux KDE, Linux Gnome (no system tray), MacOS (reported, but no details yet);
I am pretty ambitious about this project. Here are some of the features to be included in the next version, just to name a few:
  • New multiplatform installer;
  • Activity Inventory;
  • Better statistics;
  • Source code will be published on SourceForge;
So, keep tuned and don't hesitate to contact me.

Wednesday, June 30, 2010

Oracle driver in Maven

This is just a short reminder how to add Oracle driver as a dependency in POM.

In pom.xml:

<dependency>
<groupid>com.oracle</groupid>
<artifactid>driver</artifactid>
<version>10.14</version>
</dependency>


In command line:

mvn install:install-file -Dfile=PATH_TO_DRIVER/ojdbc14.jar -DgroupId=com.oracle -DartifactId=driver -Dversion=10.14 -Dpackaging=jar

Saturday, April 17, 2010

Fluent Interface Inheritance

Fluent Interface is a convenient way of writing DSLish code in the general-purpose programming language. Some of the examples are quite impressive. But there comes a problem when you try to reuse this pattern via inheritance, because the basic method chaining implementations do not actually support it very well. I will use a JPA example found in Wikipedia to demonstrate the problem:

public Collection<Student> findByNameAgeGender(String name, int age, Gender gender) {
return em.createNamedQuery("Student.findByNameAgeGender")
.setParameter("name", name)
.setParameter("age", age)
.setParameter("gender", gender)
.setFirstResult(1)
.setMaxResults(30)
.setHint("hintName", "hintValue")
.getResultList();
}

Looking at this code we can now create a naive Query implementation:

public interface Query {
Query setParameter (String name, Object value);
Collection getResultList() throws SqlException;
}

public class PreparedSqlQuery implements Query {
protected Map params = new HashMap();
public Query setParameter (String name, Object value) {
params.add(name, value);
return this;
}
public Collection getResultList() throws SqlException {
// Execute query and return results
}
}

public class SimpleQueryUser {
public static void main(String[] args) throws Exception {
new PreparedSqlQuery().setParameter("name", "value").getResultList();
}
}

No problems at all, our Fluent Interface is clean and elegant. But what happens when you create a subclass for executing prepared statements? You don't want to implement all that multiple setXxx methods once again, and instead decide to inherit from PreparedSqlQuery:

public class StoredProcedureCall extends PreparedSqlQuery {
protected String outputParameter = null;
// Stored procedures may have both input and output parameters
public StoredProcedureCall setOutputParameter(String param) {
outputParameter = param;
}
public Collection getResultList() throws SqlException {
// Execute stored procedure and return results
}
}

public class SimpleQueryUser {
public static void main(String[] args) throws Exception {
// This works fine
new StoredProcedureCall().setOutputParameter("OUT").setParameter("name", "value").getResultList();
// This produces compilation errors
new StoredProcedureCall().setParameter("name", "value").setOutputParameter("OUT").getResultList();
}
}

The second oneliner produces a compilation error because Query object returned by setParameter() does not actually have setOutputParameter() method. To address this problem we can use return type covariance, which is a language feature added to Java 5. Here goes a fixed version of our StoredProcedureCall:

public class StoredProcedureCall extends PreparedSqlQuery {
protected String outputParameter = null;
public StoredProcedureCall setOutputParameter(String param) {
outputParameter = param;
}
// Compiler allows us to use StoredProcedureCall instead of Query as the return type here because StoredProcedureCall implements Query
public StoredProcedureCall setParameter (String name, Object value) {
super.setParameter(name, value);
return this;
}
public Collection getResultList() throws SqlException {
// Execute stored procedure and return results
}
}

Actually you can see exactly the same approach used in the real-world Query implementations, like OpenJPAQuery. Now what if you don't want to override all that numerous setXxx methods in all subclasses just to change their return types? Here is my solution utilizing another Java 5 language feature - Generics:

public interface Query <T extends Query >{
T setParameter (String name, Object value);
Collection getResultList() throws SqlException;
}

public class PreparedSqlQuery<S extends PreparedSqlQuery> implements Query<S> {
protected Map params = new HashMap();
public S setParameter (String name, Object value) {
params.add(name, value);
return (S) this;
}
public Collection getResultList() throws SqlException {
// Execute query and return results
}
// Hide constructor, use factory to ensure users won't try to do something like: new PreparedSqlQuery<StoredProcedureCall>().setOutputParameter
}

// We make it generic too to enable further extension
public class StoredProcedureCall<R extends StoredProcedureCall> extends PreparedSqlQuery<StoredProcedureCall> {
protected String outputParameter = null;
public R setOutputParameter(String param) {
outputParameter = param;
return (R) this;
}
// Note we don't have to override setParameter here
public Collection getResultList() throws SqlException {
// Execute stored procedure and return results
}
}

public class EntityManager {
public static StoredProcedureCall<StoredProcedureCall> createStoredProcCall() {
return new StoredProcedureCall<StoredProcedureCall>();
}
public static PreparedSqlQuery<PreparedSqlQuery> createNamedQuery() {
return new PreparedSqlQuery<PreparedSqlQuery>();
}
}

public class SimpleQueryUser {
public static void main(String[] args) throws Exception {
EntityManager.createStoredProcCall().setParameter("name", "value").setOutputParameter("OUT").getResultList();
}
}

All that trickery with generics is done to fool the compiler. Good thing about it is that no additional methods are created, that means there are no super calls, which can potentially improve runtime performance. Bad things are obvious too:
  1. It is not safe unless you are using factories to instantiate that builders;
  2. It is definitely not obvious and looks ugly;


Disclaimer: this is a hack, never use it in your code :)

Friday, January 29, 2010

WebSphere + GWT + Comet

IBM supports Reverse AJAX (AKA Comet) in a form of WebSphere Feature Pack for Web 2.0 for WebSphere Application Server 6.0+. It is shipped by default with the latest fix packs for WAS 6.1 and in all 7.0 versions. Actually this Feature Pack has a lot of nice Web 2.0 features, but at the moment we are interested in Web Messaging Service only.

To install and enable FP you need to follow the documentation, it won't take long. As the result you will get the ability to push data to your client's web browser by publishing it to the special JMS topics. As an alternative, you may also use a more specialized API for doing this, but the Publisher object is stored in the Servlet context, therefore it can be somewhat tricky to access it from an arbitrary part of your application, which is not true with JMS.

I assume that you have successfully installed and tested your Web Messaging, and now want to upgrade your QuoteStreamer sample application to GWT. For example, you have a widget and want its methods to be called when some data arrives from the backend.

It is possible to use JSNI to achieve exactly this goal. The idea is simple: when you need to push some object to the client (for example, out of your Message Driven Bean), you first serialize it using GWT RPC mechanism, then put the resulting string to the appropriate JMS Topic. This string is wrapped to JSON envelope, sent to the client via WFP and unwrapped there via Dojo. Your JavaScript listener should be triggered at this moment. But as we use GWT for all our JavaScript programming, we should implement that listener as JSNI snippet:
private native void initCallbackAndSubscribe (String someParam) /*-{
if ($wnd.dojox) {
$wnd.dojox.cometd.subscribe("/test/" + someParam, this,
function (comet) {
module.@com.test.MyCoolWidget::onReverseAjax(Ljava/lang/String;)(comet.data)
});
}
}-*/;

// This is a normal Java code
public void
onReverseAjax(String msg) throws SerializationException {
SerializationStreamReader r = ((SerializationStreamFactory) svc).createStreamReader(msg);
Object data = r.readObject();
// Do something with that data arrived
}
As you see, the data is deserialized later in your normal Java code called by this listener. That's it. If you have initialized everything right (in your index.jsp or some similar place), this scheme should work fine. Now I will show you how to send data using GWT RPC. It should be simple via RPC.encodeResponseForSuccess method, but there is one problem - it requires SerializationPolicy object for the security reasons. This mechanism restricts serialized objects to the limited set described in *.gwt.rpc files, generated during compilation. Another problem is that there can be several such files. I haven't found a good way to get the SerializationPolicy other than by concatenating these files altogether:
public SerializationPolicy getSerializationPolicy() throws Exception {
String result = "";
for (File file : new File(PATH_TO_YOUR_GENERATED_STUFF).listFiles(new FilenameFilter() {
public boolean accept(File dir, String name) {
return name.endsWith(".rpc");
}
})) {
result += (FileUtils.readFileToString(file));
}
return SerializationPolicyLoader
.loadFromStream(new ByteArrayInputStream(result
.getBytes("UTF-8")), null);
}

public void publishObject(String topic, Object obj, Method method) throws Exception {
String r = RPC.encodeResponseForSuccess(method, obj, getSerializationPolicy());
publishStringViaJms(topic, r.toString());
}
I forgot to mention that RPC.encodeResponseForSuccess requires a Method instance, but it is used only to extract the return value type, so any method returning the object of the obj.getClass() type will do.

In general, there are some good things about such WebSphere + GWT + Comet integration, the major one is that it uses WFP, which is a pretty powerful Comet server, compared to some custom-built solutions. For example (at least on WAS 7.0), it uses connection multiplexing, nio and all that cool stuff you expect from the modern web server. Also, it naturally integrates into your ESB, so you can use it in your Process Server applications with ease. Some limitations are obvious too, for example it won't work in GWT Hosted Mode with Tomcat. Also it seems to me that this should be implemented somehow simpler, but I was unable to find it. So if you have any other ideas, please give me a clue.

P.S.: Actually, there are some alternatives to this approach. For example you can use gwt-comet-streamhub to enable Reverse AJAX for your GWT applications. But it provides its own Comet server called StreamHub which is definitely not a part of the IBM WebSphere product line :)

P.P.S.: The described method should work with other Comet-enabled J2EE servers like Jetty with minor modifications.

P.P.P.S.: There is left one more issue with security. As for now, it is not really clear for me how to implement role-based security for Comet... I can think of using several update servlets at the same time, and it should allow me to use webapp security. But this issue definitely needs further investigation.

Tuesday, January 26, 2010

WADL toolbox

WADL stands for Web Application Description Language and currently is in a state of W3C Member Submission, that means at the early stage of W3C standardization process. The purpose of the "language" is similar to WSDL, with the orientation towards RESTful APIs in the first place. What is essential for me is that this language perfectly suits the task of Pomodoro Server API description. There are surprisingly few tools utilizing this format, I guess this is due to the immaturity of the language. Though I can name some of the most useful ones:
  • Jersey, a reference implementation of JAX-RS. It is able to generate WADL at run time based on the metadata found in your Java classes.
  • soapUI, a great tool for testing web services. As one of its numerous new features in version 2.5 it can utilize WADL web service description and generate sample test cases automagically. It can even do the trick in the opposite direction, i. e. infer both WADL and XSD from the existing test case structure! Unfortunately I've found some aspects of this generation somewhat buggy not really obvious. For example, it does not inherit template parameters for nested resources. And despite the ability to specify application-wide settings for HTTP Basic Auth, it does not get applied somehow, so it should be specified for each test case separately. Anyway, it is a great tool and I'm looking forward to see it in a bit more stable state.
  • WADL to HTML is an advanced XSLT stylesheet to generate documentation from your WADLs. It seems that either my WADL is all wrong (then why it conforms to the WADL Schema?), or my XSLT processors are broken (both Saxon and Xalan running on Windows and Linux), because I was unable to get any output. But they say it works for them, so I tend to think it is actually my own problem. Anyway, I've already wrote my own simple XSLTs and going to put it here in a matter of few days :)
  • wadl2java generates a web service client based on WADL. It uses JAXB to create the necessary representations based on XSD referred in grammars section.
  • REST Describe & Compile is yet another client generator. It can infer WADL from the set of supplied request URLs, and then generate client code in several languages, namely Java and Python. The tool looks promising, but as for me, the UI is not intuitive enough. Also, you have no control over code generation, so good chances are that you will have to modify your clients manually after generation. Here you can find a great deal of documentation for the tool and underlying concepts.
P. S.: You can find WADL for Pomodoro Server here. Also you can see some generated documentation in the Google Code wiki.

Wednesday, December 23, 2009

Some useful JSR-168 resources

While trying to figure out the essentials of portlet development, I found few useful resources on this topic:
Here goes a mindmapped extract of those two: