Return-Path: Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: (qmail 65031 invoked from network); 4 May 2010 23:46:16 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 4 May 2010 23:46:16 -0000 Received: (qmail 94633 invoked by uid 500); 4 May 2010 23:46:16 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 94610 invoked by uid 500); 4 May 2010 23:46:16 -0000 Mailing-List: contact user-help@geronimo.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: user@geronimo.apache.org List-Id: Delivered-To: mailing list user@geronimo.apache.org Received: (qmail 94603 invoked by uid 99); 4 May 2010 23:46:15 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 04 May 2010 23:46:15 +0000 X-ASF-Spam-Status: No, hits=0.4 required=10.0 tests=AWL,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [98.136.44.61] (HELO smtp106.prem.mail.sp1.yahoo.com) (98.136.44.61) by apache.org (qpsmtpd/0.29) with SMTP; Tue, 04 May 2010 23:46:09 +0000 Received: (qmail 57618 invoked from network); 4 May 2010 23:45:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Yahoo-SMTP:X-YMail-OSG:X-Yahoo-Newman-Property:From:Mime-Version:Content-Type:Subject:Date:In-Reply-To:To:References:Message-Id:X-Mailer; b=25CcuQmqdSL+qc1LcwBq4K0FixHxBEWyuk0jHIqWUd2nbuJiF0LHK58MROLz5DU0WO/XUAzuI9XCxvAt7nAOHHJ998qp0t17+vd2uLIIuqDw2E3284oxS0BsMugsBbBRv9gB+NBburDzYYM6pX/4jS9g8TcoQBYUu5cuXJdNxNI= ; Received: from 076-076-148-215.pdx.net (david_jencks@76.76.148.215 with plain) by smtp106.prem.mail.sp1.yahoo.com with SMTP; 04 May 2010 16:45:48 -0700 PDT X-Yahoo-SMTP: .9oIUzyswBANsYgUm_5uPui0skTnzGJXJQ-- X-YMail-OSG: SfNaXCwVM1nD8zNSe6ZJ0eTFZILLgdGZ63GylU3WAZZ_S2DdBs9XLFFssWkMbmLcXodtc72j3jpnEC4Lt8fmfTDMeUTr.pqWrWFPr8Tmj2HEpf6G6ymtMv949H0NAqH13IuTTztqIEz.7mBIk66vqA85ixytGKFlD4JmsUxBHPb8F9lPa.B2gXzDgQR28fHtBmiLSZLhkRaSAE099blS_ouSpe4x.tfPLil2yQPkPqYlEVs0Sl5IhtU3D_eZUvy6nFB0nABsn4H4ib8GrsWaTRSdFC.ZrnHB_UQnFcN6mjvmFRNWOm4STRHcDdUFmd492JU_ X-Yahoo-Newman-Property: ymail-3 From: David Jencks Mime-Version: 1.0 (Apple Message framework v1077) Content-Type: multipart/alternative; boundary=Apple-Mail-23-504288071 Subject: Re: Question on @EJB and JNDI lookup Date: Tue, 4 May 2010 16:45:47 -0700 In-Reply-To: <0669EB61C3BF9143AF3D7BE84DF29B5202D9770CEB@rocjexm01.endava.net> To: user@geronimo.apache.org References: <0669EB61C3BF9143AF3D7BE84DF29B5202D9770CE9@rocjexm01.endava.net>,<431B420E-AF7C-4DC0-9D01-22F824C9C1F6@yahoo.com> <0669EB61C3BF9143AF3D7BE84DF29B5202D9770CEA@rocjexm01.endava.net>,<0CD430F0-AADD-40A2-B0A3-81164567E404@yahoo.com> <0669EB61C3BF9143AF3D7BE84DF29B5202D9770CEB@rocjexm01.endava.net> Message-Id: <2AD7B39A-4224-4F27-82C1-6E2AEEA297F4@yahoo.com> X-Mailer: Apple Mail (2.1077) --Apple-Mail-23-504288071 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On May 4, 2010, at 4:18 PM, Cristian Botiza wrote: > I haven't mentioned (sorry) that the problem is intermitent. I didn't = stop the EJB through the console or any other way. I suppose there were = some memory limits reached and the container was "forced" to discard the = EJB instance. The exception was: > IllegalStateException: Bean ...JAR/InterfaceName has been undeployed I don't know what this means. I would expect it to be a problem no = matter how you got the proxy. When you try to use a proxy, the request = gets assigned an instance of the stateless bean for the duration of the = call. Each call gets a new instance assigned. So if something happens = on the server so instances are no longer available, any proxy you may = get won't work, for the same reason. I'd ask on the openejb dev list what this message means, if possible = including a stack trace. thanks david jencks > =20 > I'm pretty sure an explicit JNDI lookup would fix this, but wanted to = avoid doing lookups at each web service call. > So if I use @EJB I shouldn't fear this problem? > Thanks again > From: David Jencks [david_jencks@yahoo.com] > Sent: 05 May 2010 01:30 > To: user@geronimo.apache.org > Subject: Re: Question on @EJB and JNDI lookup >=20 >=20 > On May 4, 2010, at 2:51 PM, Cristian Botiza wrote: >=20 >> Yes, local interfaces. >> Just that I'm using the interface name '...Local' when calling JNDI. >> By the way, CXF is deployed standalone, I added the JARs in the = repository. This may explain the issue. >> However, my question is about servlets (the plain old servlets) and = @EJB annotation. Could the injected EJB object (proxy) be undeployed? >=20 > If the war and ejb jar are in the same ear, you would not be able to = stop the ejbs without the web app stopping first. >=20 > david jencks >=20 >> =20 >> Many thanks >> From: David Jencks [david_jencks@yahoo.com] >> Sent: 04 May 2010 19:54 >> To: user@geronimo.apache.org >> Subject: Re: Question on @EJB and JNDI lookup >>=20 >> I'd need more details to understand what might be going on here. If = you are using POJO web services under the cxf that is installed in = geronimo and looking the ejb up in java:comp/env.... then the two = approaches should work identically. I'm also assuming that the ejb is = running in the same geronimo instance and you are using local interfaces = (although this should not affect anything). >>=20 >> david jencks >>=20 >> On May 4, 2010, at 2:09 AM, Cristian Botiza wrote: >>=20 >>> Hi all. >>> =20 >>> I had an issue with calling EJBs (stateless) from the web layer. >>> In the web layer I was using CXF and doing an explicit JNDI lookup = to retrieve the stateless EJB instance (proxy, to be more precise). The = issue was that those EJB references were retrieved only once when CXF = services were started. After some heavy load on the server, at some = point the EJB call failed with message: >>> =20 >>> Bean '...' was undeployed. >>> =20 >>> I assumed this is as designed and didn't try to fix it. >>> =20 >>> However, to avoid it I replaced CXF with plain old servlet and in = the servlet class I used @EJB to inject the EJB instances. Everything = works fine so far but I wanted to make sure I did the right thing. Is it = possible that I run in the same issue with this approach? As I = understand it, Geronimo will inject one instance in each servlet = instance (and there will be only one servlet instance by default) - this = is by the specs. Does Geronimo (OpenEJB) take care of circumstances when = the EJB is 'undeployed'? Will it inject a fresh instance? >>> =20 >>> Thanks! Answers much appreciated. >>>=20 >>> The information in this email is confidential and may be legally = privileged. It is intended solely for the addressee. Any opinions = expressed are mine and do not necessarily represent the opinions of the = Company. Emails are susceptible to interference. If you are not the = intended recipient, any disclosure, copying, distribution or any action = taken or omitted to be taken in reliance on it, is strictly prohibited = and may be unlawful. If you have received this message in error, do not = open any attachments but please notify the EndavaIT Service Desk on (+44 = (0)870 423 0187), and delete this message from your system. The sender = accepts no responsibility for information, errors or omissions in this = email, or for its use or misuse, or for any act committed or omitted in = connection with this communication. If in doubt, please verify the = authenticity of the contents with the sender. Please rely on your own = virus checkers as no responsibility is taken by the sender for any = damage rising out of any bug or virus infection. >>>=20 >>> Endava Limited is a company registered in England under company = number 5722669 whose registered office is at 125 Old Broad Street, = London, EC2N 1AR, United Kingdom. Endava Limited is the Endava group = holding company and does not provide any services to clients. Each of = Endava Limited and its subsidiaries is a separate legal entity and has = no liability for another such entity's acts or omissions. Please refer = to the =93Legal=94 section on our website for a list of legal entities. >>=20 >>=20 >=20 >=20 --Apple-Mail-23-504288071 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On May 4, 2010, at 4:18 PM, Cristian = Botiza wrote:

