Ruben's Weblog

CQ Blueprints

reusr1 — Tue, 01 Nov 2011 13:42:45 +0000

A year ago, Adobe bought a content management system called Communique (CQ) from a company in Switzerland, Day Software AG. The content management is built on Apache Sling and Apache Jackrabbit with some additional customizations. Adobe has taken the software stack from Day and made it the backbone of it’s LifeCycle enterprise platform. It also rebranded Adobe CQ and the Sling/Jackrabbit stack (called CRX in the Day world).

CRX is now called ADEP (Adobe Digital Enterprise Platform) and they merged the Adobe LifeCycle functionality into it.

CQ (Communique) is now called WEM (Web Experience Management) and is an application on top of ADEP.

The naming of these products is a bit unfortunate if you want to google for information and help about the platform.

CQ Blueprints (started before the branding change) is a website dedicated to best practices and tips and tricks for the ADEP/WEM platform. It now also features a customized google search that indexes ADEP/WEM related resources and makes it easier for the day to day work of a developer to find information that pertain to the platform.

Check it out at http://www.cqblueprints.com

Unifying your Web Applications with a common look through Apache Server Side Includes (SSI)

reusr1 — Mon, 17 Oct 2011 15:30:54 +0000

Most larger organizations have a set of web applications exposed to their customers. Some of those applications are grown in-house, some have been purchased. Each application has it’s own release cycle and therefore it becomes quite a bit of a problem to make common changes to all applications. Say your company has a new logo or is adding one more application to the top and bottom navigation of all sites, you end up having to touch each application and make the required modification in the header and footer, go through a testing cycle and redeploy all applications at the same time in order to make sure the site looks consistent.

In the fast moving world where your main website is in a content management system and the header and footer of the site can be modified by the content team at any given time the approach above seems a bit out of date and cumbersome. There are a couple of different solutions pro work around this problem. I’d like to present one that has a minimal impact on all the systems in question and provides the ability to quickly change the header and footer of your site:

The following image illustrates a common environment that can be found in an enterprise:

or a deployment where the CMS is the master and adds all other applications on the fly:

The common header and footer is served from each application individually. To modify the common look, all applications have to be touched and reloaded

The solution proposed here is to use Apache Server Side Includes in order to inject the header and footer from the CMS directly into all applications. Each Application returns an SSI statement instead of the actual header:

the HTML returned would look something like this:

... normal code

By enabling SSI includes for the proxied application through a change in the apache httpd.conf such as the following

ProxyRequests Off ProxyPass /shop http://shop:8080/shop ProxyPassReverse /shop http://shop:8080/shop SetOutputFilter INCLUDES

the request from the apache server will be sent and processed by the 3rd party application and after it is returned the apache server will then use mod_includes to inject the contents of /header.html and /footer.html into the returned page. The header.html and footer.html file can also be created by the CMS and allow instant updates to the header and footer throughout the unified site to take place without any changes to the other applications.

Note: SSI can also be turned on in Apache Tomcat to run the individual applications for test purposes without the full chain of servers as in the final deployment. If SSI is enabled in tomcat then the include will happen directly on the Tomcat side of things. This however should be turned of for any test/dev/production environement where the full chain of servers is available to avoid the SSI statements to be executed on the wrong machines and introducing additional load on the application servers.

Due to the SSI includes, the Apache server is not able to figure out the content length nor the expiration date of the page – it may be necessary to use mod_expire in Apache to enable caching control.

Conclusion

The approach to use Apache Server Side Includes (SSI) to handle the unification of the appearance of your web properties is simple. It does not introduce an additional single point of failure due to the fact that the includes are injected on the existing Apache servers in the infrastructure. A caching mechanism for header/footer.html can be employed to make sure the CMS serving those files does not become a single point of failure.

As always, I’d be happy to hear your comments

Example Thick Client App with EXTJS and Java

reusr1 — Wed, 01 Jun 2011 15:45:49 +0000

Following up my last post I wrote a small sample application using Java, EXTJS, Jetty and the djproject to create a thick client experience based on these components. I chose the djproject instead of mozswing since it is a lighter download and integrates with an existing web browser on your system instead of bundling an additional web browser with the application.I also provided a power point presentation that runs through the project and explains how it is implemented.

download at http://www.headwire.com/public/en/hw/downloads.html

As always, please let me know what you think about this post.

Writing a Thick Client Java Application with EXTJS

reusr1 — Wed, 20 Oct 2010 17:15:18 +0000

update: example application

I have been writing thick client applications in Java for a while now. You can produce nice applications with Swing if you know how to and have the right tools and libraries at hand. Lately, however, some of our clients made me rethink the approach for thick client development. We were asked to develop a thick client application for Windows, Mac OSX and Linux. The customer also pointed out that in the future they would like the same application to be web based. This made me rethink the Swing strategy and bring back an older concept we developed for a customer back in 2000. The project is still online at http://www.tisca.com/tisca-tiara/handtuft/select/en/index.html. It’s an online carpet configurator allowing the customer to color and custom order a carpet. The project was initially delivered over the web but was also distributed to stores on a CD, allowing the store owners to run the application on a local computer without an internet connection. The approach taken was simple: an autostart executable on the CD runs a webserver as well as a web browser without navigation bars, etc, as one application. To the store, the application looks like a thick client, on the web, it’s just another AJAX style web application.

