Matt RaibleMatt Raible is a writer with a passion for software. 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.
You searched this site for "xsd". 16 entries found.

You can also try this same search on Google.

Resin slower than Tomcat, fails the AppFuse Test

As part of AppFuse 1.6, I was hoping to supply the option to use Resin instead of Tomcat. In reality, hardly anyone has asked for this on the mailing list - but since so many folks say that "Resin is better" - I figured I'd give it a whirl. I hate to be the guy that spoils all the Resin users mantra, but it seems like Tomcat is the better server. Why? Speed, compliance and shit works. Here are some things I found:

  • Server startup time when AppFuse is only app installed (deleted work directories before starting):
    • Resin: 25 seconds
    • Tomcat: 14 seconds
    I also found that Resin loads my StartupListener twice b/c it's defined in web.xml and XDoclet puts it in the generated TLD. I think the best solution is to add a flag to XDoclet to allow you to exclude listeners from the TLD when it's generated. I commented out the entry in web.xml for this test.
  • Running "ant test-canoo" which runs through all the JSPs using Canoo's WebTest (server already started):
    • Resin: 1st run (no compiled JSPs) - 53 seconds, 2nd run (compiled JSPs) - 24 seconds.
    • Tomcat: 1st run (no compiled JSPs) - 49 seconds, 2nd run (compiled JSPs) - 14 seconds.

I did have to hack a number of things to even run the tests (which verifies titles, success messages, etc.) on Resin. First of all, SiteMesh seems to puke with if you try to use <dispatcher>FORWARD</dispatcher> on the filter-mapping. I had to comment this out, resulting in a lots of HTML Tidy errors during the tests ( Error: <content> is not recognized!). I also had to turn off Resin's fast-jstl to bypass this bug. Finally, I had to revert the displaytag to using the non-EL version (which required changing titleKey -> title and name="${listName}" -> name="listName"). It seems that Resin enables EL even if you're using a 2.3 DTD. With Tomcat, and I believe the spec says this, EL is only enabled if you use a 2.4 XSD.

So there you have it folks, not only is Resin 3.0.9 slower than Tomcat 5.0.28 (JDK 1.4.2, Windows XP), but it's not standards compliant. Of course, the speed could be due to my using the open source version (with performance enhancements turned off) - but I'd think the other (albeit minor) stuff should be easy to fix. Everytime I try to use Resin, I end up finding bugs and going back to Tomcat. I guess this is another one of those days. I don't think I'll include a Resin installer as part of 1.6, but I might distribute one later if I can get these issues solved. I wonder if I should give Orion a run for its money?

P.S. Since I know people are going to ask: Tomcat 5.5.3 with JDK 5.0 took 9 seconds to startup. Running "test-canoo"? First run: 37 seconds, second: 14 seconds. Looks like the new compiler is quite a bit faster.

Posted in Java at Oct 07 2004, 07:13:09 PM MDT 24 Comments

HowTo: Upgrade your app to JSP 2.0

I did some more playing with Tomcat 5.0.4 today - and converted appfuse to a JSP 2.0 application. After accomplishing this task, I created a "jsp-2" task that can (optionally) be run at build time, and whalla, you've got a Servlet 2.4/JSP 2.0 application. I learned a number of things in the process.

1. The expression language in JSP 2.0 replaces in JSTL is <c:out>, that's it. I was under the impression that I could use <c:if> or <c:forEach> tags without declaring the tag library URI, etc. I was wrong, if you want to use JSTL tags, you must import the declare the taglibs, just like you do now in Tomcat 4.x.

2. The EL is turned off by default if you have a 2.3 DTD for your web.xml. If you have a 2.4 XSD in web.xml, the EL is turned on by default. This means that you can write ${param.foo} and it will be analyzed when the EL is on (when off, it's not analyzed).

3. You can replace <html:rewrite page=""/> with <c:url value=""/> and get the same effect. The only difference is that html:rewrite is context and module-sensitive, whereas c:url is only context-sensitive.

4. I had to replace the URI's for JSTL core and fmt with their run-time URIs - http://java.sun.com/jstl/core_rt vs. http://java.sun.com/jstl/core. Otherwise, I would get something similar to the the following error.

According to TLD or attribute directive in tag file, 
  attribute test does not accept any expressions

I figure upgrading to JSTL 1.1 might solve this issue, but since it hasn't been released, why bother? So to convert appfuse to be a JSP 2.0 webapp, here's what my Ant task does:

  • Replaces URIs with their run-time equivalent.
  • Removes <c:out> tags, leaving the value of the "value" attribute intact.
  • Replaces 2.3 DTD in web.xml with 2.4 XSD.

I did some (rough) benchmarking of running my JSP tests, here are the results on a Pentium IV (2 GHz, 512 MB RAM).

start Tomcat, run tests, stop Tomcat:
 Tomcat 4.1.24: 1 minute, 17 seconds
 Tomcat 5.0.4: 1 minute, 7 seconds
 Tomcat 5.0.4/JSP 2.0: 1 minute, 3 seconds

run tests, Tomcat already started:
 Tomcat 4.1.24: 33 seconds
 Tomcat 5.0.4: 22 seconds
 Tomcat 5.0.4/JSP 2.0: 22 seconds

According to these numbers, Tomcat 5 is quite a bit faster than 4.1.x.

Posted in Java at Jul 17 2003, 01:27:01 PM MDT 5 Comments

[Denver JUG] The J2EE 1.4 Web Foundation: Servlets and JSPs

I'm sitting in the Qwest Auditorium right now, in the heart of downtown Denver. It's 7:20 p.m. and Sue Spielman is getting ready to launch her presentation on J2EE 1.4. There is a gentleman who is trying to start a JBoss Special Interest Group - if you live in Denver and are interested - send an e-mail to the DJUG mailing list. I've been here since 5:45 (after driving an hour from DTC) so this better be good. ;-) The Eclipse in Action speaker (David Gallardo) is coming to speak in October. In September, the author of AspectJ is coming in conjunction with Grady Booch. Never heard of him, but judging from the applause - I'm living under a rock.

On with the presentation. Sue thinks that J2EE 1.4 will be released towards the end of this year. Damn, I was hoping for the end of the summer.

What's new in Servlets 2.4?

1. Platform Requirements:

  • HTTP/1.1 - New static constants. HttpServletResponse.SC_FOUND to represent status code 302 instead of HttpSerlvetResponse.SC_MOVED_TEMPORARILY.
  • J2SE 1.3

2. DTD to XML Schemas:

  • Provides easier way to define element structure, element ordering structure is arbitrary under <web-app>
  • New elements in 2.4 XSD: <env-entry>, <resource-ref>, <resource-env-ref>, <jsp-config>

3. Complete event listener lifecycle:

  • New Request Events. Be aware that distributed containers handle listeners a bit different (1 instance per JVM).
    • ServletContext - manage, startup/shutdown, attribute changes
    • HttpSession - creation, invalidation, attribute changes, migration if sessions distributed
    • Request - request coming in or out of scope in a web component, attribute changes
  • javax.servlet.ServletRequestEvent, ServletRequestAttributeEvent
  • new interfaces ServletRequestListener, ServletRequestAttributeListener
  • SessionActivationListener is what you'd use for serializing sessions across a cluster

4. Filter enhancements:

  • Ability to configure filters to be invoked under request dispatcher. What does "under the Request Dispatcher mean?" It means that you can apply filters under RequestDispatcher forward() and include() calls. Defined in web.xml:
  • <dispatcher>REQUEST</dispatcher> and/or FORWARD, INCLUDE, ERROR (REQUEST was the only option in Servlets 2.3)
  • Example: if you have INCLUDE - a request doesn't invoke the filter, a forward doesn't invoke the filter, but an include would.

5. Enhancements for i18n:

  • Two new methods: setCharacterEncoding(String encoding) - do before getWriter() and getContentType().
  • <locale-encoding-mapping-list> - new element in the XSD to provide the deployer with the ability to assign locale-to-charset mappings outside servlet code.
<locale-encoding-mapping>
  <locale>en</locale>
  <encoding>en_US</encoding>
</locale-encoding-mapping>
  • Response encoding for English locales will default to US English (as opposed to the "other" English from Great Britain) ;-)

6. API Improvements added to the ServletRequest to help handle proxy servers: getLocalAddr(), getLocalName(), getLocalPort(), getRemotePort().

7. Other improvements:

  • Distributed sessions must throw an IllegalArgumentException if an object placed in the session can't be serialized
  • Relationship b/w session invalidate/timeout clarified (can now set zero or negative values in <session-timeout>)
  • Deprecation of Single ThreadModel (never used it - did you?)

8. Misc. Clarifications:

  • Welcome files can be servlets
  • Any library files exposed by the container apart from the WEB-INF structure must be loaded by the same classloader w/in any single JVM.
    • Examples include the JARs Tomcat loads from $CATALINA_HOME/shared/lib
    • This should help in avoiding potential ClassCastExceptions

As I expected, there still is now way to get the user's requested URL with container managed authentication. Damn.


JSP 2.0

