Karaf
  1. Karaf
  2. KARAF-61

admin:create use the ${karaf.home}/etc configure files

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      Here is the discussion of this issue.

      1. FELIX2011.patch
        10 kB
        Willem Jiang

        Activity

        Hide
        Willem Jiang added a comment -

        Attached the patch to copy the configuration for $

        {karaf.home}

        /etc when using admin:create to create a new instance.

        Show
        Willem Jiang added a comment - Attached the patch to copy the configuration for $ {karaf.home} /etc when using admin:create to create a new instance.
        Hide
        Guillaume Nodet added a comment -

        Committing to https://svn.apache.org/repos/asf/felix/trunk ...
        M karaf/admin/core/src/main/java/org/apache/felix/karaf/admin/internal/AdminServiceImpl.java
        M karaf/admin/core/src/test/java/org/apache/felix/karaf/admin/internal/AdminServiceImplTest.java
        A karaf/admin/core/src/test/resources/etc/org.ops4j.pax.url.mvn.cfg
        A karaf/admin/core/src/test/resources/etc/system.properties
        Committed r904025

        Show
        Guillaume Nodet added a comment - Committing to https://svn.apache.org/repos/asf/felix/trunk ... M karaf/admin/core/src/main/java/org/apache/felix/karaf/admin/internal/AdminServiceImpl.java M karaf/admin/core/src/test/java/org/apache/felix/karaf/admin/internal/AdminServiceImplTest.java A karaf/admin/core/src/test/resources/etc/org.ops4j.pax.url.mvn.cfg A karaf/admin/core/src/test/resources/etc/system.properties Committed r904025
        Hide
        Guillaume Nodet added a comment -

        The current admin service is somewhat broken.
        The ssh port is not taken into account anymore as all the config files from the root instances are reused directly and the filtering is bypassed.

        Show
        Guillaume Nodet added a comment - The current admin service is somewhat broken. The ssh port is not taken into account anymore as all the config files from the root instances are reused directly and the filtering is bypassed.
        Hide
        Guillaume Nodet added a comment -

        Committing to https://svn.apache.org/repos/asf/felix/trunk ...
        D karaf/admin/core/src/test/resources/etc/org.ops4j.pax.url.mvn.cfg
        D karaf/admin/core/src/test/resources/etc/system.properties
        M karaf/admin/core/src/main/java/org/apache/felix/karaf/admin/internal/AdminServiceImpl.java
        M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/karaf
        M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/karaf.bat
        M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/start
        M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/start.bat
        M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/stop
        M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/stop.bat
        M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/etc/org.apache.felix.karaf.shell.cfg
        M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/etc/org.ops4j.pax.url.mvn.cfg
        M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/etc/system.properties
        M karaf/admin/core/src/test/java/org/apache/felix/karaf/admin/internal/AdminServiceImplTest.java
        Committed r906932

        Need to bring back a fix for this. The above commit reverts r904025 and fixes FELIX-2032

        Show
        Guillaume Nodet added a comment - Committing to https://svn.apache.org/repos/asf/felix/trunk ... D karaf/admin/core/src/test/resources/etc/org.ops4j.pax.url.mvn.cfg D karaf/admin/core/src/test/resources/etc/system.properties M karaf/admin/core/src/main/java/org/apache/felix/karaf/admin/internal/AdminServiceImpl.java M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/karaf M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/karaf.bat M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/start M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/start.bat M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/stop M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/bin/stop.bat M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/etc/org.apache.felix.karaf.shell.cfg M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/etc/org.ops4j.pax.url.mvn.cfg M karaf/admin/core/src/main/resources/org/apache/felix/karaf/admin/etc/system.properties M karaf/admin/core/src/test/java/org/apache/felix/karaf/admin/internal/AdminServiceImplTest.java Committed r906932 Need to bring back a fix for this. The above commit reverts r904025 and fixes FELIX-2032
        Hide
        Willem Jiang added a comment -

        Hi Guilaume,

        I think we can just let karaf copy the config files such as "etc/config.properties", "etc/org.ops4j.pax.url.mvn.cfg", which can be shared between the main and new forked instance from the $

        {karaf.home}

        /etc.

        Any idea?

        Show
        Willem Jiang added a comment - Hi Guilaume, I think we can just let karaf copy the config files such as "etc/config.properties", "etc/org.ops4j.pax.url.mvn.cfg", which can be shared between the main and new forked instance from the $ {karaf.home} /etc. Any idea?
        Hide
        Charles Moulliard added a comment -

        ServiceMix4 requires also additional files like :

        activemq-broker.xml,
        org.apache.servicemix.jbi.cfg,
        org.apache.servicemix.jbi.cfg,
        org.apache.servicemix.transaction.cfg

        in etc folder

        Don't forget to copy them too if they exist !

        Show
        Charles Moulliard added a comment - ServiceMix4 requires also additional files like : activemq-broker.xml, org.apache.servicemix.jbi.cfg, org.apache.servicemix.jbi.cfg, org.apache.servicemix.transaction.cfg in etc folder Don't forget to copy them too if they exist !
        Hide
        Willem Jiang added a comment -

        Charles,

        Current Karaf Admin command doesn't know these file which are extension files of SMX,
        Maybe we need to introduce a copy script to deal with these config files.
        And SMX can override this script from assembly module.

        Show
        Willem Jiang added a comment - Charles, Current Karaf Admin command doesn't know these file which are extension files of SMX, Maybe we need to introduce a copy script to deal with these config files. And SMX can override this script from assembly module.
        Hide
        Willem Jiang added a comment -

        I'm planing to add a file which hold the list of the configuration files which need to be copied from the etc directory.
        NMR or SMX can override it by adding some additional configuration files entry.

        Any thought?

        Show
        Willem Jiang added a comment - I'm planing to add a file which hold the list of the configuration files which need to be copied from the etc directory. NMR or SMX can override it by adding some additional configuration files entry. Any thought?
        Hide
        Charles Moulliard added a comment -

        Hi Willem,

        I think that this is a better idea to copy all the files of the etc folder from master to slave beacause the project can host in this folder property file for camel/jbi endpoints, datasource ref, ...

        Show
        Charles Moulliard added a comment - Hi Willem, I think that this is a better idea to copy all the files of the etc folder from master to slave beacause the project can host in this folder property file for camel/jbi endpoints, datasource ref, ...
        Hide
        Guillaume Nodet added a comment -

        What about leaving the command with the current default behavior (i.e. plain bare karaf) and add an option to clone an existing installation. The source could be either the root instance or a previously created instance ...
        The key point is that the command need to override a few parameters such as karaf.base, karaf.home, karaf.name, sshPort and such ...

        Show
        Guillaume Nodet added a comment - What about leaving the command with the current default behavior (i.e. plain bare karaf) and add an option to clone an existing installation. The source could be either the root instance or a previously created instance ... The key point is that the command need to override a few parameters such as karaf.base, karaf.home, karaf.name, sshPort and such ...
        Hide
        Willem Jiang added a comment -

        Hi Guillaume

        Just as you said , if you want to clone the instance with admin:create, we need to make sure the karaf knows which file should be copied and which property should be override. So I think we still need a file which can tell karaf about these information.

        Show
        Willem Jiang added a comment - Hi Guillaume Just as you said , if you want to clone the instance with admin:create, we need to make sure the karaf knows which file should be copied and which property should be override. So I think we still need a file which can tell karaf about these information.
        Hide
        Guillaume Nodet added a comment -

        The list of overrides is deternined by the code, so that's not a big problem i think.
        For the list of files to copy, I think Charles made a good point that the user could have copy his own config files to the etc/ folder. We may even want to consider copying the deploy folder and do even more things.
        I guess the point is to agree what the outcome of this command should be. I see three possibilities:

        • create a new bare karaf
        • create a new configured instance (such as a new servicemix), that could include only known config fles
        • create a clone of an existing instance (which would also include the deploy folder and try to go as far as possible in cloning the existing instance

        What you were talking about is more the second thing, while Charles (as a user) is considering the third one.
        It may appear that a different strategy is required in order to implement the second and third methods. The last one may be better implemented with a full copy of the instance (including the cache of the osgi framework maybe).

        Show
        Guillaume Nodet added a comment - The list of overrides is deternined by the code, so that's not a big problem i think. For the list of files to copy, I think Charles made a good point that the user could have copy his own config files to the etc/ folder. We may even want to consider copying the deploy folder and do even more things. I guess the point is to agree what the outcome of this command should be. I see three possibilities: create a new bare karaf create a new configured instance (such as a new servicemix), that could include only known config fles create a clone of an existing instance (which would also include the deploy folder and try to go as far as possible in cloning the existing instance What you were talking about is more the second thing, while Charles (as a user) is considering the third one. It may appear that a different strategy is required in order to implement the second and third methods. The last one may be better implemented with a full copy of the instance (including the cache of the osgi framework maybe).
        Hide
        Willem Jiang added a comment -

        Hi Guillaume,
        Here is my use case which the bare karaf can't meet my needs.
        By using the karaf admin API, I can create the karaf instance as I want.
        Now I'm just wanting to let the new bare karaf instance to pick up the osgi kernal (equinox).
        Without copying the config.properties from the $

        {karaf.home}

        /etc, I don't find a easy way to override the default karaf etc.

        As my old patch will introduce some conflicts on the resource which can't be shared between the karaf instances, maybe we just need to make sure these resources will be create as newer one instead of the copying one.

        Show
        Willem Jiang added a comment - Hi Guillaume, Here is my use case which the bare karaf can't meet my needs. By using the karaf admin API, I can create the karaf instance as I want. Now I'm just wanting to let the new bare karaf instance to pick up the osgi kernal (equinox). Without copying the config.properties from the $ {karaf.home} /etc, I don't find a easy way to override the default karaf etc. As my old patch will introduce some conflicts on the resource which can't be shared between the karaf instances, maybe we just need to make sure these resources will be create as newer one instead of the copying one.
        Hide
        Guillaume Nodet added a comment -

        Willem,
        I agree with your pov. I think the command should do the following:

        • find a list of files to generate from the new instance
        • if the file exists in the source instance (we should be able to specifiy which one if possible instead of always using the root one, though root would be the default), use it else use the one from the bundle
        • always filter resources, but use a different strategy for filtering. Instead of using a keyword based filtering, use a key-value pair list and each time the file copied contains the property, override the value with the new value. But I think we need to preserve the look and order of the lines in those config files, so we can't really use the Property object to load/store those. Gert did the same thing for the new dev:framework, so we should make that a reusable class.

        This would leave the third thing (which is to clone an existing instance instead of creating a new one based on an existing instance) to a later version, but I think this is not too much of a problem.

        What do you think ?

        Show
        Guillaume Nodet added a comment - Willem, I agree with your pov. I think the command should do the following: find a list of files to generate from the new instance if the file exists in the source instance (we should be able to specifiy which one if possible instead of always using the root one, though root would be the default), use it else use the one from the bundle always filter resources, but use a different strategy for filtering. Instead of using a keyword based filtering, use a key-value pair list and each time the file copied contains the property, override the value with the new value. But I think we need to preserve the look and order of the lines in those config files, so we can't really use the Property object to load/store those. Gert did the same thing for the new dev:framework, so we should make that a reusable class. This would leave the third thing (which is to clone an existing instance instead of creating a new one based on an existing instance) to a later version, but I think this is not too much of a problem. What do you think ?
        Hide
        Willem Jiang added a comment -

        +1 for filtering the resources.
        Guillaume, can you point me the code that Gert is working ?

        Show
        Willem Jiang added a comment - +1 for filtering the resources. Guillaume, can you point me the code that Gert is working ?
        Hide
        Guillaume Nodet added a comment -

        See the methods in the following class
        http://svn.apache.org/repos/asf/felix/trunk/karaf/shell/dev/src/main/java/org/apache/felix/karaf/shell/dev/framework/Framework.java

        Looking at the code, I think it could be problematic in some cases where the property definition is split across several lines using backslashes ...

        Show
        Guillaume Nodet added a comment - See the methods in the following class http://svn.apache.org/repos/asf/felix/trunk/karaf/shell/dev/src/main/java/org/apache/felix/karaf/shell/dev/framework/Framework.java Looking at the code, I think it could be problematic in some cases where the property definition is split across several lines using backslashes ...

          People

          • Assignee:
            Unassigned
            Reporter:
            Willem Jiang
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development