You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomee.apache.org by Marco de Booij <md...@scarlet.be> on 2012/06/03 16:14:50 UTC
Tomee Plus instead of Glassfish
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
Re: Tomee Plus instead of Glassfish
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <fe...@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" <
>> rmannibucau@gmail.com>
>> To: <us...@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" <
>>>> jeanouii@gmail.com>
>>>> To: <us...@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 <da...@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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Tomee Plus instead of Glassfish
Posted by Fernando Lozano <fe...@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"
> <rm...@gmail.com>
> To: <us...@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" <
>>> jeanouii@gmail.com>
>>> To: <us...@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 <da...@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
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
Re: Tomee Plus instead of Glassfish
Posted by Marco de Booij <md...@scarlet.be>.
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"
> <rm...@gmail.com>
> To: <us...@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" <
>>> jeanouii@gmail.com>
>>> To: <us...@openejb.apache.org>
>>> Sent: Monday, June 04, 2012 7:07 PM
>>> Subject: Re: Tomee Plus instead of Glassfish
>>>
>>>
>>>
>>> David,
Re: Tomee Plus instead of Glassfish
Posted by Neale Rudd <ne...@metawerx.net>.
... 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" <rm...@gmail.com>
To: <us...@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" <
>> jeanouii@gmail.com>
>> To: <us...@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 <da...@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
>>>>
>>>>
>>>>
>>>
>>
>
Re: Tomee Plus instead of Glassfish
Posted by Neale Rudd <ne...@metawerx.net>.
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" <rm...@gmail.com>
To: <us...@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" <
>> jeanouii@gmail.com>
>> To: <us...@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 <da...@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
>>>>
>>>>
>>>>
>>>
>>
>
Re: Tomee Plus instead of Glassfish
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <
> jeanouii@gmail.com>
> To: <us...@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 <da...@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
>>>
>>>
>>>
>>
>
Re: Tomee Plus instead of Glassfish
Posted by Fernando Lozano <fe...@lozano.eti.br>.
Agreed
> 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.
>
> --
> View this message in context: http://openejb.979440.n4.nabble.com/Tomee-Plus-instead-of-Glassfish-tp4655318p4655395.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Tomee Plus instead of Glassfish
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Done.
The page is here.
http://openejb.staging.apache.org/from-glassfish-to-tomee.html
The button is on top right.
It's in the staging website for the moment.
Jean-Louis
2012/11/22 Howard W. Smith, Jr. <sm...@gmail.com>
> Jean-Louis,
>
> Sounds good to me. I would have to refer to my daily notes/journal and my
> brain/memory to document my experience on such a page.
>
> Thanks,
> Howard
>
>
> On Thu, Nov 22, 2012 at 11:01 AM, Jean-Louis MONTEIRO <jeanouii@gmail.com
> >wrote:
>
> > Hey guys,
> >
> > Thanks so much for the feedback.
> > If you think it would be valuable, let's create it.
> >
> > Maybe the best way to get something relevant is to allow you both write
> it.
> > If you agree, I can create an empty page and let you write the content.
> >
> > It's pretty cool and easy using Apache CMS cause you can do it in an
> > anonymous manner (no need to be a committer).
> >
> > On top of any page, you have a pen you can use to edit a page.
> >
> > Jean-Louis
> >
> >
> > 2012/11/22 smithh032772 <sm...@gmail.com>
> >
> > > I agree, this is a great discussion!
> > >
> > > I know this is an old topic, but I was doing some browsing, came across
> > > this
> > > topic, and thought I might take a look, since I have had the same
> goal...
> > > 'Tomee Plus instead of Glassfish'. :)
> > >
> > > It 'sounds' good, and for good 'business' to allow developers to 'drop'
> > an
> > > app (or deploy an app) to any container, but honestly, I don't mind the
> > > work
> > > involved to go from one container (e.g. Glassfish) to another container
> > > (TomEE!!!).
> > >
> > > I currently have a JSF/PrimeFaces web app that is currently running on
> > > Glassfish in production right now. For the last 5 to 7 days, I have
> been
> > > 'working' to migrate that app from Glassfish 3.1.2.2 to TomEE 1.5+
> > > (SNAPSHOT). So far, it has been a great 'and' learning experience.
> > >
> > > Yes, NetBeans/Glassfish (and Mojarra!!!) allow
> > > inexperienced/new/limited-experienced (java) developers (like myself)
> to
> > > develop an app based on tutorials/showcases, code shared by others on
> > > blogs/forums/etc..., and 10 times out of 10, that code works!
> > >
> > > All of that really helped me to be the successful JSF developer that I
> am
> > > today, but one day, I sought 'performance', I wanted my JSF web app to
> be
> > > reliable and run really really well 'in production' even though my web
> > app
> > > is serving less than 10 people (my family). Some people have knocked
> me,
> > > since I'm only developing a web app for 'family'. That's another topic,
> > so
> > > I
> > > won't discuss that. :)
> > >
> > > Anyway, while seeking performance, I saw others recommend (Apache)
> > MyFaces
> > > over Mojarra. Glassfish and Mojarra was already allowing my web app to
> > run
> > > really well, reliably, etc.., but I had an unquenched thirst for 'best
> > > performance' (still thirsty for that, too...smile).
> > >
> > > So, I decided to migrate 'from' Mojarra 2.1.7 to MyFaces Core 2.1.8. In
> > > that
> > > process, I realized that Mojarra 'allowed' so many things to work while
> > the
> > > same did 'not' work in/with MyFaces Core 2.1.8. Did I gripe or
> complain?
> > > No.
> > > I kept modifying code/xhtml, so I could complete the task of migrating
> to
> > > MyFaces, since the performance was undeniable there! If I'm not
> > mistaking,
> > > that was a 7-day job for me, but that task was completed and is in the
> > > past.
> > >
> > > So, my JSF/PrimeFaces/Glassfish3.1.2.2/MyFaces-Core-2.1.9 app is
> running
> > > very very well in production, and pages render so very fast. Yes, i've
> > add
> > > performance-tuning context-param's in web.xml as well as did some
> > > performance tuning in and for the Apache Derby database. I am sure
> that I
> > > can make more performance improvements throughout the app though as I
> > > continue to read and listen to what others are doing.
> > >
> > > Back to the topic (Tomee Plus instead of Glassfish)...
> > >
> > > As an actively-participating member of PrimeFaces Core community, I
> have
> > > seen others state in their profile signature that they are running
> Tomcat
> > > 6/7.x. When I realized that I wanted to use a new feature called
> > PrimeFaces
> > > Push (powered by Atmosphere/websockets), I had issues using this with
> > > Glassfish 3.1.2.2, but heard that it works with Tomcat and TomEE.
> > Sometime
> > > within the last 1 or 2 months, I attempted to migrate from Glassfish
> > > 3.1.2.2
> > > to Tomcat 7.0.32, but I had to drop in so many different JARs, and I
> > failed
> > > to get the app started.
> > >
> > > Last week, someone recommended TomEE for Primefaces Push, so I decided
> to
> > > migrate to TomEE plus, and the task is not complete yet, but hoping to
> > > finish soon and push my JSF/PrimeFaces/TomEE Plus app to production,
> > ASAP.
> > > :)
> > >
> > > Also, motivation to migrate to TomEE came from Mark Blevin's blog, Why
> > is
> > > OpenWebBeans so fast?
> > > <http://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/
> >
> > .
> > > Like I said, I have unquenched thirst for performance (as well as
> > > 'success'), so I want Tomcat/TomEE/OpenWebBeans/OpenEJB, and 'all' they
> > > have
> > > to offer, even/especially if that means I need to clean up and
> 'correct'
> > my
> > > 'buggy/illegal' code that worked in Glassfish as well as Mojarra!!! :)
> > >
> > > As Anthony stated below, the following blog or tutorial would be great!
> > >
> > > > Maybe creating a "Migrating Your App from Glassfish to Tomee" webpage
> > > > would be helpful.
> > >
> > >
> > >
> > >
> > > --
> > > View this message in context:
> > >
> >
> http://openejb.979440.n4.nabble.com/Tomee-Plus-instead-of-Glassfish-tp4655318p4658801.html
> > > Sent from the OpenEJB User mailing list archive at Nabble.com.
> > >
> >
> >
> >
> > --
> > Jean-Louis
> >
>
--
Jean-Louis
Re: Tomee Plus instead of Glassfish
Posted by "Howard W. Smith, Jr." <sm...@gmail.com>.
Jean-Louis,
Sounds good to me. I would have to refer to my daily notes/journal and my
brain/memory to document my experience on such a page.
Thanks,
Howard
On Thu, Nov 22, 2012 at 11:01 AM, Jean-Louis MONTEIRO <je...@gmail.com>wrote:
> Hey guys,
>
> Thanks so much for the feedback.
> If you think it would be valuable, let's create it.
>
> Maybe the best way to get something relevant is to allow you both write it.
> If you agree, I can create an empty page and let you write the content.
>
> It's pretty cool and easy using Apache CMS cause you can do it in an
> anonymous manner (no need to be a committer).
>
> On top of any page, you have a pen you can use to edit a page.
>
> Jean-Louis
>
>
> 2012/11/22 smithh032772 <sm...@gmail.com>
>
> > I agree, this is a great discussion!
> >
> > I know this is an old topic, but I was doing some browsing, came across
> > this
> > topic, and thought I might take a look, since I have had the same goal...
> > 'Tomee Plus instead of Glassfish'. :)
> >
> > It 'sounds' good, and for good 'business' to allow developers to 'drop'
> an
> > app (or deploy an app) to any container, but honestly, I don't mind the
> > work
> > involved to go from one container (e.g. Glassfish) to another container
> > (TomEE!!!).
> >
> > I currently have a JSF/PrimeFaces web app that is currently running on
> > Glassfish in production right now. For the last 5 to 7 days, I have been
> > 'working' to migrate that app from Glassfish 3.1.2.2 to TomEE 1.5+
> > (SNAPSHOT). So far, it has been a great 'and' learning experience.
> >
> > Yes, NetBeans/Glassfish (and Mojarra!!!) allow
> > inexperienced/new/limited-experienced (java) developers (like myself) to
> > develop an app based on tutorials/showcases, code shared by others on
> > blogs/forums/etc..., and 10 times out of 10, that code works!
> >
> > All of that really helped me to be the successful JSF developer that I am
> > today, but one day, I sought 'performance', I wanted my JSF web app to be
> > reliable and run really really well 'in production' even though my web
> app
> > is serving less than 10 people (my family). Some people have knocked me,
> > since I'm only developing a web app for 'family'. That's another topic,
> so
> > I
> > won't discuss that. :)
> >
> > Anyway, while seeking performance, I saw others recommend (Apache)
> MyFaces
> > over Mojarra. Glassfish and Mojarra was already allowing my web app to
> run
> > really well, reliably, etc.., but I had an unquenched thirst for 'best
> > performance' (still thirsty for that, too...smile).
> >
> > So, I decided to migrate 'from' Mojarra 2.1.7 to MyFaces Core 2.1.8. In
> > that
> > process, I realized that Mojarra 'allowed' so many things to work while
> the
> > same did 'not' work in/with MyFaces Core 2.1.8. Did I gripe or complain?
> > No.
> > I kept modifying code/xhtml, so I could complete the task of migrating to
> > MyFaces, since the performance was undeniable there! If I'm not
> mistaking,
> > that was a 7-day job for me, but that task was completed and is in the
> > past.
> >
> > So, my JSF/PrimeFaces/Glassfish3.1.2.2/MyFaces-Core-2.1.9 app is running
> > very very well in production, and pages render so very fast. Yes, i've
> add
> > performance-tuning context-param's in web.xml as well as did some
> > performance tuning in and for the Apache Derby database. I am sure that I
> > can make more performance improvements throughout the app though as I
> > continue to read and listen to what others are doing.
> >
> > Back to the topic (Tomee Plus instead of Glassfish)...
> >
> > As an actively-participating member of PrimeFaces Core community, I have
> > seen others state in their profile signature that they are running Tomcat
> > 6/7.x. When I realized that I wanted to use a new feature called
> PrimeFaces
> > Push (powered by Atmosphere/websockets), I had issues using this with
> > Glassfish 3.1.2.2, but heard that it works with Tomcat and TomEE.
> Sometime
> > within the last 1 or 2 months, I attempted to migrate from Glassfish
> > 3.1.2.2
> > to Tomcat 7.0.32, but I had to drop in so many different JARs, and I
> failed
> > to get the app started.
> >
> > Last week, someone recommended TomEE for Primefaces Push, so I decided to
> > migrate to TomEE plus, and the task is not complete yet, but hoping to
> > finish soon and push my JSF/PrimeFaces/TomEE Plus app to production,
> ASAP.
> > :)
> >
> > Also, motivation to migrate to TomEE came from Mark Blevin's blog, Why
> is
> > OpenWebBeans so fast?
> > <http://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/>
> .
> > Like I said, I have unquenched thirst for performance (as well as
> > 'success'), so I want Tomcat/TomEE/OpenWebBeans/OpenEJB, and 'all' they
> > have
> > to offer, even/especially if that means I need to clean up and 'correct'
> my
> > 'buggy/illegal' code that worked in Glassfish as well as Mojarra!!! :)
> >
> > As Anthony stated below, the following blog or tutorial would be great!
> >
> > > Maybe creating a "Migrating Your App from Glassfish to Tomee" webpage
> > > would be helpful.
> >
> >
> >
> >
> > --
> > View this message in context:
> >
> http://openejb.979440.n4.nabble.com/Tomee-Plus-instead-of-Glassfish-tp4655318p4658801.html
> > Sent from the OpenEJB User mailing list archive at Nabble.com.
> >
>
>
>
> --
> Jean-Louis
>
Re: Tomee Plus instead of Glassfish
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
Hey guys,
Thanks so much for the feedback.
If you think it would be valuable, let's create it.
Maybe the best way to get something relevant is to allow you both write it.
If you agree, I can create an empty page and let you write the content.
It's pretty cool and easy using Apache CMS cause you can do it in an
anonymous manner (no need to be a committer).
On top of any page, you have a pen you can use to edit a page.
Jean-Louis
2012/11/22 smithh032772 <sm...@gmail.com>
> I agree, this is a great discussion!
>
> I know this is an old topic, but I was doing some browsing, came across
> this
> topic, and thought I might take a look, since I have had the same goal...
> 'Tomee Plus instead of Glassfish'. :)
>
> It 'sounds' good, and for good 'business' to allow developers to 'drop' an
> app (or deploy an app) to any container, but honestly, I don't mind the
> work
> involved to go from one container (e.g. Glassfish) to another container
> (TomEE!!!).
>
> I currently have a JSF/PrimeFaces web app that is currently running on
> Glassfish in production right now. For the last 5 to 7 days, I have been
> 'working' to migrate that app from Glassfish 3.1.2.2 to TomEE 1.5+
> (SNAPSHOT). So far, it has been a great 'and' learning experience.
>
> Yes, NetBeans/Glassfish (and Mojarra!!!) allow
> inexperienced/new/limited-experienced (java) developers (like myself) to
> develop an app based on tutorials/showcases, code shared by others on
> blogs/forums/etc..., and 10 times out of 10, that code works!
>
> All of that really helped me to be the successful JSF developer that I am
> today, but one day, I sought 'performance', I wanted my JSF web app to be
> reliable and run really really well 'in production' even though my web app
> is serving less than 10 people (my family). Some people have knocked me,
> since I'm only developing a web app for 'family'. That's another topic, so
> I
> won't discuss that. :)
>
> Anyway, while seeking performance, I saw others recommend (Apache) MyFaces
> over Mojarra. Glassfish and Mojarra was already allowing my web app to run
> really well, reliably, etc.., but I had an unquenched thirst for 'best
> performance' (still thirsty for that, too...smile).
>
> So, I decided to migrate 'from' Mojarra 2.1.7 to MyFaces Core 2.1.8. In
> that
> process, I realized that Mojarra 'allowed' so many things to work while the
> same did 'not' work in/with MyFaces Core 2.1.8. Did I gripe or complain?
> No.
> I kept modifying code/xhtml, so I could complete the task of migrating to
> MyFaces, since the performance was undeniable there! If I'm not mistaking,
> that was a 7-day job for me, but that task was completed and is in the
> past.
>
> So, my JSF/PrimeFaces/Glassfish3.1.2.2/MyFaces-Core-2.1.9 app is running
> very very well in production, and pages render so very fast. Yes, i've add
> performance-tuning context-param's in web.xml as well as did some
> performance tuning in and for the Apache Derby database. I am sure that I
> can make more performance improvements throughout the app though as I
> continue to read and listen to what others are doing.
>
> Back to the topic (Tomee Plus instead of Glassfish)...
>
> As an actively-participating member of PrimeFaces Core community, I have
> seen others state in their profile signature that they are running Tomcat
> 6/7.x. When I realized that I wanted to use a new feature called PrimeFaces
> Push (powered by Atmosphere/websockets), I had issues using this with
> Glassfish 3.1.2.2, but heard that it works with Tomcat and TomEE. Sometime
> within the last 1 or 2 months, I attempted to migrate from Glassfish
> 3.1.2.2
> to Tomcat 7.0.32, but I had to drop in so many different JARs, and I failed
> to get the app started.
>
> Last week, someone recommended TomEE for Primefaces Push, so I decided to
> migrate to TomEE plus, and the task is not complete yet, but hoping to
> finish soon and push my JSF/PrimeFaces/TomEE Plus app to production, ASAP.
> :)
>
> Also, motivation to migrate to TomEE came from Mark Blevin's blog, Why is
> OpenWebBeans so fast?
> <http://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/> .
> Like I said, I have unquenched thirst for performance (as well as
> 'success'), so I want Tomcat/TomEE/OpenWebBeans/OpenEJB, and 'all' they
> have
> to offer, even/especially if that means I need to clean up and 'correct' my
> 'buggy/illegal' code that worked in Glassfish as well as Mojarra!!! :)
>
> As Anthony stated below, the following blog or tutorial would be great!
>
> > Maybe creating a "Migrating Your App from Glassfish to Tomee" webpage
> > would be helpful.
>
>
>
>
> --
> View this message in context:
> http://openejb.979440.n4.nabble.com/Tomee-Plus-instead-of-Glassfish-tp4655318p4658801.html
> Sent from the OpenEJB User mailing list archive at Nabble.com.
>
--
Jean-Louis
Re: Tomee Plus instead of Glassfish
Posted by smithh032772 <sm...@gmail.com>.
I agree, this is a great discussion!
I know this is an old topic, but I was doing some browsing, came across this
topic, and thought I might take a look, since I have had the same goal...
'Tomee Plus instead of Glassfish'. :)
It 'sounds' good, and for good 'business' to allow developers to 'drop' an
app (or deploy an app) to any container, but honestly, I don't mind the work
involved to go from one container (e.g. Glassfish) to another container
(TomEE!!!).
I currently have a JSF/PrimeFaces web app that is currently running on
Glassfish in production right now. For the last 5 to 7 days, I have been
'working' to migrate that app from Glassfish 3.1.2.2 to TomEE 1.5+
(SNAPSHOT). So far, it has been a great 'and' learning experience.
Yes, NetBeans/Glassfish (and Mojarra!!!) allow
inexperienced/new/limited-experienced (java) developers (like myself) to
develop an app based on tutorials/showcases, code shared by others on
blogs/forums/etc..., and 10 times out of 10, that code works!
All of that really helped me to be the successful JSF developer that I am
today, but one day, I sought 'performance', I wanted my JSF web app to be
reliable and run really really well 'in production' even though my web app
is serving less than 10 people (my family). Some people have knocked me,
since I'm only developing a web app for 'family'. That's another topic, so I
won't discuss that. :)
Anyway, while seeking performance, I saw others recommend (Apache) MyFaces
over Mojarra. Glassfish and Mojarra was already allowing my web app to run
really well, reliably, etc.., but I had an unquenched thirst for 'best
performance' (still thirsty for that, too...smile).
So, I decided to migrate 'from' Mojarra 2.1.7 to MyFaces Core 2.1.8. In that
process, I realized that Mojarra 'allowed' so many things to work while the
same did 'not' work in/with MyFaces Core 2.1.8. Did I gripe or complain? No.
I kept modifying code/xhtml, so I could complete the task of migrating to
MyFaces, since the performance was undeniable there! If I'm not mistaking,
that was a 7-day job for me, but that task was completed and is in the past.
So, my JSF/PrimeFaces/Glassfish3.1.2.2/MyFaces-Core-2.1.9 app is running
very very well in production, and pages render so very fast. Yes, i've add
performance-tuning context-param's in web.xml as well as did some
performance tuning in and for the Apache Derby database. I am sure that I
can make more performance improvements throughout the app though as I
continue to read and listen to what others are doing.
Back to the topic (Tomee Plus instead of Glassfish)...
As an actively-participating member of PrimeFaces Core community, I have
seen others state in their profile signature that they are running Tomcat
6/7.x. When I realized that I wanted to use a new feature called PrimeFaces
Push (powered by Atmosphere/websockets), I had issues using this with
Glassfish 3.1.2.2, but heard that it works with Tomcat and TomEE. Sometime
within the last 1 or 2 months, I attempted to migrate from Glassfish 3.1.2.2
to Tomcat 7.0.32, but I had to drop in so many different JARs, and I failed
to get the app started.
Last week, someone recommended TomEE for Primefaces Push, so I decided to
migrate to TomEE plus, and the task is not complete yet, but hoping to
finish soon and push my JSF/PrimeFaces/TomEE Plus app to production, ASAP.
:)
Also, motivation to migrate to TomEE came from Mark Blevin's blog, Why is
OpenWebBeans so fast?
<http://struberg.wordpress.com/2012/03/20/why-is-openwebbeans-so-fast/> .
Like I said, I have unquenched thirst for performance (as well as
'success'), so I want Tomcat/TomEE/OpenWebBeans/OpenEJB, and 'all' they have
to offer, even/especially if that means I need to clean up and 'correct' my
'buggy/illegal' code that worked in Glassfish as well as Mojarra!!! :)
As Anthony stated below, the following blog or tutorial would be great!
> Maybe creating a "Migrating Your App from Glassfish to Tomee" webpage
> would be helpful.
--
View this message in context: http://openejb.979440.n4.nabble.com/Tomee-Plus-instead-of-Glassfish-tp4655318p4658801.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Tomee Plus instead of Glassfish
Posted by Anthony Fryer <ap...@hotmail.com>.
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.
--
View this message in context: http://openejb.979440.n4.nabble.com/Tomee-Plus-instead-of-Glassfish-tp4655318p4655395.html
Sent from the OpenEJB User mailing list archive at Nabble.com.
Re: Tomee Plus instead of Glassfish
Posted by David Blevins <da...@gmail.com>.
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
Re: Tomee Plus instead of Glassfish
Posted by Fernando Lozano <fe...@lozano.eti.br>.
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
Re: Tomee Plus instead of Glassfish
Posted by David Blevins <da...@gmail.com>.
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@visi.com%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
Re: Tomee Plus instead of Glassfish
Posted by 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" <je...@gmail.com>
To: <us...@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 <da...@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
>>
>>
>
Re: Tomee Plus instead of Glassfish
Posted by David Blevins <da...@gmail.com>.
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
Re: Tomee Plus instead of Glassfish
Posted by Bjorn Danielsson <bj...@lists.cuspycode.com>.
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 <je...@gmail.com> 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 <da...@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
>>
>>
Re: Tomee Plus instead of Glassfish
Posted by Jean-Louis MONTEIRO <je...@gmail.com>.
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 <da...@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
>
>
Re: Tomee Plus instead of Glassfish
Posted by David Blevins <da...@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
Re: Tomee Plus instead of Glassfish
Posted by Marco de Booij <md...@scarlet.be>.
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"<md...@scarlet.be> 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"<md...@scarlet.be> 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
>>>>
>>>>
>>>>
Re: Tomee Plus instead of Glassfish
Posted by Romain Manni-Bucau <rm...@gmail.com>.
2notes:
1) @local needs an interface (remove it)
2) mappedname is container dependent (remove it)
Le 3 juin 2012 18:23, "Marco de Booij" <md...@scarlet.be> 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"<md...@scarlet.be> 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
>>>
>>>
>>>
>
Re: Tomee Plus instead of Glassfish
Posted by Marco de Booij <md...@scarlet.be>.
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"<md...@scarlet.be> 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
>>
>>
Re: Tomee Plus instead of Glassfish
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hi,
Can you share some code?
Tomee supports ejb 3.1
Romain
Le 3 juin 2012 16:16, "Marco de Booij" <md...@scarlet.be> 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
>
>