I know it is published by the app-util component. I think this is wrong. I don't think you should get it unless you specifically get it. However I do see some value in the resolver. While it isn't as good as the OBR resolver if you have a simple .eba where everything is contained by value then the no-op resolver is all you need.
I don't see application servers like geronimo using it, but I do see it being used in simple unit test scenarios and therefore has value. Rather than delete the code I would move it into a separate bundle so we can choose to take it when it fits the bill. Alasdair On 20 September 2010 02:40, Emily Jiang <[email protected]> wrote: > 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 > > > > > > -- Alasdair Nottingham [email protected]