1. Simplifies tag extension protocol

  • SimpleTag interface: doTag(), Tag attribute methods, NO scriplet code allowed
  • SimpleTagSupport class, implements SimpleTag, adds convenience methods: public JspFragment getJspBody(), public JspTag getParentTag()

2. Relationships: .tag file mechanism allows page authors to use JSP syntax to write custom actions

  • Use directive standard syntax: <%@ tag %> instead of <%@ page %>
  • JSP compiler generates custom action code (look in Tomcat's work directory)
  • Flexible packaging:
    • drop .tag file into WEB-INF/tags
    • implicit tag library generation
    • can still write a TLD if you want, or TLD in a JAR file

3. EL Functions: simple function invocations, defined in tag libraries, but it's a fair amount of work - like writing a TLD file and .java source file.

4. Expression Language:

  • . and [] operations access JavaBean properties and Collection elements
  • ${books.title}, ${books[title]}, ${books["JSTL Practical Guide"]}
  • Automatic type conversion
  • Ability to specify defaults (i.e. in case of null)
  • EL can access Cookies, request params, headers, scope variables and others

5. XML-based JSPs:

  • .jspx and .tagx for pure XML versions
  • no more <jsp:root> just use namespace: xmlns:jsp=http://www.sun.com/JSP/Page
  • For full list of XML features - see section 6.

JSTL (Java Standard Tag Library)

  • Over 42 standard custom actions available for common tasks needed by page authors
  • JSTL will become rev 1.1 in the J2EE 1.4 release

1. Core features:

  • Control flow: for each, conditionals
  • URL management: encoding, ftp, http
  • Formatting and i18n: date, time, numbers, locales
  • XML: transformations and XPath
  • Database support: queries, data sources, transactions
  • 4 custom action libraries: core, xml, i18n formatting, sql.

Man, Sue really knows her stuff. This was a very enjoyable presentation for me and I'm glad I came. Too bad JSPs can't be used as templates like Velocity - that would be sweet! Of course, I like Velocity and it is easy to use - but I've never implemented it from scratch. I do hope to in Moblogger and Struts Menu, but who knows when that will happen.

Update (7/17/2003): Presentation slides from this are now available for download:

  • July 9 - Basic Concepts: Scott Davis Apache Xerces - XML Parse (PowerPoint and samples)
  • July 9 - Main Speaker: Sue Spielman J2EE 1.4 Web Foundation (PowerPoint)

Posted in Java at Jul 09 2003, 11:15:44 PM MDT Add a Comment

Servlet 2.4 Specification

Damn, according to The Server-Side, the new XSD syntax for a web application's deployment descriptor (web.xml) has been removed. Or at least that's how I first read it. That would suck, only because it's one of the things I noted as a difference between 2.3 and 2.4. Where did I note it - in the chapters I wrote for Wrox. Doh - get those chapters back from the printing presses!

Posted in Java at Mar 09 2003, 08:44:10 PM MST Add a Comment

AppFuse and Resume App

I've decided to rename struts-xdoclet to AppFuse! Why? Because 1) it's easier to say, 2) it's a more descriptive name, and 3) it's the fuse to get your app started! I'll be checking it into SourceForge's Struts project soon, and will post more information then.

I've been thinking about my sample app for the Struts Chapter and I'd like to develop something that's useful. I doubt I'll have the time to pull it off, but I'd like to develop a resume builder/viewer app. I think it'd be a great way to demonstrate CRUD with Struts with skills and such. It could even be an application that would support multiple users, where skills can be shared and selected. I've been thinking about doing something like this for a while. It's a pain to update my resume right now because there's 4 different versions - online JSP, downloadable HTML, Word and Text. I've often thought about just creating an XML version and using JSTL to to XSL transformations into HTML, Text, RTF and PDF. I wonder if this XML resume project at SourceForge could help? I'd love to create an app that allows you to easily update your resume and can publish it in all these different formats. Even better, if it could be resume-standards-compliant (i.e. DTD or XSD) and allow users to select/upload/use different styles. I think this would take much of the headache out of online resume publishing. However, I'd probably spend more time tweaking it than I would just updating the 4 different versions of my resume. It'd kinda like this website, I chose to use Roller as my re-design engine because it was quick and easy - and now I spend a couple hours each day tweaking and updating. I could've redesigned for a lot cheaper! Of course, new content == hits.

The only problems I can foresee with this app (so far) are Old Man Time and that it might be a maintenance nightmare. I would suspect a lot of folks might want import/export to/from existing formats. Thoughts? Comments?

Posted in Java at Dec 06 2002, 09:57:52 AM MST 3 Comments

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