Hi Alasdair, Thanks for your notes. The no-op resolver service was published by the project of org.apache.aries.application.utils. I cannot quite see how in the real situation, it can make real Aries application resolver picks up the resolving job instead of the no-op resolver before the obr resolver bundle was started. Besides it is a bit sticky to explain to the users not to start one particular bundle before the other bundle has started.
It is true that from now on, we force people to use OBR resolver. Personally, I think it is good that once an Aries Application is resolved, we can guarantee it will be started. I am not quite sure whether it is wise to install an Aries Application by using no-op resolver, which is incorrect (just return the application contained bundles, unable to pull in any dependencies, ignore what application.mf states). When an Aries Application cannot be started, there won't be quite nice explanation than our obr resolver's resolver Exception error message:). Regards, Emily From: Alasdair Nottingham <[email protected]> To: "[email protected]" <[email protected]> Date: 19/09/2010 23:14 Subject: Re: [jira] Commented: (ARIES-410) Application itests fail intermittently Sent by: Alasdair Nottingham <[email protected]> Emily, by removing the no op resolved you now force people to use OBR to install an application, while it is good for people to use OBR it does raise the bar. I vote to keep the no op resolver and find another solution, perhaps we should break the no op resolver out into it's own bundle? Alasdair On 19 Sep 2010, at 12:04, Bartosz Kowalewski <[email protected]> wrote: > Hi Emily, > > As I said, I didn't analyze latest resolver related failures, so I might be wrong. However, I far as I remember the fix under Aries-327 introduced a mechanism that delayed startup of the runtime bundle until OBR resolver bundle turned to active state. This was to ensure that a proper service is referenced by the runtime bundle. > > I fully agree that if NoOpResolver is not needed anymore, removing it is the simplest way to get rid of all those intermittent failures. Mechanisms introduced in Aries-327 are no longer needed. > I was just a little bit suprised that NoOpResolver is no longer needed. I thought that the reason it was kept in the source repository was that it was helpful when there was a need to do debugging or disable OBR temporarily. It seems that this is no longer true :-). > > Best regards, > Bartek > > Emily Jiang wrote the following on 9/17/2010 5:56 PM: >> Hi Bartek, >> >> Thanks for your notes. I had a look at the fix under Aries-327. I believe the fix is temporary, as I did see the same failure recently. The fix is trying to make the real Aries Resolver to do the real work by blocking the no-op resolver. As you know, in the real customer application installation, the no-op resolver can come to do all the resolving before the Aries Resolver speeds up. I believe the ultimate fix is to get rid of the no-op resolver. >> Many thanks and kindest regards, >> Emily >> =========================== >> Emily Jiang >> WebSphere ESB Foundation Technologies >> >> MP 211, DE3A25, Winchester, Hampshire, England, SO21 2JN >> Phone: +44 (0)1962 816278 Internal: 246278 >> >> Email: [email protected] Lotus Notes: Emily Jiang/UK/i...@ibmgb >> >> >> >> >> From: "Bartosz Kowalewski (JIRA)" <[email protected]> >> To: [email protected] >> Date: 17/09/2010 13:48 >> Subject: [jira] Commented: (ARIES-410) Application itests fail intermittently >> >> >> >> >> [ https://issues.apache.org/jira/browse/ARIES-410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12910553#action_12910553 ] >> Bartosz Kowalewski commented on ARIES-410: >> ------------------------------------------ >> >> Hi Emily, >> >> I haven't had time to take an in-depth look at the issue tha you're dealing with now (I don't know which test cases are affected). Hower, I worked on a similar issue some time ago. This issue was caused by no-op resolver being picked up instead of obr resolver in the OBRResolverTest test. This was fixed (as far as I remember :)). For details seee: ARIES-327 >> >> Best regards, >> Bartek >> >> >>> Application itests fail intermittently >>> -------------------------------------- >>> >>> Key: ARIES-410 >>> URL: https://issues.apache.org/jira/browse/ARIES-410 >>> Project: Aries >>> Issue Type: Bug >>> Components: Application >>> Reporter: Emily Jiang >>> Assignee: Emily Jiang >>> >>> The application itests fail intermittently. >> >> Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
