Internna - Geared towards Open Source

Invoking Web Services via Spring

2008-07-23T10:30:00.000-07:00

SOA SOA SOA...SOA everywhere. Right now it's difficult to work on an enterprise project and don't have the need to connect to a WebService. What would we be without these buzzwords...?

Unfortunately, for us developers that is, WebServices is not the easiest of technologies (understandable as the problem it solves is also complex) and Java's approach has always been guilty of not been the most intuitive. But the need is there so it has to be solved.

To call a Web Service there are several possibilities at the framework level. The first is to use JAX-RPC but this approach is in disuse today (for uber complexity). If we stick to the standard the next API would be JAX-WS. This is a much more polished API based heavily on annotations. JAX-WS is now part of the standard Java Standard Edition. Finally there are other alternatives in the Open Source scene. And better, Spring, in some form or another, supports all of them (Groovy also helps but not everybody has access to it).

It's important to notice that a developer has two ways to connect to a WS (I'll start talking about JAX-WS from now on), creating a SEI (Service Endpoint Interface) proxy or creating and sending a SOAP message. The first case allows the programmer to create a Java interface (mainly because actually it has to be annotated) and forget about the stub. The second (more powerful) alternative creates an XML structure from scratch. Spring facilitates the work with proxies. The later case requires the Spring Web Services subproject.

So how does Spring help? In two ways, it dynamically creates the proxy and injects it to the business beans seamlessly. For the most advanced use Spring, as of now, still requires the Java interface to be provided. All in all, it's not a big deal as there's a tool (wsimport) to generate it given a WSDL. Any good IDE will do it as well. Actually, wsimport generates more than one Java source because the parameters probably require a JAXB (read Java to XML) transformation.

I haven't talked about registries yet. JAXR is the Java API to connect to WSDL containers. They basically provide a level of indirection to a WSDL. JAXR is complicated (to some extent) and if possible I like the REST API better (but not all registries provide it!). IBM Service Registry does, for example (so you can just use Dom4J with some security). Anyway, JaxWsPortProxyFactoryBean (with minor tweaks) supports this kind of access.

That should be all for the gross of the situations. Recall that JAX-WS supports WS-I Basic Profile, MTOM and other such advanced protocols by default. That's not true for all of them though! For example, it requires some work to allow for message level security. This is overcome by the use of LogicalHandlers or SOAPHandlers (you can mix and match). In Spring or AOP jargon they would be called interceptors. They allow to modify the message prior to being wired. Another common and interesting use, for example, is logging. Spring allows handler injection grouped as HandlerResolvers.

So here's the final code:

<bean id="loggingHandler" class="mypkg.LoggingHandler" />

<bean id="defaultHandlerResolver" class="mypkg.ConfiguredHandlerResolver">
   <property name="handlers">
      <list>
         <ref bean="loggingHandler" />
      </list>
   </property>
</bean>

<bean id="wsdlRetriever" abstract="true" class="...JaxWsPortProxyFactoryBean">
   <property name="lookupServiceOnStartup" value="false" />
   <property name="handlerResolver" ref="defaultHandlerResolver" />
</bean>

<bean id="aSample" parent="wsdlRetriever">
   <property name="serviceInterface" value="..Sample" />
   <property name="wsdlDocumentUrl" value="http://...Sample?wsdl" />
   <property name="serviceName" value="Sample" />
   <property name="portName" value="SampleSOAP" />
   <property name="namespaceUri" value="..." />
</bean>

Get the logging handler source code along a good explanation from here.

Working with DWR sources

2008-07-08T05:13:00.000-07:00

By now there's no doubt inside the software industry that the Open Source movement is here to stay. And the most valuable asset it provides is *hint* full access to the source code! And it's a shame that not that many people share this perception as for the majority of developers OSS just means free (read gratis) software.

Of course, being free (gratis) is handy characteristic but it should not be one that bothers much to the gross of us, as we work for companies that can afford it anyway. On the contrary, source code should be of interest for you. Let me just list some of the most useful perks:

It enables debugging
Otherwise it becomes a blind and unproductive task. And believe me, the time spent debugging will be worth it.
It's the best learning tool any programmer can access
It's code written by very proficient hackers revolving common but hard to solve problems.
It allows customizations
And I include bug fixes here!
It makes you part of a community
Share your code, discuss problems, hear other viewpoints, propose solutions et al!

IMHO fear is the main reason that prevents many programmers to contribute to the scene. But if you're by now convinced of the utility let me demystify the myths! Just follow with me this step by step tutorial to work with DWR source code :-)

Our first task is gaining access to the source code. DWR as many other projects stores the code in a repository. Beware that repositories are not like open wikis and people have different access rights. Anonymous access is the best we can hope for by now. There are many different server types (SCM), DWR has used CVS in the past but right now uses Subversion. We need to have a client installed to access a SVN repository and I can recommend Tortoise.

The repository is available at http://svn.directwebremoting.org/dwr/. It's huge as it includes all the versions ever released so it's probably better to point to the trunk folder (the latest code is available there) or, may be, branches/Branch_2_0/ (where the the code for the previous version lies).

To download the code to our machine we use the checkout command. The export command can be an option if there's no interest in having later updates. DWR has a page with detailed explanations for this step at their site.

Once we have it there we can explore it a little bit further. There are three important subfolders: core (DWR), serverside (different plugins) and ui (client side code).

There's also there a folder named etc that contains project files for different IDEs (netbeans, eclipse, IDEA). Opening DWR inside an IDE is as easy as navigating to the correct folder and opening the matching project. Opening the project in an IDE has the added benefit of allowing quick debugging of changes and their influence in your application.

Alternatively, DWR can be compiled using Ant (by just typing ant at the top of the hierarchy!). Regardless of the method, the compiled classes are always put in the (automatically) created target folder.

Some projects have an extensive documentation available. DWR does not particularly shine in this area (intentionally many times!) but, at least, things are organized so finding something should be manageable. For example, all the Spring integration classes are available inside the serverside/spring folder and are bound to just one package.

And that's all basically. Some simple steps that have configured DWR inside your workspace and facilitate your development needs. And once it's there nothing prevents you to dive a little and improve the tool ;-)

Happy hacking!

IWebMvc 1.0

2008-06-28T03:38:00.000-07:00

Last week I silently released IWebMvc latest version, labeled 1.0. Finally, I'll add! I've been working for six months to reach this point and I'm quite proud of the result. Even more so if I consider it's been a one man effort all the way from the start.

IWebMvc is a complete framework for dealing with enterprise applications with a JEE/Spring backend and an AJAX frontend. It's also the result of my experience as an architect (what a devalued title nowadays!) and my contribution to the community. I think it's a well built platform and a good (working) example to understand very complex technologies.

Unfortunately, it can't be any more. IWebMvc competes in a very crowded space against other projects like JSF/Richfaces, Grails or Wicket (among others!). All of them are supported by either big corporations, companies or foundations that can provide many resources. I just can't keep up! I have a work, contributions to other OSS projects, IWebMvc and a real life. Just too much. During the last month or so I've being lagging behind so a decision had to be made.

