William,
I did not intend this thread to escalate to a vendor-vs-vendor war. I am
not a minion of Weblogic, nor do I hold special interest in their welfare.
In fact, I was not present at the inception of my company when the app
server decision was made. Hence if my pattern or my messages tend to be
Weblogic-biased, it is only because it's the server I'm currently developing
under and am familiar with.
I also did not intend this thread to escalate to a vendor-vs-developer war.
And I'm sure that's not your intent as well. However, from the time I
started lurking on this list server (less than 2 months ago), I've seen
mostly antagonistic responses from you with regards to those who post any
topic that is basically Weblogic (non-Inprise) related. Is this any way to
win our allegiance? Give good factual reasons why Inprise is better than
anyone else and treat your potential customers with respect, and we will
download, evaluate and even purchase your product!
What did come out of this thread that I see as positive is that it stirred
some nice academic debates and exposed the strengths and weaknesses of
vendor-specific container implementations as well as my pattern. Lets keep
the focus on this: Developmental synergy!
Gene
----- Original Message -----
From: "William Louth" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, September 12, 2000 8:30 PM
Subject: Re: FatKey Pattern...
> Gene,
>
> Sorry but I must take offence with the following:
>
> "...Inprise seems to take the "Keep All of the advanced technical issues
on
> the container side" stance, which caters greatly to those new to EJB or
Java
> development. However as you can see by the responses from the denizens of
> this board, WE WANT TO BE INVOLVED!"
>
> The reason for most people responding in such a 'favourable way' to you is
> that they currently do not have any real options. Their containers cmp
> engine SUCKS, thus they need to use BMP and suffer the PERFORMANCE HIT.
Your
> solution is just TEMPORAL and does not solve the REAL ISSUE. It only
> provides RELIEF for current CHRONIC SUFFERS but no everlasting CURE. Of
> course when you are sick any relief is greatly appreciated. BUT do you
think
> these people would WILLING go through a prescribed course of medication
and
> treatment that only relieves the pain and involves so much change to their
> life. Sorry I DISAGREE. A lot of people want to be in control when a
> sickness takes over their life (only human nature) but given half the
chance
> they would LOVE to go back to the simple way of life (is this not so
noble)
> and know less of the sickness; its symptoms and the rest. Your
prescription
> though effective under certain conditions with its known side affects only
> prolongs the evitable and may infact result in other further damage to the
> rest of the body.
>
> You failed to see the point!!!! You are not meant to be programming the
> infrastructure but rather building the business components. I think we are
> giving developers a lot of respect by not selling them products that fail
to
> live up to real world expectations (loads, failover safety sfsb, slsb, eb
> ....). We are giving them tools that take the drudgery out of ejb
> programming and that allow them to work efficiently. The tools and
features
> added to a WORLD CLASS APPLICATION SERVER LIKE IAS came from the developer
> community; be it the Inprise/Borland community. Each feature was
requested;
> we have been listening a very long time.
>
> Unlike some vendors who still have to open their mouths regarding many
> issues including the ridiculous level of posts relating to getting their
> silly little appserver up and running never mind the rest. We have not
> insulted the intelligence of developers by claiming EJB 99 compliancy and
> openly encouraging non-portable bean development. In fact we have taken
> features out of IAS at the request of the many developers involved in the
> beta stages early last year because of potential threat of the production
of
> non-compliance bean development. We have worked hard to provide a cmp
engine
> which will greatly assist developers in their CHALLANGE to deploy a system
> based on ejb technology that scales and peforms. We have provided this as
> default and not forced developers to run off and purchase and learn some
> other o/r mapping tool. In building a sophisticated cmp engine we have
> allowed developers to concentrate on adding value, sorry to use the
phrase,
> and in 'INTERNET TIME'. If developers want to know 'all of the advanced
> technical issues on the container side' then why don't you, instead of
using
> J2EE use CORBA and start from scratch and build your own server. We are
> there (CORBALAND WELCOMES YOU AS DOES INPRISE) too and with even a bigger
> market share and its growing more and more. I do not recall ever seeing on
> the Visibroker newsgroup that we appeared to be keeping all those juicy
> pieces of server side programming to ourselves. What I saw was requests to
> make life easier in the CORBA world both for new entries and existing
> developers. The ejb specification promises much to the developer and we
> deliver on that promise. If you visit our newsgroup you will see people
> growing in confidence with the techology and maturing their skills. They
are
> learning and understanding whats important to them and their chance of
> success while ingoring the little details which are irrelevant and an
> artifact of old times and old ways.
>
> In some ways I welcome your solution but in other ways its just a pain
> killer which relieves and MASKS the pain but does not treat the sickness.
In
> fact it leads to procrastination in the enforcement of the treatment and
> provides a false illusion of wellbeing. Your kindness in fact is cruel and
> short sighted. If people really want to be INVOLVED and not just in
control
> (is this not want you gave up in some way with ejb) then why not spend
your
> energies in improving the ejb specification in relation to entity and
> persistence. A while back I asked people to help with evaluating the
> finder/persistence mechanisms used by all servers and come up with
something
> much more powerful then we currently have and will have next year. Did
> anybody respond? NO. Why because either their server had nothing to offer
> and they wanted others to solve this for them. What would have been nice
was
> they were off building a business components and turning in succesful
> project on time and within budget.
>
> Regarding the market share we are not losing but gaining. We have more
> successful programmers (superset) than advanced programmers (subset). I
view
> this very postively. By the way Inprise/Borland is well known for
attracting
> 'advanced' programmers both as users of our tools and r&d team members.
This
> is something Inprise/Borland has never lost.
>
> Now gene lets play your game:
> ==============================
>
> "Matt,
> <vendor>
> This is a very reasonable suggestion, and I have put a feature request
> in for this. Thanks.
> </vendor>"
> Jonathan Weedon
>
> "Hi Jonathan,
> You make many great points, and I really like the feedback; as I have
> previously said in another post, "
> Gene Chuang
>
> "I think in the end, Gene's approach is interesting, and although it is
> arguably
> (and perhaps provably) not portable, it would appear to be of considerable
> practical use. Once EJB servers have matured to the point that most of
them
> have powerful caching options (at least for CMP), it would be less
> interesting."
> Evan Ireland
> (extracts: 'not portable' and 'less interesting')
>
> "Telling whether or not a developer has altered hashcode()/equals()
strikes
> me as fairly time consuming. Telling whether they've done it "correctly"
> strikes me as impossible. "
> Matt Kleiderman
>
> "I was interested by your post jonathan. I am not a big believer in
> patterns
> and so the fact that the FatKey "spec validity" isn't a big issue in my
mind
> ;-) (this option works for Gene...).....Your serialization trick
> gives us a smart and robust solution to the problem."
> Marc Fleury
> (extracts: "works for gene.")
>
> regards
>
> William Louth
> Inprise
> www.inprise.com/appserver
>
> PS: some of the comments you used related NOT TO YOUR FAT SOLUTION but our
> hashing mechanism.
>
>
===========================================================================
> To unsubscribe, send email to [EMAIL PROTECTED] and include in the
body
> of the message "signoff EJB-INTEREST". For general help, send email to
> [EMAIL PROTECTED] and include in the body of the message "help".
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
