March 14th, 2010
Reading the above quote in a blog post about CommonJS/JSGI: The Emerging JavaScript Application Platform peeked my interest. What were they talking about? Digging around I found this really interesting talk by Ryan Dahl on event-loop concurrency.
The approach resonates with me for two reasons. One, as a Java developer I’ve seen a lot of improvements related to concurrency in the last few years. Yet fundamentally concurrency remains a significant issue. It’s neither simple to make programs safe, not is it simple to test for such conditions. Two, I once worked on a high-performing trading application that was built from the start as an event-driven system where services did not return values but posted messages on an internal message bus.
It’s interesting that JavaScript, which is now building up server-side support can approach concurrency differently.
Posted in JavaScript | No Comments »
November 15th, 2009
Over the last 2 weeks I had a chance to teach the 2-day dm Server course 3 consecutive times. One of the topics that inevitably generates a lot of interest is the “uses” directive in OSGi, which is neither easy to grasp nor to explain.
My own first encounter with the “uses” directive was in the form of the mysterious “uses conflict” messages when trying to deploy bundles into an OSGi environment. I say mysterious because they mean nothing to the uninitiated and also because they require a fair amount of research. At the end I provide some links for a more complete understanding. In the mean time I’ll offer my own plain word explanation.
The ability to run multiple versions of the same bundle (or jar) in OSGi is well-known. For example I am a bundle and I need Hibernate 3.2.6.ga. You’re a bundle and you need Hibernate 3.5. We can run side by side in OSGi because the OSGi runtime creates separate classloaders for your bundle and for my bundle, which makes it possible to use different versions of Hibernate.
The problems starts if I decide to use packages exported by you. Why is that a problem? If a class exported by you returns a Hibernate type, I may try to use it, in which case I’ll probably run into problems like LinkageError because you’re essentially using a different version of Hibernate.
That’s the problem. The solution involves the OSGi “uses” directive, which lists packages used in an exported package. The OSGi resolver takes that information and works out if problems like the one above are likely to occur. If so it produces the “uses conflict” message well ahead of runtime exceptions such as LinkageError, ClassCastException, and others.
To understand the solution consider the fact that the descibed issue occurs only if I come into “contact” with a Hibernate type passed to me through one of your exported classes. If you use Hibernate internally and never expose it in your exported packages then the issue would never occur.
If you accept the above problem and solution one more thing that leads to questions is how the uses directive is maintanted. Clearly it’s a fair amount of work figuring out everything your exported packages use. That’s a job for tools like bundlor and bnd.
For more details I highly recommend looking at:
- The OSGi specification, which has very readable definitions and examples in sections 3.5.5 (Export Package) and 3.6.4 (Package Constraints).
- This blog by Glyn Normington that explains the basic problem (note the comments section where he suggests that either bundles should use matching versions or that a bundle is refactored not to export any of the types causing the conflict).
- This follow-up blog by Rob Harrop that provides a realistic example involving Spring ORM and two versions of EclipseLink. It also provides a step by step approach to debugging such issues in the OSGi console, which is key to understanding the messages then produced in dm Server. Lastly there is an interesting variation on how this problem can occur based on deployment order.
Posted in OSGi | No Comments »
September 2nd, 2009
A beta version of Hibernate 3.5 was announced last week. The release will contain initial support for a feature called fetch profiles that is really useful for retrieving different footprints of the same entity. You can see the actual JIRA ticket HHH-3414 for more details about the feature.
Why is this useful? Let’s assume you have an Person entity with 3 associations – addresses, jobs, and hobbies. Common Hibernate wisdom advises us to keep those associations with default lazy loading settings in the mappings and override them via fetch joins at runtime for each use case. This is simple enough but let’s move on. Suppose your PersonDAO has 5 queries for finding persons by first name, last name, email, age, or some combination of the above.
This is where it gets tricky. If your application fires too many queries because lazy loading is not fetching enough data up front then you’d probably consider an optimization by providing alternative finder methods that fetch the required associated entities. So you’d have findByLastName, findByLastNameWithAddresses, findByLastNameWithJobsAndHobbies, and so on. It gets pretty confusing and the full combination is 5 finders x 10 combinations (4 + 3 + 2 + 1) = 50. And this is only an example with 3 associations without considering property paths with a depth greater than 2.
What can be even more concerning in such scenarios is that in a large application a developer that runs into a lazy loading exception or realizes that some optimization is needed would probably go back and add a ‘fetch’ join potentially affecting other scenarios and bringing back more data than is needed. There is nothing in the DAO design that would make the developer consider the performance impact because things would still work.
The fetch profiles will allow a DAO to manage all this more elegantly by accepting a parameter that represents the desired fetch profile. It would also encourage the developer to consider the available profiles without running the risk of affecting the performance of other use cases adversely.
Posted in Hibernate | No Comments »
August 18th, 2009
The question why Grails has GSP when there is JSP is a natural one. Here are a few substantial differences:
- A GSP allows the same ${…} expressions as in a Groovy GString. JSP EL expressions are restricted to object navigation, which is generally a good idea but can also make it difficult to access anything that isn’t a getter (e.g. String length()). JSTL functions provide some help but the more general case requires creating static helper methods, registering them through a taglib descriptor, adding a taglib declaration, and finally using the function.
- Using Groovy in logical and iterative tags comes with major perks such as the safe navigation operator: ${customer.phones?.size()} or the Elvis operator: ${totalCount ?: 10}.
- The ability to invoke Grails dynamic tags as methods makes it easier to produce well-formed markup:
<!-- With a regular tag -->
<a href="<g:createLink action="list" />">A dynamic link</a>
<!-- As a method call -->
<a href="${createLink(action:'list')}">A dynamic link</a>
- GSP provides a much simpler mechanism for creating and testing custom tag libraries in Groovy that does not require tld files and taglib declarations and of course uses Groovy. Here is a sample test case for a Grails tag library:
import grails.test.*
class CustomerTagLibTests extends TagLibUnitTestCase {
void testRepeat() {
tagLib.repeat(times: '2') {
'output<br/>'
}
assertEquals 'output<br/>output<br/>', tagLib.out.toString()
}
}
- The Grails paginate tag. It is such a common need for web applications. In comparison to the Displaytag library I think the Grails paginate tag is more lightweight and more usable.
Posted in Grails | 2 Comments »
July 21st, 2009
I just spent an afternoon putting too much trust in the WebLogic sever tools for Eclipse. My modest goal was to modify a JSP and see the change without me having to do anything about it. It’s just a simple file copy after all.
From what I could see there are two ways to deploy my Eclipse web project. One involves an auto-generated EAR and the other an auto-generated WAR. With either option any time I changed a JSP the auto publishing feature kicked in to rebuild the auto-generated artifact (including compilation) and to re-publish to the server. For any project of a decent size (the most common kind out there) this is completely useless, not to mention unnecessary. Furthermore the republished EAR somehow managed to consistently exhaust the connection pool.
So the only thing the plugin seems to be good for is to start and stop Weblogic from within Eclipse and possibly in debug mode. Both of these I can do just as easily and more reliably from the command line. So why isn’t there an option for deploying my web project in exploded form so that a JSP change is a simple file copy? Wouldn’t that be the simplest default?
For all the “high-end” features an application server like WebLogic provides it’s amazing to me how long countless developers have to wait for each time they make a simple JSP change.
Posted in Eclipse | No Comments »
January 18th, 2009
One thing Spring JavaScript does really well is enable rich client-side behavior in your application using best practices and without the need to learn JavaScript in-depth. This is great news but sooner or later you’ll run into a situation where you’ll wonder why a form is not submitting via Ajax, or perhaps is not submitting at all. It may sound scary but it’s actually not so hard to figure out your problem.
Use the Firebug add-on for Firefox. Click on the Net tab and see if any requests (either full refreshes or Ajax requests) are going out at all. If so check use the Net tab to see the actual response returned from the server. In most cases the above information is enough of a clue. On occasion though you’ll need to break out the debugger.
Using Firebug’s Script tab find the code you need, set a breakpoint, and re-execute the test or refresh the page. It’s quite easy to start stepping through although soon you’ll step into minified JavaScript. To get around that one option is modify your JavaScript includes. For example change dojo.js to dojo.js.uncompressed.js and Spring-Dojo.js to Spring-Dojo.js.uncompressed.js.
A second and more convenient option is to extract the uncompressed versions of the files (dojo.js.uncompressed.js and Spring-Dojo.js.uncompressed.js) from the Spring JavaScript jar, and save them under the root of your web application so that they become accessible as /dojo/dojo.js and /spring/Spring-Dojo.js respectively. After you do that debugging will get much easier because you’ll no longer have minified JavaScript. If using svn set svn:ignore on these directories and you’ll never have to worry about it again for your local environment.
To understand why this works consider the fact that Spring JavaScript bundles JavaScript files in a jar and serves them from the classpath with its ResourceServlet servlet translating the URL it gets to a package location. If you however place files on the same path under the root of your web application, those files will take precedence thus allowing you to shadow resources normally served from the classpath.
Posted in Dojo, JavaScript | No Comments »
January 3rd, 2009
In the past I had looked at Dojo’s own unit tests and one thing that impressed me was the ability to double-click a local HTML file and have tests executed in my default browser.
Recently I began taking a closer look at the Dojo Objective Harness (DOH) and one of the first things I found out was that local tests could run in Konqueror but not in Firefox 3. Firebug showed errors such as the one below:
failed loading ../../dojo/./_firebug/firebug.js with error: [Exception… “Access to restricted URI denied” code: “1012″ nsresult: “0×805303f4 (NS_ERROR_DOM_BAD_URI)”
I looked around and found out that a security fix in Firefox 3 prevents loading files from sibling or parent sibling directories:
http://ejohn.org/blog/tightened-local-file-security
https://bugzilla.mozilla.org/show_bug.cgi?id=230606
The workaround for me was to put the dojotoolkit on a local server and load the tests through it. This works fine and allows me to debug tests using Firebug but it sure would be preferable to run these tests without a web server.
Posted in Dojo | 2 Comments »
December 6th, 2008
I just came back from the annual SpringOne Americas conference. As usual it was a privilege to meet and interact with colleagues, clients, and so many other attendees from the Spring community. This year I also had the pleasure of meeting Pete Higgins and Kris Zyp both from SitePen. Pete is the Dojo Toolkit lead and Kris who is also a Dojo developer has a ton of knowledge around using JSON for SOA interactions. He maintains the site http://www.json.com/.
Posted in Spring Framework | No Comments »
October 14th, 2008
It’s been almost a year since the new Spring MVC annotation-based programming model (a.k.a. @MVC) became final with Spring 2.5. A few months ago I put together an article summarizing its benefits. In my experience the flexibility of @MVC is easy to see by all who get to spend a little time with it. As an internal measure of acceptance among Spring Framework developers consider the fact that the traditional MVC controller hierarchy is going to be deprecated in Spring 3.0 (along with the JUnit 3.8 Spring test class hierarchy).
While there are no “bad” ways to use @MVC what has not yet emerged widely is a discussion on the more subtle nuances and “preferred” ways of using the annotations. For example consider this article, which puts together what the author feels are “best-of-breed” technologies in their particular niches: jQuery, Spring MVC, and XStream/Jettison. I am in no way picking on the author of the article. In fact I don’t even assume he isn’t aware of the points I’m about to make on how to improve the CarSelectorController.java with regards to the @MVC programming model.
For example the .html extension in the @RequestMapping URI can be dropped since it is ignored by the URI pattern match. In fact the entire URI paths can be dropped if the controller is used in conjunction with the ControllerClassNameHandlerMapping. I’d also lose the ModelAndView return value in favor of the simpler Model input parameter. Both methods would return void. With a few more changes like that it’s amazing how slim the methods will become.
As I already pointed out, the purpose of this post is not to pick on the above article. In fact Spring’s own PetClinic shows code that is very similar. This is understandable since the purpose of the PetClinic sample is to introduce new capabilities in the context of an existing body of knowledge.
With the upcoming deprecation of the traditional MVC controller hierarchy perhaps it is time to put the spotlight on more “opinionated” @MVC examples. The swf-booking-mvc sample aims to do that but its points about the @MVC model have not yet been widely perceived. This is part of my reasons why I plan on giving a talk at SpringOne Americas this December in which I plan to assemble and discuss a set of best practices surrounding the new @MVC programming model. Do you have any favorites you’d like to share?
Posted in Spring Framework, Spring MVC | 1 Comment »
September 16th, 2008
If you’re like me using Ubuntu as your primary operating system you probably wait for a little bit before upgrading to a new version. I finally made the upgrade to Hardy Heron (Ubuntu 8.04) on my Lenovo T60. I have a few things to be very happy about:
- I was able to purge the binary-only ATI driver (fglrx) from my system. The open-source version (radeon) seems to work just fine with my Mobility x1400 graphics card and my 1680×1050 laptop LCD. I don’t get direct rendering, hence no cool desktop effects and no games but guess what? I can live with these limitations just fine. Instead I get much better dual-head support through xrandr, simple hassle-free installation, and a configuration that’s fully supported under Ubuntu.
- Suspend and hibernate work!!! This might be another good side effect from dropping the fglrx driver.
- Software version upgrades – skype 2 (hello video!), firefox 3, kde 3.5
Be sure to check here (important note about an upgrade freeze with 2.6.22-15):
https://help.ubuntu.com/community/HardyUpgrades
Posted in Ubuntu | No Comments »