[jira] [Assigned] (KARAF-4942) Webconsole branding does not work
[ https://issues.apache.org/jira/browse/KARAF-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré reassigned KARAF-4942: --- Assignee: Jean-Baptiste Onofré (was: Francois Papon) > Webconsole branding does not work > - > > Key: KARAF-4942 > URL: https://issues.apache.org/jira/browse/KARAF-4942 > Project: Karaf > Issue Type: Bug > Components: webconsole >Affects Versions: 4.0.8 > Environment: Debian Linux >Reporter: Ivo Leitão >Assignee: Jean-Baptiste Onofré >Priority: Major > > I've followed the documentation in the website to brand my webconsole however > it does not work. I've verified that my fragment bundle attaches to the karaf > webconsole bundle and provided all the files needed. It simply does not work. > I've done this for plain felix webconsole and it works fine. It must be > related with the karaf repackaging of webconsole. > I've checked online and found the > http://karaf.922171.n3.nabble.com/Can-t-brand-the-webconsole-td4038868.html. > The problem is the same actually. I've also found this example at > https://github.com/liveSense/org.liveSense.karaf/tree/master/webconsole-branding > which seems for a previous version. The only difference here is that > JaasSecurityProvider.java is provided also and I'm not doing this (this file > in the new version is not in the same place anyway...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-4942) Webconsole branding does not work
[ https://issues.apache.org/jira/browse/KARAF-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740098#comment-16740098 ] Jean-Baptiste Onofré commented on KARAF-4942: - Let me take a look. > Webconsole branding does not work > - > > Key: KARAF-4942 > URL: https://issues.apache.org/jira/browse/KARAF-4942 > Project: Karaf > Issue Type: Bug > Components: webconsole >Affects Versions: 4.0.8 > Environment: Debian Linux >Reporter: Ivo Leitão >Assignee: Jean-Baptiste Onofré >Priority: Major > > I've followed the documentation in the website to brand my webconsole however > it does not work. I've verified that my fragment bundle attaches to the karaf > webconsole bundle and provided all the files needed. It simply does not work. > I've done this for plain felix webconsole and it works fine. It must be > related with the karaf repackaging of webconsole. > I've checked online and found the > http://karaf.922171.n3.nabble.com/Can-t-brand-the-webconsole-td4038868.html. > The problem is the same actually. I've also found this example at > https://github.com/liveSense/org.liveSense.karaf/tree/master/webconsole-branding > which seems for a previous version. The only difference here is that > JaasSecurityProvider.java is provided also and I'm not doing this (this file > in the new version is not in the same place anyway...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-4942) Webconsole branding does not work
[ https://issues.apache.org/jira/browse/KARAF-4942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740090#comment-16740090 ] Charles George commented on KARAF-4942: --- Has there been any updates to resolving this issue? For now I've deployed a BrandingPlugin along side the fragment to properly override the webconsole.properties. > Webconsole branding does not work > - > > Key: KARAF-4942 > URL: https://issues.apache.org/jira/browse/KARAF-4942 > Project: Karaf > Issue Type: Bug > Components: webconsole >Affects Versions: 4.0.8 > Environment: Debian Linux >Reporter: Ivo Leitão >Assignee: Francois Papon >Priority: Major > > I've followed the documentation in the website to brand my webconsole however > it does not work. I've verified that my fragment bundle attaches to the karaf > webconsole bundle and provided all the files needed. It simply does not work. > I've done this for plain felix webconsole and it works fine. It must be > related with the karaf repackaging of webconsole. > I've checked online and found the > http://karaf.922171.n3.nabble.com/Can-t-brand-the-webconsole-td4038868.html. > The problem is the same actually. I've also found this example at > https://github.com/liveSense/org.liveSense.karaf/tree/master/webconsole-branding > which seems for a previous version. The only difference here is that > JaasSecurityProvider.java is provided also and I'm not doing this (this file > in the new version is not in the same place anyway...) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740043#comment-16740043
]
ASF subversion and git services commented on KARAF-6076:
Commit 5a0bbc66d75c64c1dc164c5e1601aa92d2d12260 in karaf's branch
refs/heads/master from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=karaf.git;h=5a0bbc6 ]
Merge pull request #715 from jbonofre/KARAF-6076
[KARAF-6076] Deal with feature in Xalan and Saxon
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: blueprint, saxon, xslt
> Fix For: 4.2.3
>
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740041#comment-16740041
]
ASF GitHub Bot commented on KARAF-6076:
---
jbonofre commented on pull request #715: [KARAF-6076] Deal with feature in
Xalan and Saxon
URL: https://github.com/apache/karaf/pull/715
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: blueprint, saxon, xslt
> Fix For: 4.2.3
>
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740044#comment-16740044
]
ASF subversion and git services commented on KARAF-6076:
Commit 5a0bbc66d75c64c1dc164c5e1601aa92d2d12260 in karaf's branch
refs/heads/master from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=karaf.git;h=5a0bbc6 ]
Merge pull request #715 from jbonofre/KARAF-6076
[KARAF-6076] Deal with feature in Xalan and Saxon
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: blueprint, saxon, xslt
> Fix For: 4.2.3
>
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16740042#comment-16740042
]
ASF subversion and git services commented on KARAF-6076:
Commit 8e3251b395917705694834abd7addbf2b573a844 in karaf's branch
refs/heads/master from Jean-Baptiste Onofré
[ https://gitbox.apache.org/repos/asf?p=karaf.git;h=8e3251b ]
[KARAF-6076] Deal with feature in Xalan and Saxon
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: blueprint, saxon, xslt
> Fix For: 4.2.3
>
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré resolved KARAF-6076.
-
Resolution: Fixed
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: blueprint, saxon, xslt
> Fix For: 4.2.3
>
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-6076:
Labels: saxon xslt (was: )
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: saxon, xslt
> Fix For: 4.2.3
>
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-6076:
Labels: blueprint saxon xslt (was: saxon xslt)
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Labels: blueprint, saxon, xslt
> Fix For: 4.2.3
>
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739610#comment-16739610
]
ASF GitHub Bot commented on KARAF-6076:
---
jbonofre commented on pull request #715: [KARAF-6076] Deal with feature in
Xalan and Saxon
URL: https://github.com/apache/karaf/pull/715
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.2.3
>
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jean-Baptiste Onofré updated KARAF-6076:
Fix Version/s: 4.2.3
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
> Fix For: 4.2.3
>
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739511#comment-16739511
]
Robert Varga commented on KARAF-5086:
-
Once aries-proxy-1.1.4 is released, this issue should become a dependency
upgrade request for that.
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
> Attachments: karaf.log
>
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)
> at
>
[jira] [Comment Edited] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739475#comment-16739475
]
Robert Varga edited comment on KARAF-5086 at 1/10/19 3:19 PM:
--
ARIES-1849 is filed for this.
was (Author: nite):
Aries issue filed for this.
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
> Attachments: karaf.log
>
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)
> at
>
[jira] [Commented] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739487#comment-16739487
]
Jean-Baptiste Onofré commented on KARAF-6076:
-
I tested a fix that doesn't impact the XXE for features.
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
> org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
> [63:org.apache.karaf.deployer.blueprint:4.2.2]
> at java.net.URL.openStream(URL.java:1045) [?:?]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
> [10:org.apache.felix.fileinstall:3.6.4]
> at
> org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
> [10:org.apache.felix.fileinstall:3.6.4]
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739475#comment-16739475
]
Robert Varga commented on KARAF-5086:
-
Aries issue filed for this.
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
> Attachments: karaf.log
>
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:146)
> at
>
[jira] [Commented] (KARAF-6076) Blueprint loading fails with Saxon or Xalan
[
https://issues.apache.org/jira/browse/KARAF-6076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739456#comment-16739456
]
Jean-Baptiste Onofré commented on KARAF-6076:
-
I'm able to reproduce the issue, just installing {{camel-blueprint}} and
{{camel-saxon}} features, and dropping a simple route blueprint XML.
Deployment fails with the following error:
{code}
java.io.IOException: Error opening blueprint xml url
at
org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:78)
~[?:?]
at java.net.URL.openStream(URL.java:1045) ~[?:?]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:962)
[10:org.apache.felix.fileinstall:3.6.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.install(DirectoryWatcher.java:884)
[10:org.apache.felix.fileinstall:3.6.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.doProcess(DirectoryWatcher.java:489)
[10:org.apache.felix.fileinstall:3.6.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.process(DirectoryWatcher.java:365)
[10:org.apache.felix.fileinstall:3.6.4]
at
org.apache.felix.fileinstall.internal.DirectoryWatcher.run(DirectoryWatcher.java:316)
[10:org.apache.felix.fileinstall:3.6.4]
Caused by: java.lang.IllegalArgumentException: Unknown configuration property
http://javax.xml.XMLConstants/property/accessExternalDTD
at
net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
~[?:?]
at
net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352) ~[?:?]
at
net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
~[?:?]
at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154) ~[?:?]
at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96) ~[?:?]
at
org.apache.karaf.deployer.blueprint.BlueprintTransformer.analyze(BlueprintTransformer.java:129)
~[?:?]
at
org.apache.karaf.deployer.blueprint.BlueprintTransformer.transform(BlueprintTransformer.java:71)
~[?:?]
at
org.apache.karaf.deployer.blueprint.BlueprintURLHandler$Connection.getInputStream(BlueprintURLHandler.java:73)
~[?:?]
{code}
> Blueprint loading fails with Saxon or Xalan
> ---
>
> Key: KARAF-6076
> URL: https://issues.apache.org/jira/browse/KARAF-6076
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Jean-Baptiste Onofré
>Assignee: Jean-Baptiste Onofré
>Priority: Major
>
> Reported on the mailing list:
> {code}
> I use Karaf as a runtime to host my Apache Camel routes. They are
> mostly plain blueprint .xmls that are installed and deployed with the
> blueprint handler. I make heavy use of xsl tranformations and have in
> the past used Xalan but am moving to Saxon for xslt/xpath 2.0.
> On 4.2.1 I don't have any issues installing and using either Xalan or
> Saxon bundles, but on 4.2.2, once either are installed I can no longer
> install through blueprint. It looks to be the result of the change for
> "Set the secure processing feature on TransformerFactory instances" in
> XmlUtils in commit de4c413925379913ffb3bf96ead7edc2dba98d4b. That
> commit sets XMLConstants.ACCESS_EXTERNAL_DTD and neither Xalan nor
> Saxon support that property. From what I've read searching for that
> error I believe external DTD isn't in the purview of transformation
> but in the document parser.
> Note that it is after a restart of Karaf after installing Saxon that I
> get the exception when trying to install another blueprint bundle. I
> believe a transfomer is already created from the default
> com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImp.
> Has anyone else seen this?
> Thanks.
> -John
> 2018-12-31T16:17:31,853 | ERROR |
> fileinstall-/opt/sgscamel/karaf/apache-karaf-4.2.2/deploy |
> BlueprintURLHandler | 63 -
> org.apache.karaf.deployer.blueprint - 4.2.2 | Error opening blueprint
> xml url
> java.lang.IllegalArgumentException: Unknown configuration property
> http://javax.xml.XMLConstants/property/accessExternalDTD
> at
> net.sf.saxon.Configuration.setConfigurationProperty(Configuration.java:4644)
> ~[?:?]
> at
> net.sf.saxon.s9api.Processor.setConfigurationProperty(Processor.java:352)
> ~[?:?]
> at
> net.sf.saxon.jaxp.SaxonTransformerFactory.setAttribute(SaxonTransformerFactory.java:306)
> ~[?:?]
> at org.apache.karaf.util.XmlUtils.transformer(XmlUtils.java:154)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at org.apache.karaf.util.XmlUtils.transform(XmlUtils.java:96)
> ~[63:org.apache.karaf.deployer.blueprint:4.2.2]
> at
>
[jira] [Commented] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739443#comment-16739443
]
Robert Varga commented on KARAF-5086:
-
Looking at AbstractWovenProxyMethodAdapter, this really is an aries-proxy
issue, introduced in ARIES-1186: there is an explicit check for the method
being default and invokevirtual is being used in that case.
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
> Attachments: karaf.log
>
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
> at
>
[jira] [Resolved] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jean-Baptiste Onofré resolved KARAF-6080. - Resolution: Fixed > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739441#comment-16739441 ] ASF subversion and git services commented on KARAF-6080: Commit 145d627fe62e8f18b848979905423e1183cc in karaf's branch refs/heads/karaf-4.1.x from Jean-Baptiste Onofré [ https://gitbox.apache.org/repos/asf?p=karaf.git;h=145d611 ] [KARAF-6080] Avoid duplicate configuration when cfg file already exist while installing a feature Author: J. Brébec > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on KARAF-6080 started by Jean-Baptiste Onofré. --- > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (KARAF-6085) karaf-maven-plugin verify mojo builds invalid repository URL on Windows
Dan Berindei created KARAF-6085:
---
Summary: karaf-maven-plugin verify mojo builds invalid repository
URL on Windows
Key: KARAF-6085
URL: https://issues.apache.org/jira/browse/KARAF-6085
Project: Karaf
Issue Type: Bug
Components: karaf
Affects Versions: 4.2.2
Environment: Windows
Reporter: Dan Berindei
[https://github.com/apache/karaf/blob/218c765d0ec389f44d27d9e837e965028aa30f15/tooling/karaf-maven-plugin/src/main/java/org/apache/karaf/tooling/VerifyMojo.java#L253]
{code:java}
allDescriptors.add("file:" + project.getBuild().getDirectory() +
"/feature/feature.xml");
{code}
On Windows, this builds a URL like
{{[file://C:\jenkins\workspace\InfinispanAlternateBuilds\InfinispanWindows\commons\target/classes/features.xml|file:///classes/features.xml]}},
which is invalid because {{C:}} is interpreted as a host name:
[https://en.wikipedia.org/wiki/File_URI_scheme#Windows_2]
The error is reported like this:
{noformat}
16:24:58 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.karaf.tooling:karaf-maven-plugin:4.2.0:verify
(validate) on project infinispan-commons: Unable to load features descriptors
16:24:58 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:215)
16:24:58 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
16:24:58 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
16:24:58 at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
16:24:58 at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
16:24:58 at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
16:24:58 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
16:24:58 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
16:24:58 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
16:24:58 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
16:24:58 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
16:24:58 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
16:24:58 at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
16:24:58 at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
16:24:58 at sun.reflect.NativeMethodAccessorImpl.invoke
(NativeMethodAccessorImpl.java:62)
16:24:58 at sun.reflect.DelegatingMethodAccessorImpl.invoke
(DelegatingMethodAccessorImpl.java:43)
16:24:59 at java.lang.reflect.Method.invoke (Method.java:498)
16:24:59 at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
(Launcher.java:289)
16:24:59 at org.codehaus.plexus.classworlds.launcher.Launcher.launch
(Launcher.java:229)
16:24:59 at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
(Launcher.java:415)
16:24:59 at org.codehaus.plexus.classworlds.launcher.Launcher.main
(Launcher.java:356)
16:24:59 Caused by: org.apache.maven.plugin.MojoExecutionException: Unable to
load features descriptors
16:24:59 at org.apache.karaf.tooling.VerifyMojo.doExecute
(VerifyMojo.java:293)
16:24:59 at org.apache.karaf.tooling.VerifyMojo.execute
(VerifyMojo.java:185)
16:24:59 at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
(DefaultBuildPluginManager.java:137)
16:24:59 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:210)
16:24:59 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:156)
16:24:59 at org.apache.maven.lifecycle.internal.MojoExecutor.execute
(MojoExecutor.java:148)
16:24:59 at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:117)
16:24:59 at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
(LifecycleModuleBuilder.java:81)
16:24:59 at
org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
(SingleThreadedBuilder.java:56)
16:24:59 at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
(LifecycleStarter.java:128)
16:24:59 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:305)
16:24:59 at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:192)
16:24:59 at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:105)
16:24:59 at org.apache.maven.cli.MavenCli.execute (MavenCli.java:956)
16:24:59 at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:288)
16:24:59 at org.apache.maven.cli.MavenCli.main (MavenCli.java:192)
16:24:59 at sun.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
16:24:59 at
[jira] [Commented] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739369#comment-16739369 ] ASF subversion and git services commented on KARAF-6080: Commit 11e5f2f871aef9e6995488dc84e873549c97fc7d in karaf's branch refs/heads/master from Jean-Baptiste Onofré [ https://gitbox.apache.org/repos/asf?p=karaf.git;h=11e5f2f ] [KARAF-6080] Avoid duplicate configuration when cfg file already exist while installing a feature Author: J. Brébec > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739370#comment-16739370 ] ASF subversion and git services commented on KARAF-6080: Commit a06d59e014dd5d7652eb4c796d20c0791fe3888a in karaf's branch refs/heads/master from Jean-Baptiste Onofré [ https://gitbox.apache.org/repos/asf?p=karaf.git;h=a06d59e ] Merge pull request #714 from jbonofre/KARAF-6080 [KARAF-6080] Avoid duplicate configuration when cfg file already exist while installing a feature > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739371#comment-16739371 ] ASF subversion and git services commented on KARAF-6080: Commit a06d59e014dd5d7652eb4c796d20c0791fe3888a in karaf's branch refs/heads/master from Jean-Baptiste Onofré [ https://gitbox.apache.org/repos/asf?p=karaf.git;h=a06d59e ] Merge pull request #714 from jbonofre/KARAF-6080 [KARAF-6080] Avoid duplicate configuration when cfg file already exist while installing a feature > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739368#comment-16739368 ] ASF GitHub Bot commented on KARAF-6080: --- jbonofre commented on pull request #714: [KARAF-6080] Avoid duplicate configuration when cfg file already exist while installing a feature URL: https://github.com/apache/karaf/pull/714 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739360#comment-16739360 ] J. Brébec commented on KARAF-6080: -- Thanks ! We have a Managed Service (through DS) which implements the Servlet API, and are deployed to jetty with pax-exam whiteboad. When this bug occurs, two servlets with the same alias are registered, which fails. We have a lot of IT with PaxExam, and 10% of these tests fail because of this bug. In my usecase, this issue can have a big impact of the availability of my services. > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739333#comment-16739333
]
Robert Varga edited comment on KARAF-5086 at 1/10/19 12:12 PM:
---
Looking at hotspot sources, the source of the error is
LinkResolver::resolve_method(). It seems to imply the problem is actually at
the call site, i.e. the method is invoked with invokevirtual rather than
invokeinterface.
With the javac-generated code being correct, could this perhaps be explained by
weaving proxy?
was (Author: nite):
Looking at hotspot sources, the source of the error is
LinkResolver::resolve_method(). It seems to imply the problem is actually at
the call site, i.e. the method is invoked with invokevirtual rather than
invokeinterface. If that is the case, this would be a javac bug.
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
> Attachments: karaf.log
>
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
>
[jira] [Commented] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739333#comment-16739333
]
Robert Varga commented on KARAF-5086:
-
Looking at hotspot sources, the source of the error is
LinkResolver::resolve_method(). It seems to imply the problem is actually at
the call site, i.e. the method is invoked with invokevirtual rather than
invokeinterface.
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
> Attachments: karaf.log
>
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
> at
>
[jira] [Comment Edited] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739333#comment-16739333
]
Robert Varga edited comment on KARAF-5086 at 1/10/19 12:03 PM:
---
Looking at hotspot sources, the source of the error is
LinkResolver::resolve_method(). It seems to imply the problem is actually at
the call site, i.e. the method is invoked with invokevirtual rather than
invokeinterface. If that is the case, this would be a javac bug.
was (Author: nite):
Looking at hotspot sources, the source of the error is
LinkResolver::resolve_method(). It seems to imply the problem is actually at
the call site, i.e. the method is invoked with invokevirtual rather than
invokeinterface.
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
> Attachments: karaf.log
>
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
>
[jira] [Updated] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Varga updated KARAF-5086:
Attachment: karaf.log
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
> Attachments: karaf.log
>
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:146)
> at
>
[jira] [Comment Edited] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739317#comment-16739317
]
Robert Varga edited comment on KARAF-5086 at 1/10/19 11:36 AM:
---
For what it's worth I am able to reproduce this with karaf-4.2.2. Karaf log
attached.
was (Author: nite):
For what it's worth I am able to reproduce this with karaf-4.2.2.
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)
> at
[jira] [Commented] (KARAF-5086) Java 8 default methods cause IncompatibleClassChangeError in blueprint
[
https://issues.apache.org/jira/browse/KARAF-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739317#comment-16739317
]
Robert Varga commented on KARAF-5086:
-
For what it's worth I am able to reproduce this with karaf-4.2.2.
> Java 8 default methods cause IncompatibleClassChangeError in blueprint
> --
>
> Key: KARAF-5086
> URL: https://issues.apache.org/jira/browse/KARAF-5086
> Project: Karaf
> Issue Type: Bug
>Affects Versions: 4.0.7
>Reporter: Michael Vorburger
>Assignee: Guillaume Nodet
>Priority: Critical
>
> I have an interface with a default method and an implementation of that is
> exposed as an OSGi service via Aries Blueprint, and when the default method
> is called, it's causing this error: {code}IncompatibleClassChangeError: Found
> interface org.opendaylight.infrautils.caches.CacheProvider, but class was
> expected. at Proxy*.newCache(){code}
> The code looks something like this:
> {code}public interface CacheProvider {
> Cache newCache(CacheConfig cacheConfig, CachePolicy
> initialPolicy);
> default Cache newCache(CacheConfig cacheConfig) {
> return newCache(cacheConfig, new CachePolicyBuilder().build());
> }
> {code}
> And here's the full stack trace:
> {code}opendaylight-user@root>diag
> caches-sample (57)
> --
> Status: Failure
> Blueprint
> 9/4/17 5:35 AM
> Exception:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> org.osgi.service.blueprint.container.ComponentDefinitionException:
> org.osgi.service.blueprint.container.ComponentDefinitionException: Error when
> instantiating bean sampleServiceWithCachingImpl of class
> org.opendaylight.infrautils.caches.sample.SampleServiceWithCachingImpl
> at
> org.apache.aries.blueprint.container.ServiceRecipe.createService(ServiceRecipe.java:310)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalGetService(ServiceRecipe.java:252)
> at
> org.apache.aries.blueprint.container.ServiceRecipe.internalCreate(ServiceRecipe.java:149)
> at
> org.apache.aries.blueprint.di.AbstractRecipe$1.call(AbstractRecipe.java:79)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> org.apache.aries.blueprint.di.AbstractRecipe.create(AbstractRecipe.java:88)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createInstances(BlueprintRepository.java:255)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.createAll(BlueprintRepository.java:186)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.instantiateEagerComponents(BlueprintContainerImpl.java:724)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.doRun(BlueprintContainerImpl.java:411)
> at
> org.apache.aries.blueprint.container.BlueprintContainerImpl.run(BlueprintContainerImpl.java:276)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:300)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:269)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.createContainer(BlueprintExtender.java:265)
> at
> org.apache.aries.blueprint.container.BlueprintExtender.modifiedBundle(BlueprintExtender.java:255)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:500)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.customizerModified(BundleHookBundleTracker.java:433)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$AbstractTracked.track(BundleHookBundleTracker.java:725)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$Tracked.bundleChanged(BundleHookBundleTracker.java:463)
> at
> org.apache.aries.util.tracker.hook.BundleHookBundleTracker$BundleEventHook.event(BundleHookBundleTracker.java:422)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher$2.call(EquinoxEventPublisher.java:189)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHookPrivileged(ServiceRegistry.java:1280)
> at
> org.eclipse.osgi.internal.serviceregistry.ServiceRegistry.notifyHooksPrivileged(ServiceRegistry.java:1263)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.notifyEventHooksPrivileged(EquinoxEventPublisher.java:186)
> at
> org.eclipse.osgi.internal.framework.EquinoxEventPublisher.publishBundleEventPrivileged(EquinoxEventPublisher.java:146)
> at
>
[jira] [Commented] (KARAF-6082) Eniment test case failure due to hard-coded karaf version
[ https://issues.apache.org/jira/browse/KARAF-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739255#comment-16739255 ] Jean-Baptiste Onofré commented on KARAF-6082: - Good catch. Let me clean this up. Thanks ! > Eniment test case failure due to hard-coded karaf version > - > > Key: KARAF-6082 > URL: https://issues.apache.org/jira/browse/KARAF-6082 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 >Reporter: Martin Krüger >Assignee: Jean-Baptiste Onofré >Priority: Major > Attachments: > 0001-KARAF-6082-Remove-hard-coded-version-string-from-tes.patch > > > In commit aa78736c8da40d8a292d5c474fd270ab397b5074 hard coded karaf versions > in test cases were replaced by newer versions. But this does not solve the > problem. Latest with the next tag the code is broken again in case older > artefacts are not available during test runs. > Please see the attached patch to fix the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (KARAF-6084) Startup bundles do not resolve correctly when compiled with Java 11 during assembly
[
https://issues.apache.org/jira/browse/KARAF-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang resolved KARAF-6084.
-
Resolution: Fixed
> Startup bundles do not resolve correctly when compiled with Java 11 during
> assembly
> ---
>
> Key: KARAF-6084
> URL: https://issues.apache.org/jira/browse/KARAF-6084
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Martin Krüger
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 4.2.3
>
> Attachments:
> 0001-KARAF-6084-Add-Java-11-and-11-to-the-list-of-support.patch
>
>
> The problem is that we have a fragment for the logger which needs to be
> loaded in the startup phase. We compile the bundles with Java 11 which
> results in a {noformat}Require-Capability:
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"{noformat} manifest entry.
> We during build we get an error that a bundle requirement is not met.
> We then discovered that the karaf-maven-plugin uses "1.8" as default value
> for the javase option. Changing that to "11" results in a compile error
> because this version is not supported.
> Therefore I suggest to add Java 10 and Java 11 to enum
> org.apache.karaf.profile.assembly.Builder.JavaVersion. That enables support
> for this Java version also.
> In my local tests this solved the compile issue when setting the javase
> option to 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-6084) Startup bundles do not resolve correctly when compiled with Java 11 during assembly
[
https://issues.apache.org/jira/browse/KARAF-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739236#comment-16739236
]
Freeman Fang commented on KARAF-6084:
-
Yup, we should do it.
Thanks for the contribution
Patch applied on behalf of Martin Krüger with thanks!
> Startup bundles do not resolve correctly when compiled with Java 11 during
> assembly
> ---
>
> Key: KARAF-6084
> URL: https://issues.apache.org/jira/browse/KARAF-6084
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Martin Krüger
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 4.2.3
>
> Attachments:
> 0001-KARAF-6084-Add-Java-11-and-11-to-the-list-of-support.patch
>
>
> The problem is that we have a fragment for the logger which needs to be
> loaded in the startup phase. We compile the bundles with Java 11 which
> results in a {noformat}Require-Capability:
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"{noformat} manifest entry.
> We during build we get an error that a bundle requirement is not met.
> We then discovered that the karaf-maven-plugin uses "1.8" as default value
> for the javase option. Changing that to "11" results in a compile error
> because this version is not supported.
> Therefore I suggest to add Java 10 and Java 11 to enum
> org.apache.karaf.profile.assembly.Builder.JavaVersion. That enables support
> for this Java version also.
> In my local tests this solved the compile issue when setting the javase
> option to 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-6084) Startup bundles do not resolve correctly when compiled with Java 11 during assembly
[
https://issues.apache.org/jira/browse/KARAF-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739235#comment-16739235
]
ASF subversion and git services commented on KARAF-6084:
Commit 9a9eb410b28cff8a20cbf5834bfa6864cc32d189 in karaf's branch
refs/heads/master from Martin Krüger
[ https://gitbox.apache.org/repos/asf?p=karaf.git;h=9a9eb41 ]
KARAF-6084 Add Java 11 and 11 to the list of supported versions
Signed-off-by: Freeman Fang
> Startup bundles do not resolve correctly when compiled with Java 11 during
> assembly
> ---
>
> Key: KARAF-6084
> URL: https://issues.apache.org/jira/browse/KARAF-6084
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Martin Krüger
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 4.2.3
>
> Attachments:
> 0001-KARAF-6084-Add-Java-11-and-11-to-the-list-of-support.patch
>
>
> The problem is that we have a fragment for the logger which needs to be
> loaded in the startup phase. We compile the bundles with Java 11 which
> results in a {noformat}Require-Capability:
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"{noformat} manifest entry.
> We during build we get an error that a bundle requirement is not met.
> We then discovered that the karaf-maven-plugin uses "1.8" as default value
> for the javase option. Changing that to "11" results in a compile error
> because this version is not supported.
> Therefore I suggest to add Java 10 and Java 11 to enum
> org.apache.karaf.profile.assembly.Builder.JavaVersion. That enables support
> for this Java version also.
> In my local tests this solved the compile issue when setting the javase
> option to 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Work started] (KARAF-6084) Startup bundles do not resolve correctly when compiled with Java 11 during assembly
[
https://issues.apache.org/jira/browse/KARAF-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on KARAF-6084 started by Freeman Fang.
---
> Startup bundles do not resolve correctly when compiled with Java 11 during
> assembly
> ---
>
> Key: KARAF-6084
> URL: https://issues.apache.org/jira/browse/KARAF-6084
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Martin Krüger
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 4.2.3
>
> Attachments:
> 0001-KARAF-6084-Add-Java-11-and-11-to-the-list-of-support.patch
>
>
> The problem is that we have a fragment for the logger which needs to be
> loaded in the startup phase. We compile the bundles with Java 11 which
> results in a {noformat}Require-Capability:
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"{noformat} manifest entry.
> We during build we get an error that a bundle requirement is not met.
> We then discovered that the karaf-maven-plugin uses "1.8" as default value
> for the javase option. Changing that to "11" results in a compile error
> because this version is not supported.
> Therefore I suggest to add Java 10 and Java 11 to enum
> org.apache.karaf.profile.assembly.Builder.JavaVersion. That enables support
> for this Java version also.
> In my local tests this solved the compile issue when setting the javase
> option to 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (KARAF-6084) Startup bundles do not resolve correctly when compiled with Java 11 during assembly
[
https://issues.apache.org/jira/browse/KARAF-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Freeman Fang reassigned KARAF-6084:
---
Assignee: Freeman Fang
> Startup bundles do not resolve correctly when compiled with Java 11 during
> assembly
> ---
>
> Key: KARAF-6084
> URL: https://issues.apache.org/jira/browse/KARAF-6084
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Martin Krüger
>Assignee: Freeman Fang
>Priority: Major
> Fix For: 4.2.3
>
> Attachments:
> 0001-KARAF-6084-Add-Java-11-and-11-to-the-list-of-support.patch
>
>
> The problem is that we have a fragment for the logger which needs to be
> loaded in the startup phase. We compile the bundles with Java 11 which
> results in a {noformat}Require-Capability:
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"{noformat} manifest entry.
> We during build we get an error that a bundle requirement is not met.
> We then discovered that the karaf-maven-plugin uses "1.8" as default value
> for the javase option. Changing that to "11" results in a compile error
> because this version is not supported.
> Therefore I suggest to add Java 10 and Java 11 to enum
> org.apache.karaf.profile.assembly.Builder.JavaVersion. That enables support
> for this Java version also.
> In my local tests this solved the compile issue when setting the javase
> option to 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-6082) Eniment test case failure due to hard-coded karaf version
[ https://issues.apache.org/jira/browse/KARAF-6082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739221#comment-16739221 ] Martin Krüger commented on KARAF-6082: -- The file org.apache.karaf.itests.mavenresolver.KarafMinimalMonitoredTestSupport also has this useless fallback. Also org.apache.karaf.itests.KarafTestSupport which was done in 59f500fc29940113b43ae64cee5d533110dd5784. > Eniment test case failure due to hard-coded karaf version > - > > Key: KARAF-6082 > URL: https://issues.apache.org/jira/browse/KARAF-6082 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 >Reporter: Martin Krüger >Assignee: Jean-Baptiste Onofré >Priority: Major > Attachments: > 0001-KARAF-6082-Remove-hard-coded-version-string-from-tes.patch > > > In commit aa78736c8da40d8a292d5c474fd270ab397b5074 hard coded karaf versions > in test cases were replaced by newer versions. But this does not solve the > problem. Latest with the next tag the code is broken again in case older > artefacts are not available during test runs. > Please see the attached patch to fix the problem. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (KARAF-6084) Startup bundles do not resolve correctly when compiled with Java 11 during assembly
[
https://issues.apache.org/jira/browse/KARAF-6084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Krüger updated KARAF-6084:
-
Attachment: 0001-KARAF-6084-Add-Java-11-and-11-to-the-list-of-support.patch
> Startup bundles do not resolve correctly when compiled with Java 11 during
> assembly
> ---
>
> Key: KARAF-6084
> URL: https://issues.apache.org/jira/browse/KARAF-6084
> Project: Karaf
> Issue Type: Bug
> Components: karaf
>Affects Versions: 4.2.2
>Reporter: Martin Krüger
>Priority: Major
> Fix For: 4.2.3
>
> Attachments:
> 0001-KARAF-6084-Add-Java-11-and-11-to-the-list-of-support.patch
>
>
> The problem is that we have a fragment for the logger which needs to be
> loaded in the startup phase. We compile the bundles with Java 11 which
> results in a {noformat}Require-Capability:
> osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"{noformat} manifest entry.
> We during build we get an error that a bundle requirement is not met.
> We then discovered that the karaf-maven-plugin uses "1.8" as default value
> for the javase option. Changing that to "11" results in a compile error
> because this version is not supported.
> Therefore I suggest to add Java 10 and Java 11 to enum
> org.apache.karaf.profile.assembly.Builder.JavaVersion. That enables support
> for this Java version also.
> In my local tests this solved the compile issue when setting the javase
> option to 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (KARAF-6084) Startup bundles do not resolve correctly when compiled with Java 11 during assembly
Martin Krüger created KARAF-6084:
Summary: Startup bundles do not resolve correctly when compiled
with Java 11 during assembly
Key: KARAF-6084
URL: https://issues.apache.org/jira/browse/KARAF-6084
Project: Karaf
Issue Type: Bug
Components: karaf
Affects Versions: 4.2.2
Reporter: Martin Krüger
Fix For: 4.2.3
The problem is that we have a fragment for the logger which needs to be loaded
in the startup phase. We compile the bundles with Java 11 which results in a
{noformat}Require-Capability:
osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=11))"{noformat} manifest entry. We
during build we get an error that a bundle requirement is not met.
We then discovered that the karaf-maven-plugin uses "1.8" as default value for
the javase option. Changing that to "11" results in a compile error because
this version is not supported.
Therefore I suggest to add Java 10 and Java 11 to enum
org.apache.karaf.profile.assembly.Builder.JavaVersion. That enables support for
this Java version also.
In my local tests this solved the compile issue when setting the javase option
to 11.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739193#comment-16739193 ] ASF GitHub Bot commented on KARAF-6080: --- jbonofre commented on pull request #714: [KARAF-6080] Avoid duplicate configuration when cfg file already exist while installing a feature URL: https://github.com/apache/karaf/pull/714 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (KARAF-6080) Duplicate configuration randomly created on the first start in ConfigurationAdmin
[ https://issues.apache.org/jira/browse/KARAF-6080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16739187#comment-16739187 ] Jean-Baptiste Onofré commented on KARAF-6080: - Thanks, generally speaking it's a not a big deal, but not clean for sure. Let me do a full review. > Duplicate configuration randomly created on the first start in > ConfigurationAdmin > - > > Key: KARAF-6080 > URL: https://issues.apache.org/jira/browse/KARAF-6080 > Project: Karaf > Issue Type: Bug > Components: karaf >Affects Versions: 4.2.2 > Environment: Karaf 4.1.2, Karaf 4.2.2 > Windows 7, Equinox >Reporter: J. Brébec >Assignee: Jean-Baptiste Onofré >Priority: Major > Fix For: 4.1.8, 4.2.3 > > Attachments: karaf-6080.patch > > > On the first start, if a boot feature contains a element, and the > associated .cfg file exists in the etc folder, then this Configuration can be > created twice in ConfigurationAdmin : > # File Install check the etc folder and create for every cfg a Configuration > in ConfigurationAdmin > # the FeatureService (FeatureConfigInstaller), when a feature is installed > and has a configuration, check if this configuration exists in > ConfigurationAdmin. If the configuration doesn't exists, then it creates a > new one > If 1 and 2 are executed simultaneously, then the same configuration is > created twice in ConfigurationAdmin. If this configuration is linked to a > managed service, then this service will be instanciated twice. > By default, the karaf-maven-plugin copies every cfg to the etc folder, this > issue can probably be triggered by any element on a boot feature. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
