You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@karaf.apache.org by ra...@enjekt.org on 2019/02/04 20:38:27 UTC

Features install options...

 

I just created a features file with multiple feature targets in it for
database setup, netty server, rest services, etc. Then there's an "all"
feature that calls the others. It all works fine but it acts like it
collates or includes all the other features elements when I call the install
of "all". In other words, when I do an uninstall it does not show the other
sub-targets as having been installed. I actually have 3 questions.

 

1.	Is there a directive to tell Karaf to run the features installs
individually and not to lump them together?
2.	Is there any directive to tell Karaf to delete/remove any
configuration files it has installed when it uninstalls the feature
associate it with it?
3.	In the past I've used the plugin to install .cfg files from my
bundles and there is a directive override=true/false. Does anything like
that exist for the config done directly from the feature?

 

I certainly like the use of the config directive right from the feature as
it makes configuration from Maven a snap and thus lets Jenkins manage that.

 

Thanks,

Brad


Re: Features install options...

Posted by Ranx <ra...@enjekt.org>.
Christian,

Yes, good point. Even encrypted would be bad. But picking up an encrypted
password from the environment should work and let me put that in the
features for the environments.

I usually stay out of DevOps as much as possible but I'm in a situation at a
client where the previous group of developers really didn't have any idea
about what they were doing. The broke classloaders by duplicating schemas
and regenerating classes in different bundles which meant that identical
package/classes were incompatible because they came from different bundles.
Because they couldn't figure it out, the then converted everything to a
String before dumping it on JMS and then substring parsed stuff they pulled
off...I could go on.

Since they really didn't know anything about this (I believe they are
CSharpies), the created Windows batch scripts to set up all the environments
and scrape the cfg files. 

Now that I'm prototyping a Fuse 7 instance with Netty HTTP server as and
OSGi service (thanks Guillaume!) with Camel RESTful DSL, SCR connector
classes with OSGi services using PAX-JDBC, dozer converters to cannoical
models and features file to manage all of it, I'm trying to ensure that I
cut them off at the pass and we don't end up with 20 batch files to run to
install and configure it.

Most of it should be done by Jenkins at build time but security is an
exception. I usually stay out of this side of the equation but assume that
the password would be in the config something like this:

password=ENC(${env:ENCRYPTED_PASS})



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Features install options...

Posted by Christian Schneider <ch...@die-schneider.net>.
Be aware that the configs in features are normally only meant for default
configs.
You do not want your DB password to be in a feature xml that is deployed to
maven repo.

Christian

Am Di., 5. Feb. 2019 um 00:26 Uhr schrieb Ranx <ra...@enjekt.org>:

> One thing I realized as I was looking over the docs is that what I'm
> looking
> for is something like how the install="auto" works when you hot deploy a
> features file by dropping it in the deploy folder. I'm not really wanting
> to
> install anything that way but it would be nice if I could have some similar
> functionality when doing it via repo-add or a features command line. Just
> some way to make the features autoload but retain their identity so I can
> uninstall them if I wish.
>
>
>
>
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
>


-- 
-- 
Christian Schneider
http://www.liquid-reality.de

Computer Scientist
http://www.adobe.com

Re: Features install options...

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Agree,

thanks, I create the Jira and target for 4.2.4/4.3.0.RC1.

Regards
JB

On 05/02/2019 18:25, Ranx wrote:
> Thanks, it would be great if you created the Jira ticket.
> 
> I do understand that it's difficult for any of this to be automated from the
> perspective of Karaf unless one kept a tree of dependencies in memory with
> reference counting. That would end up with a mark and sweep like garbage
> collector and that could get very complex. But as you say, if I know that my
> config is used only by my current feature (pretty common) and should be
> uninstalled when that feature is uninstalled, then having an override to
> delete seems reasonable.
> 
> For backward compatibility, the default behavior would have to be what it is
> - do nothing. Only if a user explicitly overrides that behavior and tells it
> to delete the config would it actually do so.
> 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Features install options...

