Return-Path: X-Original-To: apmail-felix-users-archive@minotaur.apache.org Delivered-To: apmail-felix-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4EF5374EA for ; Wed, 21 Dec 2011 13:57:36 +0000 (UTC) Received: (qmail 25512 invoked by uid 500); 21 Dec 2011 13:57:35 -0000 Delivered-To: apmail-felix-users-archive@felix.apache.org Received: (qmail 25478 invoked by uid 500); 21 Dec 2011 13:57:35 -0000 Mailing-List: contact users-help@felix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@felix.apache.org Delivered-To: mailing list users@felix.apache.org Received: (qmail 25470 invoked by uid 99); 21 Dec 2011 13:57:35 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Dec 2011 13:57:35 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of clement.escoffier@gmail.com designates 74.125.82.41 as permitted sender) Received: from [74.125.82.41] (HELO mail-ww0-f41.google.com) (74.125.82.41) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Dec 2011 13:57:27 +0000 Received: by wgbdt12 with SMTP id dt12so10095599wgb.4 for ; Wed, 21 Dec 2011 05:57:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=mUmlvr1qQkIdMxgUjpiIofeE8PSDh+YIxIF9/Y+1a3s=; b=LqxTd/PPmN7zW3vPrfPMcTV+jduv8GmCbb7Broxg9qgMs10Tq6HwIGp/0G9G/xfo1K BrNy4m77Q2ihw2BGM2quxulIggMgSjTKZ0tU/lkejEoWqKo81z/lBFW56F4Gl3IjWlka 6A95NlIggJY7pbkjGpyv2Qv54i8QrDF4UucIc= Received: by 10.180.19.106 with SMTP id d10mr14574996wie.2.1324475827005; Wed, 21 Dec 2011 05:57:07 -0800 (PST) Received: from [172.20.201.95] (www.spree.de. [212.6.178.2]) by mx.google.com with ESMTPS id ff1sm5947085wbb.5.2011.12.21.05.57.05 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 21 Dec 2011 05:57:05 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Apple Message framework v1251.1) Subject: Re: Dynamically change the bound service From: Clement Escoffier In-Reply-To: <4EEFFEF7.4020903@ungoverned.org> Date: Wed, 21 Dec 2011 14:57:04 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9308BAD4-91AE-45A2-A507-45A0CADB8CBE@gmail.com> References: <32999833.post@talk.nabble.com> <4EEE6DD8.2040708@ungoverned.org> <33000287.post@talk.nabble.com> <4EEF62BC.4020400@ungoverned.org> <33007245.post@talk.nabble.com> <4EEFFEF7.4020903@ungoverned.org> To: users@felix.apache.org X-Mailer: Apple Mail (2.1251.1) X-Virus-Checked: Checked by ClamAV on apache.org Hi, As explained by Richard, iPOJO uses some advanced caching technics to = avoid server switch during an execution flow. So if you have a method = using service objects but never return, it will use the same service = objects forever. To avoid it, isolate the service manipulation in = another method.=20 Regards, Clement On 20.12.2011, at 04:20, Richard S. Hall wrote: > On 12/19/11 21:53 , Fabio Fonseca wrote: >> Hello! >>=20 >> Yes, that you are right! I'm starting a thread in my run() method. I = have >> just modified my simple consumer + two providers test to remove the = thread >> and everything worked! Thanks! I only had to create a "super" = consumer (that >> consumes my consumer) to make it run my consumer's run() method = without >> having to stop and start it again. I did that because my objective = was to >> see the bound provider being changed automatically without the need = to >> restart the consumer. >>=20 >> However, I would like to see it working in a second example that uses = a >> Thread. I'm still doing some tests with it. I'll post my results here = as >> soon as possible. >=20 > As I said, it will work with a thread, but you cannot have the = thread's run() methodaccess the services directly, since that method = never exits until the thread exits, so iPOJO will cache the service = references the entire time. If you create some method = MyComponent.doSomethingWithAService() and then call it from your run() = method, then I believe it should work. >=20 > -> richard >=20 >>=20 >> Thanks! >> Fabio >>=20 >>=20 >> Richard S. Hall wrote: >>> Overall, it looks not unreasonable. >>>=20 >>> Are you starting a thread? If so, that could be an issue. >>>=20 >>> iPOJO does some sophisticated service reference management to = simplify >>> concurrency issues for you. My guess is that iPOJO cannot tell that = the >>> thread you've created ever exits the component, so it keeps a cached >>> reference for the lifetime of the thread. >>>=20 >>> Try to modify your thread so that it performs it functionality via a >>> method on the component itself invoked form its run() method...i.e., >>> your thread should explicitly enter and exit a method block to use a >>> service so that iPOJO can properly keep track of it for you, because >>> iPOJO is likely caching the service reference while your thread runs = in >>> its run() method. >>>=20 >>> To provide a little more detail, when a thread enters a component >>> method, if that method accesses a service field, then iPOJO will >>> automatically cache the service reference for that thread for the = entire >>> time that it executes inside that method. This way the thread = doesn't >>> have to worry about its service changing in the middle of using it. = (Of >>> course, it could still get errors if the service goes away, but that = is >>> normal for OSGi.) In this case, I'm guessing your component has a = run() >>> method on the component that access a service, so iPOJO caches the >>> services until the thread exits the run() method, which in your case >>> doesn't happen. >>>=20 >>> -> richard >>>=20 >>> On 12/18/11 20:49 , Fabio Fonseca wrote: >>>> Hi Richard, >>>>=20 >>>> Thanks for your response. I'd say that's definitely some basic = mistake. >>>> As >>>> you'd said, it is basic behavior (and I was hoping to read that). = The >>>> problem is that I can't find where my mistake is... Yes, I tried = field >>>> injection and I also tried method injection using the bind and = unbind >>>> methods in the consumer, but they weren't called when I thought = they >>>> should >>>> be. >>>>=20 >>>> The code that I have attached in my original post is my test with = method >>>> injection. I was hoping anybody more experienced than me could find = what >>>> I'm >>>> doing wrong. >>>>=20 >>>> Anyway, in the following lines you can find some parts of the code. >>>> Perhaps >>>> there is something that I'm missing but that is obvious to you. >>>>=20 >>>> . consumer.xml: >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>=20 >>>> . consumer.java: >>>> public class Consumer >>>> implements Runnable >>>> { >>>> private InterfaceOne inter; >>>>=20 >>>> public void start() { >>>> System.out.println("[Consumer] Validating"); >>>> run(); >>>> } >>>>=20 >>>> public void stop() { >>>> System.out.println("[Consumer] Invalidating"); >>>> stopRequestReceiver(); >>>> } >>>> =09 >>>> // This was never called >>>> public synchronized void bindInter (InterfaceOne i) { >>>> System.out.println("[Consumer] Binding"); >>>> } >>>> =09 >>>> // This was never called >>>> public synchronized void unbindInter (InterfaceOne i) { >>>> System.out.println("[Consumer] Unbinding"); =09 >>>> } >>>>=20 >>>> (...) >>>> } >>>>=20 >>>> . providerA.xml (providerB is similar): >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>>=20 >>>> >>>> >>>>=20 >>>> . providerA.java: >>>> public class ProviderA >>>> implements InterfaceOne >>>> { >>>> private int state =3D 1; >>>> =09 >>>> public void start() >>>> { >>>> System.out.println("[ProviderA] Validating"); >>>> state =3D 1; >>>> } >>>>=20 >>>> public void stop() >>>> { >>>> System.out.println("[ProviderA] Invalidating"); >>>> state =3D 0; >>>> } >>>>=20 >>>> (...) >>>> } >>>>=20 >>>> Thanks, >>>> Fabio Fonseca >>>>=20 >>>>=20 >>>> Richard S. Hall wrote: >>>>> That doesn't sound right. I'd say there is something else simple = going >>>>> wrong. If you are using field injection in the consumer, you could = look >>>>> to add method injection too to see if you are getting proper = callbacks >>>>> when services come and go. Regardless, this sounds like pretty = basic >>>>> behavior, so I have to assume there is a simple mistake. >>>>>=20 >>>>> -> richard >>>>>=20 >>>>> On 12/18/11 5:38 PM, Fabio Fonseca wrote: >>>>>> Hello all, >>>>>>=20 >>>>>> I'm starting to develop my master thesis and this is my first = post to >>>>>> this >>>>>> forum. My research concerns the challenges of developing = Self-Adaptable >>>>>> software (software that can change its behavior in response to a = change >>>>>> in >>>>>> its operation context). Right now I'm doing an assessment aiming = to >>>>>> find >>>>>> which technologies are available today that could help achieving = a >>>>>> self-adaptable software. >>>>>>=20 >>>>>> I'm using Apache Felix + iPOJO to develop a simple test. I have a >>>>>> consumer >>>>>> which wants to consume providers that implement a interface named >>>>>> InterfaceOne. I have two providers that fits this requirement = (named >>>>>> ProviderA and ProviderB). They all do nothing useful, I am just = trying >>>>>> to >>>>>> produce a self-adaptable behavior. >>>>>>=20 >>>>>> I am using the launcher.jar which is provided with the code that = comes >>>>>> with >>>>>> the great book "OSGi in Action". This launcher creates an = instance of >>>>>> the >>>>>> Felix Framework and loads the bundles found in the bundles/ = directory >>>>>> passed >>>>>> as a parameter when running the launcher.jar. >>>>>>=20 >>>>>> So I have 4 bundles. Each one of them has an iPOJO component = inside it, >>>>>> except the first one that just has the InterfaceOne interface: >>>>>> . services-1.0.jar >>>>>> . consumer-1.0.jar >>>>>> . providerA-1.0.jar >>>>>> . providerB-1.0.jar >>>>>>=20 >>>>>> The consumer is a simple http listener that uses localhost port = 8080 to >>>>>> listen to anything that may appear. When something access the = port >>>>>> 8080, >>>>>> it >>>>>> calls the available provider. >>>>>>=20 >>>>>> When I start the launcher, all bundles are active and OSGi = chooses one >>>>>> of >>>>>> the providers and binds it to the consumer. Using the shell = commands >>>>>> I'm >>>>>> able to stop the providers' bundles and when I do it, the = consumer is >>>>>> invalidated (as per the iPOJO lifecycle). >>>>>>=20 >>>>>> I concluded that when I start the consumer bundle the available >>>>>> provider >>>>>> is >>>>>> bound to the consumer and it remains bound even when I stop its = bundle >>>>>> (in >>>>>> the OSGi lifecycle). The cenario is: >>>>>>=20 >>>>>> - start ProviderA >>>>>> - start Consumer (consumer starts since its dependency is = satisfied) >>>>>> - start ProviderB >>>>>> - stop ProviderA (consumer is still valid in the OSGI's = lifecycle, >>>>>> since >>>>>> there is a provider (ProviderB) that satisfy its dependency) >>>>>>=20 >>>>>> At this moment, if I call localhost:8080, the consumer uses = ProviderA, >>>>>> even >>>>>> when ProviderA is not available anymore. I conclude that the = binding >>>>>> between >>>>>> Consumer and its provider (which is in this case still the = ProviderA) >>>>>> continues to exist even when I stop ProviderA. I read somewhere = that >>>>>> iPOJO >>>>>> lifecycle takes over OSGi's lifecycle, but when I stop ProviderA, = the >>>>>> component becames Invalidated (I know because I placed a method = that is >>>>>> called when the provider is invalidated). So, even with the = provider >>>>>> Invalidated, it is still called. I also read somewhere that each >>>>>> component >>>>>> is implemented as a Singleton by default, and I have not changed = its >>>>>> behavior. So, I'm lost here. I expected that, in the above = cenario, >>>>>> ProviderB would be called instead of ProviderA. >>>>>>=20 >>>>>> Anyone has a clue that could help me understand how this = mechanism >>>>>> works? >>>>>> Attached you can find a file with all my source code and ant = tasks I'm >>>>>> using >>>>>> to play with iPOJO and OSGi. >>>>>>=20 >>>>>> http://old.nabble.com/file/p32999833/OIA%2BCode.zip OIA+Code.zip >>>>>>=20 >>>>>> Thanks a lot in advance! >>>>>> Fabio Fonseca >>>>> = --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org >>>>> For additional commands, e-mail: users-help@felix.apache.org >>>>>=20 >>>>>=20 >>>>>=20 >>> = --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org >>> For additional commands, e-mail: users-help@felix.apache.org >>>=20 >>>=20 >>>=20 >=20 > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@felix.apache.org > For additional commands, e-mail: users-help@felix.apache.org >=20 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@felix.apache.org For additional commands, e-mail: users-help@felix.apache.org