RE: Struts (was: I switch from X to Orion because: )
Wouldn't it have been easier to just subclass ResourceBundle or one of its subclasses: public class SerializableResourceBundle implements Serializable or am I missing something obvious? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: 01 March 2001 18:51 To: Orion-Interest Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: Struts (was: I switch from X to Orion because: ) The reason for reimplementing ResourceBundle as MessageResources is that ResourceBundle is not Serializable. Some containers, notable WebLogic 6, have issues with non-serializable objects being stored in things like the application and session context. Its also very important that you only throw Serializable things in there espacially if you plan on using the tag in your web.xml. mark Mark R Mascolino The Procter & Gamble Co. [EMAIL PROTECTED] Internet Mail Message Received from host: "Jeff Schnitzer" <[EMAIL PROTECTED]>To: Orion-Interest Sent by: <[EMAIL PROTECTED]> [EMAIL PROTECTED]cc: (bcc: Mark Mascolino-MR/PGI) Subject: Struts (was: I switch from X to 02/28/01 08:25 PMOrion because: ) Please respond to Orion-Interest This subject is especially timely for me because I just finished evaluating both WebWork and Struts. I decided to go with WebWork. It wasn't so much that I was drawn to WebWork's technological coolness - there are some neat ideas there, but I think most could be adapted into Struts with a little effort. The problem was that when I looked deeply into Struts, I didn't like what I saw. I spent a *lot* of time wavering; on one hand, Struts has a solid user community and good javadocs, on the other hand, WebWork is simpler and easier to teach future members of the team. I kept switching my favor back and forth when I discovered something new I did or didn't like. What finally pushed me over the edge was my experience hunting down the problem preventing Struts from working with Orion out of the box. Here's the story: If you've ever tried loading the Struts 1.0 example app, you are immediately confounded by missing resource errors. There is a lot of complaint in the Orion and Struts archives about this, but the closest anyone has come to nailing it down is this message: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00582.html in which the principal author of Struts, Craig, implies that Orion's classloader has a problem preventing it from working with the standard JDK ResourceBundle. I knew there was something wrong with this because WebWork uses ResourceBundle without issue. So I looked through Struts' source to see how it might be using ResourceBundle differently, and what I discovered is that Struts doesn't use ResourceBundle at all! In fact, Struts has a whole homebrewed framework for handling properties which mirrors the ResourceBundle API but doesn't use any of its classes or interfaces. There are javadoc comments to the effect that the Struts code should be faster than ResourceBundles, but looking at the JDK 1.3 source code, both frameworks seem to be doing pretty much the same thing. For those curious, the actual problem with Orion is that Struts uses ClassLoader.getResourceAsStream() to build the Properties object, and (I checked the decompiled code) the Orion classloader does not implement getResourceAsStream(). Orion's fault, and logged as bug #340. But why re-invent the wheel?!? The JDK provides resource management for us! Even if the Struts code was slightly faster (which I doubt), any performance gain is going to be negligable compared to the amount of time spent processing taglibs, etc. I can't believe that whoever wrote the Struts MessageResources classes ever bothered to run the code through a profiler to find out where the real bottlenecks are. All this extra code and duplicated infrastructure is nothing but an opportunity for more bugs, IMHO. At this point I decided to go with WebWork. It is certainly not without issues as well, but I'm very happy with the results. And I am finding that in a framework this simple, fundamental changes are easy to make. I could elaborate on the differences between WebWork and Struts if anyone is really interested. If you're still writing JSP-centric applications, you *really* should look into an MVC framework. Jeff >-Original Message- >From: Arved Sandst
RE: Struts (was: I switch from X to Orion because: )
Why on earth would you want to store a MessageResources/ResourceBundle in an application or session context? The static method ResourceBundle.getBundle(...) returns a fast hash lookup for the bundle from a table the framework maintains. It has the added bonus that if you pass in the appserver's classloader, properties files are automagically reloaded just like everything else - no need for special administrative Reload actions. All that should be needed is: String blah = ResourceBundle.getBundle(name, locale, classLoader).getString(key); Why does Struts put MessageResources in a servlet context? Jeff >-Original Message- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] >Sent: Thursday, March 01, 2001 9:51 AM >To: Orion-Interest >Cc: [EMAIL PROTECTED]; >[EMAIL PROTECTED] >Subject: Re: Struts (was: I switch from X to Orion because: ) > > > >The reason for reimplementing ResourceBundle as >MessageResources is that >ResourceBundle is not Serializable. Some containers, notable >WebLogic 6, have >issues with non-serializable objects being stored in things >like the application >and session context. Its also very important that you only >throw Serializable >things in there espacially if you plan on using the > tag in >your web.xml. > >mark > >Mark R Mascolino >The Procter & Gamble Co. >[EMAIL PROTECTED] > > > > Internet Mail Message > Received from host: > > > > > > "Jeff Schnitzer" > > <[EMAIL PROTECTED]> >To: Orion-Interest > Sent by: ><[EMAIL PROTECTED]> > [EMAIL PROTECTED]cc: >(bcc: Mark Mascolino-MR/PGI) > Subject: >Struts (was: I switch from X to > 02/28/01 08:25 PMOrion >because: ) > Please respond to Orion-Interest > > > > > > > > > >This subject is especially timely for me because I just finished >evaluating both WebWork and Struts. I decided to go with WebWork. It >wasn't so much that I was drawn to WebWork's technological coolness - >there are some neat ideas there, but I think most could be adapted into >Struts with a little effort. The problem was that when I looked deeply >into Struts, I didn't like what I saw. > >I spent a *lot* of time wavering; on one hand, Struts has a solid user >community and good javadocs, on the other hand, WebWork is simpler and >easier to teach future members of the team. I kept switching my favor >back and forth when I discovered something new I did or didn't like. >What finally pushed me over the edge was my experience hunting down the >problem preventing Struts from working with Orion out of the box. >Here's the story: > >If you've ever tried loading the Struts 1.0 example app, you are >immediately confounded by missing resource errors. There is a lot of >complaint in the Orion and Struts archives about this, but the closest >anyone has come to nailing it down is this message: > >http://www.mail-archive.com/struts-user@jakarta.apache.org/msg0 >0582.html > >in which the principal author of Struts, Craig, implies that Orion's >classloader has a problem preventing it from working with the standard >JDK ResourceBundle. I knew there was something wrong with this because >WebWork uses ResourceBundle without issue. > >So I looked through Struts' source to see how it might be using >ResourceBundle differently, and what I discovered is that >Struts doesn't >use ResourceBundle at all! In fact, Struts has a whole homebrewed >framework for handling properties which mirrors the ResourceBundle API >but doesn't use any of its classes or interfaces. There are javadoc >comments to the effect that the Struts code should be faster than >ResourceBundles, but looking at the JDK 1.3 source code, both >frameworks >seem to be doing pretty much the
Re: Struts (was: I switch from X to Orion because: )
The reason for reimplementing ResourceBundle as MessageResources is that ResourceBundle is not Serializable. Some containers, notable WebLogic 6, have issues with non-serializable objects being stored in things like the application and session context. Its also very important that you only throw Serializable things in there espacially if you plan on using the tag in your web.xml. mark Mark R Mascolino The Procter & Gamble Co. [EMAIL PROTECTED] Internet Mail Message Received from host: "Jeff Schnitzer" <[EMAIL PROTECTED]>To: Orion-Interest Sent by:<[EMAIL PROTECTED]> [EMAIL PROTECTED]cc: (bcc: Mark Mascolino-MR/PGI) Subject: Struts (was: I switch from X to 02/28/01 08:25 PMOrion because: ) Please respond to Orion-Interest This subject is especially timely for me because I just finished evaluating both WebWork and Struts. I decided to go with WebWork. It wasn't so much that I was drawn to WebWork's technological coolness - there are some neat ideas there, but I think most could be adapted into Struts with a little effort. The problem was that when I looked deeply into Struts, I didn't like what I saw. I spent a *lot* of time wavering; on one hand, Struts has a solid user community and good javadocs, on the other hand, WebWork is simpler and easier to teach future members of the team. I kept switching my favor back and forth when I discovered something new I did or didn't like. What finally pushed me over the edge was my experience hunting down the problem preventing Struts from working with Orion out of the box. Here's the story: If you've ever tried loading the Struts 1.0 example app, you are immediately confounded by missing resource errors. There is a lot of complaint in the Orion and Struts archives about this, but the closest anyone has come to nailing it down is this message: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00582.html in which the principal author of Struts, Craig, implies that Orion's classloader has a problem preventing it from working with the standard JDK ResourceBundle. I knew there was something wrong with this because WebWork uses ResourceBundle without issue. So I looked through Struts' source to see how it might be using ResourceBundle differently, and what I discovered is that Struts doesn't use ResourceBundle at all! In fact, Struts has a whole homebrewed framework for handling properties which mirrors the ResourceBundle API but doesn't use any of its classes or interfaces. There are javadoc comments to the effect that the Struts code should be faster than ResourceBundles, but looking at the JDK 1.3 source code, both frameworks seem to be doing pretty much the same thing. For those curious, the actual problem with Orion is that Struts uses ClassLoader.getResourceAsStream() to build the Properties object, and (I checked the decompiled code) the Orion classloader does not implement getResourceAsStream(). Orion's fault, and logged as bug #340. But why re-invent the wheel?!? The JDK provides resource management for us! Even if the Struts code was slightly faster (which I doubt), any performance gain is going to be negligable compared to the amount of time spent processing taglibs, etc. I can't believe that whoever wrote the Struts MessageResources classes ever bothered to run the code through a profiler to find out where the real bottlenecks are. All this extra code and duplicated infrastructure is nothing but an opportunity for more bugs, IMHO. At this point I decided to go with WebWork. It is certainly not without issues as well, but I'm very happy with the results. And I am finding that in a framework this simple, fundamental changes are easy to make. I could elaborate on the differences between WebWork and Struts if anyone is really interested. If you're still writing JSP-centric applications, you *really* should look into an MVC framework. Jeff >-Original Message- >From: Arved Sandstrom [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, February 28, 2001
Struts (was: I switch from X to Orion because: )
This subject is especially timely for me because I just finished evaluating both WebWork and Struts. I decided to go with WebWork. It wasn't so much that I was drawn to WebWork's technological coolness - there are some neat ideas there, but I think most could be adapted into Struts with a little effort. The problem was that when I looked deeply into Struts, I didn't like what I saw. I spent a *lot* of time wavering; on one hand, Struts has a solid user community and good javadocs, on the other hand, WebWork is simpler and easier to teach future members of the team. I kept switching my favor back and forth when I discovered something new I did or didn't like. What finally pushed me over the edge was my experience hunting down the problem preventing Struts from working with Orion out of the box. Here's the story: If you've ever tried loading the Struts 1.0 example app, you are immediately confounded by missing resource errors. There is a lot of complaint in the Orion and Struts archives about this, but the closest anyone has come to nailing it down is this message: http://www.mail-archive.com/struts-user@jakarta.apache.org/msg00582.html in which the principal author of Struts, Craig, implies that Orion's classloader has a problem preventing it from working with the standard JDK ResourceBundle. I knew there was something wrong with this because WebWork uses ResourceBundle without issue. So I looked through Struts' source to see how it might be using ResourceBundle differently, and what I discovered is that Struts doesn't use ResourceBundle at all! In fact, Struts has a whole homebrewed framework for handling properties which mirrors the ResourceBundle API but doesn't use any of its classes or interfaces. There are javadoc comments to the effect that the Struts code should be faster than ResourceBundles, but looking at the JDK 1.3 source code, both frameworks seem to be doing pretty much the same thing. For those curious, the actual problem with Orion is that Struts uses ClassLoader.getResourceAsStream() to build the Properties object, and (I checked the decompiled code) the Orion classloader does not implement getResourceAsStream(). Orion's fault, and logged as bug #340. But why re-invent the wheel?!? The JDK provides resource management for us! Even if the Struts code was slightly faster (which I doubt), any performance gain is going to be negligable compared to the amount of time spent processing taglibs, etc. I can't believe that whoever wrote the Struts MessageResources classes ever bothered to run the code through a profiler to find out where the real bottlenecks are. All this extra code and duplicated infrastructure is nothing but an opportunity for more bugs, IMHO. At this point I decided to go with WebWork. It is certainly not without issues as well, but I'm very happy with the results. And I am finding that in a framework this simple, fundamental changes are easy to make. I could elaborate on the differences between WebWork and Struts if anyone is really interested. If you're still writing JSP-centric applications, you *really* should look into an MVC framework. Jeff >-Original Message- >From: Arved Sandstrom [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, February 28, 2001 1:42 PM >To: Orion-Interest >Subject: RE: I switch from X to Orion because: > > >Just a few comments...not angry comments. :-) > >As a committer on an Apache project, let me just say that decisions to >support JDK 1.1, on a per-project basis, are not about supporting "dead >things". We have, in fact, people who _must_ use JDK 1.1 >(probably more than >you might think). As another example, we are a J2EE shop; but >just recently >we had a (big) requirement to support ISAM data. That's >ancient, too, but >I'll bet there's more ISAM data out there than there is >relational data. >Would you personally turn up your nose at supporting ISAM? >Well, maybe you >would. I dunno. > >I haven't used Struts myself, but since you mention it, I'd >guess you'd have >to ask Rickard himself why he decided to write his own >framework. With all >due respect to him, the primary reason, 9 times out of 10, >that people write >their own code is because as an industry we are damned >terrible at re-use. >There are a whole bunch of bad reasons why this is so - >laziness, arrogance, >reluctance to share the limelight, etc etc. Only rarely do you >find that >somebody wrote code because they conducted a thorough search >and couldn't >find anything that could even be modified. I'm personally >pretty hot about >this topic because there is a huge amount of wasted time due to this. >Frameworks are a particularly bad offender - everybody and his >brother wants >to write their own framework. > >As far as bloat, well, that's in the eye of the beholder. If a product >provides 100 features, but any given user only needs 25 of >them, but nearly >all of the features are useful to someone, it's "bloat" to >almost everyone, >b
