[jira] [Issue Comment Edited] (KARAF-1476) cellar broadcasts configuration changes to a group that has been left before ...

["Jürgen Kindler (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274696#comment-13274696 ] 

Jürgen Kindler edited comment on KARAF-1476 at 5/14/12 4:06 PM:
----------------------------------------------------------------

Could it be that this is created by a diff between Karaf 2.2.6 and Karaf 2.2.7 ?
(I just switched my Karaf 2.2.7 to use equinox, but that also showed no effect.)

Why would that be not reproducible on Karaf 2.2.7 and still break with tesb ???
                
      was (Author: jkindler):
    Could it be that this is created by a diff between Karaf 2.2.6 and Karaf 2.2.7 ?
(I just switched my Karaf 2.2.7 to use equinox, but that also showed no effect.
                  
> cellar broadcasts configuration changes to a group that has been left before ...
> --------------------------------------------------------------------------------
>
>                 Key: KARAF-1476
>                 URL: https://issues.apache.org/jira/browse/KARAF-1476
>             Project: Karaf
>          Issue Type: Bug
>          Components: cellar-core
>    Affects Versions: cellar-2.2.4
>            Reporter: Jürgen Kindler
>            Assignee: Jean-Baptiste Onofré
>            Priority: Critical
>
> The scenario is the following:
> # Start up an instance of Karaf
> # Install cellar (using default hazelcast broadcast enabled config)
> # Join a new group
> # Quit the default group
> # Verify that the default group has been left using cluster:group-list ( (!) sometimes, your node will still be in default group even though the quit command gives a different feedback!!! (!) ) - if this fails, quit the default group again, until your node really appears to be out of the default group
> # Start a second instance of Karaf
> # Install cellar (using default hazelcast broadcast enabled config)
> # Verify the configuration of the second container. In my case I realized that there were configurations pushed from the first container to the second, e.g. in Pid: org.ops4j.pax.logging I found paths from the first container inside the configuration of the second container (log4j.appender.sift.appender.file, log4j.appender.out.file)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira