You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by to...@quarendon.net on 2019/03/13 13:50:01 UTC
Replacing or blacklisting felix fileinstall
I'm trying to experiment with an alternative way of loading up configuration. So my goal is to disable felix fileinstall and provide an alternative implementation of the org.apache.felix.cm.PersistenceManager interface.
However, so far I'm having great difficulty either blacklisting fileinstall or replacing it.
in etc/org.apache.karaf.features.xml I have tried:
<blacklistedBundles>
<bundle>mvn:org.apache.felix/org.apache.felix.fileinstall</bundle>
</blacklistedBundles>
However I can't get this to have any effect. I have traced through with a debugger, and the LocationPattern.matches method is returning true, and it appears to be doing the right thing at that level, but the bundle still starts. I can't see any log messages that might be relevant.
I also tried using <bundleReplacements> in that file too. I had slight success -- I can use:
<bundleReplacements>
<bundle
originalUri="mvn:org.apache.felix/org.apache.felix.fileinstall"
replacement="mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.5-SNAPSHOT"/>
</bundleReplacements>
and can compile my own version of fileinstall 3.6.5 and I can see that it's being loaded in.
I say can. I could. I did that this morning, though I seem unable to reproduce that now, I'm getting both versions of the bundle now. Anyway, I struggled to change the group and artifact to something else (wasn't changing any code, I was just changing the pom to change the maven coordinates it was building to and then trying to reference that in the replacement url). But as soon as I did that it went back to loading the original.
Anyone got a recipe for providing an alternative implementation of file install?
Thanks.
Re: Replacing or blacklisting felix fileinstall
Posted by to...@quarendon.net.
> I'm working on a Karaf Configuration persistence layer to "abstract"
> fileinstall, (especially to deal with encryption, AWS keys, etc). It
> will help you to implement your own backend.
That will be awesome. Any targeted release date?
Thanks.
Re: Replacing or blacklisting felix fileinstall
Posted by to...@quarendon.net.
> You have to create a custom framework features that you use at
> startupFeature instead of the "standard" karaf feature.
OK I see. I've been reluctant to do this in the past as I have to make sure to track changes that occur in the versions of the "normal" one. But it sounds like the simplest solution here.
Re: Replacing or blacklisting felix fileinstall
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
You have to create a custom framework features that you use at
startupFeature instead of the "standard" karaf feature.
I'm working on a Karaf Configuration persistence layer to "abstract"
fileinstall, (especially to deal with encryption, AWS keys, etc). It
will help you to implement your own backend.
Regards
JB
On 13/03/2019 18:12, tom@quarendon.net wrote:
>> You should remove fileinstall from etc/startup.properties to remove it.
>
> So how would I do that from a maven build? We're using the karaf maven plugin, so the startup.properties file gets generated automagically. I'm guessing I'd have to either put a version of it in my filtered_resources/etc or unfiltered_resources/etc direct and hope that overwrites, or put a post process step in to remove the line?
>
> Anyway. That gives me a method of experimentation which is good. I'll probably worry about how to do it properly if I can get my preferred solution working otherwise.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Replacing or blacklisting felix fileinstall
Posted by to...@quarendon.net.
> You should remove fileinstall from etc/startup.properties to remove it.
So how would I do that from a maven build? We're using the karaf maven plugin, so the startup.properties file gets generated automagically. I'm guessing I'd have to either put a version of it in my filtered_resources/etc or unfiltered_resources/etc direct and hope that overwrites, or put a post process step in to remove the line?
Anyway. That gives me a method of experimentation which is good. I'll probably worry about how to do it properly if I can get my preferred solution working otherwise.
Re: Replacing or blacklisting felix fileinstall
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,
that's normal as fileinstall is loaded BEFORE the feature service.
You should remove fileinstall from etc/startup.properties to remove it.
Regards
JB
On 13/03/2019 14:50, tom@quarendon.net wrote:
> I'm trying to experiment with an alternative way of loading up configuration. So my goal is to disable felix fileinstall and provide an alternative implementation of the org.apache.felix.cm.PersistenceManager interface.
>
> However, so far I'm having great difficulty either blacklisting fileinstall or replacing it.
>
> in etc/org.apache.karaf.features.xml I have tried:
>
> <blacklistedBundles>
> <bundle>mvn:org.apache.felix/org.apache.felix.fileinstall</bundle>
> </blacklistedBundles>
>
> However I can't get this to have any effect. I have traced through with a debugger, and the LocationPattern.matches method is returning true, and it appears to be doing the right thing at that level, but the bundle still starts. I can't see any log messages that might be relevant.
>
> I also tried using <bundleReplacements> in that file too. I had slight success -- I can use:
> <bundleReplacements>
> <bundle
> originalUri="mvn:org.apache.felix/org.apache.felix.fileinstall"
> replacement="mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.5-SNAPSHOT"/>
> </bundleReplacements>
>
> and can compile my own version of fileinstall 3.6.5 and I can see that it's being loaded in.
>
> I say can. I could. I did that this morning, though I seem unable to reproduce that now, I'm getting both versions of the bundle now. Anyway, I struggled to change the group and artifact to something else (wasn't changing any code, I was just changing the pom to change the maven coordinates it was building to and then trying to reference that in the replacement url). But as soon as I did that it went back to loading the original.
>
> Anyone got a recipe for providing an alternative implementation of file install?
>
> Thanks.
>
--
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Replacing or blacklisting felix fileinstall
Posted by to...@quarendon.net.
> I've implemented a SQL mechanism for persisting configurations. I started
> by trying to implement a custom persistence mechanism for Felix CM. This
> didn't work (see
> http://karaf.922171.n3.nabble.com/Custom-PersistenceManager-configurations-not-instantiating-components-td4052786.html#a4052799
> ).
>
> What I ended up doing was having a component which just interacted with
> Configuration Admin (creating configurations at startup; updating the
> database when modifications occur; deleting configurations at shutdown).
> File install is still running - it creates files when my component creates
> configurations, and updates & deletes them as necessary.
>
> The only downside I've found is the factory configurations get a new PID
> every time Karaf starts (as you can't specify the pid for a new factory
> configuration - though I understand this is possible in new versions of
> Config Admin).
That's the kind of thing I want to do. I have had success with a custom PersistenceManager before, but fileinstall got in the way, and there was a change in behaviour at some point that affected things (this is going back a year or so).
So my first aim is to get fileinstall out of the way and put a simpler component in that will just statically load the config from the .cfg files in etc. Then I'll play with trying to save any dynamic changes.
Thanks. Good to know that someone's had at least some kind of success with this sort of thing.
Re: Replacing or blacklisting felix fileinstall
Posted by Paul McCulloch <pk...@gmail.com>.
I've implemented a SQL mechanism for persisting configurations. I started
by trying to implement a custom persistence mechanism for Felix CM. This
didn't work (see
http://karaf.922171.n3.nabble.com/Custom-PersistenceManager-configurations-not-instantiating-components-td4052786.html#a4052799
).
What I ended up doing was having a component which just interacted with
Configuration Admin (creating configurations at startup; updating the
database when modifications occur; deleting configurations at shutdown).
File install is still running - it creates files when my component creates
configurations, and updates & deletes them as necessary.
The only downside I've found is the factory configurations get a new PID
every time Karaf starts (as you can't specify the pid for a new factory
configuration - though I understand this is possible in new versions of
Config Admin).
Paul
On Wed, 13 Mar 2019 at 13:50, <to...@quarendon.net> wrote:
> I'm trying to experiment with an alternative way of loading up
> configuration. So my goal is to disable felix fileinstall and provide an
> alternative implementation of the org.apache.felix.cm.PersistenceManager
> interface.
>
> However, so far I'm having great difficulty either blacklisting
> fileinstall or replacing it.
>
> in etc/org.apache.karaf.features.xml I have tried:
>
> <blacklistedBundles>
> <bundle>mvn:org.apache.felix/org.apache.felix.fileinstall</bundle>
> </blacklistedBundles>
>
> However I can't get this to have any effect. I have traced through with a
> debugger, and the LocationPattern.matches method is returning true, and it
> appears to be doing the right thing at that level, but the bundle still
> starts. I can't see any log messages that might be relevant.
>
> I also tried using <bundleReplacements> in that file too. I had slight
> success -- I can use:
> <bundleReplacements>
> <bundle
> originalUri="mvn:org.apache.felix/org.apache.felix.fileinstall"
>
> replacement="mvn:org.apache.felix/org.apache.felix.fileinstall/3.6.5-SNAPSHOT"/>
> </bundleReplacements>
>
> and can compile my own version of fileinstall 3.6.5 and I can see that
> it's being loaded in.
>
> I say can. I could. I did that this morning, though I seem unable to
> reproduce that now, I'm getting both versions of the bundle now. Anyway, I
> struggled to change the group and artifact to something else (wasn't
> changing any code, I was just changing the pom to change the maven
> coordinates it was building to and then trying to reference that in the
> replacement url). But as soon as I did that it went back to loading the
> original.
>
> Anyone got a recipe for providing an alternative implementation of file
> install?
>
> Thanks.
>