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