That said, IWebMvc has reached a state that can be of use to many as it provides:

Full Spring support
Including Webflow 2.0 and Security 2.0 and working code to configure transactions, AOP, MVC (controllers, locales, AJAX) and all.
JPA support
A generic service to persist entities using Hibernate as the provider. Includes solutions for many problems common to any application (full text search, transactions, DAO hierarchies, filters, complex relations, multiple DB/server support, automatic schema creation).
AJAX
IWebMvc offers, hands down, the most complete DWR 3.0 integration (for pull requests) out there.
Project configuration
Working scripts to kick start a project, download transitive dependencies, compile, test and package everything, deploy to an embedded server or integrate with a CI server.
Widgets
Dozens of them based on dojo! And Google AJAX APIs! Many of them original to the project
And many more useful utilities like cahing, compression, encryption, user administration, audits, CRUD operations, themes, sound & video support, captcha, multi-file upload and more

At this point, my only regrets have been not being able to finish the documentation and not being able to test it as much as I'd have liked in IE.

Finally I would like to thank you all the people that have supported the project like Google, ZeroTurnAround, JavaLobby, Joe Walker (of DWR fame), JAWR and all the developers that have contacted me with offering help, ideas, critics, opinions or just to say thank you!

div lightbox with jQuery

2008-06-22T01:40:00.000-07:00

I know there are next to thousands of lightbox versions, including several built over jQuery. But you know, none of them seem to fit your needs ever. This time around I was looking for one that could enhance parts of the page and not specifically images. Thickbox can present inline content (divs or iFrames) but it's not as pretty as others and it has some nasty CSS side effects. In addition it wasn't correctly working in IE6 for some corner cases and the syntax was (somehow) weird.

After a little search I found this plug-in from Leandro Vieira. It resembled the original lightbox plugin but, unfortunately, it was designed to view just images (alone or as a gallery). After realizing I was not going to get what I was looking for without some effort I decided to stick with it and modify it to suit my needs which basically where:

Visually attractive
HTML, Flash, other jQuery plugins as content
Working in FF, IE6+, Safari
Working inside a frameset
Simple to use (nothing beyond $("#id").lightbox())

Take into account that this is a hack as I wasn't expecting to release it in any form. A good solution would integrate with the original code and not just replace it! So I'm not going to explain the code in detail (or at all) but, for those interested, here are the modifications required:

settings = jQuery.extend({
   ...
   timeout:                -1,
   hideOnClickOutside:     false,
   alreadyOpened:          false
}, settings);

function _initialize() {
   _start(this, jQueryMatchedObj)
   $(document).keydown(function(objEvent) {
      _keyboard_action(objEvent)
   })
   if (settings.timeout != -1)
      setTimeout("$('#lightbox-secNav-btnClose').click()", settings.timeout)
   return false
}

function _start(objClicked,jQueryMatchedObj) {
   if (!settings.alreadyOpened) {
      settings.alreadyOpened = true
      $('embed, object, select').css({ 'visibility' : 'hidden' });
      _set_interface();
      settings.placeHolder = objClicked
      _set_image_to_view();
      $("#lightbox-image object").css("visibility", "visible")
      $("#lightbox-image embed").css("visibility", "visible")
      $("#lightbox-image object embed").css("visibility", "visible")
   }
}

function _set_image_to_view() {
   $('#lightbox-image,
      #lightbox-nav,
      #lightbox-nav-btnPrev,
      #lightbox-nav-btnNext,
      #lightbox-container-image-data-box,
      #lightbox-image-details-currentNumber').hide();
   $(settings.placeHolder).appendTo($("#lightbox-image"))
   elem = $("#lightbox-image")
   _resize_container_image_box(elem.width(), elem.height())
}

The CSS had to be slightly modified as well. And finally (for the lazy ones) here's a sample. It's a WAR file, if you don't have a servlet container available just uncompress and change the paths. To access it in your localhost http://localhost:[8080]/demo/index.jsp (or flash.jsp, frames.jsp, carousel.jsp).

jQuery effects

2008-06-17T08:37:00.000-07:00

One of the lastest tasks (in addition to some OSS work) I've been working on has been a framework to show asynchronous messages to a logged user. These messages usually are loaded in a placeholder that is then presented on the screen using some kind of effect (like fading or sliding). They range from very intrusive to mildly annoying (heck..I'm being payed!). Examples include the simplest pre-positioned banner, the modal lightbox, the interstitial or the inline popup among others.

As many know, I'm a big fan of the dojo toolkit and I promote it as much as I can. I have to admit that one of the things I like most is the widget library (named dijit). Unfortunately, this time around I didn't need one and dojo's effects (dojo.fx) are less than stellar. Add some troubles related to the number of files to deploy (I'm just talking about the dojo core) and I was quickly looking for an alternative.

The first one I inspected was jQuery as it's packaged in a single (tiny) file, has gathered a supportive community and it's always been tagged as really simple to use. By haphazard, the UI team ahd just released a new version so I started there. Let's start by saying that jQuery UI is not a fully featured component library but, good for me, it does pack a number of effects (ala scriptaculous). There's a demo page available that I recommend visiting. And can be extended with plugins easily (I used for example thickbox and liScroll). I didn't bothered to look beyond :-)

So, here's my stance on the library:

It works. And that's a lot to say when testing with IE6, FF3RC & Safari. In fact, it works from the start and without ugly hacks (and, my God, I'm used to those!)
I came thinking it was easy to use and I wasn't disappointed. As long as you are proficient with JS/CSS (functions, callbacks, selectors) it's very intuitive. For example, I found rather easier to make a container movable using jQuery's $("id").draggable() than dojo's new dojo.dnd.Moveable("id") (although both are actually quite straightforward)
Chaining is a bless though it's used without measure in the framework! Please, be sure to understand fluent interfaces beforehand.
The API is clear yet very powerful. The UI effects are awesome. The people in my project were amazed when I demoed the prototype. Nobody could believe a single line of code could generate that results.
Of course, all this goodies are of no use if you need widgets though..The UI team has a daunting task there.

All in all, a completely different approach to JS than dojo where there's a function/package/module for (nearly) everything. jQuery is concise but with its simplicity it also brings efficiency and saves time and troubles. Even more so if the developer is not that well versed in the intricacies of javascript (and I reckon there are many).

In short, I expect to use it again soon, without doubts.

IWebMvc Milestone 5 released

2008-05-26T12:20:00.000-07:00

I expected to have a Release Candidate by now but I couldn't get it in time so I'm releasing an intermediate release, Milestone 5, that packs a couple new widgets along with preliminary documentation. It's available at the repository.

The first widget deals with addresses and integrates Google Maps with IWebMvc. A nice feature to have indeed.

The second adds sound (MP3) support based on Sound Manager 2, a nice JS library. It includes a really well shaped player.

