TheServerSide is pleased to announce that it will be hosting a book review process for the upcoming book on Struts, an O'Reilly book by Chuck Cavaness. Available immediately for review are chapters 3 and 4 of the book-in-progress: "An Overview of the Struts Framework", and "Configuring the Struts Application".

New review chapters and versions will be posted here every 2 weeks or so. Congragulations to Chuck for bringing his book to TheServerSide for review!

Review Chapters from the Jakarta Struts Book Review Project.

The PDF for this book will not appear on TSS. And for those who are wondering, my books PDF (EJB Design Patterns) will be posted in early May.

What about "EJB Design Patterns" ?

Sorry guys for bringing it up here. But the link to this book still says "FREE PDF Available SOON", and its been months since i have been seeing it.

When are we goona see the PDF version of the book, which was promised long time back. Is it becoming that difficult to exract out the PDF version from the publisher.

Wud luv to hear from TSS on this.

Kapil,

  As I mentioned in the last line of the news post, it will be coming in early may. I feel your pain here, I really want it up sooner as well, but this is unfortunately not under my control.

Floyd

Thanks floyd! I can't wait to read it!

Thanks Floyd,

Cant wait to read it too.

Kapil

One thing I've found in my Struts experience is that the xml file becomes a bone of contention. I was wondering it Chuck is planning on talking about this and strategies for dealing with it, as well as build issues.

Also, I noticed that there is now some JUnit suport for struts. We tend to use straigh JUnit for our testing, but It may be worth including as well.

I've also had the same experience. We were constantly asking one another to "please check in the config file". This is also true with the message bundle. With 1.1, multiple configuration files are supported, as well as multiple resource bundles. Unfortuntaly, the multi-app support has some issues, as do the support for multiple resource bundles. I've entered several defect for these issues. I'm not sure however, that the multi-app support in 1.1, will be what everyone wants or needs. I think it will be more of a phased implementation.

My group is kicking off construction on another product at my company where we are using 1.1b. We had a meeting today on the very problem of contention with these files. One of the solutions proposed was to let everyone specify and use their component specific files and then let our build manager put the files together with Ant during a build. I'm not sure how this will work however.

Right now, I plan to cover these issues in Chapter 20 "Packaging your Struts Applications", but it really is more than a packaging issue. I'll add a note to put something about this in Chapter 4 also.

Chuck

I would like to share some of my experiences with Struts:

In the past, the way we worked on large Struts projects was to split up the struts-config.xml into different sections (we divided them up according to different services developed by different groups of developers).

For example:

ecommerce-struts-config.xml
forum-struts-congig.xml
bugs-struts-congig.xml
...

Then, in our struts-config.xml, we had:
<struts-config>
<form-beans>
        &ecommerce-form-beans;
        &forum-form-beans;
</form-beans>
<global-forwards>
        &core-global-forwards;
</global-forwards>
<action-mappings>
        &ecommerce-action-mappings;
        &forum-action-mappings;
</action-mappings>
</struts-config>

This worked really well and we could reuse the different services across different projects. This was before 1.1 came out with the multi-apps support.

Also, another problem with large projects was the maintenance of the JSPs. Since Struts uses reflection to determine which formBeans to use, we found it very difficult to change our code, eg:

<bean:write name="sampleForm" property="someAttribute" />

If we changed "someAttribute" to "anotherAttrubute", we had to do a search and replace in the JSPs. A real pain. What I proposed recently in the mailing list was a Struts Compiler. The compiler will take 2 arguements:
(1) source path
(2) jar file

It will scan the JSPs in the source path and look for form beans and their attributes. Then it peforms the reflection to ensure that it is available in the jar file.

This would be extremely useful if integrated into the Ant build process, as it will ensure that the JSPs are not broken.

Regards
Keith

Keith,

 I like that idea. Let me play around with that idea for the book and at work and see if we can leverage it. Which component does the work of pulling all of that together? Is it the parser's job? Or that just something magical about XML and DTD's?

Chuck

Hi Chuck

The cool thing about that technique is that it's part of the XML specifications. The XML parser will include all the parts referenced.

This could be good news for me. I've have looked for some way to do a sort of include in xml many times. I've stared at the XML spec but this mechanism has never been apparent to me.

I've looked again, but I still do not completely understand what you are doing. I have got the Xerces DOMWriter sample program to parse the following xml:

------------------------------
<?xml version="1.0"?>

<!DOCTYPE struts-config [
  <!ENTITY form-beans SYSTEM "./form-beans.xml">
  <!ENTITY global-forwards SYSTEM "./global-forwards.xml">
]>

<struts-config>
  <form-beans>
    &form-beans;
  </form-beans>
  <global-forwards>
    &global-forwards;
  </global-forwards>
</struts-config>
------------------------------

But to make the DOMWriter.java sample expand the entities I have to add a line 201:

  parser.setFeature( "http://apache.org/xml/features/dom/create-entity-ref-nodes", false);


Tomcat (3.2) as it stands does not seem to allow this. Without my DOCTYPE the parser objects to the entity reference. With my DOCTYPE I get a null pointer exception.

Can someone point me in the right direction here?

Reg

Please! send Code ActionServlet.java

Function InitMapping From Your'Idea

Thank You Verymuch

The inclusion of separate XML files into the config file is a good idea, we've been using that same technique with ANT build files.

What a coincidence. I am using that in my ant build files too. Sometimes it just makes things much more reusable and convenient, doesn't it?

Keith

i hope i can get chapter one and chapter two,what can i
do?
thank you for the authors' hard work!

Chapters 1 and maybe 2 will be posted within the next week, definitely by Friday. I had some changes that I wanted to make that mostly had to do with formatting. I'll get them out asap.

Please keep in mind that I have to put some space between posting each one so that I have some time to merge everyone's feedback into the previous one. I'm also still writing the other chapters, so as you can imagine, it's a time management nightmare :)

Chuck