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 <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/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,
>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...
>
>
>
>
>
