Agreed, but if it "makes it work", I personally prefer that, at least until
you have 50%+ of the market.
It's a really interesting topic really.
"Making it work" helps tomee become easier to use.
It's a bad "design decision", but good for "business".
From what I see often, people like things to be easy.
They are going to run into various time-taking learning curves moving to
tomee already, so if they run into a spec issue that forces their code to be
"correct" but actually their code already works on their first
Netbeans+Glassfish EE download example, it will probably push them back to
GF. Which is a waste considering what TomEE has to offer.
So IMO it's an allowable trade-off, even if it's horribly wrong.
Based on that, what do you think?
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
