December 2005 Archives

Paul Browne

AddThis Social Bookmark Button

Related link: http://www.firstpartners.net/blog/location/dublin/2005/12/30/did-you-notice-how-…

5 Years ago, you could walk into Waterstones bookshop in Dublin and see 8-10 sections filled with computer books. Walk in today and you would be lucky to see 1-2 sections, less than a quarter the number. The titles still being covered are the ‘mass market’ items - Word, Excel , Access, Microsoft Office. No longer can you find the items of specialist interest - JMX, Aspect Orientated Programming, Ajax and the like. Even slightly more mainstream books on Oracle and Enterprise Java are getting hard to find.

What is going on? Remember how the dot com boom promised to revolutionise retailing and that old fashioned retailers were doomed? It turns out that a both online and offline retailers are thriving. Specialist areas (the long tail - as explained in this post) are migrating online. Mass market hits (such as Sharon Osbourne’s and Will Young’s biographies) stay in the shop, where you’re more likely to buy them as a last minute present or impulse purchase.

From on online retailers point of view (e.g. Amazon), computer books are a perfect product. No ‘bricks and mortar’ book shop is going to be able to stock all the books I need. Given that for a worldwide population of 6 Billion people, I’m guessing that less than 20,000 copies will be sold of an book such as Java Messaging Service (JMS), even for a popular title from O’Reilly. This translates to about a quarter a copy a year for even an above average bookshop in Dublin , Belfast or Drogheda. Bundle them up into an online bookshop however, and 20,000 copies is a very nice market.

This process, far from being the death of traditional retailers is proving their renaissance. Companies like Tesco and Argos are mastering true Clicks and Mortar techniques. They can devote previous shelf space to high volume, high profit goods, while direct their ‘do you have this in pink in a size 20′ queries to their online store. Maybe not as convenient for techies in search of the latest knowledge fix, but 3 days wait for a book is better than not being able to get that book at all.

Are you seeing that same trend in shops in your area?

Robert Cooper

AddThis Social Bookmark Button

Related link: http://simile.mit.edu/java-firefox-extension/

So I tripped over this today. A code by-product of the extremely cool Piggy Bank FF extension, it is a simple framework for invoking Java code from the XUL Firefox extension framework.

I admit I haven’t had quite enough time to put it through the motions. However, I intend to give it the good ole college try on seeing how this relates to XULRunner in terms of development. If it is possible to build business layer in Java and UI in XULRunner, this might represent something extremely cool in terms of desktop app development. Honestly, I still wish the JRE would include Gecko/XUL out of the box, but barring that, this seems like a pretty nice balance between the two.

Robert Cooper

AddThis Social Bookmark Button

Related link: http://www.artima.com/forums/flat.jsp?forum=106&thread=142428

Wow. Just Wow.

Artima has an article up about do’s and don’ts for designing an API, and it now goes into my short list of Biblical writings on programming in general. A lot of this is stuff that I have been ranting about for years — including several recent discussions with my coworkers about *cough* violating said rules.

Some highlights:

API design goals

What should the design goals of your API be? Apart from compatibility, the following goals from Elliotte’s
presentation seem like an excellent set:

  • It must be absolutely correct. In the case of XOM, this meant that the API could never produce
    malformed XML documents no matter what the caller did. For the JMX API, for example, it means that you can
    never get the MBean Server into an inconsistent state by registering strange MBeans in it or using funny
    ObjectNames or performing several operations concurrently.

  • It must be easy to use. This is hard to quantify. A good way to get an idea is to write lots of
    example code. Are there groups of operations that you keep having to repeat? Do you have to keep looking up
    your own API because you forget what things are called? Are there cases where the API doesn’t do what you might
    expect?

  • It must be easy to learn. This overlaps considerably with ease of use. But there are some obvious
    principles to make learning easier. The smaller the API, the less there is to learn. Documentation should
    include examples. Where appropriate, the API should look like familiar APIs.

  • It must be fast enough. Elliotte was careful to put this in the list after the above items.
    Make sure the API is simple and correct. Then think about performance. You might be inclined to make
    API changes because the original API could only be implemented in an inefficient way. By all means change it to
    allow a more efficient implementation, provided you don’t compromise correctness or simplicity. Don’t
    rely on your intuition to know what performs well. Measure. Then tweak the API if you’ve determined
    that it really matters.

  • It must be small enough. This covers the size of the compiled code and especially the amount of memory
    it needs as it runs. The same principles as for speed apply. Make it simple and correct first; measure; and
    only then think about tweaking the API.


