Matt RaibleMatt Raible is a Java Champion and Developer Advocate at Okta. developer.okta.com

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.

JSP 2.0 and Servlets 2.4 Research

I'm going to record a few items from my JSP 2.0 and Servlet 2.4 research tonight. I hope you don't mind.

From JSR 152 (JSP 2.0):

We plan to incorporate two main new features into JSP, and a few incremental features. Additionally we expect to incorporate erratas and clarifications as well as opportunistic improvements.

The two key features are the use of JSP to author custom actions, and adding expression language support into the container. The main goal of this JSR is to deliver these new features into the JSP specification in a timely manner. This goal will likely limit what other features can be incorporated.

So (to me) this means that if you know JSTL, you already know half of JSP 2.0. And the best part of JSP 2.0? One main theme of this update of the JSP specification is that we want to simplify, not complicate, the view of a JSP that most users, specially page authors, have.

From JSR 154 (Servlet 2.4):

Servlet 2.4 will be a relatively small upgrade to the existing API. Since the technology is highly popular, we have a large number of small requests for enhancement to the API that we would like to be able to accommodate. Over and above that, Servlet 2.4 will address the following areas in a portable manner:-

* Modularization of the deployment format

The goal is to achieve a level of modularity with the deployment format which is not currently possible using the current DTD based deployment descriptor. The intent is to enable this modularity to manage the organization of deployment information of related technologies that use the web container as the underlying platform. These frameworks include dependencies on other J2EE components, JSP technology, JavaServer Faces, JAXM, JAX-RPC and other frameworks that build on servlet semantics.

Hmmm, this almost sounds like the module idea in Struts. Does this mean they want to allow sub-applications (or modules) within a web application? After a little research, it appears that the 2.4 spec will allow you to add new namespaces to your web.xml file, and therefore, you can extend the deployment descriptor for your own needs. Look for vendors to use this, as well as UI Frameworks like JSF. The top of your web.xml will resemble the following on 2.4 container:

<web-app xmlns="http://java.sun.com/xml/ns/j2ee"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://
    java.sun.com/xml/ns/j2ee/web-app_2_4.xsd" version="2.4">

Also on the list:

* Enhancements to the security model
     - Provide a facility for logging out of web applications portably
     - Clarify, possibly by adding API or deployment syntax, the relationship between HTTP session state and authentication state

* Smallish enhancements to the filter and listener models
     - Provision of deployment syntax for declaring API dependencies between elements in a filter chain
     - Addition of request and response level listeners and event notifications.

Cool, sounds like good stuff. Logging out of web applications portably? You mean there's more we can do than invalidate the session? I wonder what else there is to logging out? Maybe it'll remember the last page the user was on? No such luck (but you can do that with Cookies). It appears that there's a strong effort to encourage vendors to implement single sign-on for webapps. Tomcat is the only one I know that does this now. HttpSession has a new logout method - if the servlet container implements single signon, the logout logs the client out of all web applications on the servlet container and invalidates all sessions associated with the same client. I guess this is cool if you have more than one webapp on your server. Now we just need an API to allow webapps to talk to each other on the same container. I guess you could call this HTTP, but I want something better than that. Another interesting item I found is that you'll be able to use a servlet as your welcome-file, which is currently not allowed in the 2.3 spec.

So how do these new specs influence how you write your webapps? It doesn't seem like there's much that's new, and certainly no ground-breaking features. So learn Struts, so you'll have a headstart on JSF, and learn JSTL, so you'll know the expression language used in JSP 2.0. If you've been put off by writing tag libraries, it'll be easier with JSP 2.0, as you'll be able to use JSP fragments as a type of tag library. Lastly, if you're not using container-managed authentication (i.e. BASIC, FORM), you might want to consider it. The thing I like most about container-managed authentication is that you can bookmark pages in an app, and then get right back to them by entering a login/password - this is how it should be vs. login -> main menu -> bookmarked page. You can use filters to restore any session or request information that is needed for the bookmarked page.

Pheww, boy am I lucky! I copy-pasted this post before I tried to submit it, and whaddya know, Chimera crashed after I hit the "Post to Weblog" button!

Posted in Java at Nov 29 2002, 07:09:23 PM MST 4 Comments
Comments:

About the logout thing: i've got an app running on WLS 6.1 (just to give some context) and my "logout" invalidates the session: but somehow the user can still access "restricted" pages. The only certain way to clear the login is to close the browser! This is using container-managed security (i've always hand-rolled it in the past). And so I look forward to container-managed-logout. And on "single sign-on" I've gotten intimations from a coworker that WLS 7.1 has gotten this working better (but I think you need a homogeneous deployment - place the same base JARs into each app - yuck).

Posted by Lance on November 30, 2002 at 04:31 AM MST #

I just followed the "logout method" link in your post, and noticed that they didn't have an "Added in #version#" tag. I hate that! Every method should have this information.

Posted by Lance on November 30, 2002 at 04:35 AM MST #

That's wierd that after a session.invalidate(), they can still access restricted pages. Are you sure they're not cached in the user's browser? Do you have the browser set to check for a new page each time? Another possibility is a leftover cookie that it's still reading. You could try doing alert(document.cookie) in a javascript block and see if there's one hanging around.

Posted by Matt Raible on November 30, 2002 at 11:04 AM MST #

Yeah, all of the above are possible (likely?). Still annoying. Clearing the session out to do the trick. I have my browser set to check each time it hits a page, but that is not the default. And I've never looked to see what (if any) cookies get set...

Posted by Lance on November 30, 2002 at 05:09 PM MST #

Post a Comment:
  • HTML Syntax: Allowed