... 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,
Not sure how to understand that post content.
IMO, a @Local annotation (without any interface specified) on the bean
class is not allowed by the spec.
JLouis
2012/6/4 David Blevins <david.blev...@gmail.com>
On Jun 3, 2012, at 9:18 AM, Marco de Booij wrote:
> @Local
> @Stateless(name="**I18nCodeManager")
> public class I18nCodeManager {
> @EJB
> private I18nCodeDao i18nCodeDao;
>
Strangely enough we're seeing a lot of portability issues on
GlassFish's
handling of @Local.
Some JBoss friends just pinged me the other day with this:
https://issues.jboss.org/**browse/WELD-1133<https://issues.jboss.org/browse/WELD-1133>
As well another user recently reported this:
https://issues.apache.org/**jira/browse/OPENEJB-1818<https://issues.apache.org/jira/browse/OPENEJB-1818>
Three GlassFish @Local issues reported in less than a month.
-David
