Matt RaibleMatt Raible is a Web Developer and Java Champion. Connect with him on LinkedIn.

The Angular Mini-Book The Angular Mini-Book is a guide to getting started with Angular. You'll learn how to develop a bare-bones application, test it, and deploy it. Then you'll move on to adding Bootstrap, Angular Material, continuous integration, and authentication.

Spring Boot is a popular framework for building REST APIs. You'll learn how to integrate Angular with Spring Boot and use security best practices like HTTPS and a content security policy.

For book updates, follow @angular_book on Twitter.

The JHipster Mini-Book The JHipster Mini-Book is a guide to getting started with hip technologies today: Angular, Bootstrap, and Spring Boot. All of these frameworks are wrapped up in an easy-to-use project called JHipster.

This book shows you how to build an app with JHipster, and guides you through the plethora of tools, techniques and options you can use. Furthermore, it explains the UI and API building blocks so you understand the underpinnings of your great application.

For book updates, follow @jhipster-book on Twitter.


Over 10 years ago, I wrote my first blog post. Since then, I've authored books, had kids, traveled the world, found Trish and blogged about it all.

Tapestry 4.0 support in AppFuse's CVS

I spent the last couple of days upgrading AppFuse from Tapestry 3.0.3 to Tapestry 4.0.1. While the integration isn't as clean as I'd like it to be, everything works and all tests pass, so that's good. I did post a few remaining issues to the Tapestry mailing list, but there's nothing major. While the upgrade was frustrating (it took me 4 hours to figure out I needed "validators" instead of "validator"), I feel I know a fair bit more about Tapestry now. Furthermore, my experience on the Tapestry user mailing list was incredible. Yesterday, for every question I'd send, I'd get 2-3 replies in a matter of minutes. It was like having my own personal Tapestry consultant by my side. It goes to show that Tapestry is a thriving community, with a lot of folks willing to help out. Thanks guys - I really appreciate the help.

Update: You can view the FishEye Changelog to see what the upgrade entailed.

Posted in Java at Mar 31 2006, 05:49:25 PM MST 7 Comments

What about an upgrade to Spring 2.0 (both MVC and business layer)? Is it in your pipeline? (by the way thanks for providing this great tool)

Posted by Chris on April 01, 2006 at 06:35 AM MST #

If there's enough demand from users, we can certainly do it. I'd prefer to wait for a Spring final release, but I'm willing to upgrade to M3 if there's enough demand. You might ask for users' opinions on the mailing list and see what their general thoughts are.

Posted by Matt Raible on April 01, 2006 at 10:14 AM MST #

Matt, I'm glad you spent the time learning Tapestry so that the rest of us don't have to. :) Seriously though-- my question is about how Tapestry uses session storage. Based on your experience, is it possible to develop a reasonably complex Tapestry web app without relying on session storage? The ultimate test: can the user safely bookmark any page on the site? (...and in the future, after logging in again, see all the same stuff on the screen). My impression from other reading is that Tapestry's automatic state management relies heavily on the HttpSession object to do its magic. As you are likely aware, session-based storage does not lend itself well to bookmarking.

Posted by Jeoff Wilks on April 05, 2006 at 02:31 PM MDT #


Regarding Session storage, it is fully configurable. Using the session is the easy way, but you can easily conceive stateless applications using the 'client' storage type rather than 'session' on page/component's property (i.e. store the object id on the client on a hidden field or a query parameter rather than the id in the session).

Good documentation on the tapestry site regarding server state:

On the bookmark management side, the logic here is relying on a specific Tapestry 'Service', called External Service, which allows you to point to a page with a series of (named or ordered) parameters of type: (all this is stateless).

In addition, since Tap4, a 'Friendly URL encoder' brought a very elegant way of customising URLs look, so that the most dynamic page can look as a static page URL. More reading there:

Hope this helps,


PS: I have personnaly gone with Tapestry after using CGI, my own framework, Struts, proprietary BEA, and I can say that it is very elegant. Furthermore, and it is my own personal opinion, I think that HiveMind, an IoC container upon which Tapestry is built, is very powerful and replaced in my application the famous and very good Spring container. A bit of learning curve, well well worth it.

Posted by Hugues on April 05, 2006 at 03:43 PM MDT #

In response to Jeoff: speaking from personal experience, it is certainly possible to create large tapestry web apps without relying on session storage. Tapestry 4 goes even futher down that road by providing a variety of persistence mechanisms (and the ability to easily add your own). Of note is the "client" persistence strategy that will persist properties in the client url and/or forms.

The biggest single tip is to use external pages and external links as much as possible. These links, and pages, are specifically designed to be "bookmarkable". So, if you want any page in your app to be bookmarkable, then you would want all of your pages to implement IExternalPage and to use external links throughout.

Posted by Robert Zeigler on April 05, 2006 at 03:44 PM MDT #

The relevant excerpt from that link you provided regarding client-based state storage is:

"Client properties are stored on the client, in the form of query parameters. All persistent properties for each page are encoded into a single query parameter, named state:PageName. The query parameter value is a MIME encoded byte stream."

That's really not what I had in mind; I'm looking for more of the classic HTTP/REST approach: filesystem-like paths, redirect-after-post on forms, all non-sensitive properties displayed in individual query parameters, etc. It sounds like I would have to use External Service / IExternalPage / external links everywhere. My gut feeling is that this departure from the modus operandi would pit me in a battle with the framework at various times, since it's not the way the framework authors expected it to be used.

However, it's nice to see that Tapestry 4 is now placing more emphasis on Friendly URIs. I will watch it with increasing interest, especially as the framework continues to move toward giving URIs first-class status.

Posted by Jeoff Wilks on April 05, 2006 at 06:09 PM MDT #


I think you are very true in assuming that Tapestry does its little magic in its own way, i.e. you do not have, by default, full control on how things are made easier on the development front.
However, with HiveMind, Engine Services and Service Encoder (a.k.a Friendly URLs), you can accomodate much of your URL formatting needs. For my own project, I have developed my own Engine Services, with their specific encoders (all stateless BTW). The parameters I pass to the service are named and you are not forced to follow the pattern: state:PageName="...". All this is seamlessly configured using HiveMind. And you keep the historical beauty of Tapestry, which is the clean, simple and powerful development through components.

The only thing I have to say is that, despite much effort from Howard and the guys on the Tapestry team, there *is* a learning curve. It is not CGI development, there are predefined rules (and you can override them through configuration) and an original way of doing things, and if you come from a different background with your own habits (like I did), well, you will surely have to lose some of them. But what a reward, at least for me, because I have with Tapestry and HiveMind the basis of all my developments.


Posted by Hugues on April 06, 2006 at 01:25 AM MDT #

Post a Comment:
  • HTML Syntax: Allowed