Skip to main content

Posts

Sedna XML DB and RelWithDebugInfo mode

Once we had a severe issue with Sedna hanging regularly. It was caused by broken indexes after an upgrade at that moment. The issue caused quite a nightmare and led to a lot of time wasted until we solved it together with Sedna devs. Since that moment it has become very important to be able to look into what is happening inside Sedna at any particular moment. Fortunately, there is a suitable way although it's not documented properly on the Sedna website. All you need is to build Sedna from source with a special flag RelWithDebugInfo . Cmake build modes. Using gdb. Using netstat. Cmake build modes Cmake has several build modes with Release and Debug obviously among them. Another mode that can be of big use is called RelWithDebugInfo . There is a perfect explanation for it on the mailing list : The difference between Debug and RelwithDebInfo is that RelwithDebInfo is quite similar to Release mode. It produces fully optimised code, but also builds the program database, and in

Customizing oXygen Author Component

In this article I'm going to guide you through the process of customization of oXygen Author Component . More specifically I'm going to create a new operation for the DITA framework that will generate and insert an xml fragment into the current document. While you can find the official documentation on this topic very useful, it misses any real code examples. Of course, you can download the author component startup project but it'll help those looking how to integrate the component as a Java Applet, thus, it's slightly irrelevant for us. Requirements In order to make a customization for the Author Component you need to have an oXygen standalone installation. For the development of Java customizations you'll need oxygen.jar on the classpath. This library is available in the oXygen installation directory as well as in the Author SDK project and in the author component startup project. Moreover, inside last two resources you can find javadocs and partial source

Play Framework with RequireJS and YUI

I've concluded an older post with a promise to investigate the issues of integration of Play Framework with RequireJS and YUI . Finally I've got some time to resolve all issues so I'm going to showcase a working sample multi-page project in this article. Sample project. Issues. Sample project Play Framework offers a nice official tutorial for RequireJS-support . However, it appeared that not all RequireJS features are fully supported by Play Framework yet (see below in Issues section). So it required some tuning before everything started working. I've published a sample project on github so you're welcome to look into it. Some of the issues that I faced are described in the section below. Here I'm going to show a couple of screenshots of the sample application. This is how one page of the application looks like: Below is the screenshot of the network tab of the Google Chrome developer tools showing all page resources in the production mode. You c

YUI Cross-Domain transactions without Flash

Recently I've worked on the application making cross-domain ajax calls with YUI . While YUI offers io-xdr module for making cross-domain requests via Flash transport , it seems to me quite unnatural as it leads to unnecessary complexity. Moreover, io-xdr was marked deprecated several months ago without explicit mentioning the preferred way. An obvious alternative is using XMLHttpRequest as a transport for cross-domain requests. However, it has some limitations and undocumented pitfalls that I'd like to review in this post. Cross-Domain request using XMLHttpRequest. YUI IO Utility. YUI Datasource IO. Cross-Domain request using XMLHttpRequest Cross-domain requests can be sent using a common XMLHttpRequest object. The only requirement is that the server must be configured to properly handle those requests. Specifically, it should set the Access-Control-Allow-Origin response header according to Cross-Origin Resource Sharing specification . For more details and good tuto

Analysis of network issues with tcpdump and wireshark

I've recently had to deal with the application connectivity issue (details on stackoverflow ) that appeared after the migration of the application to a new server. It resulted in "Connection timed out" Java exceptions in certain cases. The answer was on the surface but I didn't know where to look at exactly. So I had to investigate and apply network sniffing tools such as tcpdump and Wireshark . Here I'd like to share my experience with the network analysis. The issue and the cause. Wireshark. Tcpdump. The issue and the cause The following exception was thrown by Saxon XSLT processor when the document function was invoked: Caused by: org.apache.commons.lang.exception.NestableRuntimeException: net.sf.saxon.trans.DynamicError: net.sf.saxon.trans.DynamicError: java.net.ConnectException: Connection timed out at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) at j

My first Play Framework application

My first Play Framework application has recently gone live. This time it was the Java version of the framework, next time I may move on to Scala finally. Nevertheless, I've learned a lot and will try to share some knowledge here. The application is meant for managing the data stored in the Dydra graph database ( RDF & SPARQL ). It's a thick client application meaning that the data loading happens in the client JavaScript layer via JSON requests, while routing and user authentication is done by means of Play Framework. Also I've made use of the RequireJS support in Play Framework for dynamic JS module loading. For the UI I've chosen a well-known YUI library . More details are following below. Application architecture. User model and authentication. Dydra database layer and SPARQL client. JavaScript logic and YUI. RequireJS module loading. Application architecture As any web application, this one can be described in terms of MVC pattern . Play Framewor

Cocoon refactorings

I've been maintaining a complex Cocoon application for a couple of years now. Unfortunately, as the code gets older, it requires more and more time for maintenance unless you keep it clean and neat from the beginning. Finally I've found time to refactor the project gradually and I'll try to keep it this way. In this article I'm going to review the steps I've taken to improve the code and build quality. Remove duplicated resources I've started with removing duplicated and unused resources (mostly images and icons). Many of them were duplicated across the application in several Cocoon blocks. So I had to keep common resources in a single shared block and modify references from other blocks accordingly. For this I've added the following sitemap rule into all blocks: <map:match pattern="shared/resource/external/**"> <map:read src="servlet:shared:/resource/external/{1}"/> </map:match> This single improvement decre