... and those subtle differences can have dramatic performance and
scalability implications, in addition to the programmatic issues.
Take, for example, the use of Beans.instantiate() in creating the tag
instances. This method actually attempts to locate and read a .ser
file on the filesystem always before attempting to load the class using
Class.forName(). The Beans package was designed to be used with
spec-compliant JavaBeans that store their state to external .ser files.
So, for an application like Java PetStore which has an insane amount
of tag objects in the JSP template (used to render each and every
page), all concurrent users contend for access to .ser files on the
file system. Moreover, the chock point isn't the file itself, but the
synchronized method in the ClassLoader used to load all files as
resources. I think the term anti-scalability applies here.
Other app server vendors have recently seen the error of their ways in
using Beans.instantiate() and converted their implementation to use
Class.forName() for tag instantiation.
The point is that even in an idealized world of WORA, you still need to
assess the performance and scalability implications of switching
vendors. IMHO, the programmatic issues pale in comparison to having to
retest and retune the server environment to revalidate throughput and
response time requirements. Frankly, if the application suffers from a
high coefficient of drag, it won't matter whether your uptime is 24/7
because nobody will want to use it.
Mike
--- Tony Wilson <[EMAIL PROTECTED]> wrote:
> Yes, this is ideal. However, there are subtle differences between
> the app
> servers. They are sometimes caused by bugs, but more often are
> caused by
> ambiguous points within the j2ee specs.
>
> For example, Jrun puts all of it's statically included files within a
> java
> block {}.. Orion does not. Jrun doesn't reuse it's tags, orion
> does by
> default. Jrun assumes that the class for the TagExtraInfo property
> type is
> imported in your jsp, so then just writes the class name out as you
> enter
> it. Orion does a Bean instantiation (similar to Class.forName) on
> the type
> you specify. This means that in orion, unlike Jrun, you must specify
> a
> fully enumerated class name (with packages) for anything not in
> java.lang
>
> There are many more, very subtle differences. These things take time
> to
> figure out and test, especially when you are going for a 24/7 uptime.
> Also,
> it takes time to setup new machines and do production server
> upgrades, etc.
>
>
> So the decision on which app server to use is very important, even
> when you
> design to the spec as much as possible.
>
> Tony Wilson
>
> -----Original Message-----
> From: Ozzie Gurkan [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 15, 2001 8:41 AM
> To: Orion-Interest
> Subject: RE: Any news from Orion yet??: Rebuttle...
>
> Not to sound like a hipocrat but I believe the J2EE standard
> calls for a
> pplication server independence flexibility. You must think
> to yourself what
> makes your application so dependent on the server it is
> deployed onto.
> Besides the custom deployment descriptors (orion-ejb-jar,
> weblogic-ejb-jar,
> jboss, and so on) you should architect your system
> independent of any app
> server dependent features like clustering, fail-over and
> load balancing. If
> you sit down and outline the layers that are dependent on
> the underlying
> mechanism, you will be able to isolate and separate your
> application. Do
> you rememeber that Java is supposed to be independent of its
> OS?
>
> So, coming back to my point: even if Orion does go under,
> you should be
> able to switch out to another server and modify some
> deployment descriptors
> with no problem. I have my application running under
> Weblogic, Orion, and
> Jboss with only the deployment descriptors different.
>
> I hope this helps and triggers some thought.
>
> Thanks,
> Ozzie Gurkan
>
> --- Robert Krueger <[EMAIL PROTECTED]> wrote:
> >
> > >
> > >
> > >Of course, this is a little unfair - weblogic hadn't had
> a new release
> > for
> > >several months, either. They've just had a major release
> recently, which
> > >makes it seem like they're more active than Orion, when
> that's not
> > >necessarily the case. It might be, but that's not implied
> by the
> > situation
> > >at present.
> > >
> > >For the most part, Orion is still very much ahead of the
> pack, and the
> > >speed is stil EXCELLENT. While I'm very much looking
> forward to a new
> >
> > doesn't buy you much if it isn't reliable. that's the sad
> thing. it's
> > true
> > that they are ahead of the pack in a number of fields but
> if you're stuck
> >
> > with a serious bug without the slightest hint when things
> will be fixed
> > it's still a KO criterion (germanism?). at the moment
> we're not switching
> >
> > to an alternative because
> >
> > 1. most of our projects where orion is currently used in
> production
> > wouldn't allow a switch to WLS budgetwise
> > 2. OSS alternatives are still far from the completeness
> orion offers (sad
> >
> > but it's the truth), which especially hurts if you have a
> large number of
> >
> > deployed J2EE applications which we do
> > 3. there is some (not too much) hope left, they have
> learned their lesson
> >
> > and won't underestimate QA requirements in the future once
> they come back
> >
> > and start releasing updates again
> >
> > at the moment we settled for living with a number of
> strange behaviours
> > and
> > awkward workarounds that we simply hope won't break our
> necks the next
> > day
> > (which is not a good feeling to live with). one lesson I
> have learned is
> > that there is a substantial risk involved in choosing a
> brandnew (even
> > standard) technology. I would be more careful next time.
> Now too much
> > work
> > has gone into the current setup to change it to other
> alternatives and
> > other products supporting the same standards are simply
> too expensive.
> >
> > >round of released bug fixes, I'm still waiting for some
> things to shake
> > >out before I abandon ship.
> >
> > but you have to admit that it's getting harder to hold on
> to that?
> >
> > my 2 c
> >
> > robert
> >
> > > >
> > > > -----Original Message-----
> > > > From: Santosh Kumar [mailto:[EMAIL PROTECTED]]
> > > > Sent: Monday, January 15, 2001 12:57 AM
> > > > To: Orion-Interest
> > > > Subject: Re: Any news from Orion yet??
> > > >
> > > >
> > > > Hi kevin,
> > > > As far as i have known WL5.1 or <, there is no
> concept of ear
> >
> > > files,
> > > > does 6.0 include
> > > > that. Doesn't the J2EE mandate (I am not sure!) the
> use of EAR
> > > = WAR + JAR
> > > > + CAR(or JAR)?
> > > > To deploy the JPS1.1.1 on Orion, it is a piece of
> cake, while
> > deploying on
> > > > WLS, i have to
> > > > unpack the EAR files and dis-integrate them which is
> contrary to the
> > > essence
> > > > of packaging the ear files,
> > > > Even meddling with the ugly weblogic.properties
> frustrates one and
> > all. Is
> > > > that true with all WLS users?
> > > >
> > > > Orion is a neat impl of J2EE, is WLS6.0?
> > > >
> > > > Regards,
> > > > Santosh.
> > > > ----- Original Message -----
> > > > From: Kevin Duffey <[EMAIL PROTECTED]>
> > > > To: Orion-Interest <[EMAIL PROTECTED]>
> > > > Sent: Monday, January 15, 2001 12:07 PM
> > > > Subject: RE: Any news from Orion yet??
> > > >
> > > >
> > > > > I am not one to advocate another product, but WL6
> looks nice. It is
> > easy
> > > > to
> > > > > work with compared to WL5.1. Orion is still the
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