Back to 2010, we know have libraries such as EXTJS that bring an application look and feel to your web application. Out of the box, EXTJS supports more feature rich components than are supported by Java/Swing. Firefox is a great browser and the mozswing project allows you to bundle Firefox into your Java/Swing application. if you combine this with an embedded web server such as Jetty you can write and deliver a thick client application the same way you deliver a web application. The hybrid approach allows you to handle parts of your application such as file dialogs, etc in Swing. Once a user selects a file to load, you can make a javascript call from your Java/Swing application into the MozSwing browser window to communicate back to your local web server to load the file.

Using this technology stack allows us to deliver a rich thick client experience and at the same time reuse most of the code, apart from specific features such as file dialogs.

The following is a screenshot of the current application we’re building:

Please let me know what you think about this approach. If there is enough feedback I’ll follow up this post with an example application for you to play with.

An example implementation can be found here http://ruben42.wordpress.com/2011/06/01/example-thick-client-app-with-extjs-and-java/

Easy PDF Production

reusr1 — Sun, 24 Jan 2010 16:33:18 +0000

I have been looking for a good way to produce PDF documents and merge data into the documents as well as enable or disable different sections of the documents depending on certain conditions. The idea is to produce larger PDF documents for insurances and banks as easy as possible. Most of the approaches I have seen so far require one to produce a PDF with Word and then Adobe Acrobat Professional to create form fields on top of the PDF. Once that’s done, the dynamic data is filled into the PDF form by a ‘stamping’ process and the PDF fields are removed at that time.

Others just entirely produce the PDF document with a library such as iText, PDFBox or some other PDF creating making the approach very developer centric.

I was trying to find a better solution to handle PDF document creation within server based applications. I wanted to just annotate word or open office documents and use them directly to create the PDFs. No need to create A PDF from the word document anymore and no need to create A PDF form anymore. We could save a lot of time in development this way.

I thought if one can convert an open office document to FOP then you can render FOP as PDF as well as modify the FOP document on the fly to add the data into the output PDF. I found the following project on sourceforge: Office2FO – to my surprise, the creators of that project also created Inforama – a full editor and server suite to do just what I wanted to do.

Inforama can take a n open office document and your datasources, merge the data together and produce good looking, easy to maintain PDF documents

A great solution to finally make PDF production easier! I’d like to know what you think about this application and what your pain points are with creating PDF documents.

What is the easiest way to create a custom JComboBox Popup?

reusr1 — Thu, 28 May 2009 17:18:52 +0000

If you want a swing JComboBox popup that is not a list (say you want to do a calendar) it would be great to be able to just replace the popup used with your own implementation – you can do that by subclassing the look and feel class and do your own implementation of the Combo Box but you will have to do that per look and feel that you support and what if you want to support every look and feel?

Can you help? What is a good suggestion to circumvent the Look and Feel Problem? Your comment is appreciated!

Catching all Runtime Exceptions in Swing

reusr1 — Mon, 30 Mar 2009 05:27:05 +0000

[note: see my post about writing a java thick client applications using extjs]

So you got some framework that you are using in your swing application and it throws a runtime exception. The Exception is thrown all the way out and ends up on the system.out – very nasty, not good looking and doesn’t help us determining that there is a problem in our application. We might just go on and do the same task again even though the exception was telling us that something went fatally wrong and that it probably would be a good idea to change the state of the application, go into recovery or terminate gracefully.

What can we do to prevent this? We can use try/catch clauses all over the place whenever we call some third party code but that is neither fun nor good code. And still there can be some exceptions slipping by – or are you really sure your code never throws a null pointer exception? Really?

There is an easier way to deal with this problem: All swing activity originates from the event queue and therefore all events are thrown to the event queue as well. So in order to catch all runtime exceptions such as a null pointer exception we can just use the event queue.

We just need to extend EventQueue and overwrite the dispatchEvent method.

class EventQueueProxy extends EventQueue {

	protected void dispatchEvent(AWTEvent newEvent) {
		try {
			super.dispatchEvent(newEvent);
		} catch (Throwable t) {
			t.printStackTrace();
			String message = t.getMessage();

			if (message == null || message.length() == 0) {
				message = "Fatal: " + t.getClass();
			}

			JOptionPane.showMessageDialog(null, "General Error", message, JOptionPane.ERROR_MESSAGE);
		}
	}
}

The proxy class still calls it’s parents dispatchEvent method and catches anything throwable. When it does, it pops up a simple dialog.

Only thing remaining, we need to install our new event dispatcher on the event queue.

