Return-Path: X-Original-To: apmail-geronimo-user-archive@www.apache.org Delivered-To: apmail-geronimo-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id BAD299B3D for ; Fri, 13 Jan 2012 09:46:35 +0000 (UTC) Received: (qmail 69559 invoked by uid 500); 13 Jan 2012 09:28:21 -0000 Delivered-To: apmail-geronimo-user-archive@geronimo.apache.org Received: (qmail 69074 invoked by uid 500); 13 Jan 2012 09:28:08 -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 69045 invoked by uid 99); 13 Jan 2012 09:28:00 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2012 09:28:00 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of scmccarthys@gmail.com designates 74.125.82.50 as permitted sender) Received: from [74.125.82.50] (HELO mail-ww0-f50.google.com) (74.125.82.50) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jan 2012 09:27:51 +0000 Received: by wgbdr11 with SMTP id dr11so3066700wgb.31 for ; Fri, 13 Jan 2012 01:27:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=RIXJZ6bY3P7wThZW5M/hOLYfMg1w61tEuM9kLehFbj4=; b=gq5e9MIDMbOu3TFVdhk+OQDYWObfqmJ2oRQbZJB5AzUX8vn7xExfk4/D2w0YMfnbB+ EYPiKRUXCJjVWGNSv5dV31PbQ2caXOTPm5FcbznQa4yCojYwJ7LecLt8j5Gnolx0vF5T n72rPC52+eKKjnWmtyKT2WNdYlkquT4B7cGvE= MIME-Version: 1.0 Received: by 10.180.79.10 with SMTP id f10mr7197921wix.0.1326446851679; Fri, 13 Jan 2012 01:27:31 -0800 (PST) Received: by 10.223.155.194 with HTTP; Fri, 13 Jan 2012 01:27:31 -0800 (PST) In-Reply-To: References: Date: Fri, 13 Jan 2012 09:27:31 +0000 Message-ID: Subject: Re: EJB Circular problem From: Sean McCarthy To: user@geronimo.apache.org Content-Type: multipart/alternative; boundary=f46d0442829868674d04b6657961 X-Virus-Checked: Checked by ClamAV on apache.org --f46d0442829868674d04b6657961 Content-Type: text/plain; charset=ISO-8859-1 Hi, Thanks Viola. My mistake. I was using Geronimo 2.2.1, and I've found the problem. I was setting the MinSize of the StatelessContainer to 20. If I set the MinSize to 0 it works flawlessly. I don't know if it is the intended behavior for the container, but It was trying to generate the objects for the pool before completing the EJB resolution process. The JNDI injection information of @EJB annotations was not available for beans not resolved yet. I was getting a lot of: 2012-01-13 01:26:06,280 WARN [OpenEJB] Injection data not found in JNDI context: jndiName='com.ias.test.BeanA/beanB', target=com.ias.test.BeanA/beanB 2012-01-13 01:26:06,281 INFO [OpenEJB] invoking method create on test.circular.ejb.jar/BeanB So when the container was creating the instances of BeanB for the pool, it was trying to inject BeanA into BeanB, but BeanA's information was not available at the jndi. After that, when the container was creating BeanA instances, BeanB was available, so it didn't fail. Still, at runtime, BeanA's reference inside BeanB was null, but BeanB's reference in BeenA were ok. I have tested if the new instances of BeanB that get created after the first 20 instances get evicted, are created correctly. A strange behavior, one would expect that the container will not try to create Bean instances until all the JNDI binding is complete. Is this a bug or an intended behavior for stateless beans? Thanks, Sean On Fri, Jan 13, 2012 at 12:57 AM, viola lu wrote: > Openejb version in Geronimo 2.2 is 3.1.2, you can try geronimo 2.2.1, its > openejb version is 3.1.4 > > > On Fri, Jan 13, 2012 at 1:17 AM, Sean McCarthy wrote: > >> Hi, >> >> I'm having a problem with an ear that I'm deploying to deploy on Geronimo >> 2.2. The problem is that two beans reference each other (in the same >> ejb.jar in the ear): >> >> class BeanA implements BeanAInterface { >> >> @EJB >> BeanBInterface beanB >> >> } >> >> class BeanB implements BeanBInterface { >> >> @EJB >> BeanAInterface beanA >> >> } >> >> The problem is that they do get deployed but on runtime the B's reference >> to BeanA is null. I know they should have been resolved by the time it gets >> to make the call to the object, but no matter what I do the reference is >> always null. I've check the deployment log and I can see that BeanB loads >> before BeanA so beanB reference in BeanA is ok, but the beanA reference on >> BeanB never gets loaded. >> >> I've checked openejb docs and they state that this scenario should be >> supported on OpenEJB 3.1.4. >> >> Thanks, >> >> Sean McCarthy >> >> >> >> > > > -- > viola > > Apache Geronimo > > --f46d0442829868674d04b6657961 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

Thanks Viola. My mistake. I was using Geronimo 2.2.1, and I'= ve found the problem. I was setting the MinSize of the StatelessContainer t= o 20. If I set the MinSize to 0 it works flawlessly.

I don't kno= w if it is the intended behavior for the container, but It was trying to ge= nerate the objects for the pool before completing the EJB resolution proces= s. The JNDI injection information of=A0 @EJB annotations was not available = for beans not resolved yet. I was getting a lot of:

2012-01-13 01:26:06,280 WARN=A0 [OpenEJB] Injection data not found in J= NDI context: jndiName=3D'com.ias.test.BeanA/beanB', target=3Dcom.ia= s.test.BeanA/beanB
2012-01-13 01:26:06,281 INFO=A0 [OpenEJB] invoking me= thod create on test.circular.ejb.jar/BeanB

So when the container was creating the instances of BeanB for the pool,= it was trying to inject BeanA into BeanB, but BeanA's information was = not available at the jndi. After that, when the container was creating Bean= A instances, BeanB was available, so it didn't fail. Still, at runtime,= BeanA's reference inside BeanB was null, but BeanB's reference in = BeenA were ok.

I have tested if the new instances of BeanB that get created after the = first 20 instances get evicted, are created correctly.

A strange beh= avior, one would expect that the container will not try to create Bean inst= ances until all the JNDI binding is complete. Is this a bug or an intended = behavior for stateless beans?

Thanks,

=A0=A0=A0=A0 Sean

On F= ri, Jan 13, 2012 at 12:57 AM, viola lu <viola.lu@gmail.com> wrote:
Openejb version in Geronimo 2.2 is 3.1.2, you can try geronimo 2.2.1, its o= penejb version is 3.1.4


On Fri, Jan 13, 2012 at 1:17 AM, Sean McCarthy <scmccarthys@gmail.com> wrote:
Hi,

I'm having a problem with an = ear that I'm deploying to deploy on Geronimo 2.2. The problem is that t= wo beans reference each other (in the same ejb.jar in the ear):

class BeanA implements BeanAInterface {

@EJB
BeanBInterface beanB

}

class BeanB implements Be= anBInterface {

@EJB
BeanAInterface beanA

}

The prob= lem is that they do get deployed but on runtime the B's reference to Be= anA is null. I know they should have been resolved by the time it gets to m= ake the call to the object, but no matter what I do the reference is always= null. I've check the deployment log and I can see that BeanB loads bef= ore BeanA so beanB reference in BeanA is ok, but the beanA reference on Bea= nB never gets loaded.

I've checked openejb docs and they state that this scenario should = be supported on OpenEJB 3.1.4.

Thanks,=

=A0=A0 Sean McCarthy






--
viola

=
Apache Geronimo


--f46d0442829868674d04b6657961--