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
><distributable /> 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 PM Orion
>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/[email protected]/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 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,
>>but also useful to almost everyone. It's only bad bloat if the extra
>>features get in your way, though, when you want to use your subset. I
>>question whether this happens that often. But most of your
>comments are
>>pretty general, so who knows exactly what you were talking about.
>>
>>Are Apache products perfect? No, not by a long shot. Are they
>>as bad as you
>>make them out to be? No, not by a long shot.
>>
>>Regards,
>>Arved Sandstrom
>>
>>-----Original Message-----
>>From: [EMAIL PROTECTED]
>>[mailto:[EMAIL PROTECTED]]On Behalf Of Victor A.
>>Salaman
>>Sent: Wednesday, February 28, 2001 4:20 PM
>>To: Orion-Interest
>>Subject: RE: I switch from X to Orion because:
>>
>>
>>Tomcat does not support EJB... the original author of the
>message meant
>>Tomcat & JBoss... And that integration is pure hell... Of
>>course, you can
>>download the already integrated version, but you'd be getting
>>an old JBoss
>>and an old Tomcat...
>>
>>The main problem with Tomcat and JBoss is also their virtue. Since
>>everything is so modular, it also means that there are a lot
>>of components,
>>some of which have conflicts among eath other.... Among other
>>things, JBoss
>>is not compliant to any spec, as simple things like
>>java:/comp/env namespace
>>are plainly not supported by their jndi impl, cmp (jaws)
>>support is very
>>poor and does not really scale well to more than a couple kids playing
>>"deploy" on 3 machines...
>>
>>JBoss also has many problems deploying j2ee "ear" (Enterprise
>>Archives) ...
>>
>>Although Orion is small, it's self-contained and requires very
>>little work
>>to get everything running.
>>
>><flame-warning>
>>I respect the authors of JBoss as they have done a great job,
>>but you really
>>can't compare... it's a orange vs. apples comparison.
>>
>>As for Tomcat, it gives a bad name to server-java altogether...
>>and as for Apache Server, well, what can I say, a simple
>>"java" appserver
>>such as Orion beats its performance by leaps...
>>
>>Most of the ASF is trying to stay compatible with dead things
>>(jdk 1.1),
>>which makes their software suffer a great deal. For example,
>>they dislike
>>the use of the Collections API, try to solve everyone's problems for
>>everyone, and in the way bloat their products unnecessarily... And
>>repeatedly "break" the rules... (How crazy is it creating
>>threads inside the
>>web container [Cocoon2] when the specs specifically say that
>>it should not
>>be done) ...
>>
>>An example of this is Jakarta-Struts... Sure it's great... but
>>why then did
>>Rickard Oberg (one of the technical leads in JBoss) create
>WebWork? ...
>>Struts is just too damned bloated... same happens with most
>of Apache's
>>offerings. It's rather sad, as most of those problems could easily be
>>solved...
>>
>>Sometimes people on the list say things like "I can't get
>>Cocoon to work
>>under Orion", "I can't get XXX Apache product to work under
>>Orion"... well
>>now you know why :) haha ... Most of these problems are
>>classloader issues
>>which would break anyways, but since Tomcat has an arcane
>>single classloader
>>architecture, they'd never notice...
>></flame-warning>
>>
>>-----Original Message-----
>>From: Christian Sell [mailto:[EMAIL PROTECTED]]
>>Sent: Wednesday, February 28, 2001 3:01 PM
>>To: Orion-Interest
>>Subject: Re: I switch from X to Orion because:
>>
>>
>>> 2. Tomcat does not support EJB, even if it did, getting
>>Tomcat & Apache
>>> working together is sometimes a hair-pulling experience.
>>
>>now what exactly was your problem there? I just installed tomcat under
>>apache on my new Linux box, and had no problems at all - just
>>followed the
>>instructions. And deploying an app is not more than copying
>>the .war into
>>the webapps directory...
>>
>>
>>
>>
>>
>
>
>
>
>
>
