> -----Original Message-----
> From: Arved Sandstrom [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, February 28, 2001 5: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 also use ISAM data, talk to mainframes (MVS, OS/390, VSE) and minis ....
but we are not talking about that. We are talking about Apache neglecting
important features in newer versions of the jdk which would work with all
versions of the jdk. for example, instead of producing code with 200
occurences of:
Class clazz=Class.forName("blabla");
these could be replaced with:
Class clazz=ClassUtils.findClass("blabla");
where you could have a "central" ClassUtils with a static method called
findClass which would find the class in the correct classloader
(contextclassloader or primordial, etc)... The only drawback to this
approach is that although the resulting code would work with any jdk, it
would need jdk1.2+ to compile, but of course there are workarounds around
this... So just becuase there are few jdk1.1 users out there, Apache
releases code which will not work in advanced containers and require severe
patching. (e.g. ever tried to use Xalan, BSF or Xerces together in JBoss,
Resin, Orion?) ....
> 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.
>
quoting from Webwork documentation...
"Q: What is the difference between WebWork and Struts?
A: Struts is probably the technique that was the most similar to WebWork.
The main problem with Struts is its large API. There is quite a bit of API
to learn, and it is closely tied to Servlet API. The Struts API also imposes
quite a few implementation rules with regard to how things are done, leaving
less room for customization.
"
(Large API == Bloated?) since both do the same things in concept.
This industry is very pro-reuse, it's only when projects become surreal,
when people start building something else. Let's get real, would you spent
your time building something when there is another product which is
accesible and fits your needs entirely... ? thought not...
The problem here is that you can't serve god and devil at the same time.
> 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.
>
Usually I don't mind about extra features, but take Xerces for example...
it's a 800k jar file compressed, provides for just about every xml parsing
scheme that currently exists, has a built-in serialization API, XML DOM,
HTML DOM, you name it, it's there.... It is also the most popular xml parser
for java right now... what's the problem? it's also the worst performant out
of the xml parsers for java... So strictly my opinion, why not spend
precious time trying to improve the things which are really important (speed
and basic conformance) instead of trying to build a do-it-all-for-everyone
parser. Then people say, "Why is java slow?" .... Is Apache becoming the
Microsoft of the open source arena?
> 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.
>
Perfection cannot be attained, it can be aspired... The problem is that you
can't aspire perfection without criticism. And Apache hates criticism.
> 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...
>
>
>
>