I haven't = mentioned (sorry) that the problem is intermitent. I didn't stop the EJB = through the console or any other way. I suppose there were some memory = limits reached and the container was "forced" to discard the EJB = instance. The exception was:
IllegalStateException: Bean ...JAR/InterfaceName has = been undeployed

I = don't know what this means.  I would expect it to be a problem no = matter how you got the proxy.  When you try to use a proxy, the = request gets assigned an instance of the stateless bean for the duration = of the call.  Each call gets a new instance assigned.  So if = something happens on the server so instances are no longer available, = any proxy you may get won't work, for the same = reason.

I'd ask on the openejb dev list what = this message means, if possible including a stack = trace.

thanks
david = jencks

 
I'm pretty sure an explicit = JNDI lookup would fix this, but wanted to avoid doing lookups at each = web service call.
So if I use @EJB I shouldn't fear this = problem?
Thanks again
From: David Jencks = [david_jencks@yahoo.com]
Sent: 05 May 2010 = 01:30
To: user@geronimo.apache.org
<= b>Subject: Re: = Question on @EJB and JNDI = lookup


On May 4, 2010, = at 2:51 PM, Cristian Botiza wrote:

Yes, local interfaces.
Just that I'm using the = interface name '...Local' when calling JNDI.
By the way, CXF is deployed = standalone, I added the JARs in the repository. This may explain the = issue.
However, my question is about servlets (the plain old = servlets) and @EJB annotation. Could the injected EJB object (proxy) be = undeployed?

