Jonathan Lehr

author
+ Follow
since Oct 07, 2003
Cows and Likes
Cows
Total received
0
In last 30 days
0
Total given
0
Likes
Total received
0
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Jonathan Lehr

Thanks Dirk and Jason, I really enjoyed it. I'll try to keep up with the forum and hopefully chime in now and again.

Congratulations to the winners. I hope you enjoy the book!

Jonathan
15 years ago
Hi Alvin,

Here are a couple of posts from earlier this week that address this:

https://coderanch.com/t/50853/Struts/Jonathan-Lehr

https://coderanch.com/t/50854/Struts/Struts-Vs-Other-Frameworks

Jonathan
15 years ago
Hi Alvin,

The prerequisites for reading Struts Live are a solid background in Java and a basic grasp of Servlets and JSP.

Jonathan
15 years ago
Hi Alvin,

There are actually two parts to the current version of Struts Live. Chapters 1-9 were written by Rick Hightower, and provide an introduction to Struts 1.1. Chapters 10 and 11 (11 will be available in a couple of weeks), proceed to some advanced issues, presenting unique solutions to some of the more challenging problems facing Struts developers. These solutions have been incorporated in an open source framework named for the book (http://strutslive.dev.java.net).

There are a few small API changes between 1.1 and 1.2, principally deprecating ActionError in favor of ActionMessage, and one or two changes related to Tiles. There are also a few significant bug fixes in 1.2.

Jonathan
[ April 09, 2005: Message edited by: Jonathan Lehr ]
15 years ago
Hi Mark,

Glad to hear that you're a fan of e-books! Like the old saw about the cobbler's son having no shoes, it is a bit ironic that the IT publishing industry has moved so slowly on this front. Having worked with one of the larger publishing houses (Wiley), I know from experience that their business processes and institutional knowledge are based on many decades of working successfully with the traditional hard-copy publishing model. There's bound to be a good deal of inertia in a system of that magnitude and duration, and I would guess that given the profitability of their current model, larger publishers won't be likely to make significant changes until they are pushed to do so by market forces.

Manning is a much younger, more nimble player, and like all new entrants they are under extreme pressure to gain market share, so it's not surprising that their support for e-books is stronger than most. O'Reilly is also a relatively young and innovative company whose roots do not lie in traditional publishing, and their Safari offering is only the most recent evidence of this.

The reason my fellow authors and I are so excited about the SourceBeat model is that it moves the process of publishing books on open source software closer to the model of software development that generally works best: iterative development, with frequent releases to production. Given the rapid pace of change in open source projects, it seems almost self-defeating to publish in hard-copy. Many of us have experienced the frustration of writing a book that wound up out of date before it reached the shelves because the had already changed during the ordinarily lengthy production cycle.

And as in iterative software development, a SourceBeat book can be updated throughout its lifecycle to stay in sync with their rapidly evolving subjects. As well, authors have a free hand to add new material, correct errors, and otherwise enhance the existing material. Perhaps the most unique and rewarding aspect of the SourceBeat model for its authors though, is the degree to which we get to interact with our readers. It's great to be able to get feedback on my blog, through email, or in person at conferences and then be able to incorporate that feedback in an update the next month.

As to reading books on a computer screen vs. in hard-copy, SourceBeat now offers the best of both worlds through its print-on-demand capability. To my mind this should be truly compelling for folks who prefer to do most of their reading on paper copy. You can order a SourceBeat book from Amazon, or Barnes & Noble, etc., but still have access to updated and new material, corrections, etc., which of course you can either print out or read on-screen. So this is bonus material you would never get with the traditional publishing model. I think it's a true win for readers and authors alike. (But then again, of course I would think that -- that's why I write for SourceBeat!)

Jonathan
[ April 09, 2005: Message edited by: Jonathan Lehr ]
15 years ago
Hi Mark,

