For me I would say not to add a bug to get market share. A bug is a bug
and should be fixed. It is better to create a simple working example
that follows the rules. People like me who try to create applications
with only a limited knowledge depend on examples and help like Neale
says. We run around and try to find something that is working. If you
provide TomEE with good and simple example applications that follow the
rules then the market share will go up. Not by implementing bugs. If you
support bugs then they will never go away.
I just re-deployed the code as explained by Romain in Glassfish and it
works so the TomEE code runs everywhere ;-)
Best regards,
Marco
Op 04-06-12 19:58, Neale Rudd schreef:
... and the reason people are using that bad coding style (according
to earlier emails) is that there are apparently some bad examples out
there.
Bad examples hurt - but they get reproduced, blogged, liked on FB,
tweeted and +1'd.
We often have a similar issue here with people using DBCP pools with
minActive=10 maxActive=100 (stupid numbers really, but SO many new
customers follow some example that has those numbers). Almost
everyone has some areas of their code that aren't closing connections
properly, so they get a leak. Their app works fine for them locally,
then their connection pool runs out of connections finally when it
reaches 100 (usually during prod, when they're asleep, so it pulls
down their whole site - as they never tested for that error
condition). We don't force them to use a more sensible number, but we
do scan their settings files and send them a warning by email (ie: we
*allow* it). That keeps the customers happy, and they can tell when
they've made a mistake. Maybe in this case TomEE could issue a
warning in the logs that their code is wrong-as-per-spec and may not
work in the future.
Developers will use examples they see on Google, they trust the blogs
they see, and use the example code. The most important validation is
to get something "working". So if it's easy (ie: works in GF, then
works in TomEE too), it makes TomEE more popular, even if the code
doesn't make any sense.
Anyway, as I said - just my 2c. Flames welcome and thanks Romain for
getting the discussion going ;-)
Best Regards,
Neale
----- Original Message ----- From: "Romain Manni-Bucau"
<rmannibu...@gmail.com>
To: <users@openejb.apache.org>
Sent: Tuesday, June 05, 2012 3:13 AM
Subject: Re: Tomee Plus instead of Glassfish
hmm,
personnally (you probably know) i have no issue doing something not
in the
spec but here i don't find it logical, i even don't understand it at
all.
If there is no interface that's obviously local (even localbean is
weird by
the way).
Aligning on RI is not always good...aligning just to say "we do like
others" is never good IMO
- Romain
2012/6/4 Neale Rudd <ne...@metawerx.net>
My 2c on this:
If Glassfish is passing EE6 but has this bug, TomEE should allow
this bug.
Obviously this is an EE6 suite bug that isn't being checked for yet,
since
Glassfish is passing. However the test should be added to the EE6
suite in
the future so we need to be prepared for it.
TomEE could have a "strict-mode" and use that for unit tests. That
way
all examples are compliant to pass future EE6 tests as per the spec.
This "strict-mode" would be disabled by default (ie: production) and
could
be enabled by a flag for maven builds, or by users if they want to
comply
100% to spec.
At this stage I think it's more important to allow any
Glassfish-compliant
code to run without change, as you should be aiming to be the
"container-of-choice". For non EE, Tomcat is definitely the
container of
choice after all IMO. So with a case like this, if the spec doesn't
allow
it, but you pass EE6 with the bug, then allow the same bugs that
Glassfish
does. And also aim to allow stuff that JBoss allows (ie: container
JSF and
JPA can be overridden per webapp with special flags in web.xml - a
feature
some of our customers are used to).
My reasoning:
- Glassfish is kind of the reference-implementation for EE at the
moment,
Oracle pushes it everywhere
- TomEE is aiming to become a major player, and with it's lite-profile,
fast startup and ability to pass EE6-WP, it has an excellent chance
- Therefore, if an app runs on Glassfish, and it passes the EE6 test
suite, ignore the spec (*make it easy to use)
- Likewise, if it runs on Tomcat, make it work on TomEE (*do no harm)
Browsers have followed this methodology in the past to gain market
percentage, so from a business-perspective I think it makes sense.
However - it's obviously not spec and it's not *right* - so comments
and
flames welcome ;-)
Best Regards,
Neale
----- Original Message ----- From: "Jean-Louis MONTEIRO" <
jeano...@gmail.com>
To: <users@openejb.apache.org>
Sent: Monday, June 04, 2012 7:07 PM
Subject: Re: Tomee Plus instead of Glassfish
David,