Posted by Ranx <ra...@enjekt.org>.
Thanks, it would be great if you created the Jira ticket.

I do understand that it's difficult for any of this to be automated from the
perspective of Karaf unless one kept a tree of dependencies in memory with
reference counting. That would end up with a mark and sweep like garbage
collector and that could get very complex. But as you say, if I know that my
config is used only by my current feature (pretty common) and should be
uninstalled when that feature is uninstalled, then having an override to
delete seems reasonable.

For backward compatibility, the default behavior would have to be what it is
- do nothing. Only if a user explicitly overrides that behavior and tells it
to delete the config would it actually do so.




--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Features install options...

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi,

You have an option to install all feature containing in a features repo
when you do repo-add.
At that step, we could use the "install" attribute on the feature to
install it or not.

Do you mind if I create the Jira (I think it's already partially done) ?

Regards
JB

On 05/02/2019 00:26, Ranx wrote:
> One thing I realized as I was looking over the docs is that what I'm looking
> for is something like how the install="auto" works when you hot deploy a
> features file by dropping it in the deploy folder. I'm not really wanting to
> install anything that way but it would be nice if I could have some similar
> functionality when doing it via repo-add or a features command line. Just
> some way to make the features autoload but retain their identity so I can
> uninstall them if I wish.
> 
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Features install options...

Posted by Ranx <ra...@enjekt.org>.
One thing I realized as I was looking over the docs is that what I'm looking
for is something like how the install="auto" works when you hot deploy a
features file by dropping it in the deploy folder. I'm not really wanting to
install anything that way but it would be nice if I could have some similar
functionality when doing it via repo-add or a features command line. Just
some way to make the features autoload but retain their identity so I can
uninstall them if I wish.




--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html

Re: Features install options...

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi Brad,

see my comments inline:

> 
>  1. Is there a directive to tell Karaf to run the features installs
>     individually and not to lump them together?

Why not splitting your feature in features, and then you can do 
feature:install ? I'm not sure I understand what you mean ;)

>  2. Is there any directive to tell Karaf to delete/remove any
>     configuration files it has installed when it uninstalls the feature
>     associate it with it?

Not currently (for "security" reason on the config). You can override 
the cfg files at install time.
I can create a Jira to add an option to cleanup file based on 
<configfile/> finalName.

>  3. In the past I’ve used the plugin to install .cfg files from my
>     bundles and there is a directive override=true/false. Does anything
>     like that exist for the config done directly from the feature?

I guess you mean <config/> element. No, <config/> element is for 
ConfigAdmin, it's created at feature install time.

Regards
JB

Re: Features install options...

Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Fair enough, I agree to add an option to cleanup the config/configfile
provisioned by the feature. It's a little bit hazardous, but if the user
provide the option, he knows what he does ;)

Mind if I create the Jira ?

These improvements can go in Karaf 4.3.x.

Regards
JB

On 04/02/2019 23:26, Ranx wrote:
> One item about uninstalling configuration files is when using PAX JDBC as an
> example. When I'm not using the database connection because I've uninstalled
> the feature(s) that use it, I would like the connection and OSGi service to
> go away. The configuration file shouldn't remain behind and potentially keep
> the connection alive.  
> 
> That's a quibble really. I guess I was just after some mechanism with the
> features that was more akin to manually typing feature:install foo that I
> was able to call from another feature.
> 
> 
> 
> --
> Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html
> 

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Features install options...

Posted by Ranx <ra...@enjekt.org>.
One item about uninstalling configuration files is when using PAX JDBC as an
example. When I'm not using the database connection because I've uninstalled
the feature(s) that use it, I would like the connection and OSGi service to
go away. The configuration file shouldn't remain behind and potentially keep
the connection alive.  

That's a quibble really. I guess I was just after some mechanism with the
features that was more akin to manually typing feature:install foo that I
was able to call from another feature.



--
Sent from: http://karaf.922171.n3.nabble.com/Karaf-User-f930749.html