The deployer is unrelated to so called "features" in karaf.
The karaf deployer consists in filemonitor / fileinstall + a set of
custom transformers.
The transformer interface is defined in the filemonitor:
http://svn.apache.org/repos/asf/felix/trunk/karaf/deployer/filemonitor/src/main/java/org/apache/felix/karaf/deployer/filemonitor/DeploymentListener.java
It's role is solely to transform something dropped into one of the
monitored folder into an OSGi bundle. This is used to deploy war
files (through pax-web), spring xml config files, etc...
As I said, it's really unrelated to "application" deployment handled
using features. Actually, there is also a feature deployer that can
handle a feature descriptor copied into the deploy folder and will
install the listed features, but again, this is done through an
implementation of the above interface registered in the OSGi registry,
so not tied to the deployer itself.
I do agree this would be a bad idea to put the "features" support into
the fileinstall, but that's not what I was talking about here.
On Tue, Jun 16, 2009 at 10:08, Glyn Normington<[email protected]> wrote:
> I'm a little concerned about positioning deployer function below file
> install.
>
> There are clearly many single bundle application scenarios where this makes
> a lot of sense. But if you consider applications consisting of multiple
> bundles where the deployer needs to perform certain operations on the whole
> set of bundles, things get a bit tricky since the result of that install
> operation is presumably limited to be a single Bundle.
>
> Also isn't it likely that the Karaf deployer will evolve at a faster rate
> than the Felix OSGi framework and possibly even spawn multiple variants?
>
> So should the Karaf deployer should be integrated tightly in to file install
> or enabled to plug in via an extension mechanism so that it can logically
> sit on top of file install and perhaps more easily cope with multiple bundle
> operations and evolve faster?
>
> Glyn
>
> On 15 Jun 2009, at 15:31, Richard S. Hall wrote:
>
>> I think this sounds reasonable as long as it keeps the basic simple
>> functionality in tact by default and the implementation remains simple
>> overall, since that was the original goal, as mentioned by Sahoo and
>> Filippo.
>>
>> It doesn't sound like the added features add too much complexity and could
>> also be made optional where appropriate. So, that sounds good.
>>
>> The original idea for FELIX-922 (supporting different types of files) was
>> to create something really lightweight, such as a simple handler service
>> interface which the core could retrieve from the service registry and other
>> bundles could implement. It sounds like this is what has been done, so that
>> seems good too.
>>
>> Also as mentioned, merging might be more difficult, since the code bases
>> have changed, but merging features sounds possible.
>>
>> I had also wondered about supporting start levels. My original thought
>> there was to create numbered subdirectories that correspond to the start
>> level for the contained bundles; however, that might be problematic with
>> exploded bundle support...something to think about.
>>
>> -> richard
>>
>> On 6/15/09 4:45 AM, Guillaume Nodet wrote:
>>>
>>> I'd like to start discussing how we can merge karaf deployer and felix
>>> fileinstall.
>>> Note that karaf deployer is originally based on the same code base but
>>> has since evolved.
>>> Here are a list of the main features we've added to the karaf deployer
>>> over time:
>>> * use the preference service (if available) to store the status of
>>> the deployer
>>> thus the last update time for each tracked object is stored and
>>> at restart the deployer
>>> is able to detect changed files
>>> * ability to handle exploded bundles
>>> * ability to transform artifacts on the fly (wars, spring config
>>> files, blueprint config files, etc...) through OSGi services
>>> this issue has been raised in FELIX-922
>>>
>>> I know some of you wants to keep file install minimalistic, so I'd be
>>> fine keeping both versions around if that's the outcome of the
>>> discussion, but I think we need to have this discussion at some point.
>>> Note that the karaf deployer is only 35k whereas fileinstall is 32k
>>> ... so I guess we need to define what minimalistic / lightweight /
>>> (whatever adjective you want) is ...
>>>
>>>
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