Be minimalist

Because of the compatibility requirement, it’s much easier to put things in than to take them out. So
don’t add anything to the API that you’re not sure you need.

There’s an approach to API design which you see depressingly often. Think of everything a user could possibly
want to do with the API and add a method for it. Toss in protected methods so users can subclass to tweak every
aspect of your implementation. Why is this bad?

  • The more stuff there is in the API, the harder it is to learn. Which classes and methods are the
    important ones? Which of the five different ways to do what I need is the best?

    The situation is exacerbated by the Javadoc tool, which dumps all the classes in a package, and all the
    methods in a class, in an undifferentiated lump. We can expect that JSR 260 will update the Javadoc tool to allow you to produce
    “views” of the API, and in that case fatter APIs will not be so overwhelming.

  • The bigger the API, the more things can go wrong. The implementation isn’t going to be perfect, but
    the same investment in coding and testing will yield better results for a smaller API.

  • If your API has more methods than it needs, then it’s taking up more space than it needs.

The right approach is to base the API on example code. Think of problems a user might want to solve with
the API. Add just enough classes and methods to solve those problems. Code the solutions. Remove anything
from the API that your examples don’t need. This allows you to check that the API is useful. As a happy
side-effect, it gives you some basic tests. And you can (and should) share the examples with your users.

This really goes back to a lot of things I was trying to get at with Ruby the Rival. SWING is unapproachable. JNDI is so over inclusive and configuration reliant as to be problematic. JavaMail was based on a dare.

I think the other thing I would add to this segment, however, is this:

Higher level objects should be the ones people want to use. and Don’t be afraid of building APIs on top of APIs

Think about all the J2EE elements that go unused because they are useless on their own (ServletRequest anyone?) or get effectively re-implemented to provide similar functionality in a slightly different environment.

Still every time I look at JavaMail or Swing I can’t help but think that there should be a set of minimalist top-level classes that provide a simple, clean and obvious way to meet 80:20 requirement that I can then cast to more complicated objects if I need to get real fancy.

The next section of this I have to admit I agree with, but there are times…

There’s a certain style of API design that’s very popular in the Java world, where everything is expressed in
terms of Java interfaces (as opposed to classes). Interfaces have their place, but it is basically never a good
idea for an entire API to be expressed in terms of them. A type should only be an interface if you have a good
reason for it to be.
Here’s why:

  • Interfaces can be implemented by anybody. Suppose String were an interface.
    Then you could never be sure that a String you got from somewhere obeyed the semantics you
    expect: it is immutable; its hashCode() is computed in a certain way; its length is never
    negative; and so on. Code that used String, whether user code or code from the rest of the J2SE
    platform, would have to go to enormous lengths to ensure it was robust in the face of String

    implementations that were accidentally incorrect. And to even further lengths to ensure that its security
    could not be compromised by deliberately evil String implementations.

    In practice, implementations of APIs that are defined entirely in terms of interfaces often end up cheating
    and casting objects to the non-public implementation class. DOM typically does this for example. So you
    can’t give your own implementation of the DocumentType
    interface as a parameter to
    DOMImplementation.createDocument
    and expect it to work. Then what’s the point in having
    interfaces?

  • Interfaces cannot have constructors or static methods. If you need an instance of an interface, you
    either have to implement it yourself, or you have to ask some other object for it. If Integer were an interface,
    then to get the Integer for a given int you could no longer use the obvious new
    Integer(n)
    (or, less obvious but still documented inside Integer,
    Integer.valueOf(n)). You would have to use IntegerFactory.newInteger(n) or whatever.
    This makes your API harder to understand and use.

  • Interfaces cannot evolve. Suppose you add a new method to an interface in version 2 of your API.
    Then user code that implemented the interface in version 1 will no longer compile because it doesn’t implement
    the new method. You can still preserve binary compatibility by catching AbstractMethodError
    around calls to the new method but that is clunky. If you use an abstract class instead of an interface you
    don’t have this problem. If you tell users not to implement the interface then you don’t have this problem
    either, but then why is it an interface?

  • Interfaces cannot be serialized. Java serialization has its problems, but you can’t always get away
    from it. The JMX API relies heavily on serialization, for example. For better or worse, the way serialization
    works is that the name of the actual implementation class is serialized, and an instance of that exact
    same class is reconstructed at deserialization. If the implementation class is not a public class in your API,
    then you won’t interoperate with other implementations of your API, and it will be very hard for you to ensure
    that you even interoperate between different versions of your own implementation. If the implementation class
    is a public class in your API, then do you really need the interface as well?

