Tomee Plus instead of Glassfish

classic Classic list List threaded Threaded
25 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Tomee Plus instead of Glassfish

Marco de Booij
Hello,

Nearly 2 years ago I tried OpenEJB. I wanted to use it with Tomcat. It
was not such a big success for me :-( Lack of knowledge from my side. I
went to Glassfish and there I managed to get an application running. I
used EJB3.1 so I could pack the whole application in a single WAR and
did not need to create any interface for my beans. The application works.

Glassfish is nice (Beautiful console) but it is not really free. Oracle
is visible everywhere and openJDK is not supported.

To free myself from Oracle I decided to replace MySQL by Postgres and
Glassfish by Geronimo. But then Tomee Plus came to my attention and I
decided to use this. I installed it and created a Tomee Plus server in
Eclipse. When I deploy my application I get the following error message
for each EJB:
     Ambiguous @Local() usage on bean class.  Must list interfaces
explicitly in annotation.

Also my beans cannot be found (WARNING: Unresolved ejb reference
"java:comp/env/...). To me it looks like Tomee does not expect EJB 3.1.
Do I need to configure somewhere that I want to use EJB 3.1 or doesn't
Tomee accept EJB 3.1 yet.

I searched for a few days on how to fix it but I am a bad searcher or my
limited knowledge is the problem. Can somebody help me out? It works on
Glassfish so it must be a configuration problem.

Regards,

Marco

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Romain Manni-Bucau
Hi,

Can you share some code?

Tomee supports ejb 3.1

Romain
Le 3 juin 2012 16:16, "Marco de Booij" <[hidden email]> a écrit :

> Hello,
>
> Nearly 2 years ago I tried OpenEJB. I wanted to use it with Tomcat. It was
> not such a big success for me :-( Lack of knowledge from my side. I went to
> Glassfish and there I managed to get an application running. I used EJB3.1
> so I could pack the whole application in a single WAR and did not need to
> create any interface for my beans. The application works.
>
> Glassfish is nice (Beautiful console) but it is not really free. Oracle is
> visible everywhere and openJDK is not supported.
>
> To free myself from Oracle I decided to replace MySQL by Postgres and
> Glassfish by Geronimo. But then Tomee Plus came to my attention and I
> decided to use this. I installed it and created a Tomee Plus server in
> Eclipse. When I deploy my application I get the following error message for
> each EJB:
>    Ambiguous @Local() usage on bean class.  Must list interfaces
> explicitly in annotation.
>
> Also my beans cannot be found (WARNING: Unresolved ejb reference
> "java:comp/env/...). To me it looks like Tomee does not expect EJB 3.1. Do
> I need to configure somewhere that I want to use EJB 3.1 or doesn't Tomee
> accept EJB 3.1 yet.
>
> I searched for a few days on how to fix it but I am a bad searcher or my
> limited knowledge is the problem. Can somebody help me out? It works on
> Glassfish so it must be a configuration problem.
>
> Regards,
>
> Marco
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Marco de Booij
Hello,

My EJB is like:
@Local
@Stateless(mappedName = "CodeDao")
public class I18nCodeDao extends Dao<I18nCodeDto> {
   static  Logger  logger  = LoggerFactory.getLogger(I18nCodeDao.class);

   @PersistenceContext(unitName="doos",
type=PersistenceContextType.TRANSACTION)
   private EntityManager em;

   public I18nCodeDao() {
     super(I18nCodeDto.class);
   }

   @Override
   public String getApplicationName() {
     return DoosBase.APPLICATION_NAME;
   }

   @Override
   protected EntityManager getEntityManager() {
     return em;
   }

   @Override
   public Logger getLogger() {
     return logger;
   }
}

The Dao class is an abstract class defined as public abstract class
Dao<T extends Dto>

The I18nCodeDao is used as:

@Local
@Stateless(name="I18nCodeManager")
public class I18nCodeManager {
   @EJB
   private I18nCodeDao       i18nCodeDao;

So for me this all looks quite simple and straight forward. I use no XML
for this part. Only for JSF (faces-config.xml) and sun-web.xml with
(unused) security role mapping.

Regards,

Marco

Op 03-06-12 17:58, Romain Manni-Bucau schreef:

> Hi,
>
> Can you share some code?
>
> Tomee supports ejb 3.1
>
> Romain
> Le 3 juin 2012 16:16, "Marco de Booij"<[hidden email]>  a écrit :
>
>> Hello,
>>
>> Nearly 2 years ago I tried OpenEJB. I wanted to use it with Tomcat. It was
>> not such a big success for me :-( Lack of knowledge from my side. I went to
>> Glassfish and there I managed to get an application running. I used EJB3.1
>> so I could pack the whole application in a single WAR and did not need to
>> create any interface for my beans. The application works.
>>
>> Glassfish is nice (Beautiful console) but it is not really free. Oracle is
>> visible everywhere and openJDK is not supported.
>>
>> To free myself from Oracle I decided to replace MySQL by Postgres and
>> Glassfish by Geronimo. But then Tomee Plus came to my attention and I
>> decided to use this. I installed it and created a Tomee Plus server in
>> Eclipse. When I deploy my application I get the following error message for
>> each EJB:
>>     Ambiguous @Local() usage on bean class.  Must list interfaces
>> explicitly in annotation.
>>
>> Also my beans cannot be found (WARNING: Unresolved ejb reference
>> "java:comp/env/...). To me it looks like Tomee does not expect EJB 3.1. Do
>> I need to configure somewhere that I want to use EJB 3.1 or doesn't Tomee
>> accept EJB 3.1 yet.
>>
>> I searched for a few days on how to fix it but I am a bad searcher or my
>> limited knowledge is the problem. Can somebody help me out? It works on
>> Glassfish so it must be a configuration problem.
>>
>> Regards,
>>
>> Marco
>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Romain Manni-Bucau
2notes:
1) @local needs an interface (remove it)
2) mappedname is container dependent (remove it)
Le 3 juin 2012 18:23, "Marco de Booij" <[hidden email]> a écrit :

> Hello,
>
> My EJB is like:
> @Local
> @Stateless(mappedName = "CodeDao")
> public class I18nCodeDao extends Dao<I18nCodeDto> {
>  static  Logger  logger  = LoggerFactory.getLogger(**I18nCodeDao.class);
>
>  @PersistenceContext(unitName="**doos", type=PersistenceContextType.**
> TRANSACTION)
>  private EntityManager em;
>
>  public I18nCodeDao() {
>    super(I18nCodeDto.class);
>  }
>
>  @Override
>  public String getApplicationName() {
>    return DoosBase.APPLICATION_NAME;
>  }
>
>  @Override
>  protected EntityManager getEntityManager() {
>    return em;
>  }
>
>  @Override
>  public Logger getLogger() {
>    return logger;
>  }
> }
>
> The Dao class is an abstract class defined as public abstract class Dao<T
> extends Dto>
>
> The I18nCodeDao is used as:
>
> @Local
> @Stateless(name="**I18nCodeManager")
> public class I18nCodeManager {
>  @EJB
>  private I18nCodeDao       i18nCodeDao;
>
> So for me this all looks quite simple and straight forward. I use no XML
> for this part. Only for JSF (faces-config.xml) and sun-web.xml with
> (unused) security role mapping.
>
> Regards,
>
> Marco
>
> Op 03-06-12 17:58, Romain Manni-Bucau schreef:
>
>> Hi,
>>
>> Can you share some code?
>>
>> Tomee supports ejb 3.1
>>
>> Romain
>> Le 3 juin 2012 16:16, "Marco de Booij"<[hidden email]>  a écrit :
>>
>>  Hello,
>>>
>>> Nearly 2 years ago I tried OpenEJB. I wanted to use it with Tomcat. It
>>> was
>>> not such a big success for me :-( Lack of knowledge from my side. I went
>>> to
>>> Glassfish and there I managed to get an application running. I used
>>> EJB3.1
>>> so I could pack the whole application in a single WAR and did not need to
>>> create any interface for my beans. The application works.
>>>
>>> Glassfish is nice (Beautiful console) but it is not really free. Oracle
>>> is
>>> visible everywhere and openJDK is not supported.
>>>
>>> To free myself from Oracle I decided to replace MySQL by Postgres and
>>> Glassfish by Geronimo. But then Tomee Plus came to my attention and I
>>> decided to use this. I installed it and created a Tomee Plus server in
>>> Eclipse. When I deploy my application I get the following error message
>>> for
>>> each EJB:
>>>    Ambiguous @Local() usage on bean class.  Must list interfaces
>>> explicitly in annotation.
>>>
>>> Also my beans cannot be found (WARNING: Unresolved ejb reference
>>> "java:comp/env/...). To me it looks like Tomee does not expect EJB 3.1.
>>> Do
>>> I need to configure somewhere that I want to use EJB 3.1 or doesn't Tomee
>>> accept EJB 3.1 yet.
>>>
>>> I searched for a few days on how to fix it but I am a bad searcher or my
>>> limited knowledge is the problem. Can somebody help me out? It works on
>>> Glassfish so it must be a configuration problem.
>>>
>>> Regards,
>>>
>>> Marco
>>>
>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Marco de Booij
Thanks.  The errors disappeared.

Op 03-06-12 18:49, Romain Manni-Bucau schreef:

> 2notes:
> 1) @local needs an interface (remove it)
> 2) mappedname is container dependent (remove it)
> Le 3 juin 2012 18:23, "Marco de Booij"<[hidden email]>  a écrit :
>
>> Hello,
>>
>> My EJB is like:
>> @Local
>> @Stateless(mappedName = "CodeDao")
>> public class I18nCodeDao extends Dao<I18nCodeDto>  {
>>   static  Logger  logger  = LoggerFactory.getLogger(**I18nCodeDao.class);
>>
>>   @PersistenceContext(unitName="**doos", type=PersistenceContextType.**
>> TRANSACTION)
>>   private EntityManager em;
>>
>>   public I18nCodeDao() {
>>     super(I18nCodeDto.class);
>>   }
>>
>>   @Override
>>   public String getApplicationName() {
>>     return DoosBase.APPLICATION_NAME;
>>   }
>>
>>   @Override
>>   protected EntityManager getEntityManager() {
>>     return em;
>>   }
>>
>>   @Override
>>   public Logger getLogger() {
>>     return logger;
>>   }
>> }
>>
>> The Dao class is an abstract class defined as public abstract class Dao<T
>> extends Dto>
>>
>> The I18nCodeDao is used as:
>>
>> @Local
>> @Stateless(name="**I18nCodeManager")
>> public class I18nCodeManager {
>>   @EJB
>>   private I18nCodeDao       i18nCodeDao;
>>
>> So for me this all looks quite simple and straight forward. I use no XML
>> for this part. Only for JSF (faces-config.xml) and sun-web.xml with
>> (unused) security role mapping.
>>
>> Regards,
>>
>> Marco
>>
>> Op 03-06-12 17:58, Romain Manni-Bucau schreef:
>>
>>> Hi,
>>>
>>> Can you share some code?
>>>
>>> Tomee supports ejb 3.1
>>>
>>> Romain
>>> Le 3 juin 2012 16:16, "Marco de Booij"<[hidden email]>   a écrit :
>>>
>>>   Hello,
>>>> Nearly 2 years ago I tried OpenEJB. I wanted to use it with Tomcat. It
>>>> was
>>>> not such a big success for me :-( Lack of knowledge from my side. I went
>>>> to
>>>> Glassfish and there I managed to get an application running. I used
>>>> EJB3.1
>>>> so I could pack the whole application in a single WAR and did not need to
>>>> create any interface for my beans. The application works.
>>>>
>>>> Glassfish is nice (Beautiful console) but it is not really free. Oracle
>>>> is
>>>> visible everywhere and openJDK is not supported.
>>>>
>>>> To free myself from Oracle I decided to replace MySQL by Postgres and
>>>> Glassfish by Geronimo. But then Tomee Plus came to my attention and I
>>>> decided to use this. I installed it and created a Tomee Plus server in
>>>> Eclipse. When I deploy my application I get the following error message
>>>> for
>>>> each EJB:
>>>>     Ambiguous @Local() usage on bean class.  Must list interfaces
>>>> explicitly in annotation.
>>>>
>>>> Also my beans cannot be found (WARNING: Unresolved ejb reference
>>>> "java:comp/env/...). To me it looks like Tomee does not expect EJB 3.1.
>>>> Do
>>>> I need to configure somewhere that I want to use EJB 3.1 or doesn't Tomee
>>>> accept EJB 3.1 yet.
>>>>
>>>> I searched for a few days on how to fix it but I am a bad searcher or my
>>>> limited knowledge is the problem. Can somebody help me out? It works on
>>>> Glassfish so it must be a configuration problem.
>>>>
>>>> Regards,
>>>>
>>>> Marco
>>>>
>>>>
>>>>

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

David Blevins-2
In reply to this post by Marco de Booij

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

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Jean-Louis MONTEIRO
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 <[hidden email]>

>
> 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
>
>
   --
    Jean-Louis Monteiro
    http://twitter.com/jlouismonteiro
    http://www.tomitribe.com
Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Bjorn Danielsson
I distinctly remember having seen the combo @Local @Stateless
in a Glassfish tutorial a few years ago, because I copied from
that tutorial and used the code for a while (in Glassfish 2.1)
until I ran into some unrelated problem that made me rewrite
all my annotations.

--
Björn Danielsson
Cuspy Code AB


Jean-Louis MONTEIRO <[hidden email]> wrote:

> 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 <[hidden email]>
>
>>
>> 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
>>
>>
Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Neale Rudd
In reply to this post by Jean-Louis MONTEIRO
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" <[hidden email]>
To: <[hidden email]>
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 <[hidden email]>
>
>>
>> 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
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Romain Manni-Bucau
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 <[hidden email]>

> 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" <
> [hidden email]>
> To: <[hidden email]>
> 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 <[hidden email]>
>>
>>
>>> 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
>>>
>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Neale Rudd
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" <[hidden email]>
To: <[hidden email]>
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 <[hidden email]>
>
>> 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" <
>> [hidden email]>
>> To: <[hidden email]>
>> 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 <[hidden email]>
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Neale Rudd
In reply to this post by Romain Manni-Bucau
... 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" <[hidden email]>
To: <[hidden email]>
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 <[hidden email]>
>
>> 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" <
>> [hidden email]>
>> To: <[hidden email]>
>> 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 <[hidden email]>
>>>
>>>
>>>> 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
>>>>
>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Fernando Lozano
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"
> <[hidden email]>
> To: <[hidden email]>
> 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 <[hidden email]>
>>
>>> 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" <
>>> [hidden email]>
>>> To: <[hidden email]>
>>> 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 <[hidden email]>
>>>>
>>>>
>>>>> 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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Marco de Booij
In reply to this post by Neale Rudd
For me I would say not to add a bug to get market share. A bug is a bug
and should be fixed. It is better to create a simple working example
that follows the rules. People like me who try to create applications
with only a limited knowledge depend on examples and help like Neale
says. We run around and try to find something that is working. If you
provide TomEE with good and simple example applications that follow the
rules then the market share will go up. Not by implementing bugs. If you
support bugs then they will never go away.

I just re-deployed the code as explained by Romain in Glassfish and it
works so the TomEE code runs everywhere ;-)

Best regards,

Marco

Op 04-06-12 19:58, Neale Rudd schreef:

> ... 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"
> <[hidden email]>
> To: <[hidden email]>
> 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 <[hidden email]>
>>
>>> 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" <
>>> [hidden email]>
>>> To: <[hidden email]>
>>> Sent: Monday, June 04, 2012 7:07 PM
>>> Subject: Re: Tomee Plus instead of Glassfish
>>>
>>>
>>>
>>>  David,

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Romain Manni-Bucau
In reply to this post by Fernando Lozano
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 <[hidden email]>

> 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" <
>> [hidden email]>
>> To: <[hidden email]>
>> 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 <[hidden email]>
>>>
>>>  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" <
>>>> [hidden email]>
>>>> To: <[hidden email]>
>>>> 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 <[hidden email]>
>>>>>
>>>>>
>>>>>  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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

David Blevins-2
In reply to this post by Neale Rudd
Great discussion!

Note, I'm also having this exact same discussion with the JBoss folks who are also facing the same issue.

We'll be working this out with GlassFish and likely making some clarifications or changes in EJB 3.2.

On Jun 4, 2012, at 9:58 AM, Neale Rudd wrote:

> If Glassfish is passing EE6 but has this bug, TomEE should allow this bug.


We used to do exactly that:

  http://mail-archives.apache.org/mod_mbox/openejb-dev/201008.mbox/%3CA31E7871-6962-49D8-AA00-3613AACE2A2B@...%3E

> Obviously this is an EE6 suite bug that isn't being checked for yet, since Glassfish is passing.  

It wasn't checked in Java EE 5 and in OpenEJB 3.x we supported it.  It is checked indirectly in Java EE 6 and that forced us to change to be more strict.

> 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.

This is a great idea and I mention it as well in the email linked above.

Note that the TCK license agreement explicitly mentions such flags.  They are allowed but must be on by default.  The default settings must be compliant.


-David

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

David Blevins-2
In reply to this post by Jean-Louis MONTEIRO

On Jun 4, 2012, at 2:07 AM, Jean-Louis MONTEIRO wrote:

> 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.

Exactly right.  On deploy we flagged it and failed the deployment with a clear error message saying it was non compliant.

Marco updated his app and not it is far more portable.

Now that I type this it occurs to me the error message in this exact case should have recommended using @LocalBean instead.

I filed a JIRA for that one here:

  https://issues.apache.org/jira/browse/OPENEJB-1836

If someone wants to work on that, that'd be a great place to start contributing!

In fact, we have a number of validations we could do that would save user's time and prevent runtime bugs.

  https://issues.apache.org/jira/browse/OPENEJB-453

Everything in that list not checked green is up for grabs.

These validations are very easy to write as we have a pretty clean framework for implementing them and testing them.  I can't say enough how great of a place it is to get started coding and creating something that directly benefits other users.

Here is an example of a validation to ensure EJBs using Container-Managed Transactions are not also trying to reference UserTransaction.  This is illegal per spec.  Trying to compete with the container transaction management by also using UserTransaction is going to result in serious issues at runtime, so we check for it.

The code to check it is really very tiny:

http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/main/java/org/apache/openejb/config/rules/CheckUserTransactionRefs.java

The test for it as well is also very small:

http://svn.apache.org/repos/asf/openejb/trunk/openejb/container/openejb-core/src/test/java/org/apache/openejb/config/rules/CheckUserTransactionRefsTest.java

We can thank Karan Malhi for the amazing validation test suite.


-David

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Fernando Lozano
In reply to this post by David Blevins-2
Hi,

> Note that the TCK license agreement explicitly mentions such flags.
> They are allowed but must be on by default. The default settings must
> be compliant. -David

Curious how JBoss AS was certified and used to be non-compliant on the
default configuration. At least this was the case with AS 4, 5 and 6.


[]s, Fernando Lozano

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

David Blevins-2

On Jun 4, 2012, at 1:24 PM, Fernando Lozano wrote:

> Hi,
>
>> Note that the TCK license agreement explicitly mentions such flags. They are allowed but must be on by default. The default settings must be compliant. -David
>
> Curious how JBoss AS was certified and used to be non-compliant on the default configuration. At least this was the case with AS 4, 5 and 6.

I think it's just one of those things all vendors struggle with on a near continual basis, including the implementations I've worked on (TomEE, Geronimo, WAS CE).

As large and expansive as the TCK is, it could always be bigger.  Many of us would love to see it open sourced so people could contribute to it in times like this.


-David

Reply | Threaded
Open this post in threaded view
|

Re: Tomee Plus instead of Glassfish

Anthony Fryer
In reply to this post by Neale Rudd
I understand the good intentions but have to disagree that you should allow a bug just because glassfish also allows it.  At what point do you look at a container and say, they allow this therefore I should also allow it so its easier for them to migrate to my container?  Why select only glassfish?  What about jboss, weblogic, webspere etc.?

I think a clearly visible error message that exactly describes the problem (and recommends using @LocalBean instead as David mentioned) is much more preferable.  The problem with allowing it is that you can then end up encouraging wrong programming practice for the sake of making people's lives easier when migrating non-compliant apps from glassfish to tomee.  

Maybe creating a "Migrating Your App from Glassfish to Tomee" webpage would be helpful.
12