Hi,
On 17.08.2010 21:51, Justin Edelson wrote:
> On 8/17/10 4:20 PM, Felix Meschberger wrote:
>> Hi,
>>
>> Sounds like an interesting approach, too.
>>
>> I would really like to include the OSGi Install stuff together with
>> this "ResourceProvider" and the new File Installer to be included with
>> Sling 6. If we go the route as Justin proposed, we would probably have
>> to include File Installer configured to the ${sling.home}/startup
>> location to support existing use cases depending on the startup folder
>> being used to install bundles.
> What is this "new File Installer" of which you speak? Is this Felix's
> FileInstall or extracting BootstrapInstaller from launchpad.base and
> into this new launchpad.installer bundle (or something else).
This is a new functionality built by Carsten in his efforts to support
configurations in the launchpad. The idea is to scan one or more
directories handing over found data to OSGi Install. As such it is the
Filesystem based counter-part to the JCR Install bundle and your
"Launchpad Resource" support.
>
> I was thinking about this some more, and if getting osgi.installer ready
> for Sling 6 is really a problem, perhaps launchpad.installer can simply
> include a limited subset of functionality. So much of osgi.installer
> seems to be about keeping resource lists and monitoring them whereas all
> launchpad.installer needs is to do this for configs (plus some extra
> code for handling factory pids):
>
> String pid = createPid(path)
> Dictionary dict = parseDictionary(stream);
>
> if (!configExists(pid)) {
> createConfig(pid, dict)
> }
>
> And for bundles, we already have all the code we need in
> BootstrapInstaller, so moving that logic into a separate bundle should
> be straight forward enough.
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.
>
> 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.
>>>
>
>