A lot of really good things here. I know for one I get frustrated with this sometime. Even the ROME project, to which I am a constributor, suffers from this, and I found myself changing some of my code so that it matches the, um, unfavorable overuse of interfaces that was preexisting.

HOWEVER, until Sun decides to let us use an Object as an Interface for the purposes of Dynamic Proxies, you are kind of stuck with this. (Please don’t mention CGLIB. Thanks.) Now, I consider this to be one of the things that is getting in the way of Java having the same kind of utility we see in Ruby that everyone loves so much, and I think it needs to be addressed. Until then, however, we need to code around it.

Lastly…

Don’t implement Cloneable. It is usually less useful than you might think to create a copy of an object. If you do need this functionality, rather than having a clone() method it’s generally a better idea to define a “copy constructor” or static factory method.

This, I agree with. I, however, have always seen more things along the lines of the Copy From interface (using ROME as an example — alternately CopyTo, which I think is better personally). I find this has several advantages over a constructor. 1) It allows constructors for extended objects to use their natural flow while mapping bean properties from a different class properly. 2) It can be cascaded up and down objects with super.* calls easier than you can with super() calls. But hey, that’s just me.

What are your rules?

Tim O

AddThis Social Bookmark Button

Related link: http://www.etsy.com

Having trouble explaining concepts like Folksonomy and Web 2.0 around the table during the holidays? Look no further than Etsy.com. This site provides an online exchange for handmade goods and crafts. It provides a fully-Web 2.0-compliant buyer and seller community for everything from vintage jewelry and wookworking to quilts and papergoods. It is Paper Source meets Flickr and it is the perfect vehicle to explain Web 2.0 concepts to a cynical audience. Read on…

Tim O

AddThis Social Bookmark Button

Related link: http://www.medicare.gov/

Maybe you sat down to help grandma sign up for the new Medicare Prescription Drug plan this year? If you and gramps ended up staring at a HTTP 500 response code, you weren’t alone. The Medicare website, a mishmash of Microsoft ASP and ASP.NET pages, has been overwhelmed by activity, and, from most reports, is suffering from frequent outages. Read on…

Stories? Please share.

Tim O

AddThis Social Bookmark Button

Related link: http://sourceforge.net/projects/collections

Commons Collections has a ubiquitous presence in Java programming, and I haven’t seen a single project in the last four years that hasn’t included this library. For those of you who are looking for a version of Commons Collections with support for Java 5 generics, take a look at Commons-Collections with Generics.

Paul Browne

AddThis Social Bookmark Button

Related link: http://www.firstpartners.net/blog/category/web/web-20/

Admit it, you probably looked a Javascript in the late 90’s , thought it was good for a few narrow areas (special effects on a web page, validating user input) and then went elsewhere to program in a ‘real’ language. If asked, we’d complain about lack of language features and the restrictiveness of running only within a client side browser.

While we were concentrating on Enterprise Java Servers and Scalable web apps, the awkward teenager that was Javascript (complete with spots and braces) has grown up. This author included, we only started paying attention again when Ajax burst upon the scene. Whatever your choice of server side language (be it Java, Ruby, .Net or PHP), it’s undeniable that Javascript is running the show when it comes to Web 2.0 and dynamic web applications.

