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".
