i "understand" but I know we'll not agree i don't want tomee to be popular because glassfish examples work! To be honest i don't really care about glassfish, i like Tomcat and that's one big part of why i like TomEE.
by the way http://svn.apache.org/repos/asf/openejb/trunk/openejb/examples/local-on-localview-bean/src/test/java/org/superbiz/bean/LocalBeanWithLocalTest.java works - Romain 2012/6/4 Fernando Lozano <ferna...@lozano.eti.br> > Hi, > > I think the "works there, should work also on TomEE" should be aplied to > JBoss AS examples, not only Glassfish ones. TomEE could even log a warning > alerting it is bad style, against the spec, or doesn't makes sense. But > working "out of the box" is a must IMHO. I'd also like a switch for "strict > compliance" where those would flag erros, but this should not be the > default. > > > []s, Fernando Lozano > > > > ... 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> >>>>>> <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> >>>>>> <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 >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> >