So, it’s time for me to go back to school and understand what the language has to offer. A good start is an article available on VSJ. It blows away the myth that Javascript is not an Object Orientated language. While Ajax is cool, if we don’t structure our code properly then we failed to learn any lessons in architecture from the last 5 years.

Me, I’m off to write 100 lines in detention: ‘Java is not the only Object Orientated Language’.

Has Ajax rekindled your interest in Javascript?

Paul Browne

AddThis Social Bookmark Button

Related link: http://www.firstpartners.net/blog/category/web/web-20/

Here’s a thought for you: Part of the endurance of Unix is that it does the core things well (System Stability, running processes etc) but that it makes combining functions easy (where would we be without scripting as glue , the ‘|’ operator and the ability to tail the last 500 lines of output from a process then grep the results?)

The more you think about it, the more Web 2.0 is heading the same way. You have big, stable processes like the Google Maps API , RSS feeds and other XML interfaces to-from your favourite website and tagging services from Del.icio.us to name but a few (or even your own Enterprise Apps written in Java). You have scripting glue (be it PHP, Ruby or even Perl) to tie them all together. What you get is mashups able to quickly evolve new services, but with serious industrial strength underpinnings to cope when your site appears on Slashdot.

What are your best examples of Web 2.0 as a Unix box?

Tim O

AddThis Social Bookmark Button

Related link: http://del.icio.us

If you haven’t heard, del.icio.us has been toast for multiple days. Looks likes a confluence of events (and this is a guess based on the blog post): power failure caused RAID to corrupt some files, that corrupted data happened to be a replicated master database, and the slave databases faithfully copied said corruption. Can’t fault them for that, but I’m sure they will mark it up as a lesson learned. When you are using RAID, make sure to invest in redundant power supplies and have sufficient battery backup to power down in a controlled fashion. If anyone from del.icio.us is reading this, a detailed forensic failure analysis would be very helpful to the community. Read on for more about my own del.icio.us withdrawl…

Anyone else suffering from del.icio.us withdrawl?

Tim O

AddThis Social Bookmark Button

How much does it cost to write a book? A good pair of eyes, a gaggle of late nights, and a little bit of sanity. Most importantly, proof-reading tiny text on a 17″ eMachine Monitor did some serious damage. I had my first eye exam since last year, and my optometrist sends me away with “Computer Glasses”. For those of you not familiar with “Computer Glasses”, let me translate. “Computer Glasses” translates roughly to “Glasses for 29 year olds who use the computer way too much and who can’t imagine wearing bifocals for at least another 15 years”.

When I remember to use them, I find myself constantly switching between my “Computer Glasses” and my regular glasses. I program for an hour, something beyond a 5 foot radius interrupts me, and I get annoyed with all the optical context switching.

Enough with optical interfaces. I’m ready for a direct brain to USB interface.

Tim O

AddThis Social Bookmark Button

Ever deal with an online merchant and have a bad experience? You call customer service only to find yourself on the phone with someone who clearly doesn’t want to be bothered with actually sending you the merchandise you just ordered. The customer service representative representative has a heavy New York accent, and you try to visualize the surroundings. Well, good news, someone has done the dirty work for you. Don Wiss looked up the addresses of a bunch of camera dealers in Brooklyn and took some pictures. It’s interesting to see some of these “businesses”. I’ve had a encounters with shifty camera dealers in New York. Read on…

Anyone have any online retailer horror stories?

Tim O

AddThis Social Bookmark Button

Related link: http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=/…

I found it strange that I’ve been reading about this case for a few years now, but I still haven’t seen a good resource that links to the patents in question.
Here’s a list of the Patents involved in NTP v. RIM. Read on…

Is this case just the first in a decade long series of cases against companies and open source projects? Are we entering into a dark age for innovation?

Dejan Bosanac

AddThis Social Bookmark Button

