I think I identified the JCRInstall problem. See
https://issues.apache.org/jira/browse/JCR-2720
Working around this in the test shouldn't be hard, but it's a nasty bug.
Justin
On Wed, Aug 18, 2010 at 2:35 PM, Justin Edelson <justinedel...@gmail.com> wrote:
> 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.
>>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>>
>