The codebase is frozen and just bug fixes (mainly in IE7) till the 1.0 release which I expect will be soon.

PS.- IWebMvc loads the browser with requests and hits the two connection per server limit pretty fast. FF3 has upped the limit to eight concurrent connections (IE8 has done it as well but dojo is still unsupported there) so it's highly recommended!

Creating a playing bot in Java

2008-05-11T10:17:00.000-07:00

So, I've just read an interesting article at DZone about how to build a poker bot today. Nonetheless it was somehow misleading. After reading it, one can get the impression that to build a bot C++ knowledge is a prerequisite. And advanced Windows programming as well. In all fairness, they are not.

In fact, any developer with basic Java understanding can code a bot in less than a day. Of course, everything depends on the kind of game...a table game (read Poker or BlackJack) is achievable. WoW is not. I'll show you how building a roulette bot in Java step by step.

First of all, I won't provide the FULL source code. Gambling (and even more so online gambling) bears some subtleties that make it hazardous. That's also the reason I've chosen roulette: no bot or betting system can ever beat the house edge in the log run (read the wizard of odds if in doubt). This is good for us though, the bot is useless (in the long run) so the reader should be just interested in the techniques and not the product.

Roulette is a simple game. Past events cannot influence the outcome of future spins so a player just needs to place his bets and wait until the ball lands in a number. Of course some AI would be useful though. But in the end the bot just needs to be able to bet and recognize the table state.

So basically there's an input and some actions. The input needs to be captured from the screen and the actions are performed controlling the mouse. This tasks can be done using a Java class, java.awt.Robot.

The OCR
Trying to get true OCR is not really feasable. Fortunately, there's a shortcut. First, the bot just needs to scan portions of the screen, second the data is fixed and third the screen is updated from time to time. For example, when the bot wants to scan the outcome of a spin just needs to check for numbers 0 to 36 in some fixes coordinates.

The first task of the bot developer is to save image files with all the possible outcomes. In roulette this means 40 images (37 numbers and three extra button images to check if the bot can bet at a given time). I use AutoIt Window Info to get screen coordinates quickly. Then it's a question of using the createScreenCapture method of the Robot class and the Java ImageIO API to save a PNG of each location.

Rectangle spinResultArea = new Rectangle(100, 100, 50, 15);
BufferedImage res = robot.createScreenCapture(spinResultArea);
ImageIO.write(res, "png", new File(...));

Once generated (the code is disposable now) the images must be packaged inside the JAR and loaded using:

InputStream img = getClass().getResourceAsStream("/resources/0.png");
BufferedImage number = ImageIO.read(img);

As a matter of fact, it's better to have an array of pixels to make the comparisons so:

protected int[] getData(BufferedImage im) {
   int[] rgb = new int [im.getWidth() * im.getHeight()];
   image.getRGB(0, 0, im.getWidth(), im.getHeight(), rgb, 0, im.getHeight());
   return rgb;
}

Load all the images on startup and save the generated arrays in a List for later. The last part of the OCR routine is comparing images. This is easy:

int[] rgb = getData(sourceImg);
Arrays.equals(rgb, numbers.get(number))

The mouse
The Robot class controls the mouse (or keyboard) fine. A simple function will suffice:

protected void click(int[] screenPosition) {
   robot.mouseMove(screenPosition[0], screenPosition[1]);
   robot.delay(75);
   robot.mousePress(InputEvent.BUTTON1_MASK);
   robot.delay(150);
   robot.mouseRelease(InputEvent.BUTTON1_MASK);
   robot.delay(150);
}

The code is self explanatory really. Read the javadoc if in doubt.

The AI
The bot should be fully functional by now. Of course, it's not very intelligent. All bots need some kind of AI. And unfortunately, the AI is probably the difficult part. For roulette the AI is limited to selecting a betting system and coding it. The cancellation system should work. Just one advice here, use unit tests! The number of combinations for a table game is huge so manually testing them becomes a daunting task really quick. Creating unit tests, in addition to saving time, ensures the code is bug free (to some extent) which comes handy when playing for real money, I guess.

And that's really all it takes. No DLL hooks or C++ ;-)

IWebMvc Milestone 4 released

2008-04-29T07:36:00.000-07:00

So a new version is up. This time the feature list is heavy on the server side. Let's review them one by one:

License change
I'm not sure it's the best time to announce it...but from now on IWebMvc will be released under the Apache Software License (ASL 2). I've waited till today just because the initial versions were very preliminary and GPL just keeps things under control. Things have changed and IWebMvc has nearly reached the point where other people can probably contribute better ideas than me.
Groovy support
I've talked about it recently so I'm not adding much here. It supports compiled classes and scripted (dynamic) beans. Just be careful with the IDE support. In particular with Netbeans, at least until v6.5
Spring Webflow 2.0 support
So SWF published the first RC last week and IWebMvc already includes it. Nice! It's very well integrated with the rest of the framework, in particular with MVC, JPA, Security and AJAX. I pretend to blog about this feature in the near future.
Jasper Reports / Dynamic Jasper support
PDF & Excel file download. Automatic grid reports in less than 20 lines of code! Really useful for statistics in the future.
Multi file upload
Upload documents and images in multiples and group them in the server. Including a specific widget.
Image Gallery widget
Show grouped images as a thumbnail strip or as a slideshow with one line of code!
Rating widget
A new way to bind numbers using the latest dojo widget.
Miscellaneous
Several bug fixes and Eclipse support were also improved. Glassfish configuration as well. Check the changelog if interested!

As always, the code along with a new screencast of the features is available at the project's download page. I've to thank you the Google code team for doubling the available space for IWebMvc!

Enjoy!

Mixed feelings adding Groovy support

2008-04-26T02:55:00.000-07:00

One of the purposes I had for this year was learning Groovy. And, since the beginning, I knew IWebMvc was going to support Groovy although I didn't have a real clue about the extension of this support. During the last week I've worked to get both things done. As a matter of fact, it was easy and I learned a couple or three things in the process that may be of interest to some Groovy beginners (like me). Let's start with the cool features:

Prototyping
Scripting is FAST and it really saves time. If you're like me and start coding just to get an idea of the problem and explore possible solutions this feature alone makes Groovy worth the effort. It boosts productivity by an order of magnitude!
Spring support
Well..Spring is always good, isn't it? Unless you're using JavaRebel (and enjoying it already), refreshable beans are a bless. And it also allows (encourages?) quick & dirty hacks ;-)
Groovy beans
I migrated the Domain model of IWebMvc to Groovy. I don't know the lines of code that where removed in the process. A boilerplate killer!
Language entensions
GStrings and Object extensions (read Collection) are outstanding. I won't even mention closures (you should be used to them via Javascript). Really useful
Choice
Better let the developer choose which language is better suited for a particular problem. IMHO any modern Java based framework should include Groovy support.

I had a so-so feeling about some things though:

