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.

10+ YEARS


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.

Can you base a web framework on another web framework?

It looks like the Struts guys are going to base Struts 2.0 on JSF (detailed proposal, wiki). It should be interesting to see a web framework developed on top of another web framework. Of course, it's been done before. The two things I really like in this proposal are 1) a built-in IoC container and 2) the security stuff (remember me, user registration). Here's the details from the proposal:

3.5 Service Provisioning APIs

Inversion of Control (IoC) containers (the techniques are also referred to as Dependency Injection) are becoming a popular mechanism for assembling the required services and logic of an application. If Struts included such a framework, it would provide a solid basis for building maintainable apps, as well as allowing the framework to configure itself using the same capabilities.

Rather than building such a container ourselves, we should seek to incorporate an existing one that is license-compatible and which can be integrated into the JSF managed beans facilities (so that value binding and method binding expressions can leverage the facilities of this container transparently). From my research so far, I like Spring's capabilities in this area the best, but am open to other suggestions.

3.6 Authentication and Authorization APIs

In order to support reasonably complete solutions for applications that wish to provide their own authentication and authorization services (as well as interact with container managed security), we need APIs available for performing user registration, implementing "remember me" features, and represent the results via a wrapped request (so that apps depending on getRemoteUser(), getUserPrincipal(), and isUserInRole() will still work). Using JDK 1.4 as a base platform would allow us to integrate mechanisms like JAAS. Other alternatives include plugins like SecurityFilter.

I added the emphsis on Spring. I'm all for this because 1) I'm on the JSF Expert Group (as of last week) and 2) it'd be nice to see JSF stretched, poked and prodded. IMO, JSF needs more "real-world" usage and the popularity of Struts will give it that. By "real-world" usage - I mean it needs to be used by developers that aren't cooped up in some cube with a fancy IDE. I also like the proposal because there's tons of Struts apps out there - and many of them might want to "upgrade". This means more (potential) work for me. Of course, I also plan on spending more time with Tapestry so I can offer client's an "educated" suggestion. BTW, the reason I joined the JSF EG is to be the "developer's voice" among the IDE Vendors. So if you'd like your voice to be heard - send me your suggestions, I'm all ears.

The question is - when will Shale be released? Of course, since it's open-source, the answer is "when it's ready". My guess is 1 year from today. I'm thinking of making AppFuse 2.0 use this new stuff. Of course, it'll have Tapestry and JSF options long before that.

If nothing else, the Shale proposal should motivate other web framework developers to highlight their roadmaps and what's new and cool on their horizons.

Posted in Java at Nov 08 2004, 08:59:01 AM MST 10 Comments
Comments:

Good to see they're addressing "monolithic controllers" - section 1.2, as well as better support for transactions that span multiple requests. Its worth noting this as a currently weakness for Struts vis-a-vis say Spring. Spring gives you the "developer-friendly approach [combining] tightly coupled processing actions into a single Java class" -- a la its FormController hierarchy. It also provides built-in support for duplicate submits. :-)

Posted by Keith on November 08, 2004 at 04:32 PM MST #

I hope Shale get released NEVER.

.V
ps: Somone said that your framework extension may not be thread safe since there are properties in action, just fyi.

Posted by Vic on November 08, 2004 at 06:26 PM MST #

Vic - regarding properties in Actions: this is perfectly thread-safe if you're using Spring's ContextLoaderPlugin and have singleton="false" on your action bean definitions. Someone actually entered a bug about this today - maybe it was the same guy?

Posted by Matt Raible on November 08, 2004 at 07:10 PM MST #

I had a short discussion with Craig McC at ApacheCon 2003; at the time he was interested in HiveMind as the container for the next generation Struts (but HiveMind's CLA had not yet been signed by WebCT, so it was not a great option). Anyway, Tapestry 3.1 is being rebuilt today on top of HiveMind with great success.

Posted by Howard Lewis Ship on November 08, 2004 at 07:52 PM MST #

nnooooooooo! firstly, they need to drop actions completely (look at crazy bob's delegate for a better approach) and then change the form loading mechanism so that *any* IoC container can be used. Including another framework within a framework is the second worst design decision CM has made (The first is splitting forms and actions ;)). the biiggest mistake the webwork2 guys made was including xwork. i don't want to maintain 2 IoC frameworks, i'd ratther use the one i prefer (spring in my case).

Some day soon, someone will come up with the perfect marriage of request/response (like struts delegate & webwork1) & event handling (jsf, wicket), until then, we are stuck with a bunch of frameworks that only do small, focussed tasks well. If only I can't straigthen the idea in my head ;)

Posted by analogueboy on November 08, 2004 at 08:26 PM MST #

ASP.NET lite for Struts? Want to have (1) standard server-side state management and (2) View, fully detached from submitted input (apparently it should be done via redirection to result page (aka "success message") using 303 "See Other").

Posted by Michael Jouravlev on November 08, 2004 at 08:56 PM MST #

analogueboy, you're obviously confused. Most of the functionality of WebWork 2.x is implemented in XWork. XWork ALSO has a small IoC container in it, but it's not required by your code and it doesn't preclude you from using Spring/Hivemind/Picocontainer... In fact Spring/WW integration is very popular.

Posted by Jason Carreira on November 10, 2004 at 03:12 AM MST #

I did indeed speak with Howard about using HiveMind -- which is now legally viable because all that stuff has been dealt with. I'm sure HiveMind would work, but I confess to a preference for the fundamental bean lookup API that Spring allows:

<code>MyBean bean = (MyBean) beanFactory.get("foo");</code>

versus what HiveMind requires (and this is typical of most of the other IoC frameworks too):

<code>MyBean bean = (MyBean) registry.getService("foo", MyBean.class);</code>

It's somewhat an aesthetics issue, but why should I have to redundantly specify MyBean.class when I have to cast the result anyway?

Of course, an IoC services architecture isn't the only thing Spring has to offer either.

Posted by Craig McClanahan on November 11, 2004 at 05:55 AM MST #

Matt, I thought you hated JSF?????? http://raibledesigns.com/page/rd/20040806 What changed your mind? cheers, David

Posted by David Hay on December 03, 2004 at 11:10 PM MST #

David - you might want to check out http://raibledesigns.com/page/rd?anchor=i_don_t_hate_jsf.

Posted by Matt Raible on December 04, 2004 at 12:42 AM MST #

Post a Comment:
  • HTML Syntax: Allowed