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
As well another user recently reported this:
https://issues.apache.org/jira/browse/OPENEJB-1818
Three GlassFish @Local issues reported in less than a month.
-David