Groovy != Java
This may come as a surprise to some (it was for me) and be obvious for others (heck it's Groovy and not Java!). The fact is the relation is tight: they both work in the JVM, can work together and share syntax but..they're different. Subtle differences really but some that make impossible to rename your Java classes to .groovy and expect your application to work.
Groovyc
Joint compilation is a very intelligent idea and Groovyc works very well but it's not on the same league as Javac. It lacks maturity, reliability and speed. I hope Sun can help the Groovy team as they did with JRuby.
Migration
After adding Groovy support to IWebMvc I was forced to move some code to Groovy even if just to serve as an example. I had mixed feelings with the results. Groovy is amazing to improve productivity but you miss that when you have an already working code. And then there's the static typing issue..I wasn't happy to loose it. At all (I guess my code is not that groovysh)

Finally there were things I just plain disliked:

IDE support
I'm a Netbeans user. There's no current Groovy plug-in that works with 6.1RC2 out-of-the-box. You may try to install one from the Development Update Center (I couldn't). One doesn't know how much he relies on things like syntax highlighting (let's not say debugging!)...IDE support in Netbeans is bluntly put, awful.
Generics
Are Generics in open confrontation with dynamic typing? I guess they are. Java support for Generics is mild...Groovy's...much worse.

All in all, Groovy IS the future. I'm quite sure I'll be using it extensively. Unfortunately, today and with Netbeans is not ready for prime time.

IWebMvc receives a JavaRebel free OSS development license

2008-04-15T00:47:00.000-07:00

I received it in the mail yesterday and I'm eager to start using it. For those that don't now JavaRebel is an astounding tool that lets a developer reload modified classes during runtime. This means that once an application is deployed it will automatically detect changes in class files and transparently apply them! Only Weblogic 10.3 seems to have a feature like it..at how many times the price!!

The best of all is that ZeroTurnAround people are working hard to get Spring support working. In fact, Spring works per se but they want to get automatic configuration reload so bean state is kept. Awesome isn't it? And other proxy libraries as well (JavaAssist, CGLIB and such). IMO it's one of the most interesting technologies right now and one to watch this year.

Thank you JavaRebel! And thank you for supporting OSS projects! Even those as less known (yet) as IWebMvc.

IWebMvc CRUD Screencasts. Learn the framework

2008-04-13T07:57:00.000-07:00

During the last month I've been asked the same question time and again, people somehow feel that IWebMvc demo is cool but have many many doubts about how to make use of it. In fact, if IWebMvc lacks something at the moment that's documentation! Well, I had some time during the weekend so I decided to invest it creating two little videos. Both of them show how easily you can leverage IWebMvc functionality in your application.

The first one explains how to add a new (somehow simple) entity that uses a couple of the framework widgets and how the DB schema is automatically generated and the developer gets CRUD operations & security in less than 30 lines of code.

The later tries to go a step further and use an entity inside other entities while getting full text search and RSS feeds in the process. By the way, it uses a custom view instead of those provided by default.

Both together give a quick glimpse of the CRUD possibilities of IWebMvc. They're available at the project download page.

Enjoy them! And help share the news!

Web Framework Smackdown Questions: IWebMvc

2008-04-13T04:59:00.000-07:00

Other frameworks have already answered (Click, Tapestry) Matt's questions so I'm doing it as well:

What is the overall performance of your framework as it compares to others?
No benchmarks have been passed yet but IWebMvc makes full use of Spring MVC / Hibernate on the server side and DWR / dojo on the client. Performance should be on par with those libraries.
How does your web framework position themselves in relation to Web Beans?
JSF / EJB3 is a powerful stack but it cannot stand the visuals and possibilities of dojo on the client and the flexibility Spring + JPA offers on the server.
How easy is it to create a re-usable component in your framework? Is it as easy as sub-classing an existing component?
A new component is composed of a tag lib wrapping the client code and a JPA entity that serves as backend. The most complex components may required a specific Spring data binder. There are several (ten or more) examples for each of these. Framework components are designed to be extensible by nature. All server operations are generic and will work for any new component (CRUD, RSS, security...)
What is the key differentiating characteristic of your framework that makes it better than the rest?
The base is impressive and rock solid (JEE / Spring (AOP, MVC, ORM, TX, Security) / JPA (Hibernate) /DWR / dojo) and IWebMvc just starts there. So basically you get a working application based on those technologies and lots of goodies to make the developer life easier. In addition, choosing such a fixed stack ensures a tight integration between each layer.
What do you think about the various scopes introduced by Seam, e.g. conversation vs request or session? If you support these additional scopes, do you also provide some sort of concurrency control?
IWebMvc will support out-of-the-box Spring Webflow integration in the near future.
Why can't we, the Java Community, come together and adopt the best application framework and settle the web development subject?
Innovation is key in this world. Each framework offers something new and different. IWebMvc probably offers the best DWR / dojo integration with server side technologies available to date.
What are you doing to help with developer productivity?
That's the main goal indeed! Working project scripts (compile, dependency management, QA), generic controllers and functionality, pre-built common tasks, wrapped client code, powerful stack, screencasts & documentation. Everything points in that direction. IWebMvc is a framework aimed at developers.
2008 is a huge year for the mobile web. How do you help developers build great mobile web applications?
I'm not sure IWebMvc fits the bill here or if some other frameworks are better suited.
If you couldn't use your framework, what would you use and why?
I guess bare Spring MVC / Webflow / DWR / JPA and rebuild some work from there. Another route would be Grails.
How do you enable rich Ajax applications?
IWebMvc was designed with AJAX in mind and cannot really be used otherwise. All widgets support and use AJAX extensively.
Can a developer make a change to source, and hit RELOAD in the browser to see the change? If not, why not?
No problem with client side code (JSP, tag libs, JS, CSS). Java / Spring beans / JPA entities requires the use of and additional product like JavaRebel (or Weblogic 10.3) or a plain restart (to update the DB schema for example).
What do you think about the whole Flex revolution, and do you think you are competitors to this technology?
In some ways we do as IWebMvc offers a lot of client side code. Flex is an interesting technology and so is AJAX. Both are well suited for web develoment. IWebMvc prefers the later because it saves the developer the need of learning a new language and because target applications are more likely to be of the enterprise class rather than highly interactive Flash enabled sites.
How easy is it to create a module and plug it into a bigger application, complete with configuration, code, and view?
Framework and application code are clearly separated. But in truth, as of now, IWebMvc is not designed to create plugins but complete web / enterprise applications. Nonetheless, as long as you keep the Spring configuration in a different XML file and use a different namespace for your sources, with a little extra work everything should be fine.

IWebMvc Milestone 3 released

2008-04-10T03:31:00.000-07:00

I've been working hard to polish a lot of aspects of IWebMvc for this milestone 3 and finally today I've finished. The result is a much more mature product that starts to resemble a usable framework. Nonetheless, I had time to add new features as well, some of them really important!

Let's review some of them:

Security
IWebMvc now supports Spring security 2.0 based authentication and authorization using the new security namespace possibilities.
- Spring Security 2.0 RC1
  The new version of Acegi is fully configured. Declarative security enabled.
- Database realm
  Users / Roles are persisted in DB as any other entity.
- User Administration
  CRUD operations to add / edit users, assign permissions and toggle (enable/disable) them are provided out-of-the-box.
- Login / log off widget
  Working and easily integrated form based authentication. Default user/password combination is iwebmvc/iwebmvc (change it in iwebmvc.properties file)
- Captcha widget
  AJAX validated captcha to enable human detection.
- Remember me
  The framework will auto-login a user if so desires and will store authentication info using cookies.
Preliminary documentation
A long standing due. A good percentage of the client interface is documented using the demo application.
Widgets
- I18n Text
  A user can attempt to automatically translate texts into any of the supported languages using the Google AJAX Translation API
- Tree (Hierarchy) widget
  New in this version, a user can build a tree of generic nodes and modify it as wished.
- Grid (Table) widget
  The new grid supports a contextual menu, filtering (in addition to paging and ordering), inline edition of cell data (with AJAX storage management), cell content view (for data that exceeds column width) and auto width/height
- Form widget
  Allows to check required fields before submitting and sending complete forms using JSON.
- Other widgets
  Everything has been revamped a little or a lot.
Miscellaneous
- YUI compression
  All JS is minified before sent (in addition to GZIP). This isn't activated by default in development environments.
- Audit
  All create / update / delete operations are transparently audited (user, operation type, date/time, affected record, ...)
- RSS feeds
  A generic framework to obtain RSS feeds of any entity has been developed. Example feeds have been created for audit operations.
- DWR custom converters
  Working with JPA entities in JS is easier with the UUID and the Class converters.
- IE7/Opera support
  A lot of work has been invested in making IWebMvc compatible with other browsers. IE7 is fully compatible with this release (though this bug in dojo affects any page that contains an Editor). Opera support is preliminary but a good chunk of the code is working.
- Upgraded libraries
  In particular, to dojo 1.1 final but Spring, Hibernate and many others as well. Important: Netbeans project files have been migrated to v6.1beta to get rid of some absolute paths and facilitate project sharing (and include sources and ...). I've just tested this release with Netbeans/Glassfish & Ant/Jetty (though Eclipse/tomcat should still work fine).

And dozens of bug fixes and other issues. All in all, a decent work! Remember that you can download it from the repository. Or save time by watching the (trimmed) screencast (you may need this codec). Enjoy it!

IWebMvc Milestone 3 Client Features Screencast

2008-03-31T09:00:00.000-07:00

I'm still in the middle of the way to Milestone 3 but I wanted to create a screencast of the features currently available so here it is!

Unfortunately:

I've tested it under VideoLan & QuickTime and both play the file fine. For some obscure reason WMP fails to do it.
Google Code just allows files up to 20MB so I had to remove the later parts (searching, auditing, other widgets) and compress it further
It just covers the client side (won't see any code)

But, all in all, it's a good showcase of what IWebMvc offers out-of-the-box to any developer. In the near future, I'll try to create a new one showing the development process, probably explaining how to create a new domain entity and getting CRUD operations running.

And remember, some of those features (security, documentation, widget enhancements...) are exclusive of Milestone 3 so they won't be publicly available for a while (I reckon a week or so yet). But you can always get the latest SVN revision if you want to test them today.

IWebMvc M2 available: Lots of goodies

2008-03-21T06:08:00.000-07:00

It's been less than a month since the preview release of IWebMvc but a lot of things have been added to the platform and I thought it was a good moment to release a new version. I will label it as Milestone 2. In case that you didn't try the first one I've created a short presentation of the framework possibilities. It's the fastest way to get your feet wet with IWebMvc and an interesting reading nonetheless. You can obtain it from the project download page.

And to the topic! This new version packs lots of new functionalities so I'm going to just list them and provide some info (remember that the best way to understand everything is downloading and checking for yourself!):

Environment features
- Additional supported configurations
  In addition to embedded Jetty, IWebMvc can now be run in Tomcat and/or Glassfish (or any other JEE5 compliant AS really). IWebMvc will autodetect the deployment server and apply some custom configuration.
- Per server configuration
  IWebMvc transaction management can be configured in pretty much any way you like. It offers examples to be easily deployed in different environments: Database pools, full JTA, Spring JPA, driver manager connections, JOTM, with or without JNDI, ...
- IDE integration
  This version provides Netbeans 6 / Eclipse Europa project files for easy workspace setup.
- MySQL support
  IWebMvc will accept MySQL (in addition to HSQLDB) as database back end.
- Installation guide
  In addition to Jetty demo, IWebMvc includes now complete installation instructions to run it in the several supported configurations.
- Cache & compression filters
  All content served will include HTTP cache headers and will be compressed using gzip, improving performance and saving bandwidth.
- IE 7 preliminary support
  There are still minor glitches (mainly with file management) but 90% of the features already work.
Hibernate features
- Full Text Search
  In addition to filters, IWebMvc can look up entities searching in all indexed fields.
- Completely revamped Filter functionality
  Easier to include and more powerful.
- Support for lazy initialized collections
  Views can wok with uninitialized collections transparently.
DWR features
- Classpath scanning
  DWR will scan the classpath looking for suitable beans (those annotated with @RemoteProxy) and create automatic proxies for them.
- New DWR read store
  Built from scratch dojo data read store. Tested support for FilteringSelect and/or Grid widgets.
dojo features
- Upgraded to version 1.1 beta 3
  All client code has been migrated to the latest available developing version of dojo (final release of 1.1 expected this month).
- Theme support
  User can change the appearance at any time. All three (Soria, Tundra, Nihilo) themes from dojo are available. Custom themes can be added with little effort.
- Entity Locator widget
  Domain entities can be binded using a powerful search widget (in addition to preexistent combobox widget).
- Video widget
  New video component supporting Flash (.flv) archives
- Thumbnail widget
  Server side on the fly creation of thumbnails for any image.
- Grid widget
  In addition to PagingGrid, classical dojo grids are now available
- List widget
  Any List<DomainEntity> can be created / updated transparently. All binding and validation is automatic as well. A specific tag wrapper and client component have also been created. Other collection widgets can be easily derived from this one.
- Refactored client code
  Most of JS code has been refactored out of the widgets to a common file to improve performance and maintainability.

In fact, there are more features present but I'll left them undescribed for now. Of course, this version packs dozens of bug fixes as well. But better see it by yourself! So I have to encourage everybody to go to the dowload page and give it a try. Or by checking out the latest sources (svn export http://internna.googlecode.com/svn/trunk/IWebMvc IWebMvc). As always comments, suggestions, contributions, requests are very welcomed using the mailing list. And expect many more new features coming soon :-)

IWebMvc first preview version available!

2008-03-03T03:42:00.001-08:00

The landscape of web frameworks based on Java is crowded. For the most part, they are all flexible and capable and you're better served using them than trying to build something by your own. At the bare minimum you are saving time. The price to pay is the learning curve. And sometimes is steep! Let's take Spring, for example. The basics, the IoC container, is easy to learn and leverage but add now, AOP, transaction management, MVC, security and/or ORM capabilities. Things can get complex really soon.

Unfortunately, even if you happen to master all those topics, a new issue will rise his ugly face. It happens because even the best frameworks just target some clearly defined development areas, for example, Hibernate targets database abstraction. This means any developer is forced to include a variable number of libraries and integrate them as best as he can. Being a committer of DWR (currently responsible of the Spring integration) I, for sure, know first hand what this means. In short, troubles.

Some Open Source frameworks have come to the rescue. AppFuse will let you kick start a project using a different combinations of frameworks quickly. Grails is another great web platform, the scaffolding features are fantastic (automatic controllers and views!) but it's based on Groovy.

Nonetheless, in my mind what I really needed was a platform that:

Is based on Java
Although supporting Grooy / JRuby is a plus
Helps me to kick start a project
But simplifying the process by giving me the best (and this can be tricky) set of frameworks for each task
Integrates both server and client sides
And it's lightweight, robust and extensible. Read enterprise quality.
Supports all the common tasks a web app has to handle
I include here: User Management, CRUD operations, i18n support (both framework & data), AJAX and astounding visuals

In the end there was nothing in the wild that could help me. In part because my framework choices are pretty clear (and fixed): JEE5/Spring/Hibernate/DWR/dojo. I have a number of projects on my back (heck! 10 years!) and these tools have helped me (like no others) to achieve robustness, productivity and quality.

So at the beginning of the year I embarked a personal task. I would build a web framework (yet another!), filling the void that existed, and release it as Open Source. I knew I had the knowledge (picking ideas from each successful project I've been in) and it was a matter of effort.

I'm glad to be able to release the first alpha (preview) version today! Here's the list of features I could manage to get working during the time:

Environment
- Fully configured project
- Ant + Ivy working build scripts
  - Transitive dependency management
  - Quality assurance tools and reports
  - Platform independent
- Server and database independent
  - Tested against Glassfish v2 and Jetty
  - Tested against MySQL and HSQLDB
Spring
- AOP, Context, MVC, ORM, TX pre-configured
- Root (parent) & per web application contexts
- Incredibly reduced XML configuration
  - Convention over configurarion
  - Annotation based configuration
- Locale support (English, Spanish)
- Powerful but easy validation framework
  - Injected in Controllers
  - Remote use with AJAX
- Repository abstraction
  - Implementation based on HDD (more following)
JPA / Hibernate
- Annotation based
- Automatic DB schema creation & update
- Base domain model provided
- JTA
- Generic DAO implementation
DWR
- Advanced use of converters & javascript
  - Mapped domain objects allow transparent work in the browser
- File upload with progress bar
- Leverages upcoming 3.0 functionalities
  - Not yet available in any other framework
  - Remote beans using annotations
  - File transfers
dojo
- Wrapped dojo widgets inside tag files
  - Centralized access
  - Auto-configured
- DWR integration
  - Including a DWR read store to populate content
  - Automatic remote validation added
- Widgets
  - Provided backing beans in the server for each widget
    - Automatic binding and validation
  - Included in this release
    - Textbox family (text, number, date, checkbox)
    - I18n text
    - Rich text editor
    - Document upload
    - Image upload
    - Entity grid (including pagination, ordering & AJAX backing model)
    - Filter (includes filter groups and ranges)
    - Menu bar
    - Entity selector (using a combo)
    - Color chooser
CRUD
- Automatic CRUDs for any domain entityt
- Default or customized views
- Build domain classes using Lego pieces
  - Automatic DB mappings
Miscellaneous
- 3DES Encryption
- Utility classes
- Little demo application

Not bad for a months work :-)

If you wanna try it (and I really hope so!) here are the installation instructions. Just a little disclaimer before: This is a preview (alpha status) release. It has many glitches (Firefox is in fact recommended). It's main goal is to offer a vision of where the framework is heading (it lacks several important features like security, documentation, theme support...). In addition I really wanted to make this release today so I rushed a little and couldn't fix some tests (don't worry about that). So, finally, the promised instructions, enjoy it:

Requirements
- Installed JDK 6
- Subversion client (if checking the sources)
Download
- From HTTP: Download from repository
- From subversion:
  svn checkout -r 72 https://internna.googlecode.com/svn/trunk/IWebMvc IWebMvc
Double click the provided run.bat file
Point your browser to http://localhost:8080/iwebmvc

Now, the real value of the platform can be seen creating a new domain class (like those in the demoapp.domain package) and getting for free the CRUD operations, the screens and the DB schema. And building the model class should be fairly easy using the provided backing beans (I18nText, RichText, Document, Image, ...).

For any questions (comments, contributions, recommendations, doubts...) related to IWebMvc please refer them to the mailing list.

DWR 3.0 & Spring: A quick preview

2008-02-13T10:39:00.000-08:00

With DWR 3 around the corner (the first milestone is available right now) is time to have a look at the new features it brings to the table. In fact, it packs so many, that I'm going to talk just about those related to Spring.

As you know (or should :-), by now DWR has a nice integration with Spring and specially Spring MVC, thanks to the custom namespace it provides. Nonetheless the team has make an effort to improve it. And the results are astounding! Let's review the new features:

Remoting beans from a parent (root) context
Until now, when using <dwr:controller> just the beans in the same context where proxied. From now on, the root context can define candidate beans as well.

New defaults
DWR will offer default names for your controller and remoted beans. In the former case the bean will be called dwrController. In the later, the bean will be available in your client code with the same name as the bean, capitalized. So <bean id="sample" class="..."> will be remoted as Sample.js

Explicitly setting an application context
As of now, the default web application context was always used. The new version allows a developer to set a specific application context in the DWR Spring servlet. DWR will scan this context looking for candidate beans.

Namespace support improved
Release 3 will add the <dwr:url-mapping /> tag. If declared in your XML (along with a <dwr:controller />) all the needed mappings will be automatically created and handled.

Configure everything using annotations
Spring beans annotated with @RemoteProxy and @RemoteMethod will be automatically proxied and available in the browser. To activate this feature a new <dwr:annotation-config /> tag has been developed. Just one caveat, this kind of configuration does not work for advised / scoped proxies for the time being. You have to revert to the common <dwr:remote /> and <aop:scoped-proxy /> in that case.

Classpath scanning
DWR will scan the classpath looking for classes annotated with @RemoteProxy and create the bean definitions directly (so you can ommit the @Component annotation). A new <dwr:component-scan/> tag has been created for it. A side note here, the code is not yet available (it's not in the milestone) because it requires Spring 2.5.2+ which has not been publicly released yet.

Several other minor changes and bug fixes
A lot of work behind the scenes. For example, a bean name can now be preceded by a slash so it's automatically mapped.

All in all, a lot of good work. And the best of all, it's just the beginning! Other areas, like file handling or reverse AJAX, pack even more interesting features. I can only recommend that you give it a try today.

Choosing a dynamic language to learn (Ruby/Groovy/Scala)

2008-01-29T04:49:00.000-08:00

I've had Ruby sitting in my ToDo list for far too long. I mean, at least for a couple of years! It's been so long that in the time some fellows have made into the list as well, namely Groovy and Scala.

Finally, this year, I've decided that the time has come and that I have to invest some effort. Unfortunately, I know have to decide where.

I will start saying that all three candidates share the basic functionality that I'm looking for:

Scripting
I want an interpreted language that saves me time to come up with quick prototypes and hacks. I want a powerful OS tool beyond shell scripts. I may need to compile to bytecode later as well.
Elegance and expressiveness
I want to avoid boilerplate. I need dynamic typing and runtime inference. I want syntax sugar! I want easy to read DSLs.
Closures
They are a must. My only concern is readability but beyond that I cannot understand why Java does not have them yet.
Mixins
Inheritance on steroids.
Go Functional
Try to combine imperative style with some characteristics natural to functional programming. Less what and more how (descriptive style).

In the end, I want to be productive and those are the minimal requirements (nowadays). Beyond that, it's a matter of taste. Here's a little list of pros and cons of each. Take it with a grain of salt, this list is based on my personal preferences, many points will not be worth something to anyone but me:

Ruby
The first of the crop and the most popular for sure.
- Pros
  - Refreshing (depart from C syntax)
  - Rails
  - Mature (since 1995)
  - Community
  - JRuby / SUN involvement (leverage the Java platform)
- Cons
  - Too much hype
  - Lacks "enterprise" consideration (Threading? Scaling?)
  - Low ROI (see market penetration)
  - Is it loosing momentum?
Groovy
Enterprise capabilities along with cool productivity features
- Pros
  - Tight Java / JVM integration
  - Extends JDK API(GDK)
  - Easyness / Learning curve
  - Out-of-the-box Spring integration
  - Grails
- Cons
  - Performance
Scala
A general purpose (multi-paradigm) programming language
- Pros
  - Interoperability with Java
  - Language features not retrofitted (ie Genericity)
  - Actors, concurrency and distributed programming
  - Implicit enrichment of a Java class
  - Statically typed with inference
- Cons
  - Tooling
  - Not mainstream yet
  - Smaller community

In the end, I've chosen Groovy. I'm a geek, true. But I'm also a lazy developer and I like to apply my knowledge on day-by-day basis. For me that's easier in the Java camp (ie. with Spring).

I could choose JRuby then, but I'm not sure that's the correct path even though Sun's commitment (for example, with Netbeans and the compiler) seems pretty heavy.

Scala could be. Indeed it's improving (as the others) but it's not there yet. In the end, Scala seems more like a (future) Java replacement and that's not what I'm looking for right now.

A little bit more DWR and Spring MVC

2008-01-21T03:33:00.000-08:00

I've blogged before about integrating Spring and DWR. This is just an update (though interesting) with some clarifications due to a request in the DWR mailing list.

Each new version of the Spring framework adds flexibility mainly by adding new features. This, in turn, can mean added complexity even though the additions are well thought and easy to apply. The complexity comes with the mix and match. In some way, it's like Java itself, it's not the added complexity of a new language feature, it's the integration with the rest of the language and the corner cases that appear. This is commonly a consequence of backward compatibility and the absence of deprecation.

Spring MVC 2.x has included new implementations of the classical Controller interface. Along with them new view resolvers and mappings were developed. These new controllers provide a new way of getting things done, for example, using annotations, but were designed to work side by side with the rest of the framework. This can lead to some confusion, easily, when some controllers are instantiated using component scan, others are declared in XML, some are mapped by annotations, others using convention over configuration and the views are injected or resolved by name and/or URL. Add DWR to the mix and things get scary for the less experienced developers.

I will start with an advice, do not mix different technologies if at all possible. This will force you to choose a path and commit to it but it will pay benefits in the long run. Less is more.

So what options are available? I will list the ones I consider the more intuitive. There are more combinations possible and even more options that I won't list (for example, declare the URL as the bean id).

Use XML to explicitly declare beans and mappings
As always have been made. It's simple and expressive. Views can be handled by a InternalResourceViewResolver. The schema is highly integrated so DWR just becomes a couple of added lines in the related beans. The bad news, the unneeded boilerplate.
Convention over configuration
Use ControllerClassNameHandlerMapping and DefaultRequestToViewNameTranslator. Declare your beans in XML. Add a specific mapper for DWR at the end of the chain (order = 2).
Annotations all the way
They're concise and powerful because they're attached to the element. Do not mix with XML or get ready for the mandatory pandemonium that you have started. By the way, HandlerMappings are usually easier than HandlerAdapters. Unfortunately, currently DWR annotations are not tightly integrated (something to improve) so you need to fall back to the provided schema which seems counterintuitive.

And that's pretty much it. As I know that some people will still reject the advice and throw everything together, I have prepared a little sample project. It features four different controllers, three different mappings and a couple of view resolvers in addition to a DWR remoted bean. It's available here. Hope it helps.

The evilness of accessors

2008-01-14T04:50:00.000-08:00

There are things in life that you take for granted. That is, you are so accustomed to them that you never question them. What for? Accessors (member functions that directly manipulate the value of fields) in the Java world is one of them.

The use of getters and setters is one of the first lessons to learn when working with Java, probably because the JavaBeans specification mandates their use. They help to increase robustness, enforce logic and hide implementation details. What's not to love? Well, something.. but maybe Java 7 will finally bring us properties...

During the weekend I read an interesting article titled Dishonest Programming. I'll quote one of the paragraphs:

Don't write a public accessor to a private member and tell me that member is still private. If an object is completely and utterly accessible from anywhere in the application, it's a global variable.

Everything was related to the following line of code (a line I've written a handful of times...):

setupModel.getOverrides().add(accountOverride);

Or a subtle variant:

for(Bean b: a.getBeans()) b.doC();

The Law of Demeter (Principle of Least Knowledge) clearly states that a method M of an object O may only invoke the methods of the following kinds of objects

O itself
M's parameters
Any objects created/instantiated within M
O's direct component objects

Right there I was puzzled. The principle seemed correct but its implications were awful! Imagine this class:

public class company {
   private List<Address> addresses;
   private Set<Account> accounts;
   private Map<Long, Employee> employees;
   ...
}

Can you determine the number of methods to add to the interface if you pretend to comply with the LoD? At least a couple of dozens for the collections (just java.util.List packs thirty approximately) and some more for the types.. On the other hand, the reasons exposed by the author (here) seemed valid:

Violate encapsulation
Tightly couple all three objects together
Cripple modularity/type independence
Deprive the parent class of the ability to guard, or even be aware of, the child data

First of all, as an architect I tend to agree with those reasons.

The first one is problematic though. Aren't public getters already breaking encapsulation? The moment they're available any other object can really interact with the supposedly private fields.

The second worries me greatly! This kind of code glues together objects that shouldn't be tied.

The fourth is problematic as well. PropertyChangeListeners already exist in Java but they're meant for peer-to-peer interactions not for parent/child invocations. If you're bypassing the object this way it's probably better to refactor.

At this stage, we have a problem. If the internal structure of an object is available (and so do the getters) it's difficult to avoid using it (or telling a programmer to avoid using it, if you prefer). I've come to the conclusion that creating proxy methods for cascade operations is the way to go, even if they are a lot!

There are two options then:

Defaulting to a protected visibility
Returning immutable objects

Both have pros ans cons. The first one may not work at all if the rest of the architecture expects public getters (some ORM frameworks or the EL in a JSP do, for example). The second one can be (somehow) confusing, tedious to implement for beans (for Collections is already done) and (depending on the implementation) even penalize the overall performance.

Finally, and I agree with the original author here, everything is a trade off and nothing should be written in stone. Just don't abuse the delegate strategy and try to conform to a best practice. We all know Java is verbose to the extreme and that this solution adds even more boilerplate (and that in 90% of the cases it won't matter) but if you stick to Java that's a nasty side effect you have to bear with. Just don't try to create shortcuts that punish good design.

Squashing boilerplate in Spring

2008-01-05T13:00:00.000-08:00

Nobody can deny that the advent of IoC/DI frameworks, ORM tools and Web Services has brought robustness to the enterprise world. Programs are more clear and concise than ever before, at the cost of moving configuration from the source code to a specific realm, usually based on XML files. This, by itself, is not bad at all. In fact, is a Good Thing. Problems appear when the configuration is a language itself and grows so much that can be compared in size to the source code.

Here's a little guide that will help you to minimize the amount of config needed in a project

Annotations are your friend!
Easy one. From a dubious start, annotations are now considered a first class citizen. Even Spring developers encourage their use now. If you are using Java5+ try to move as much XML to annotations. It will help you in two ways: less code is needed and configuration is attached to the component directly (which makes reading code easier).

In Hibernate/JPA nearly everything can be expressed with an annotation. Spring now offers annotations for bean creation(@Component...), managing life cycles(@PostConstruct...), wiring dependencies (@Resource...) and security (@Secured...). The MVC framework (in 2.5) also packs some more to help with controllers (@Controller...) and method and parameter mappings(@RequestMapping...).
Leverage the latest version
One of the areas that has evolved more positively from Spring 1.x, without doubt, is writing configuration XML. The second release of Spring brought a lot of syntax sugar in the form of additional schemes(jee, util,...) and simplified the dependency declaration. Spring 2.5 has brought the p namespace and component scanning. And above all, not only is XML configuration easier to write, it is now also extensible.
Autowire
Autowire has always been available and has been discouraged with passion as well. Detractors will tell you to skip the magic that happens behind the curtain. I cannot agree more. It was a common point of failure. And one difficult to debug.

Nonetheless, the situation now has changed a little. The @Autowired annotation is already quite clear and it can be used in conjunction with @Qualifier to improve the understanding. I wouldn't autowire everything, don't get me wrong, but how many times do you have an interface with just a default implementation? Not all your beans can be candidate to be replaced by another strategy, do they?
Convention over configuration
A mantra for RoR developers. Probably they embraced it after writing some code in Java! Basically, avoid configuring something if there's a suitable default value already. And stick to defaults as much as possible. Maven does it for example, keep the standard directory structure and Maven can work with pretty little configuration overhead.

Spring has always favored this kind of development as well. But in 2.x MVC new additions encourage it further(it's called sensible defaulting): ControllerClassNameHandlerMapping and DefaultRequestToViewNameTranslator. In case you haven't used them yet, they allow the dispatcher servlet to select a handler based on the class name of the controller and equally forward the result to a view. For example, IndexController and index.jsp would be invoked for http://.../index.htm without any configuration explicitly written.

Of course, beware that there's again a lot of magic behind the curtain. At least document it somewhere (the project wiki comes to my mind). It won't cause you any troubles though (if you're not pushing the edges..), the controller and the view will be invoked or not
Create a root application context
Beans can be inherited from a parent application context in Spring. This means that any shared beans should be refactored there and later be referenced from any other context. Beans can be shared between web applications, EJBs and the like. More info is available here. Remember that Spring 2.5 offers the possibility of deploying application contexts as a JCA adapter for headless applications.
Create abstract beans
Probably you're already using abstract classes to encapsultae common functinality. Are you doing the same for beans? I'll copy Spring documentation here:
A bean definition potentially contains a large amount of configuration information, including container specific information (i.e. initialization method, static factory method name, etc.) and constructor arguments and property values. A child bean definition is a bean definition which inherits configuration data from a parent definition. It is then able to override some values, or add others, as needed. Using parent and child bean definitions can potentially save a lot of typing. Effectively, this is a form of templating.
If you're still in doubt imagine how many of your beans usually have a dependency on the persistence facade, the document repository, a cipher or a combination of them! A hierarchy of bean skeletons helps immensely (and not only in writing less code).
Less is more
If you've read Getting Real from 37 Signals (it's free and highly recommended!) you're familiar with the term. If you've read The Pragmatic Programmer you are intimate with the DRY (Don't Repeat Yourself!) principle by now. Maybe Martin Fowler Refactoring? Pick the example you like most, rest assured there are several. All point in the same direction, write less, more concise code. It'll be easier to read, to debug, to maintain and generally it'll work better. The moral is to abandon all complexity!

Starting up

2007-12-29T04:19:00.000-08:00

This is the first time I'm going to blog to recommend something. I haven't done it before because I find it quite boring. There are lots of blogs (and sites) that do it already. Even for technical stuff.

But I've found this post enlightening. I tried some time ago to build my own company and I failed. Miserably! Really. The worst of all is I didn't take the time, back in the day, to understand what didn't work or what could be improved.

Read 36 Startup Tips: From Software Engineering to PR and More! first and then you'll be able to understand what did I wrong:

Code! Code! Code! Of course...I'm a good Java architect (and programmer) but it's difficult to sell just by saying it loud. People have heard it thousands of times from thousands of different people. Prove it!! Designers have a portfolio. I should have had one as well
Size! Do not try to embrace so many different areas. It's not credible. A small sized company has to focus if it tries to compete. A lot!
And finally..PR. If you're good technically concentrate in that tasks because you probably aren't good at networking. And even if you are, you probably won't have the time to do both things in parallel

The bright side is you don't need to accomplish every point in that list to be mildly successful. After more than two and a half years Internna is still open for business (without loosing a cent). I can't commit my full time to it (as I would like) but there it is if the opportunity arises!

Good luck in your endeavors!