You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@karaf.apache.org by "Jürgen Kindler (JIRA)" <ji...@apache.org> on 2012/05/14 16:05:51 UTC
[jira] [Created] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Jürgen Kindler created KARAF-1476:
-------------------------------------
Summary: 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
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
[jira] [Assigned] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Baptiste Onofré reassigned KARAF-1476:
-------------------------------------------
Assignee: Jean-Baptiste Onofré
> 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
[jira] [Resolved] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Baptiste Onofré resolved KARAF-1476.
-----------------------------------------
Resolution: Cannot Reproduce
> 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
> Fix For: cellar-3.0.0, cellar-2.2.5
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "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 commented on KARAF-1476:
---------------------------------------
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
[jira] [Commented] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "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=13274703#comment-13274703 ]
Jürgen Kindler commented on KARAF-1476:
---------------------------------------
But exactly this fileinstaller patch we have also inside (so it's a 2.2.6 PLUS fileinstaller patch!)
> 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
[jira] [Commented] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274700#comment-13274700 ]
Jean-Baptiste Onofré commented on KARAF-1476:
---------------------------------------------
Yes, as we have an issue on Karaf 2.2.6 with ConfigAdmin/FileInstall (config admin changes were not flushed in the cfg file). That's why we released Karaf 2.2.7 so quickly.
> 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
[jira] [Commented] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "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=13274677#comment-13274677 ]
Jürgen Kindler commented on KARAF-1476:
---------------------------------------
karaf@trun> cluster:config-list default
----------------------------------------------------------------
Pid: org.apache.cxf.workqueues
Properties:
org.apache.cxf.workqueue.default.highWaterMark = 50
org.apache.cxf.workqueue.default.initialSize = 5
service.pid = org.apache.cxf.workqueues
org.apache.cxf.workqueue.names = default
karaf.cellar.sync = 1337008780629
org.apache.cxf.workqueue.default.lowWaterMark = 5
----------------------------------------------------------------
Pid: org.ops4j.pax.url.mvn
Properties:
org.ops4j.pax.url.mvn.useFallbackRepositories = false
service.pid = org.ops4j.pax.url.mvn
org.ops4j.pax.url.mvn.disableAether = true
org.ops4j.pax.url.mvn.repositories = http://tadmin:tadmin@localhost:8082/archiva/repository/repo-release, http://tadmin:tadmin@localhost:8082/archiva/repository/repo-snapshot@snapshots, http://repo1.maven.org/maven2, http://repository.apache.org/content/groups/snapshots-group@snapshots@noreleases, http://svn.apache.org/repos/asf/servicemix/m2-repo, http://repository.springsource.com/maven/bundles/release, http://repository.springsource.com/maven/bundles/external, http://oss.sonatype.org/content/repositories/releases/
karaf.cellar.sync = 1337008780596
----------------------------------------------------------------
Pid: org.apache.karaf.webconsole
Properties:
role = admin
service.pid = org.apache.karaf.webconsole
realm = karaf
org.apache.karaf.features.configKey = org.apache.karaf.webconsole
karaf.cellar.sync = 1337008780610
----------------------------------------------------------------
Pid: org.talend.esb.job.client
Properties:
karaf.cellar.sync = 1337008780587
ws-security.signature.properties = file:/Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/etc/keystores/clientKeystore.properties
logging = false
https.config = file:/Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/etc/org.talend.esb.job.client.https.xml
ws-security.signature.password = ckpass
service.pid = org.talend.esb.job.client
ws-security.signature.username = myclientkey
----------------------------------------------------------------
Pid: org.apache.cxf.osgi
Properties:
karaf.cellar.sync = 1337008780581
org.apache.cxf.servlet.context = /services
service.pid = org.apache.cxf.osgi
----------------------------------------------------------------
Pid: org.apache.karaf.log
Properties:
service.pid = org.apache.karaf.log
size = 500
karaf.cellar.sync = 1337008780584
pattern = %d{ISO8601} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n
----------------------------------------------------------------
Pid: org.apache.karaf.jaas
Properties:
karaf.cellar.sync = 1337008780628
encryption.prefix = {CRYPT}
encryption.name =
encryption.enabled = false
encryption.suffix = {CRYPT}
encryption.encoding = hexadecimal
service.pid = org.apache.karaf.jaas
encryption.algorithm = MD5
----------------------------------------------------------------
Pid: org.talend.esb.job.service
Properties:
ws-security.signature.properties = file:/Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/etc/keystores/serviceKeystore.properties
service.pid = org.talend.esb.job.service
karaf.cellar.sync = 1337008780643
ws-security.signature.username = myservicekey
ws-security.signature.password = skpass
----------------------------------------------------------------
Pid: org.apache.karaf.features
Properties:
service.pid = org.apache.karaf.features
featuresRepositories = mvn:org.apache.karaf.assemblies.features/standard/2.2.6/xml/features,mvn:org.apache.karaf.assemblies.features/enterprise/2.2.6/xml/features,mvn:org.apache.activemq/activemq-karaf/5.5.1/xml/features,mvn:org.apache.camel.karaf/apache-camel/2.9.2/xml/features,mvn:org.apache.cxf.karaf/apache-cxf/2.6.0/xml/features,mvn:org.talend.esb/features/5.1.1-SNAPSHOT/xml,mvn:org.talend.esb.ee/features/5.1.1-SNAPSHOT/xml,mvn:org.apache.karaf.cellar/apache-karaf-cellar/2.2.4-SNAPSHOT/xml/features,mvn:org.jclouds.karaf/jclouds-karaf/1.3.1/xml/features
featuresBoot = config,ssh,management,kar,webconsole,cxf,camel,camel-blueprint,camel-cxf,camel-jms,tesb-sam-agent,talend-job-controller,tesb-job-server,camel-ftp,camel-talendjob,tesb-jmx-http-agent
karaf.cellar.sync = 1337008780654
----------------------------------------------------------------
Pid: org.talend.esb.job.client.sts
Properties:
sts.endpoint.name = UT_Port
ws-security.sts.token.usecert = true
ws-security.sts.token.properties = file:/Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/etc/keystores/clientKeystore.properties
service.pid = org.talend.esb.job.client.sts
sts.wsdl.location = http://localhost:8040/services/SecurityTokenService/UT?wsdl
ws-security.sts.token.username = myclientkey
sts.namespace = http://docs.oasis-open.org/ws-sx/ws-trust/200512/
ws-security.encryption.properties = file:/Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/etc/keystores/clientKeystore.properties
karaf.cellar.sync = 1337008780638
ws-security.is-bsp-compliant = false
sts.service.name = SecurityTokenService
ws-security.encryption.username = mystskey
----------------------------------------------------------------
Pid: org.apache.karaf.features.repos
Properties:
karaf.cellar.sync = 1337008780593
openejb = org.apache.openejb:openejb-feature:xml:features:(0,]
camel = org.apache.camel.karaf:apache-camel:xml:features:(0,]
jclouds = org.jclouds.karaf:feature:xml:features:(0,]
activemq = org.apache.activemq:activemq-karaf:xml:features:(0,]
cxf = org.apache.cxf.karaf:apache-cxf:xml:features:(0,]
service.pid = org.apache.karaf.features.repos
wicket = org.ops4j.pax.wicket:pax-wicket-features:xml:features:(0,]
----------------------------------------------------------------
Pid: org.apache.karaf.features.obr
Properties:
karaf.cellar.sync = 1337008780653
resolveOptionalImports = false
service.pid = org.apache.karaf.features.obr
----------------------------------------------------------------
Pid: org.talend.esb.update
Properties:
karaf.cellar.sync = 1337008780652
defaultRepositories = mvn:org.apache.cxf.karaf/apache-cxf/2.6.0/xml/features,mvn:org.talend.esb/features/5.1.1-SNAPSHOT/xml,mvn:org.apache.karaf.assemblies.features/standard/2.2.6/xml/features,mvn:org.apache.camel.karaf/apache-camel/2.9.2/xml/features,mvn:org.apache.activemq/activemq-karaf/5.5.1/xml/features,mvn:org.apache.karaf.cellar/apache-karaf-cellar/2.2.4-SNAPSHOT/xml/features,mvn:org.apache.karaf.assemblies.features/enterprise/2.2.6/xml/features,mvn:org.jclouds.karaf/jclouds-karaf/1.3.1/xml/features,mvn:org.talend.esb.ee/features/5.1.1-SNAPSHOT/xml
service.pid = org.talend.esb.update
----------------------------------------------------------------
Pid: org.apache.aries.transaction
Properties:
service.pid = org.apache.aries.transaction
aries.transaction.timeout = 600
karaf.cellar.sync = 1337008780594
aries.transaction.howl.logFileDir = /Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/data/txlog/
----------------------------------------------------------------
Pid: org.apache.felix.fileinstall.87637610-5aee-440d-bef1-c0cb0c4f4aa4
Properties:
service.pid = org.apache.felix.fileinstall.87637610-5aee-440d-bef1-c0cb0c4f4aa4
felix.fileinstall.poll = 1000
service.factoryPid = org.apache.felix.fileinstall
karaf.cellar.sync = 1337008780649
----------------------------------------------------------------
Pid: org.talend.esb.job
Properties:
service.pid = org.talend.esb.job
policy.token = /Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/etc/org.talend.esb.job.token.policy
policy.saml = /Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/etc/org.talend.esb.job.saml.policy
karaf.cellar.sync = 1337008780576
----------------------------------------------------------------
Pid: org.talend.esb.sam.agent
Properties:
collector.lifecycleEvent = false
collector.scheduler.interval = 500
service.retry.number = 3
service.retry.delay = 5000
service.url = http://localhost:8040/services/MonitoringServiceSOAP
karaf.cellar.sync = 1337008780578
log.enforceMessageIDTransfer = true
service.pid = org.talend.esb.sam.agent
log.messageContent = true
log.maxContentLength = -1
collector.maxEventsPerCall = 10
----------------------------------------------------------------
Pid: org.apache.cxf.http.conduits.140d388d-2c12-45cc-ae73-db8fcaf2bf54
Properties:
tlsClientParameters.keyManagers.keyPassword = password
service.factoryPid = org.apache.cxf.http.conduits
tlsClientParameters.keyManagers.keyStore.file = ./etc/keystores/keystore.jks
tlsClientParameters.trustManagers.keyPassword = password
tlsClientParameters.disableCNCheck = true
tlsClientParameters.keyManagers.keyStore.type = JKS
service.pid = org.apache.cxf.http.conduits.140d388d-2c12-45cc-ae73-db8fcaf2bf54
karaf.cellar.sync = 1337008780595
tlsClientParameters.trustManagers.keyStore.password = password
url = https.*
tlsClientParameters.trustManagers.keyStore.file = ./etc/keystores/keystore.jks
tlsClientParameters.cipherSuitesFilter.include = .*_EXPORT_.*,.*_EXPORT1024_.*,.*_WITH_DES_.*,.*_WITH_AES_.*,.*_WITH_NULL_.*,.*_DH_anon_.*
tlsClientParameters.trustManagers.keyStore.type = JKS
tlsClientParameters.keyManagers.keyStore.password = password
----------------------------------------------------------------
Pid: org.ops4j.pax.logging
Properties:
log4j.appender.out.maxBackupIndex = 10
log4j.appender.sift.appender.layout.ConversionPattern = %d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32c{1} | %-32.32C %4L | %m%n
log4j.appender.out = org.apache.log4j.RollingFileAppender
log4j.appender.out.layout = org.apache.log4j.PatternLayout
log4j.appender.sift.appender = org.apache.log4j.FileAppender
log4j.rootLogger = INFO, out, osgi:VmLogAppender
log4j.appender.sift = org.apache.log4j.sift.MDCSiftingAppender
log4j.throwableRenderer = org.apache.log4j.OsgiThrowableRenderer
log4j.appender.sift.appender.layout = org.apache.log4j.PatternLayout
log4j.appender.stdout.layout = org.apache.log4j.PatternLayout
log4j.appender.out.layout.ConversionPattern = %d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n
log4j.appender.stdout.layout.ConversionPattern = %d{ABSOLUTE} | %-5.5p | %-16.16t | %-32.32C %4L | %X{bundle.id} - %X{bundle.name} - %X{bundle.version} | %m%n
log4j.appender.sift.appender.file = /Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/data/log/${bundle.name}.log
log4j.appender.sift.key = bundle.name
log4j.appender.stdout = org.apache.log4j.ConsoleAppender
service.pid = org.ops4j.pax.logging
karaf.cellar.sync = 1337008780587
log4j.appender.out.file = /Users/jkindler/temp/qa_tesb_cluster/nodes/cluster.node1/container/log/tesb.log
log4j.appender.out.append = true
log4j.appender.out.maxFileSize = 1MB
log4j.appender.sift.appender.append = true
log4j.appender.sift.default = tesb
> 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
[jira] [Updated] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Baptiste Onofré updated KARAF-1476:
----------------------------------------
Fix Version/s: (was: cellar-2.2.4)
cellar-2.2.5
> 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
> Fix For: cellar-3.0.0, cellar-2.2.5
>
>
> 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
[jira] [Issue Comment Edited] (KARAF-1476) cellar broadcasts
configuration changes to a group that has been left before ...
Posted by "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
[jira] [Commented] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274694#comment-13274694 ]
Jean-Baptiste Onofré commented on KARAF-1476:
---------------------------------------------
So, it works as designed as the default group config distributed map has been populated with node1 values.
The ConfigurationSynchronizer first pull the config and after push, that's why when node2 starts on default group, he gets the config from the distributed set.
> 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
[jira] [Commented] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274707#comment-13274707 ]
Jean-Baptiste Onofré commented on KARAF-1476:
---------------------------------------------
So it should behave the same.
> 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
[jira] [Commented] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13274635#comment-13274635 ]
Jean-Baptiste Onofré commented on KARAF-1476:
---------------------------------------------
on node1 (the first started one), could you check the content of the config distributed map with:
cluster:config-list default
I'm quite sure that the distributed map still contains the node1 configuration pushed at startup, that's why the second node takes this configuration.
> 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
[jira] [Commented] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13490783#comment-13490783 ]
Jean-Baptiste Onofré commented on KARAF-1476:
---------------------------------------------
I'm not able to reproduce this behavior (with Karaf 2.2.9 and Cellar 2.2.5-SNAPSHOT). I close this Jira for now, please, reopen if you encounter this issue again.
> 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
> Fix For: cellar-3.0.0, cellar-2.2.5
>
>
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (KARAF-1476) cellar broadcasts configuration
changes to a group that has been left before ...
Posted by "Jean-Baptiste Onofré (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/KARAF-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jean-Baptiste Onofré updated KARAF-1476:
----------------------------------------
Fix Version/s: cellar-2.2.4
cellar-3.0.0
> 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
> Fix For: cellar-3.0.0, cellar-2.2.4
>
>
> 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