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. >> >>