If the = war and ejb jar are in the same ear, you would not be able to stop the = ejbs without the web app stopping first.

david = jencks

 
Many thanks
From: David Jencks = [david_jencks@yahoo.com]
Sent: 04 May 2010 = 19:54
To: user@geronimo.apache.org
<= b>Subject: Re: = Question on @EJB and JNDI lookup

I'd = need more details to understand what might be going on here.  If = you are using POJO web services under the cxf that is installed in = geronimo and looking the ejb up in java:comp/env.... then the two = approaches should work identically.  I'm also assuming that the ejb = is running in the same geronimo instance and you are using local = interfaces (although this should not affect = anything).

david jencks

On = May 4, 2010, at 2:09 AM, Cristian Botiza wrote:

Hi all.
 
I had an issue with calling EJBs (stateless) = from the web layer.
In the web layer I was using CXF and doing an explicit = JNDI lookup to retrieve the stateless EJB instance (proxy, to be more = precise). The issue was that those EJB references were retrieved only = once when CXF services were started. After some heavy load on the = server, at some point the EJB call failed with message:
 
Bean '...' was = undeployed.
 
I assumed this is as designed and didn't try to fix = it.
 
However, to avoid it I replaced CXF with plain old = servlet and in the servlet class I used @EJB to inject the EJB = instances. Everything works fine so far but I wanted to make sure I did = the right thing. Is it possible that I run in the same issue with this = approach? As I understand it, Geronimo will inject one instance in each = servlet instance (and there will be only one servlet instance by = default) - this is by the specs. Does Geronimo (OpenEJB) take care of = circumstances when the EJB is 'undeployed'? Will it inject a fresh = instance?
 
Thanks! Answers much = appreciated.

The information in this email is confidential and may = be legally privileged. It is intended solely for the addressee. Any = opinions expressed are mine and do not necessarily represent the = opinions of the Company. Emails are susceptible to interference. If you = are not the intended recipient, any disclosure, copying, distribution or = any action taken or omitted to be taken in reliance on it, is strictly = prohibited and may be unlawful. If you have received this message in = error, do not open any attachments but please notify the EndavaIT = Service Desk on (+44 (0)870 423 0187), and delete this message from your = system. The sender accepts no responsibility for information, errors or = omissions in this email, or for its use or misuse, or for any act = committed or omitted in connection with this communication. If in doubt, = please verify the authenticity of the contents with the sender. Please = rely on your own virus checkers as no responsibility is taken by the = sender for any damage rising out of any bug or virus = infection.

Endava Limited is a company registered in England = under company number 5722669 whose registered office is at 125 Old Broad = Street, London, EC2N 1AR, United Kingdom. Endava Limited is the Endava = group holding company and does not provide any services to clients. Each = of Endava Limited and its subsidiaries is a separate legal entity and = has no liability for another such entity's acts or omissions. Please = refer to the =93Legal=94 section on our website for a list of legal = entities.

=



= --Apple-Mail-23-504288071--