DWR version 3.0

The much awaited DWR version 3.0 has reached release candidate 1. What's new?

• RPC Enhancements
  • Varargs support
  • Method overloading (DWR tries to copy Java's method matching rules)
  • Typed parameters (so you can say new Apple() in JavaScript and pass it to the addFruit() method and DWR will instantiate the correct type on the server)
  • Lightweight typed parameters (as above, but by adding $dwrClassName:"Apple", for when you are getting the objects from something else)
• More natural synchronous XHR (so you can call var reply = Remote.getData() when doing 'Sjax')
• Improved Marshalling
  • Binary file upload/download (byte[], java.awt.BufferedImage, InputStream etc and FileTransfer can be uploaded from an input type=file, offered for download, or sent to an img)
• Functions (Store a reference to a JavaScript function on the server for later execution)
• Objects by Reference (Store a reference to a JavaScript object, and then call methods on that)
• Locale, Currency (DWR will marshal to and from java.util.Locale and java.util.Currency objects)
• Reverse Ajax
  • JavaScript can now implement a Java interface (For simple integration with Java Events/Listeners)
  • More scalable Reverse Ajax APIs (See org.directwebremoting.Browser)
  • DOM Manipulation Library (Window and Document can now be manipulated from the server)
  • The server now runs in 3 modes: stateless (New - save memory with no page tracking), passiveReverseAjax (the default) and activeReverseAjax (comet enabled)
• TIBCO GI Integration
  • Complete set of Reverse Ajax Proxy APIs (So you can manipulate your GI user interface from Java on the server)
• Dojo Integration
  • Data Store (Keep a server side data store in sync with data in a client browser with both sides able to send updates. The data store also supports paging, sorting and filtering)
  • Packaging Integration (dojo.require all your DWR scripts)
• Server Support
  • Asynchronous servlet support for Tomcat and Glassfish
  • Improved Spring and Guice support
• Over the wire
  • JSONP support
  • JSON-RPC support
• Tech Previews
  • JMS Integration (Publish to the browser directly from JMS)
  • Jaxer Integration (Zero configuration for trusted environments)
• Infrastructure
  • SVN (We've moved from CVS to SVN)
  • Related Projects (Our repository contains a set of related projects including a number of demos)
• CLA (We've been through a legal review and have signed CLAs for dwr.jar)
• Dojo Foundation (We joined the Dojo Foundation and are now hosted by their servers)
• Better Documentation (DWR version 1.x had great docs. Version 2.x let things slide a bit, but we've dropped Drupal, and have our own system now)

There are also a bunch of things like better logging, error reporting and so on, but the full list would get quite dull. 2 things dropped out that we’d previously talked about: Bayeux Support and Gears Offline integration. We'll get to those, particularly Gears, soon.

I'm sure there will be lots of questions about how to use these features. Please don't ask in the comments; join the mailing list and ask there. As we roll out the new documentation system in the next week or so, all the details will be in there, and I'll then come back and link up this blog post.

You can download it now.

(Via Joe Walker’s Blog.)

We have just released version 1.0.1 of Jersey, the open source, production quality, reference implementation of the JAX-RS 1.0
API. The JAX-RS specification is available at the JCP web site and also available in non-normative HTML here.

This release will be available soon from the Glassfish v2 and v3 update centers.

To get started with Jersey read the getting started document. For an overview of JAX-RS features visit the Jersey wiki and read the overview document. To understand more about what Jersey depends on read the dependencies document. For details of the Jersey API go to here.

This release has many bug fixes, you can see the change log here, as well as the following improvements and features:

• The IoC integration SPI was improved to provide a clearer and well-defined distinction between IoC-managed components and Jersey-managed components. Additionally, Jersey managed components now support @PostConstruct and @PreDestroy for all the supported Jersey-based life-cycles.
• Spring integration was improved based on IoC integration improvements. Spring-registered beans (in the XML configuration or auto-wired) that are root resource or provider classes are automatically registered. See the JavaDoc here for more details on how to integrate with Spring.
• Craig McClanahan has contributed a high-level MIME multipart API. This makes it easier to read and write MIME body parts using the same mechanisms as reading and writing entities of requests and responses. We expect to leverage this API for further ease of use improvements in future releases.
• Jakub added two maven archetypes for quickly creating maven projects: a quick start Web application archetype using Glassfish and embedded Glassfish; and a quick start Grizzly application archetype. See Jakub’s enterprise tech tip and Arun’s blog entry for more details.
• A Scala-based Web application sample and a very simple Groovy-based embedded Grizzly server sample are now included in the samples.

For the next release, 1.0.2 scheduled for Jan/Feb 2009, we plan to include the following contributions:

• Utilizing the Jersey Client API with the Apache HTTP client, contributed by Jorge Williams.
• Integration with Guice, contributed by Gili Tzabari.

For feedback send email to:

users@jersey.dev.java.net (archived here)

or log a bugs/features here.

(Via Earthly Powers.)

Since the launch of Restlet 1.0 in April 2007, we have been working hard to prepare this new version. To protect your investment in existing code, we have maintained the initial API design, extending it where necessary and always ensuring a direct if not transparent migration path.

Here is a selection of the most exciting new features:

• Broader and deeper HTTP support with features such as partial downloads, resumable uploads or content integrity validation.
• Best support for the WADL specification in the industry, allowing an automatic and always in sync documentation of your REST APIs. WADL documents can be generated in XML or converted on the fly to HTML using the popular stylesheet from Yahoo!
• One of the first and most complete implementations of the new JAX-RS 1.0 specification provided for those preferring an annotation-oriented approach.
• New Restlet-GWT module provided, porting the client-side of the Restlet API to the popular Google Web Toolkit 1.5 JavaScript platform, allowing you to invoke RESTful applications right from your Web browser.
• New extensions for easier integration with the JAXB 2.1, JiBX 1.1, Spring 2.5, OAuth, OSGi, Oracle XDB and SSL technologies.
• Improved support for Atom Syndication XML format and for Atom Publishing Protocol. Both formatting and parsing are now available.
• New POP3 connector based on JavaMail to access RESTfully to remote mail boxes.
• New Grizzly HTTP server connector, first to fully leverage the NIO support in the Restlet API, leading to new levels of scalability and performance.
• New internal HTTP client and server connectors to simplify development phases (zero configuration necessary) and allow very small footprint deployments.

In addition, we have significantly expanded our documentation with a 150 pages long Restlet User Guide, a screencast and first steps tutorials. We have also added new licensing options: LGPL 3.0 and transferable commercial licences (OEM).

You just need to download Restlet 1.1.0 to enjoy those new features !

(Via Noelios Technologies.)

We have just released version 1.0 of Jersey, the open source, production quality, reference implementation of the JAX-RS 1.0
API. The JAX-RS specification is available at the JCP web site and also available in non-normative HTML here.

To get started with Jersey read the getting started document. For an overview of JAX-RS features visit the Jersey wiki and read the overview document. To understand more about what Jersey depends on read the dependencies document. For details of the Jersey API go to here.

Jersey 1.0 is released to the Java.Net maven repository. Jars, source, JavaDoc and samples are all available from the following base URI:

http://download.java.net/maven/2/com/sun/jersey/

All the samples can be obtained individually or as one zip file.

Jersey will be available soon from the Glassfish v2 and v3 update centers. And will be available in the Netbeans 6.5 release.

I decided to forgo a cycling themed picture this time and instead present a Castell. To quote Eduardo: "Many people need to do their tasks very well to build such a big castell". While the JAX-RS and Jersey castells may not require as many people as Glassfish i think the analogy still applies. Perhaps one could view Glassfish as an Escher like castell where each component is a castell itself? in any case i digress!

I would like to thank everyone that has contributed to the JAX-RS API and/or Jersey, whether it be the expert group members, comments on JAX-RS from external individuals (emails and blogs) and the many developers living on the edge trying out the Jersey early access releases, providing feedback and contributing code.

We have a better API because of the JCP process. With at least five different implementations of JAX-RS in development, four of them open source as of writing, the API was tested early and often.

We have a better reference implementation because we are open source, released early and often, and are responsive to the community.

What’s next? In terms of JAX-RS the expert group will be starting a maintenance release to align with EE 6. In terms of Jersey here are some current aspects off the top of my head:

• improve the boundaries between Jersey modules (for OSGi) and further modularize, this will require name changes to some API packages;
• better MIME multipart support;
• investigate further comet/AJAX integraton; and
• improve the integration with IoC frameworks. It is hard to be abstract from any IoC framework.

there is much more and i plan to create a more complete set of short and long term tasks in the next couple of weeks. If you have ideas send email to:

users@jersey.dev.java.net

or log a feature here.

(Via Earthly Powers.)

Release 1.1 RC2 is out, with all known bugs in Restlet closed (more than 20 fixed!). Please help us test this build while be work on the documentation tasks for the final 1.1 release.

Here is a summary of the main changes:

• Added support for HTTP authentication in Restlet-GWT module and fixed compilation issues.
• Fixed socket closing issues with internal HTTP server connector.
• Fully stabilized the Grizzly HTTP server connector.
• Fixed regression with SpringHost due to context refactoring.
• Fixed class-loading regressions.
• WADL extension now properly supports nested resources.
• Updated db4o to version 7.4.58.
• Updated FreeMarker to version 2.3.14.
• Updated JAX-RS API to version 0.11.
• Updated GWT to version 1.5.2 (final).

• Alexander Koppelhuber
• Alexei Sokolov
• Bruno Dumon
• Carlos Alexandre Moscoso
• Christoph Korn
• Doug Alcouffe
• Emblem Parade
• John Logdson
• Marcelo Ochoa
• Paolo Borelli
• Rasmus Agerholm
• Rob Heittman
• Roman Geus
• Stephan Koops
• Tamas Cservenak
• Vincent Ricard

Changes log:
http://www.restlet.org/documentation/1.1/changes

Download links:
http://www.restlet.org/downloads/1.1/restlet-1.1rc2.zip
http://www.restlet.org/downloads/1.1/restlet-1.1rc2.exe

Maven repositories:
http://maven.restlet.org is updated on the 1st and 15th of each month
http://maven.noelios.com is updated daily with new artifacts (access reserved to subscribers)

(Via Noelios Technologies.)

We have just released version 0.9 of Jersey. This aligns with the 0.9 release of the JAX-RS
API
and the editors draft.

For this and further releases the mechanism to obtain Jersey is different. There is no longer one zip file to download. Jersey is now modularized and mavenized thanks to the hard work of Jakub. Jars, source, JavaDoc and samples are all available from the Java.Net maven repo at the following base URI:

http://download.java.net/maven/2/com/sun/jersey/

All the samples can be obtained individually or as one zip file.  

Now it is much easier for maven developers to use Jersey. But as a consequence it is a little harder for non-maven developers to use Jersey. To aid such developers we provide a detailed dependencies document and a bundled jar containing all jersey-related functionality that was previously available in the 0.8 release.

In this release i managed to add support for generic server-side filters and a specific filter to support the "X-HTTP-Method-Override" HTTP header for clients that do not support HTTP PUT and DELETE. Martin has integrated JavaDoclet WADL support. See the example here for more details.

In the past week we have been doing things in parallel and i have been working on the 0.10 implementation before 0.9 is released. We need to step up the pace as the 1.0 finishing line is just a few weeks away.

(Via Earthly Powers.)

Yes, it’s true! A project has been underway for some time to create a GWT (Google Web Toolkit) wrapper for SmartClient.

The project, dubbed SmartGWT, will be made available under the same LPGLv3 license as SmartClient LGPL, with commercial licensing available as well. It will be hosted on Google Code with public SVN access, and external committers will be welcome to participate as with SmartClient LGPL.

We are happy to say that Sanjiv Jivan, the creator of another popular GWT wrapper, is involved in the development of SmartGWT. Sanjiv brings expertise in precisely the right areas, and with his help we’ve been able to make much more rapid progress with SmartGWT than would otherwise be possible. We expect a preview release sometime in late October to early November.

Our Approach

(if you’re asking ‘what is GWT?’ read “Why GWT?” below)

Anyone who has looked deeply knows that SmartClient is a vast, very complete system - a recent count is that SmartClient supports more than 4000 documented, supported APIs. Translated to Java, this number will be far larger.

For this reason, we’ve taken an approach of generating GWT code from SmartClient’s documentation, combined with hand-coding portions that can’t feasibly be generated. By tweaking our documentation set to contain additional metadata (some of it GWT-specific), we’ve been able to generate code you might not otherwise expect, including things like enumerated constants and convenience constructors.

What this means is that the first release of SmartGWT will provide the complete SmartClient API, fully documented. Out of the gate, SmartGWT will be the most complete GWT platform in existence. And of course, all future versions of SmartGWT will match the API set of the latest SmartClient release.

Why GWT?

GWT allows you to write Java code which is translated to JavaScript by a special compiler, so that it can be run in the browser. This is best explained by example:

You write Java like:

import org.smartgwt;
import org.smartgwt.client.widgets.Button;
...
Button button = new Button("myButton", "Click me");
button.addClickListener(new ClickListener() {
    public void onClick(ClickEvent event) {
        ISC.say("Hello World!");
    }
});

This means the same thing as:

isc.Button.create({
    ID:"myButton",
    title:"Click me",
    click:"isc.say('hello world!')"
})

There are many approaches for “hiding” JavaScript behind a server-side Java abstraction (such as JSF, JMaki, etc). All these approaches have a common flaw that any code you write in Java requires a trip to the server to execute. The more customization, the more trips to the server, throwing away the primary benefits of Ajax (scalability and responsiveness). In these frameworks, something like a custom drag and drop interaction is essentially impossible - it’s not realistic to contact the server every onmousemove().

GWT differs fundamentally from these server-oriented Ajax approaches. In GWT, the Java code you write actually executes as JavaScript in the browser. So you can write event handlers, drag and drop logic, even custom subclasses of SmartClient widgets, and all of this code executes in-browser, exactly as though you were using SmartClient directly via JavaScript.

In a nutshell, with GWT you get the robust toolset of Java and the performance and scalability of a true “smart client” architecture.

It’s also important to understand that, although you are using Java instead of JavaScript to build your UI, you aren’t tied to a Java server. You can use SmartGWT with any server technology supported by SmartClient itself, including XML or JSON services built in PHP, or WSDL web services. And that combination is still an entirely free, open source offering.

Get Involved

If you are interested in getting the absolute first available sneak peak of SmartGWT, or if you are interested in getting involved in the project, send email to smartgwt at isomorphic.com.

In the meantime, it’s important that anyone choosing platforms right now knows about this very compelling option.  Please help us spread the word - to your colleagues, and to the Ajax blogs and sites you read most!

Thanks,

              Charles

(Via Ajax for the Real World.)

Just in case it got hidden in the message of the 0.8 release Jersey now supplies Spring support via the spring maven module that was contributed by Martin.

So, rather than copying some code from my blog, you can depend on this module and reference the Spring servlet:

com.sun.jersey.spi.spring.container.servlet.SpringServlet 

in the web.xml. That is it. Martin describes this in more detail here. Note that after this was written some changes were made to the package names as Martin describes here.

I am quite happy with it as we managed to solve a knotty issue of referencing Spring beans in constructor/method parameters that Jersey is responsible for invoking, thus JAX-RS/Jersey-based annotated parameters can be intermixed with Spring-based annotated or referenced parameters. Having said that i think we may be able to make the integration even smoother in two areas when using Spring-based annotation configuration: 1) inferring the life-cycle Jersey requires; and 2) reusing @Autowired for constructor/method parameters.

The mechanisms by which Jersey integrates with Spring can equally apply to Guice or WebBeans or a more specialized integration.

(Via Earthly Powers.)

A question came up at work recently about the best time (in terms of cost and quality) to build security into a web application, that got me thinking about this whole thing. Since we use the Spring Framework for our web applications, Acegi is the natural choice, being the de-facto security solution for it.

Acegi is very flexible - it has lots of customization hooks, and can connect to almost any popular authentication backend. However, to paraphrase Spiderman’s uncle Ben - “with great flexibility comes great complexity”, and Acegi is no exception. The configuration is the complex part - it’s done by wiring Acegi beans in the Spring application context, so you need to know what beans are available within Acegi and how to wire them up.

Several excellent guides exist on the Internet (do a search for “acegi tutorials“) - they are all worth a read. In addition, you probably also want to read the Acegi Reference Guide for more extensive coverage. It also helps to have the source JAR handy - I found lot of answers to my questions in the code.

I primarily used Bart van Riel’s Spring Acegi Tutorial as a guide when securing my app. The approach I propose here is prescriptive - given an insecure (Spring) web application, this post lists out the tasks that need to happen in order to make it secure with a rather basic but working Acegi configuration.

Unlike the other tutorials, this post makes no attempt to explain the purpose of the various beans in the configuration - I simply point out the places where you need to customize it for your own application. Not sure about you, but this format works better for me personally… I like to set up something quickly and fiddle with the code until it does my bidding. Obviously, to extend this configuration, you will need to read up to locate and understand the Acegi components involved.

(Via Salmon Run.)

Oracle is delivering the Eclipse tools for Oracle WebLogic Server 10gR3 with a simpler packaging (just one, with all features), and a new price (free!). This release of Workshop for WebLogic 10g R3 combines all the features of the other products.

(Via Eclipse In The News.)