Recently, I had to fix some application that does a lot of logging. But not just a simple debug logging where all of your messages are going to one rotating file on the disk and are examined only when something goes terribly wrong.
Requirements for this application were to log all events of a certain type in a separate log (rotating file) and to send en email if an error condition is encountered.
The original application has used the JDK Logging API to cope with these requirements, but something has gone wrong in the implementation and I had to fix it.
First of all, I have to confess that my default choice for Java logging is certainly the log4j API since it is clean and is capable of doing everything that I’ve needed thus far. As far as commons logging library is in question, I don’t see that this extra layer is useful in applications. Libraries are totally different story for that matter.
So, here’s what I’ve found about JDK Logging API that convinced me to stay with log4j whenever I can:

  • There is no way to configure multiple instances of the logger handler class in the properties file - I’ve needed this to configure multiple FileHandler instances that would write to different log files. But unfortunately, it is impossible to do it through the properties file configuration mechanism.
    When you are using this mechanism, you first define handlers that you will be using, by specifying their classes.

    handlers= java.util.logging.FileHandler, java.util.logging.ConsoleHandler

    Next, you have to configure every class and set its properites.

    java.util.logging.FileHandler.pattern = %h/java%u.log
    java.util.logging.FileHandler.limit = 50000
    java.util.logging.FileHandler.count = 1
    java.util.logging.FileHandler.formatter = java.util.logging.XMLFormatter

    So as you see, there is no standard way to configure multiple FileHandler instances that will write to different files.
    For that reason you can, for example, find a custom implementation of LogManager in Tomcat called JULI. JULI solves the problem by allowing you to add numbers in front of your class names and treats that “classes” as independent instances. While this is acceptable solution, I didn’t want to go that way and introduce solution which is not standard and widely accepted.
    The other solution was to configure logging mechanism programmatically, but that was just out of question.

  • JDK Logging API cannot reliably log messages from the shutdown hook - while this is not as important limitation as the previous one, it could be restricting to some applications (like it was this specific application that I have worked on). It seems that the Logging API has its own shutdown hook and because: (quotation from the API)
    When the virtual machine begins its shutdown sequence it will start all registered shutdown hooks in some unspecified order and let them run concurrently
    you can’t be sure that your messages will be logged.

At this moment I have started thinking of how hard would it be to migrate this application to log4j. And it turns out that it was the easiest solution to all of aforementioned problems.
Here are the steps needed to do this:

  • First of all you’ll have to change the method that is used to obtain the appropriate log. So, instead

    Logger.getLogger("log_name")

    you’ll have to use

    LogManager.getLogger("log_name")

    This may look like a hard manual task, but I’m sure that your IDE will help you in a great deal.

  • Next, you’ll have to change names of the appropriate log methods, since fine() is now debug(), etc. With simple search-replace commands, this also won’t take more then few minutes.
  • Now, you can configure your log4j logging mechanism by writing the log4j.xml (or log4j.properties) file. I will not elaborate here how to do it, since there are more than enough resources on the Web that explain every detail of log4j.
  • Finally, if you have used java switch to instruct your application where to look for the logging configuration, there is one more step you’ll have to do in order to finish this transition.
    The typical switch example that is needed to configure JDK Logging API looks like this

    -Djava.util.logging.config.file="logging.properties"

    So now when we are using log4j.xml, it should be replaced with something like this

    -Dlog4j.configuration=file:log4j.xml

If your application has no special requirements for logging, then it really doesn’t matter which of these two solutions you will use. But for any non-trivial logging the JDK Logging API is too limited to be useful. And as we have seen, even in existing applications it is just a matter of minutes to switch these two libraries.

Have you expirienced some of the limitations of the JDK Logging API? How did you overcome them?

Robert Cooper

AddThis Social Bookmark Button

Related link: http://www.zdnet.com.au/news/software/soa/Time_for_Linux_bigots_to_take_a_back_s…

Ian Ferguson at ZD starts throwing fireballs with “Time for Linux bigots to take a back seat”. There is a kernel of a point I agree with in here, but mostly he is just stooging.

That idealism unfortunately manifests itself most often in online diatribes against Microsoft, in particular, and proprietary software, in general.

Gartner analyst Brian Prentice said recently the “flaming Linux bigots” who were prone to hyperbole and religious debates to advance their cause actually impeded the growth of Linux and open source software.

