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.
Carsten - what's the other IT you see fail consistently?
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.
>>>>>
>>>
>>>
>>
>
>