EventQueue queue = Toolkit.getDefaultToolkit().getSystemEventQueue();
queue.push(new EventQueueProxy());

Using this method one can also use exceptions to handle errors throughout a swing application – dealing with errors and exceptions ends up at one place in the application this way and can be used to transform the exceptions into human readable error messages.

For some other helpful links for building swing applications have a look at helpful-java-swing-articles

Analyzing Open Source Projects as a Computer Science Class

reusr1 — Sun, 25 Jan 2009 18:05:50 +0000

Looking back at my time studying computer science I remember I learned a lot from the operating system class. The professor implemented his own variation of Xinu (http://en.wikipedia.org/wiki/Xinu) and then discussed parts of the implementation with us and left some things as an exercise for us to implement. It was one of the harder classes since there was a lot of lab work to actually complete the assignments but I still think about what we did in that class a lot and it gave me a good insight that I still use today.

Since I graduated a lot happened in our industry – as everybody knows, there are more open source projects than one can count. The lessons I learned from Xinu – looking at an architecture and analyzing an implementation – could also be learned from analyzing multiple open source projects and comparing their architecture and design, judging their quality, elasticity (how easy is it to extend and advance them and in what areas), appearance and complexity (complexity of code compared to functionality and overall learning curve complexity to start work on the project).

Analyzing existing code in such a way can be a good entry point into understanding projects and preventing the ‘can not fix because not written by me/it’s not good we have to redo this’ attitude a lot of developers have and would help giving a developer a better feel when a project can not be saved anymore.

I therefore suggest to add a class to computer science studies where the students take apart a set of open source applications and write a paper on their findings. It would be great if those findings should then also be published and available to everybody on the Internet in some public form.

Google Chrome JavaScript Speed Compared

reusr1 — Tue, 09 Sep 2008 23:37:15 +0000

By now everybody knows Google Chrome beta is available and we have all seen the claims about JavaScript speed. It’s one thing to read about it, it’s another to actually see the speed difference. So I figured I’ll write a little test program checking out how much faster Google Chrome and JavaScript in Google Chrome actually is. This test is by no means a complete test – the claim that JavaScript is faster should be across the board – therefore doing one test with some specific features should be faster otherwise the claim is not really true, now is it?

I’m an old Commodore C64/Amiga guy – so one thing I always liked back then were the copper bars. In short, the C64 and Amiga allows you to change the color of the screen background per line or even per a certain amount of pixels. The computers also had some vertical blank interrupt allowing you to run some code every time the monitor beam is at the top of the screen. People then wrote cool color bars floating around, nicely animated at 50Hz per second. I figured I can do a similar effect in the browser by using a div per raster line and altering the colors with an interval timer every 20ms.

The sample html page can be found here: http://www.headwire.com/javascript/chrome.html

The image to the right is a screen shot of the copper bars running in Google Chrome.

sample copper bars

Speed test results running on a Dell Latitude D820 under Vista:

Browser	200 lines
Google Chrome	~97 frames/sec
Firefox 3	~70 frames/sec
IE7	~20 frames/sec

Update: the nightly minefield (firefox beta) gets about 80 frames/sec.

Observation: the test is of course not just a JavaScript speed test but also a test on how fast changes that are made to the DOM can be reflected on the screen. If not using DIV’s but an image to perform the same test (using the JavaScript BMP Library [not supported in IE7]) we see a 50% speed increase for Google Chrome vs Firefox3. Update: Minefield actually beats chrome on this test by about 10%

A couple of notes:

There is a faster way to do this if the program does not have to run in IE. You can actually create an inline image with JavaScript with the JavaScript BMP Library (http://neil.fraser.name/software/bmp_lib/). The library allows you to convert an array of color information and a color pallet into an image. Update: bmp creation with minefield seems to be faster than with any other browser.
I did not test with IE8 Beta on Vista since trying to run it forced me to apply the whole windows update and that used an awful lot of disk space (2+ GB)
When running into limits (two may lines updated, computer getting slow and running the test in multiple browsers) Google Chrome was way more responsive than Firefox3
There seemed to be no big difference in speed between Firefox 3 and the current beta with the updated JavaScript Engine (Shiretoko).

As always, would love to hear your comments on this one.

Running Java in .NET

reusr1 — Wed, 13 Aug 2008 16:18:41 +0000

Did you write a java library but now some of your customers would like to use the library in their .NET code? Or do you have a .NET library and you need to integrate with a java application? There is this great tool out there called IKVM (http://www.ikvm.net) – it allows you to cross compile the byte code to the .NET CLR and then run it on top of the .NET framework (swing excluded).

If you have not yet, you have to try this tool. We used it to bridge a java RMI client library to .NET code. So now the .NET application calls the Java RMI client that then calls it’s Java RMI server. Sure, we could have implemented a .NET client to call the server side but this was easy (a days work to play with the tool, get to know it and do the implementation).

Would love to hear from you what you think about IKVM and what you’re experience with it was.