Now, first off, I can’t express how low my opinion of Gartner is as an organization. As a consultancy they are all but worthless and as punditry they represent a more transparent Cash-for-Media organization than anything of which Armstrong Williams could dream. Of course, the irony of talking about “flaming Linux bigots” and then criticising them for being “prone to hyperbole and religious debates” itself is not lost.

This is where there is a slight kernel of truth. Too often in the Linux community there is a gut level response that is anti-anything-outside-our-ideal. The whole GNOME project represents such a response: a backlash against KDE and its underpinnings in the Free-as-in-beer QT library. Of course, TrollTech GPLing QT didn’t change their already formed religious beliefs. I still argue that KDE is the far superior dekstop on *nix for a number of reasons, but that doesn’t stop GNOME from continuing. Indeed, the religious nature of GNOME in many ways continues to hurt the project. Continuous “framework” change before even a generation of apps is developed keeps it from having the kind of smooth user experience that people expect in a modern desktop.

There is also a NIH syndrome that is problematic. As great as the Beagle desktop search and Dashboard utility are, no one expects to see them make it into Fedora Core anytime soon, mostly because RedHat is loathe to give too much credit to Novell for a good product, even if it is “open source”.

Moreover, I think the Linux communities’ (a) rejection of Java on philosophical grounds and (b) lack of demand that Java get tier-one support as a desktop system on Java from Sun has held back more of their ideas than not. Sure, Java now tops SF.net, but I don’t think that is terribly meaningful. I can’t help but laugh that Linux distros don’t seem to have much of a problem including the Flash plug in, for which Macromedia doesn’t even make dev tools for Linux, yet there is still a holy war mentality.

That is the kernel of truth. The rest of Mr. Ferguson’s argument, however, is complete bunk:

However, heading into the new year, it is becoming increasingly apparent that the Linux and open source software community can ill-afford the luxury of diluting its message to business and government communities. While significant ground has been made this year in winning broader acceptance, most notably by in securing a level playing field in competing with proprietary software companies for lucrative government procurement deals, Microsoft for one is not taking the situation lying down.

Securing procurement is not “the message” of open source. That is the message of a company. RedHat, Novell, Microsoft all have that message. The “message” of open source is that options are good, you should not be held under the boot of your vendors and that the value of software is rarely the product, but the expertise to make it work how you want.

For one, the company’s massive revamp of its security position two years ago — requiring programmers to take training in secure coding — is starting to pay off, with exploits of problems in Microsoft products coming down. This effort — combined with the increasing frequency at which problems are being found with Linux and open source code — is quickly undermining the Linux and open source community’s argument that Microsoft software is high risk when compared to alternatives.

This argument always drives me nuts. Does “Linux” have security problems? Sure. For years BIND and Sendmail were nightmarish to keep updated. PHP and individual PHP apps have seen all kinds of security holes. The thing is, you need to compare apples to apples. Pretending that all of “Open Source” is the alternative to a Microsoft view is flawed. Fedora or SUSE come with no less than 12 email clients. Does a flaw in one of these count against the “Operating System”? How does that compare with a flaw in Outlook(/Express) that is the only option on a stock Windows install? Moreover, even thinks like the international domain name “exploit” in Mozilla doesn’t really compare with the drumbeat of XSS, sandbox and ActiveX flaws we are pummeled with from Microsoft. No, we haven’t gotten a Teardrop style exploit in a while, but how much damage did Slammer do? Judging incident counts is only part of security.

Secondly, Redmond is likely to step up its efforts to warn customers that deploying Linux and open source solutions could expose them to litigation over patent royalties arising from the use of shared code. (However, the effectiveness of this argument could be blunted if the so-called Open Invention Network — a company formed by IBM, Sony, Philips, Novell and Red Hat — is effective in its intention to buy up Linux patents and offer them royalty-free to Linux developers).

Is anyone taking the SCO thing seriously enough to even buy this FUD anymore. Yes, we need serious reform in the IP infrastructure in this country. However, there seem to be very few cases where this has become a real issue. Microsoft can say it, but that doesn’t make it true.

In addition, Microsoft is likely to continue to aggressively protect its market share, leveraging its incumbency and size to ensure it loses as little ground as possible to its smaller rivals. The business cases presented by sellers of Linux and open source software — both large and small — are going to have to trump Redmond on value for money and fitness for purpose, as well as overcome the innate conservatism of information and communications technology purchasers. A tall order indeed.