I kind of wore myself out responding to your other great post (<a href="https://coderanch.com/t/50871/Struts/Struts-Live-Framework-frustrations"/> , and it's getting pretty late, so if you don't mind I'm going to call it a day, and wait until tomorrow so that I can reply more fully to this one. :-)

Jonathan
15 years ago
Hi Mark,

Thanks for the great questions!


What is your personal biggest frustration about the Struts Framework?


Hm, that's a tough question because there are so many it's hard to pick one. If you don't mind, maybe I'll give two or three of the things I've found most frustrating.

First, I'd have to agree with you that naming has been a sore point, particularly when it's coupled with the large number of moving parts, often connected in tenuous and obscure ways.

I have always felt that one of the chief flaws in the architecture of Struts was the decision to focus on modeling HTML forms (ActionForm) rather than web pages. If you take a look at WebObjects and Tapestry, I think they get this more or less right. They model web pages as hierarchies of nested components that represent portions of a page, with the outermost component representing the page itself. As in any good O-O model, state is encapsulated within a set of behaviors defined for each given component, allowing for an extraordinary level of reuse, and simplifying design for complex pages.

I guess if I had to pick one thing though, it's the way Struts decouples rendering logic from everything else. When you think about it, the Struts tag libraries are optional (i.e., you can use JSTL, Velocity, as well as other rendering technologies), so in this sense, rendering behavior, and for the most part entire the View layer of MVC, is outside the scope the Struts framework. Of course, Struts also doesn't provide any components to deal with the Model, so all we're left with is a thin Controller layer that doesn't coordinate inbound and outbound binding behavior.

I think that's unfortunate. Let me give you a very simple example. Nearly every web application has forms that contain a number of required fields. It's a complete no-brainer that you need rendering behavior to indicate to the user that a given field is required (for example, by placing a red asterisk next to the field label). Naturally these same fields need to be validated as required fields on submission. It stands to reason that if I designate a field as 'required' from a validation standpoint, it needs to be rendered as one. But since the rendering model is entirely outside the framework, there's no simple way to make this connection.

Similarly, if fields that represent currency values, percentages, dates, etc., need their validation logic to be consistent with the way they're rendered. In Struts Live, I advocate using Formatter classes and customizations to ActionForm and RequestProcessor to support this kind of integration, and to avoid another major pitfall -- the broken Converter architecture in BeanUtils/binding mechanism in Struts.

Anyway, I could probably go on for the rest of the night along these lines, so before I bore you to distraction, let me move on to your second question:


What do you consider to be the biggest hurdle newcomers face when learning Struts?


Oof! These are juicy questions, Mark! I suspect the biggest hurdle is the disconnected nature of things in Struts multiplied by the number of moving parts plus a lack of decent error reporting. For example, I responded to two lengthy threads yesterday that dealt with mysterious errors caused by a form bean unexpectedly being null in the session or request. In both cases, the problem was that the developer was navigating directly to the JSP rather than going through an action mapping. For experienced Struts developers this kind of problem is usually pretty easy to diagnose, but it often leads to days of frustration and hand-wringing for newbies.

Unfortunately, because Struts lacks a decent component model, even when developers get past these initial hurdles, Struts lacks sophisticated components to help with common tasks such as managing paginated list views, so new developers are often faced with rolling their own before they've had time to get a clear picture of the framework. The results are usually pretty messy.

I'm currently working on some framework extensions (http://strutslive.dev.java.net) in hopes of addressing some of these issues. It currently includes binding enhancements that provide an integrated, and fairly automated approach to formatting, conversion, and validation. Among other things, I've also got a version of a generic list management component checked into a branch, and I hope to have an alpha release out sometime this month for people to play with.

Regards,

Jonathan
15 years ago
Hi Sonal,

The NoClassDefFoundError in the stack trace indicates that Tomcat was unable to find a class from commons-logging.jar. You would ordinarily expect to find this, along with several other required jars (e.g., struts.jar, commons-beanutils.jar, commons-digester.jar, etc.), in your project's WEB-INF/lib directory.

The easiest way to debug these types of issues is to start by looking at what's actually getting deployed, and work backwards from there. I actually posted some instructions on how to do this yesterday. Here's the link:

https://coderanch.com/t/50817/Struts/Struts-Error-servlet-action-as

Jonathan
15 years ago
Hi Melody,

Thanks for the great post! You've made some excellent observations.

For better or for worse, at the moment, Struts is the dominant web app framework for corporate J2EE projects. I agree with you that it can be quite frustrating to deal with its idiosyncracies, and that it can be quite difficult to extend, depending on what you're trying to do. (Sorry to disagree with Jeanne there.)

However, in spite of many drawbacks, there is a great deal of value in things like the RequestProcessor, as well as in the integration with commons-beanutils, which is almost certainly something you wouldn't want to write yourself. There's also a lot of value in the tremendous amount of testing that the Struts codebase has been through, as thousands of developers have been pounding on the code for several years now.

Another advantage that Struts has over custom frameworks is the availability of documentation and training. It can be costly to provide sufficient documentation and knowledge transfer for a proprietary framework that necessarily has a limited audience. Also, I've noticed that developers are often resistant to working on projects based on custom frameworks because they don't want to put effort into gaining knowledge that they won't be able to leverage on other projects. Plus, many developers want to be able to add things to their resume that they feel will be valuable from a career standpoint.

On the flip side, most managers want to use technologies that are well known, because it's easier for them to find developers that have relevant experience, and to get training for staff members when needed. They also feel more comfortable knowing that there are established guidelines and best practices.

What I've found to be a reasonable compromise has been creating a custom framework that sits on top of Struts, so that I can try to make things easier for developers while still taking advantage of the benefits that Struts has to offer. You might want to take a look at the open source project I've been working on (http://strutslive.dev.java.net) to see if this approach might be workable for you.
15 years ago
Hi Alvin,

The thing to remember is that Struts and JSP are two separate technologies, so adding struts.jar to your project doesn't change the way that JSP works, so there's no reason that <jsp:useBean> tags wouldn't work the same way they did before. So yes, you can use a call to setAttribute() to place a bean in the request, and then put in into page scope with a <jsp:useBean> tag.

In general though, Struts provides the ActionForm class, the <form-bean> element in struts-config.xml, and the <html:form> tag so that the framework can manage this for you. In fact, I usually recommend that developers avoid writing Action code that places objects directly in the request or the session, and instead consider whether the values could be made properties of an ActionForm.

Jonathan
15 years ago
Hi Anselm,

Thanks for your question. I may have covered some of this ground in my response to another of your posts (<a href="https://coderanch.com/t/50854/Struts/Struts-Vs-Other-Frameworks"/> , so I'll try to avoid repeating too much.

Struts has a tremendous lead in mindshare and network effects over the other frameworks, so technology decisions on many projects will likely continue to be influenced by these factors. (In other words, the likelihood that management may require a team to use Struts on their next project is still high.) However, I think JSF spec compliant frameworks will make strong inroads by virtue of being rolled into J2EE, and because of the strong tooling support from multiple vendors. There are also quite a few books, training course, etc. available on the topic.

If I had to guess, I think its likely that the other frameworks will also erode Struts's market share, though to a much smaller degree. Tapestry has been adopted as a Jakarta project, so that (along with its other advantages) may help it gain a bit more market penetration. (I certainly hope that's the case, as I think Tapestry is a breath of fresh air for the Java community.) I think Spring offers a compelling case as an integrated stack, and WebWork is very clean, so they should continue to do well, though again, I think JSF and Struts will dominate.

Interestingly, Struts is not standing still. Work on Struts 1.3 is pretty far along, and the major features (breaking RequestProcessor callbacks up into individual classes glued together by Commons Chain, adding support for an ActionContext, etc.) should be very welcome. Meantime, Struts 2.0 (Shale) appears to be incorporating significant chunks of the JSF spec, so it promises to be much more than an update, and in fact will probably feel more like an entirely new web app framework. If they do a good job integrating workflow features, Shale is likely to attract a lot of attention.

Jonathan
15 years ago
Hi Anselm,

I think that Jason hit the nail on the head with respect to the two main advantages Struts has: mind share, and what's often referred to as 'network effects,' or a 'value chain,' meaning the implicit value of all the books, articles, blogs, training courses, add-ons, and plugins, etc., as well as a large base of developers who have at least some Struts experience.

From a technological standpoint, I basically view the web app framework world as divided into roughly three camps:
  • Struts and its direct descendants, such as WebWork and the relevant portions of Spring;
  • JSF implementations, such as MyFaces.
  • WebObjects and its sole descendant, Tapestry;

  • Admittedly I don't have much direct experience with WebWork and the web app framework stuff in Spring, but they appear to me to be modernized versions of Struts that smooth some of its rough edges, and thereby simplify development. What they share in common is a simple architecture that primarily provides a front controller, a navigation mechanism, and a binding mechanism (Struts lags here in that its Converter architecture never really fulfilled its promise).
    So there's not a lot of meat to their architectures.

    JSF has some similarities, but it also defines a sophisticated component model that the others lack. The downside of JSF is that, arguably, it is overengineered. There's a lot of complexity under the covers, though that does buy you increased extensibility. The question is though, how many developers are really going to need/take advantage of that flexibility? That being said, if I had to pick from all the above, I'd lean towards JSF, though I'd take a closer look at Spring before deciding.

    Finally, there's WebObjects and Tapestry. WebObjects usually doesn't enter into the discussion because it's not open source, but from my experience it increased developer productivity by a factor of 3 or more (in no small measure because it includes a superb O/R mapping framework, and a sophisticated controller layer in between). Tapestry's architect, Howard Ship, was formerly a WebObjects developer, and that model of development is strongly reflected in the design of his framework.

    One of the huge advantages of WebObjects/Tapestry over other web app frameworks is that it models web pages and components of web pages rather than being form-oriented. Another huge advantage is the approach to templating, which relies solely on a simple HTML tag (<WEBOBJECTS name="foo"/>) in WebObjects, or even better, custom HTML attributes in Tapestry, so that there's no scripting code or funky tags in HTML templates.

    The downside of Tapestry is that it is reportedly quite large and complex (but then again, it has a lot of features that the other frameworks don't). Also, most Java developers are familiar with the simpler, JSP-oriented approach of the other frameworks, and for some folks apparently have difficulty adapting to a new way of thinking about the problem space.

    If I had to choose from among all the available open source frameworks, all things being equal I would probably pick Tapestry, because it offers a more sophisticated model of web development that over time would make a development team far more productive than they would be using the other open source frameworks. Though I haven't used Tapestry, I'm familiar enough with that model from my years doing WebObjects development to be convinced of the fundamental benefits of that approach.

    Jonathan

    [ April 06, 2005: Message edited by: Jonathan Lehr ]
    [ April 06, 2005: Message edited by: Jonathan Lehr ]
    15 years ago
    Hi Rizwan,

    You haven't given us very much to go on. Are you deploying the application as a WAR, an EAR, or as an exploded directory? When you say that all the jars are in the lib directory, where are you looking, the source tree, the build directory, or Tomcat's webapps directory?

    Usually the best way to begin diagnosing this type of problem is to look first at what's actually being deployed -- in other words start by looking in the webapps directory in your Tomcat installation. If you're deploying as an EAR, copy it to a temp directory and unpack it to get the WAR file. (If you're deploying as a WAR, this step is obviously unnecessary.) In any case, you then can list the WAR's contents by using the 'jar' command. For example, to list out the contents of struts-blank.war on my machine, I'd do the following:

    This gives you a relatively easy way to determine whether the project is getting deployed correctly, and allows you to be certain about the locations of various application resources at deployment time. Please let me know if this is any help. If you're still having problems, you can paste a copy of the WAR file listing (usually referred to as the manifest) here, which might make it easier to figure out what's going on.

    Jonathan
    15 years ago
    Hi Wendy,

    It's hard to be sure what the problem is without seeing the code for your LoginAction class, but you might want to check to make sure that it extends org.apache.struts.Action or one of its subclasses.

    Jonathan
    15 years ago
    Hi Lee,

    Please see my answer to the following post:

    https://coderanch.com/t/50830/Struts/Cannot-find-bean-lookupForm-any

    I'm pretty sure you've run into precisely the same problem.

    Jonathan
    15 years ago