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: )
iginal 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. > > >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 e
RE: I switch from X to Orion because:
Hi, Mike Any or all of the Apache products are open to criticism, just as any software should be. I guess my reaction to points like yours below would be: (1) severe bloat: by what definition? The core JAR size? The distribution size? The API size? For that matter, if we're talking APIs, the normal developer using Xerces, for example, should be concerned with public APIs like SAX and DOM. Exactly how are these different from anyone else's SAX or DOM interfaces?; (2) old JDKs: not sure I understand this one. Support for old JDKs? Well, like I said before, not every real world developer has access to a 1.2+ JDK. And the mission of Apache is not to support J2EE specifically; (3) Bad spec conformance: on what basis? Not keeping up with the latest specs as fast as you might like? Or declaring that they conform to spec A12.3, and not in fact doing so? There's a difference; (4) Appalling speed: you can always find a stripped down little product that blazes through problem X. I use nanoxml from time to time for specific problems, and it's fast as hell - does that mean that Xerces is then bad because it's slower on the same problem? And a number of Apache products are acknowledged as being the fastest. If I know that you had a hate-on for Tomcat it would help clarify the discussion; blanket statements are exceedingly unhelpful; (5) Some sort of strange developer arrogance: OK, this could use some clarification. But I sure as hell haven't seen it. There have been real problems associated with the donation of code and people to Apache projects by big companies. Those problems doubtless led to perceptions that I have heard here. Many of those perceptions are not entirely wrong. These problems are being addressed. There are a number of ways of productively influencing Apache software. All of them entail becoming involved to some degree. As for the list of stuff you mention, I've used some of them, too, and as you know I'm interested in OpenSymphony. That list is a bit misleading - Apache doesn't have a J2EE server project that I'm aware of, one of the JDOM authors is in fact an ASF member, OpenSymphony doesn't have an Apache counterpart, can't speak for the tags thing, and Saxon...well, hell, I like Saxon better myself, but it's not free of bugs either. :-) Not sure I understand the license reference, though. Regards, Arved Sandstrom -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Mike Cannon-Brookes Sent: Wednesday, February 28, 2001 8:52 PM To: Orion-Interest Subject: RE: I switch from X to Orion because: On another note (am I imagining things?) or isn't JDK2 _REQUIRED_ for J2EE ? (Apache-folk: note the 2 in J2EE) That tells me that Tomcat can never effectively be part of a true J2EE server. Other than that I agree with all that Victor has said. Apache products suffer from - severe bloat, - old JDKs, - bad spec conformance, - appalling speed and - some sort of strange developer arrogance Why does everyone on the Apache project seem to think their products are 'the best' and cannot be beaten?! Sadly, 'tis not even close to true. -mike (who uses Orion, Saxon, Jdom, Epesh.com tags and OpenSymphony - not one released under the ASL and all rock)
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 th
RE: I switch from X to Orion because:
On another note (am I imagining things?) or isn't JDK2 _REQUIRED_ for J2EE ?
(Apache-folk: note the 2 in J2EE)
That tells me that Tomcat can never effectively be part of a true J2EE
server.
Other than that I agree with all that Victor has said.
Apache products suffer from
- severe bloat,
- old JDKs,
- bad spec conformance,
- appalling speed and
- some sort of strange developer arrogance
Why does everyone on the Apache project seem to think their products are
'the best' and cannot be beaten?! Sadly, 'tis not even close to true.
-mike (who uses Orion, Saxon, Jdom, Epesh.com tags and OpenSymphony - not
one released under the ASL and all rock)
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Victor A.
> Salaman
> Sent: Thursday, March 01, 2001 9:49 AM
> To: Orion-Interest
> Subject: RE: I switch from X to Orion because:
>
>
> > -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 y
RE: I switch from X to Orion because:
And let's not forget how J2EE 1.3beta3 is packaged...TomCat 3.2.1!!! > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Victor A. > Salaman > Sent: Wednesday, February 28, 2001 2: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. > > > 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... > > > -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... > >
RE: I switch from X to Orion because:
> -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
p
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. 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... -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 >
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. 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... -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...
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...
RE: I switch from X to Orion because:
Just a comment on Tomcat. I agree that Orion is a great product, and Tomcat has a funky protocol arrangement with Apache, but that will get better. Right now, Tomcat is integrated with Jboss, and there is talk of putting Apache into the equation. Openejb is also stated to be integrated with Apache and Tomcat. Resin is great for integration with Apache and Resin EJB will become part of that equation. If had a wish list, I like to see the potential to integrate Orion with Apache (through Orion software). -Original Message-From: Thomas Pridham [mailto:[EMAIL PROTECTED]]Sent: Wednesday, February 28, 2001 7:41 AMTo: Orion-InterestSubject: RE: I switch from X to Orion because: I switched because: 1. Bluestone's Total-e-Server will cost you over $100,000.00. And that is an iteration based license. After so many app server iterations (oh yeah, they don't tell you what an iteration is...), it's time to buy more iterations (HP now owns this company). 2. Tomcat does not support EJB, even if it did, getting Tomcat & Apache working together is sometimes a hair-pulling experience. 3. All of the horror stories from developers claiming that iPlanet is VERY buggy. 4. Because Websphere / Weblogic is too expensive for some customers. 5. Because Unify is rumored to be on unstable financial ground (even though eWave is only $595/cpu). 6. Because Orion was easy to install, easy to deploy, and easy to maintain. Granted that we DO NOT use entity beans. We only use stateless session beans. EJB is still too immature to be using entity beans, if you don't believe me, look at the majority of the posts on this mailing list. They mostly deal with entity bean problems!! That's my personal opinionplease be gentle with the entity-flame-emails :) Regards, Tom Pridham -Original Message-From: Vaskin Kissoyan [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 27, 2001 2:05 PMTo: Orion-InterestSubject: I switch from X to Orion because: Please fill in the blank as you see fit.
RE: I switch from X to Orion because:
I switched because: 1. Bluestone's Total-e-Server will cost you over $100,000.00. And that is an iteration based license. After so many app server iterations (oh yeah, they don't tell you what an iteration is...), it's time to buy more iterations (HP now owns this company). 2. Tomcat does not support EJB, even if it did, getting Tomcat & Apache working together is sometimes a hair-pulling experience. 3. All of the horror stories from developers claiming that iPlanet is VERY buggy. 4. Because Websphere / Weblogic is too expensive for some customers. 5. Because Unify is rumored to be on unstable financial ground (even though eWave is only $595/cpu). 6. Because Orion was easy to install, easy to deploy, and easy to maintain. Granted that we DO NOT use entity beans. We only use stateless session beans. EJB is still too immature to be using entity beans, if you don't believe me, look at the majority of the posts on this mailing list. They mostly deal with entity bean problems!! That's my personal opinionplease be gentle with the entity-flame-emails :) Regards, Tom Pridham -Original Message-From: Vaskin Kissoyan [mailto:[EMAIL PROTECTED]]Sent: Tuesday, February 27, 2001 2:05 PMTo: Orion-InterestSubject: I switch from X to Orion because: Please fill in the blank as you see fit.
RE: I switch from X to Orion because:
As a Principal Architect, for me time to market, sky rocking performance and ease of development were good enough to investigate and invest 2 of my developers and myself for 3 days. After our research and due dilligence (lack of doc so we learned the hard way !) All the feature we needed are there and they work fine. We were left with Weblogic and Orion on our short list as the only ejb2.0 compliant appserver in the industry. Orion hasn't got the impressive references BEA comes up with in production yet Orion doesn't come up with the assle one has to deal with when facing the sales force of BEA and they famous and unrealistic node locking licenses. Websphere, ATGDynamo, IPlanet and some others were long gone in phase 2 of our testing !!! The results of the above gave us the ultimate winner across all division of my present company - ORION :-)) my CFO was the most shiny and happy looking !!! CTO and VP of R&D gave us the bottoms up to roll development on this server. This left BEA and VITRIA with they sucky BusinessWare product arguing our competences and technical abilities... Dr Denis Eric Despinoy Principal Architect PS: thank u to the list while transitionning to orion... --- Russ White <[EMAIL PROTECTED]> wrote: > X is to slow to implement new J2EE specs while Orion > is moving at a nice > pace. And once you understand the spec, and take a > little familiarization > time Orion simply works like a dream. Granted > documentation is lacking, but > the product is solid and feature rich. > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On > Behalf Of Vaskin Kissoyan > Sent: Tuesday, February 27, 2001 2:05 PM > To: Orion-Interest > Subject: I switch from X to Orion because: > > > Please fill in the blank as you see fit. > > > __ Do You Yahoo!? Get email at your own domain with Yahoo! Mail. http://personal.mail.yahoo.com/
RE: I switch from X to Orion because:
X is to slow to implement new J2EE specs while Orion is moving at a nice pace. And once you understand the spec, and take a little familiarization time Orion simply works like a dream. Granted documentation is lacking, but the product is solid and feature rich. -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Vaskin KissoyanSent: Tuesday, February 27, 2001 2:05 PMTo: Orion-InterestSubject: I switch from X to Orion because: Please fill in the blank as you see fit.
I switch from X to Orion because:
Please fill in the blank as you see fit.