Might I suggest reading The Cathedral and the Bazaar? If there is a manifesto to these flaming bigots, that would be it, and it would seem to me that half of the message goes directly to these points.

The message is pretty clear when it comes to the growth of Linux and open source software in Australia. The ideologues are going to have to fade into the background and keep their philosophical debates within the confines of the community while the sharp and commercially savvy deal with the hard reality of winning business contracts.

With even Schwartz explaining the value of Open Source in both terms of philosophy and economics, not to mention RedHat, Big Blue and Novell already there, I am not seeing the problem. Much like certain political pundits like to troll for what one whacko said somewhere on the internet to waive as an example of “the debate”, Mr. Ferguson seems to be trolling the comments on Slashdot or Digg and assuming it actually represents anything important, rather than being the braying of adolescents and people ill informed enough to take it for serious dialog.

Dejan Bosanac

AddThis Social Bookmark Button

In his blog, Bram Smeets has described mechanisms for configuring the DWR Ajax library with Spring (http://bram.jteam.nl/?p=2 - please read it before proceeding with this post).
That document contains the complete guide that you will need to get started with Ajax in your Spring-enabled Java projects and it is a de-facto tutorial for that topic.
However, there is one issue that bother me with the solution described in that blog. In order to describe this issue, let me first explain how this DWR-Spring integration works.
First of all, you have to put the following configuration snippet in your web.xml file.

<servlet-mapping>
   <servlet-name>main</servlet-name>
   <url-pattern>/dwr/*</url-pattern>
</servlet-mapping>

This configuration maps all URLs that are under /dwr/ path to your Spring’s DispatcherServlet named 'main'.
Now we need to map DWR calls to the appropriate DWR controller bean in the instance of our Spring’s SimpleUrlHandlerMapping class.
In this example it is done by adding the following property

<prop key="/**/*">dwrController</prop>

to the end of the class’s ‘mappings’.
In this configuration all requests that are not matched against any other previous pattern are sent to the DWR controller. The appropriate DWR calls are handled correctly and everything looks just fine.
The problem emerges for requests that are not DWR calls, but are matched against this pattern and sent to the DWR controller. As you can guess those are requests for which we expect 404 (page not found) status to be returned. Unfortunately, these requests are passed to the DWR controller that will throw java.lang.SecurityException and thus return a response with 505 (Error) status.
This can be a problem for your web application, especially if you want to receive an email for every exception that is thrown. In this case the DWR controller will generate a bulk of emails for every 404 response (usually generated by various spiders if you run a public web site).
One simple solution is to replace the previous mapping configuration with the following one

<prop key="/**/*.js">dwrController</prop>
<prop key="exec/*">dwrController</prop>

Let me explain how this configuration is different and what benefits does it bring.
When you encounter this problem, your first try would probably be to map all URLs that matches /dwr/**/* pattern to the DWR Controller. Unfortunately, this won’t work, because Spring (in a default configuration) sees these URLs without the /dwr prefix. So, for example /dwr/engine.js will basically be treated as engine.js and obviously we have to find another solution.
The DWR controller needs an access to certain JavaScript libraries, such as engine.js, which is usually located at /dwr/engine.js. Also, for every interface that will be exposed through this library there is an appropriate JavaScript library dynamically created (e.g. /dwr/interface/productManager.js in the original example). So the first line in our example is here to allow an access to these dynamic JavaScript libraries.
Secondly, every call to a method defined in the interface is mapped to a certain URL. For example, a call to the getAllProducts() method of the productManager object defined in the Bram’s example will be converted to the /dwr/exec/productManager.getAllProducts URL request. All these URLs starts with /dwr/exec/ so we must match them against exec/ pattern. So with the second configuration line, we map this kind of URLs to our DWR controller.
With this solution we have allowed normal functioning of our DWR controller and assured that it will handle only requests that are regular Ajax calls. Also, it will improve the performance of your application a little bit, since there will be no ‘false’ Ajax calls for every 404 response.

Update: Bram have suggested a more cleaner solution to this issue (look at the comments for more details about this discussion). The trick is to define a new url mapper that will handle just DWR URLs. The final solution could look like this:

<bean id="dwrUrlMapping" class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
<property name="alwaysUseFullPath" value="true"/>
  <property name="mappings">
  <props>
 <prop key="/dwr/**/*">dwrController</prop>
 </props>
</property>
</bean>

Have you experienced similar issues? How did you solve them?

Robert Cooper

AddThis Social Bookmark Button

So I am frustrated…

A couple days ago, I got an email from Yahoo!:

Your Yahoo! ID is: kebernet
Your password for this account has recently been changed. You don’t
need to do anything, this message is simply a notification to protect
the security of your account.

Please note: your new password may take awhile to activate. If it
doesn’t work on your first try, please try it again later.

DO NOT REPLY TO THIS MESSAGE. For further help or to contact support, please
see http://help.yahoo.com/help/edit/

***************************************************************
You can always change your password by doing the following:

1. Sign in to any Yahoo! service
2. Click on any “Account Info” link
3. Choose “Change Password”

If you cannot find an “Account Info” link, you can sign in to My Yahoo!
(http://my.yahoo.com) and you’ll find it in the upper right corner.

[172.201.39.27]

Since I am neither an AOL user, nor have I been to IL anytime soon, it is obvious someone has pwned my Yahoo account. Fine.

Yahoo customer service has been decidedly unhelpful in helping me regain control of my account, which doesn’t increase my mood at all. However, it has me thinking more and more about one of the problems with unified identities:

I now can’t use my Yahoo! IM account. Flickr is out. I can’t control the mailing lists that are directed at my inbox through Yahoo groups. Now really, if it were any one of these services that I had lost control over, that would be inconvenient. However, with a unified identity, I have now lost control over a large block of things that I actually do use.

With all the talk about “Web 2.0″ and loosely coupled web services, what happens when some of those loosely coupled services are tied to a monolithic identity system? Honestly, between all the Yahoo merchants I have purchased from over the years not to mention HotJobs, and all the various things tied to that account, I don’t even know what information might be attached to it.

Is a monolithic identity, even within an organization, really such a good idea?

Robert Cooper

AddThis Social Bookmark Button

Related link: http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci114934…

(via TSS):

TechTarget reports:

Sun Microsystems Inc. yesterday kicked open its software doors, making its Java Enterprise System (JES) middleware suite, N1 management product and developer’s tools freely available. It also plans to combine them with its free, open source Solaris operating system to form what it will call the Sun Enterprise System.

JES includes six software suites — high availability, identity management, Web infrastructure, application platform, messaging and integration. Loiacono said the identity management and integration suites would be first in line to build out open source communities.

Sun only jumped into the integration business this summer with the acquisition of enterprise application integration (EAI) vendor SeeBeyond Inc., but Loiacono underscored how critical it has become in the software industry.

“The game now is in integration,” he said.

The development tools include Sun Studio 11, Sun Java Studio Creator and Sun Java Studio Enterprise 8, offering drag-and-drop development tools and pattern-based development.

“Every major player in software now has to have an open source strategy to match Sun,” [[Marc Fleury]] said. “Sun just detonated a nuclear bomb in the [revenue stream] of IBM and the other traditional vendors by open sourcing SeeBeyond.”

This is a HUGE deal. (For maybe the first time ever) I agree 100% with Fleury. Not just as a NetBeans user, but as a developer, the first thing I jumped to was not even the N1 and SeeBeyond stuff. It was the fact that there is now an open source, high quality UML tool with round trip engineering. That is huge.

This is going to be a seriously big deal.

Paul Browne

AddThis Social Bookmark Button

Related link: http://www.dublinjava.org/

It’s at dublinjava.org . Feel free to drop by

To Quote Jakub , the Meetup Organiser:

The Dublin Java Meetup Group is the place to connect with fellow Java professionals. Meeting every month, we give you the opportinity to meet with other developers to cut through the vendor hype, toss around ideas about what works and what doesn’t, compare battle scars, and sound off on issues that matter to you.

New members of all experience levels welcome

Paul

Advertisement