On Wed, Aug 18, 2010 at 1:38 PM, Justin Edelson <justinedel...@gmail.com> wrote:
> I fixed the ConfigInstallTest failure in the osgi.it module. Not sure if
> this is the one which has been "failing for a long time".
>
> The problem is in the waitForConfiguration method of OsgiInstallerTestBase.
>
> The logic was:
> if (result != null ||!shouldBePresent) {
> break;
> }
>
> but this fails to take into account when we want result to be null. As
> such, the sleep was never happening.
>
> After this fix, I did get another test failure due to an
> IllegalStateException. It seems that this happens if a Configuration is
> deleted between the time ConfigurationAdmin.listConfigurations(null) and
> cfg.getPid() are called (in the findConfiguration method). I think the
> only way to avoid this is to increase the sleep time between
> configuration checks from 25 ms to 250 ms.
I went another way and am catching the IllegalStateException.
>
> Carsten - what's the other IT you see fail consistently?
Is it RemovedResourceDetectionTest? I saw that fail twice now, but
haven't been able to reproduce it either while debugging or with
pax.exam.log.level=DEBUG.
Still, I added some more logging into the even waiting code to see if
this might help trap the problem.
Justin
>
> Justin
>
> On 8/18/10 8:34 AM, Carsten Ziegeler wrote:
>> Felix Meschberger wrote
>>>
>>> I am not particularly keen on putting too much effort into something
>>> which will be thrown almost immediately.
>>>
>>> Rather I would suggest for Carsten to indicate whether he will succeed
>>> in-time for Sling 6 or whether we can be of any help to him getting this
>>> ready for Sling 6.
>> I think I changed/removed/refactored quiet a lot now and I'm nearly at
>> the point of starting to add missing features and looking for long
>> outstanding bugs/problems.
>>
>> We now have a cleaner api which is nearly ready for a new release.
>>
>> At the moment some test cases are failing in the jcrinstaller (this
>> seems to be caused by upgrading to the latest sling testing module with
>> JCR 2.0 included) and two test cases in the IT module (one of them is
>> failing for a long time, even before my changes, the other one is new).
>>
>> In addition as I refactored the IT tests, there are now some things
>> untested like if the installer is idle after it has done the tasks it
>> should do. This should be done as junit tests inside the installer module.
>>
>> So in short, any help in getting the tests fixed and new tests is really
>> appreciated. I hope to start on the new stuff soon.
>>
>> Regards
>> Carsten
>>
>>>
>>>>
>>>> But before we can do this, I apparently need to convince everyone of two
>>>> things:
>>>>
>>>> 1) There is no harm in doing all of our "should I install/upgrade this
>>>> bundle" checks on every startup of launchpad.
>>>
>>> I can live with that. In fact, IIRC JCR Install already does this on
>>> every bundle reastart.
>>>
>>>>
>>>> 2) There is no harm in installing/upgrading bundles directly from
>>>> (Launchpad) ResourceProvider.
>>>
>>> We had this before we started copying bundles into the startup folder.
>>> So this is perfectly ok for me -- provided we still support the startup
>>> folder for extra deployment (as used by Sakai IIRC).
>>>
>>>>
>>>> If we can agree on these, the implementation of bundle installation
>>>> within launchpad.installer will be a lot simpler.
>>>>
>>>>>
>>>>> Regarding the name: Yes, the ResourceProvider in the launchpad/base is
>>>>> older than the ResourceProvider in the Resource API. But, this older
>>>>> ResourceProvider has always been an internal API of the launchpad/base
>>>>> module thus renaming it to prevent the name collision is a good idea.
>>>>>
>>>>> Maybe something "intelligent" as LaunchpadResourceAccessor ;-)
>>>>> Honestly, I am not sooo good at finding good names....
>>>> My initial suggestion was going to be "LaunchpadContentProvider", which
>>>> I dismissed because I didn't think Launchpad belonged in the name...
>>>
>>> On the other hand, the content or resources is/are really provided form
>>> inside the launchpad package (either the standalone jar or the web
>>> application or even the launchpad plugin).
>>>
>>> I could live well with LaunchpadContentProvider.
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>> Justin
>>>>
>>>>>
>>>>> Regards
>>>>> Felix
>>>>>
>>>>> On 8/17/10, Justin Edelson <justinedel...@gmail.com> wrote:
>>>>>> As I mentioned last week, I had some concerns about using FileInstall
>>>>>> for ConfigAdmin support and, more than concerns about FileInstall in
>>>>>> particular, I didn't like the whole approach within Launchpad of
>>>>>> "copying some files out of the JAR/WAR" and didn't want to see us
>>>>>> continue this pattern.
>>>>>>
>>>>>> I worked out a solution to this today and I'm pretty happy with it.
>>>>>>
>>>>>> In short... Launchpad exposes a service which allows bundles/services
>>>>>> within the framework to access the contents of the launchpad archive (or
>>>>>> project, in the case of the maven-launchpad-plugin) as a virtual file
>>>>>> system.
>>>>>>
>>>>>> It is then trivial to create a component which uses this service to
>>>>>> access configuration files and install them via osgi.installer.
>>>>>>
>>>>>> The specific steps involved were:
>>>>>> 1) Creating a new launchpad.api bundle which contains the
>>>>>> ResourceProvider interface [1]
>>>>>>
>>>>>> 2) Modifying launchpad.base to use the new ResourceProvider interface,
>>>>>> add it to the list of system packages, and register the service.
>>>>>>
>>>>>> 3) Modifying maven-launchpad-plugin to use the new ResourceProvider
>>>>>> interface.
>>>>>>
>>>>>> 4) Creating a new launchpad.installer bundle which contains a Component
>>>>>> referring to the ResourceProvider service and osgi.installer.
>>>>>>
>>>>>> The patch can be viewed here: [2]. It looks much bigger than it is due
>>>>>> to all of the internal changes within launchpad.base. There are also two
>>>>>> minor changes in osgi.installer which I think should probably be made
>>>>>> regardless.
>>>>>>
>>>>>> This patch includes a sample cfg file in both launchpad/builder and
>>>>>> launchpad/testing. This was done so I could ensure that it worked in
>>>>>> war, jar, and launchpad:run scenarios. There needs to be some kind of
>>>>>> automated test.
>>>>>>
>>>>>> Note that in order for this to work properly [3], I had to introduce
>>>>>> osgi.installer into the main pom. I'd like to get rid of the separate
>>>>>> reactor for installer entirely, but there are still some integration
>>>>>> test failures in osgi/it and it looks like Carsten is still working on
>>>>>> this module. In any case, going down this path means that osgi.installer
>>>>>> will need to be part of Sling 6 (if we want ConfigAdmin to be part of
>>>>>> Sling 6, of course).
>>>>>>
>>>>>> Justin
>>>>>>
>>>>>> [1] Because ResourceProvider was already used within launchpad.base for
>>>>>> this purpose, I used that name, although it's a bit odd that we have two
>>>>>> different service interfaces named ResourceProvider. Suggestions for
>>>>>> alternate names welcome :)
>>>>>>
>>>>>> [2] http://codereview.appspot.com/1953045/
>>>>>>
>>>>>> [3] This is only 50% true.
>>>>>>
>>>>
>>>>
>>>
>>
>>
>
>
