date:20161011

[jira] [Resolved] (KARAF-4760) Upgrade to Felix FileInstall 3.5.6

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré resolved KARAF-4760.
-
Resolution: Fixed

> Upgrade to Felix FileInstall 3.5.6
> --
>
> Key: KARAF-4760
> URL: https://issues.apache.org/jira/browse/KARAF-4760
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Affects Versions: 4.0.7
>Reporter: Oliver Lietz
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Pax Exam adds comments (see below) to configuration files when they are 
> modified by calling e.g. {{editConfigurationFilePut(...)}} which renders 
> {{*.config}} files in tests invalid (FELIX-5261).
> {noformat}
> #Modified by paxexam
> #Mon Oct 10 21:45:07 CEST 2016
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4760) Upgrade to Felix FileInstall 3.5.6

2016-10-11 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on KARAF-4760:


Commit db9e2bfee3919bcb4aab703763cc3a12084a4a24 in karaf's branch 
refs/heads/karaf-4.0.x from [~jbonofre]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=db9e2bf ]

[KARAF-4760] Upgrade to Felix Fileinstall 3.5.6


> Upgrade to Felix FileInstall 3.5.6
> --
>
> Key: KARAF-4760
> URL: https://issues.apache.org/jira/browse/KARAF-4760
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Affects Versions: 4.0.7
>Reporter: Oliver Lietz
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Pax Exam adds comments (see below) to configuration files when they are 
> modified by calling e.g. {{editConfigurationFilePut(...)}} which renders 
> {{*.config}} files in tests invalid (FELIX-5261).
> {noformat}
> #Modified by paxexam
> #Mon Oct 10 21:45:07 CEST 2016
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (KARAF-4760) Upgrade to Felix FileInstall 3.5.6

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré reassigned KARAF-4760:
---

Assignee: Jean-Baptiste Onofré

> Upgrade to Felix FileInstall 3.5.6
> --
>
> Key: KARAF-4760
> URL: https://issues.apache.org/jira/browse/KARAF-4760
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Affects Versions: 4.0.7
>Reporter: Oliver Lietz
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Pax Exam adds comments (see below) to configuration files when they are 
> modified by calling e.g. {{editConfigurationFilePut(...)}} which renders 
> {{*.config}} files in tests invalid (FELIX-5261).
> {noformat}
> #Modified by paxexam
> #Mon Oct 10 21:45:07 CEST 2016
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4760) Upgrade to Felix FileInstall 3.5.6

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated KARAF-4760:

Issue Type: Dependency upgrade  (was: Improvement)

> Upgrade to Felix FileInstall 3.5.6
> --
>
> Key: KARAF-4760
> URL: https://issues.apache.org/jira/browse/KARAF-4760
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Affects Versions: 4.0.7
>Reporter: Oliver Lietz
> Fix For: 4.1.0, 4.0.8
>
>
> Pax Exam adds comments (see below) to configuration files when they are 
> modified by calling e.g. {{editConfigurationFilePut(...)}} which renders 
> {{*.config}} files in tests invalid (FELIX-5261).
> {noformat}
> #Modified by paxexam
> #Mon Oct 10 21:45:07 CEST 2016
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4760) Upgrade to Felix FileInstall 3.5.6

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated KARAF-4760:

Summary: Upgrade to Felix FileInstall 3.5.6  (was: Use Felix File Install 
3.5.6)

> Upgrade to Felix FileInstall 3.5.6
> --
>
> Key: KARAF-4760
> URL: https://issues.apache.org/jira/browse/KARAF-4760
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-core
>Affects Versions: 4.0.7
>Reporter: Oliver Lietz
> Fix For: 4.1.0, 4.0.8
>
>
> Pax Exam adds comments (see below) to configuration files when they are 
> modified by calling e.g. {{editConfigurationFilePut(...)}} which renders 
> {{*.config}} files in tests invalid (FELIX-5261).
> {noformat}
> #Modified by paxexam
> #Mon Oct 10 21:45:07 CEST 2016
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4760) Upgrade to Felix FileInstall 3.5.6

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated KARAF-4760:

Fix Version/s: 4.0.8
   4.1.0

> Upgrade to Felix FileInstall 3.5.6
> --
>
> Key: KARAF-4760
> URL: https://issues.apache.org/jira/browse/KARAF-4760
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Affects Versions: 4.0.7
>Reporter: Oliver Lietz
> Fix For: 4.1.0, 4.0.8
>
>
> Pax Exam adds comments (see below) to configuration files when they are 
> modified by calling e.g. {{editConfigurationFilePut(...)}} which renders 
> {{*.config}} files in tests invalid (FELIX-5261).
> {noformat}
> #Modified by paxexam
> #Mon Oct 10 21:45:07 CEST 2016
> {noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KARAF-4760) Use Felix File Install 3.5.6

2016-10-11 Thread Oliver Lietz (JIRA)

Oliver Lietz created KARAF-4760:
---

 Summary: Use Felix File Install 3.5.6
 Key: KARAF-4760
 URL: https://issues.apache.org/jira/browse/KARAF-4760
 Project: Karaf
  Issue Type: Improvement
  Components: karaf-core
Affects Versions: 4.0.7
Reporter: Oliver Lietz


Pax Exam adds comments (see below) to configuration files when they are 
modified by calling e.g. {{editConfigurationFilePut(...)}} which renders 
{{*.config}} files in tests invalid (FELIX-5261).

{noformat}
#Modified by paxexam
#Mon Oct 10 21:45:07 CEST 2016
{noformat}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (KARAF-4759) Unable to retrieve full list of features via jmx by calling cellar feature bean operation getFeatures

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré reassigned KARAF-4759:
---

Assignee: Jean-Baptiste Onofré

> Unable to retrieve full list of features via jmx by calling cellar feature 
> bean operation getFeatures
> -
>
> Key: KARAF-4759
> URL: https://issues.apache.org/jira/browse/KARAF-4759
> Project: Karaf
>  Issue Type: Bug
>  Components: cellar-features
>Affects Versions: cellar-4.0.1, cellar-4.0.2
>Reporter: Joel
>Assignee: Jean-Baptiste Onofré
> Fix For: cellar-4.0.3
>
>
> Stack trace when calling getFeatures cellar mbean using "default" as the 
> cellar group
> java.lang.IllegalArgumentException: Array arguments itemNames[], 
> itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).
> The issue is happening in CellarFeaturesMBeanImpl line number 288 when 
> defining OpenType[] array



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4759) Unable to retrieve full list of features via jmx by calling cellar feature bean operation getFeatures

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated KARAF-4759:

Fix Version/s: cellar-4.0.3

> Unable to retrieve full list of features via jmx by calling cellar feature 
> bean operation getFeatures
> -
>
> Key: KARAF-4759
> URL: https://issues.apache.org/jira/browse/KARAF-4759
> Project: Karaf
>  Issue Type: Bug
>  Components: cellar-features
>Affects Versions: cellar-4.0.1, cellar-4.0.2
>Reporter: Joel
>Assignee: Jean-Baptiste Onofré
> Fix For: cellar-4.0.3
>
>
> Stack trace when calling getFeatures cellar mbean using "default" as the 
> cellar group
> java.lang.IllegalArgumentException: Array arguments itemNames[], 
> itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).
> The issue is happening in CellarFeaturesMBeanImpl line number 288 when 
> defining OpenType[] array



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4759) Unable to retrieve full list of features via jmx by calling cellar feature bean operation getFeatures

2016-10-11 Thread Joel (JIRA)


 [ 
https://issues.apache.org/jira/browse/KARAF-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel updated KARAF-4759:

Description: 
Stack trace when calling getFeatures cellar mbean using "default" as the cellar 
group

java.lang.IllegalArgumentException: Array arguments itemNames[], 
itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).


The issue is happening in CellarFeaturesMBeanImpl line number 288 when defining 
OpenType[] array

  was:
Stack trace when calling getFeatures cellar mbean using "default" as the cellar 
group

java.lang.IllegalArgumentException: Array arguments itemNames[], 
itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).


> Unable to retrieve full list of features via jmx by calling cellar feature 
> bean operation getFeatures
> -
>
> Key: KARAF-4759
> URL: https://issues.apache.org/jira/browse/KARAF-4759
> Project: Karaf
>  Issue Type: Bug
>  Components: cellar-features
>Affects Versions: cellar-4.0.1, cellar-4.0.2
>Reporter: Joel
>
> Stack trace when calling getFeatures cellar mbean using "default" as the 
> cellar group
> java.lang.IllegalArgumentException: Array arguments itemNames[], 
> itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).
> The issue is happening in CellarFeaturesMBeanImpl line number 288 when 
> defining OpenType[] array



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4759) Unable to retrieve full list of features via jmx by calling cellar feature bean operation getFeatures

2016-10-11 Thread Joel (JIRA)


 [ 
https://issues.apache.org/jira/browse/KARAF-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel updated KARAF-4759:

Affects Version/s: cellar-4.0.1

> Unable to retrieve full list of features via jmx by calling cellar feature 
> bean operation getFeatures
> -
>
> Key: KARAF-4759
> URL: https://issues.apache.org/jira/browse/KARAF-4759
> Project: Karaf
>  Issue Type: Bug
>  Components: cellar-features
>Affects Versions: cellar-4.0.1, cellar-4.0.2
>Reporter: Joel
>
> Stack trace when calling getFeatures cellar mbean using "default" as the 
> cellar group
> java.lang.IllegalArgumentException: Array arguments itemNames[], 
> itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).
> The issue is happening in CellarFeaturesMBeanImpl line number 288 when 
> defining OpenType[] array



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4759) Unable to retrieve full list of features via jmx by calling cellar feature bean operation getFeatures

2016-10-11 Thread Joel (JIRA)


 [ 
https://issues.apache.org/jira/browse/KARAF-4759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Joel updated KARAF-4759:

Description: 
Stack trace when calling getFeatures cellar mbean using "default" as the cellar 
group

java.lang.IllegalArgumentException: Array arguments itemNames[], 
itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).

  was:
Stack trace when calling getFeatures cellar mbean

java.lang.IllegalArgumentException: Array arguments itemNames[], 
itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).


> Unable to retrieve full list of features via jmx by calling cellar feature 
> bean operation getFeatures
> -
>
> Key: KARAF-4759
> URL: https://issues.apache.org/jira/browse/KARAF-4759
> Project: Karaf
>  Issue Type: Bug
>  Components: cellar-features
>Affects Versions: cellar-4.0.2
>Reporter: Joel
>
> Stack trace when calling getFeatures cellar mbean using "default" as the 
> cellar group
> java.lang.IllegalArgumentException: Array arguments itemNames[], 
> itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré resolved KARAF-4758.
-
Resolution: Fixed

> Upgrade to Aries Transaction Manager 1.3.1
> --
>
> Key: KARAF-4758
> URL: https://issues.apache.org/jira/browse/KARAF-4758
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Reporter: Marc Durand
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Aries Transaction Manager 1.3.1 provides a fix that prevents the 
> TransactionManager from being re-published to the OSGi registry upon startup 
> of Karaf.
> See: https://issues.apache.org/jira/browse/ARIES-1621



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on KARAF-4758:
---

Github user asfgit closed the pull request at:

https://github.com/apache/karaf/pull/247


> Upgrade to Aries Transaction Manager 1.3.1
> --
>
> Key: KARAF-4758
> URL: https://issues.apache.org/jira/browse/KARAF-4758
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Reporter: Marc Durand
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Aries Transaction Manager 1.3.1 provides a fix that prevents the 
> TransactionManager from being re-published to the OSGi registry upon startup 
> of Karaf.
> See: https://issues.apache.org/jira/browse/ARIES-1621



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on KARAF-4758:


Commit a70420f6557d8eae24b2fb4329695b5a3b7edbf0 in karaf's branch 
refs/heads/karaf-4.0.x from [~marc.durand]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=a70420f ]

[KARAF-4758] Upgrade to Aries Transaction Manager 1.3.1


> Upgrade to Aries Transaction Manager 1.3.1
> --
>
> Key: KARAF-4758
> URL: https://issues.apache.org/jira/browse/KARAF-4758
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Reporter: Marc Durand
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Aries Transaction Manager 1.3.1 provides a fix that prevents the 
> TransactionManager from being re-published to the OSGi registry upon startup 
> of Karaf.
> See: https://issues.apache.org/jira/browse/ARIES-1621



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on KARAF-4758:


Commit 289b2b0f86e33bb1a661ddadc6eba330433bb526 in karaf's branch 
refs/heads/master from [~marc.durand]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=289b2b0 ]

[KARAF-4758] Upgrade to Aries Transaction Manager 1.3.1


> Upgrade to Aries Transaction Manager 1.3.1
> --
>
> Key: KARAF-4758
> URL: https://issues.apache.org/jira/browse/KARAF-4758
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Reporter: Marc Durand
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Aries Transaction Manager 1.3.1 provides a fix that prevents the 
> TransactionManager from being re-published to the OSGi registry upon startup 
> of Karaf.
> See: https://issues.apache.org/jira/browse/ARIES-1621



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on KARAF-4758:


Commit e1ad33c572ef0d4aed8c429502e5bc128e7fb0d3 in karaf's branch 
refs/heads/master from [~jbonofre]
[ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=e1ad33c ]

[KARAF-4758] This closes #247


> Upgrade to Aries Transaction Manager 1.3.1
> --
>
> Key: KARAF-4758
> URL: https://issues.apache.org/jira/browse/KARAF-4758
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Reporter: Marc Durand
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Aries Transaction Manager 1.3.1 provides a fix that prevents the 
> TransactionManager from being re-published to the OSGi registry upon startup 
> of Karaf.
> See: https://issues.apache.org/jira/browse/ARIES-1621



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré updated KARAF-4758:

Affects Version/s: (was: 4.0.7)

> Upgrade to Aries Transaction Manager 1.3.1
> --
>
> Key: KARAF-4758
> URL: https://issues.apache.org/jira/browse/KARAF-4758
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Reporter: Marc Durand
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Aries Transaction Manager 1.3.1 provides a fix that prevents the 
> TransactionManager from being re-published to the OSGi registry upon startup 
> of Karaf.
> See: https://issues.apache.org/jira/browse/ARIES-1621



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KARAF-4759) Unable to retrieve full list of features via jmx by calling cellar feature bean operation getFeatures

2016-10-11 Thread Joel (JIRA)

Joel created KARAF-4759:
---

 Summary: Unable to retrieve full list of features via jmx by 
calling cellar feature bean operation getFeatures
 Key: KARAF-4759
 URL: https://issues.apache.org/jira/browse/KARAF-4759
 Project: Karaf
  Issue Type: Bug
  Components: cellar-features
Affects Versions: cellar-4.0.2
Reporter: Joel


Stack trace when calling getFeatures cellar mbean

java.lang.IllegalArgumentException: Array arguments itemNames[], 
itemDescriptions[] and itemTypes[] should be of same length (got 5, 5 and 3).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread JIRA


 [ 
https://issues.apache.org/jira/browse/KARAF-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jean-Baptiste Onofré reassigned KARAF-4758:
---

Assignee: Jean-Baptiste Onofré

> Upgrade to Aries Transaction Manager 1.3.1
> --
>
> Key: KARAF-4758
> URL: https://issues.apache.org/jira/browse/KARAF-4758
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Affects Versions: 4.0.7
>Reporter: Marc Durand
>Assignee: Jean-Baptiste Onofré
> Fix For: 4.1.0, 4.0.8
>
>
> Aries Transaction Manager 1.3.1 provides a fix that prevents the 
> TransactionManager from being re-published to the OSGi registry upon startup 
> of Karaf.
> See: https://issues.apache.org/jira/browse/ARIES-1621



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread ASF GitHub Bot (JIRA)


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

ASF GitHub Bot commented on KARAF-4758:
---

GitHub user mdurand76 opened a pull request:

https://github.com/apache/karaf/pull/247

Update pom.xml

KARAF-4758 - Upgrade to Aries Transaction Manager 1.3.1

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/mdurand76/karaf patch-1

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/karaf/pull/247.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #247


commit 3d1c3e44504268255d0f8c0136d07679f17dc9b9
Author: Marc Durand 
Date:   2016-10-11T16:26:28Z

Update pom.xml




> Upgrade to Aries Transaction Manager 1.3.1
> --
>
> Key: KARAF-4758
> URL: https://issues.apache.org/jira/browse/KARAF-4758
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Affects Versions: 4.0.7
>Reporter: Marc Durand
>
> Aries Transaction Manager 1.3.1 provides a fix that prevents the 
> TransactionManager from being re-published to the OSGi registry upon startup 
> of Karaf.
> See: https://issues.apache.org/jira/browse/ARIES-1621



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread Marc Durand (JIRA)


 [ 
https://issues.apache.org/jira/browse/KARAF-4758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Marc Durand updated KARAF-4758:
---
Description: 
Aries Transaction Manager 1.3.1 provides a fix that prevents the 
TransactionManager from being re-published to the OSGi registry upon startup of 
Karaf.

See: https://issues.apache.org/jira/browse/ARIES-1621

  was:Aries Transaction Manager 1.3.1 provides a fix that prevents the 
TransactionManager from being re-published to the OSGi registry upon startup of 
Karaf.


> Upgrade to Aries Transaction Manager 1.3.1
> --
>
> Key: KARAF-4758
> URL: https://issues.apache.org/jira/browse/KARAF-4758
> Project: Karaf
>  Issue Type: Dependency upgrade
>  Components: karaf-core
>Affects Versions: 4.0.7
>Reporter: Marc Durand
>
> Aries Transaction Manager 1.3.1 provides a fix that prevents the 
> TransactionManager from being re-published to the OSGi registry upon startup 
> of Karaf.
> See: https://issues.apache.org/jira/browse/ARIES-1621



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KARAF-4758) Upgrade to Aries Transaction Manager 1.3.1

2016-10-11 Thread Marc Durand (JIRA)

Marc Durand created KARAF-4758:
--

 Summary: Upgrade to Aries Transaction Manager 1.3.1
 Key: KARAF-4758
 URL: https://issues.apache.org/jira/browse/KARAF-4758
 Project: Karaf
  Issue Type: Dependency upgrade
  Components: karaf-core
Affects Versions: 4.0.7
Reporter: Marc Durand


Aries Transaction Manager 1.3.1 provides a fix that prevents the 
TransactionManager from being re-published to the OSGi registry upon startup of 
Karaf.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4719) Aether cannot to resolve m2 repositories after adjustments in org.ops4j.pax.url.mvn.cfg

2016-10-11 Thread Grzegorz Grzybek (JIRA)


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

Grzegorz Grzybek commented on KARAF-4719:
-

Increasing start-level for pax-url-aether is good workaround, but it still 
isn't 100% reliable (estimated increas from 50% reliable to 95% reliable).

Without actual change to pax-url-aether, to make it wait for ConfigurationAdmin 
there's no 100% way of making this work. But pax-url-aether *can* run without 
Configuration Admin...

[~gnt], [~jbonofre] what do you think about increasing start-level for 
pax-url-aether?

> Aether cannot to resolve m2 repositories after adjustments in 
> org.ops4j.pax.url.mvn.cfg
> ---
>
> Key: KARAF-4719
> URL: https://issues.apache.org/jira/browse/KARAF-4719
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Antonio Maria
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Start levels for pax-url-aether(5) and org.apache.felix.configadmin(10) are 
> defined in framework xml feature. Therefore pax url aether is configured 
> after org.ops4j.pax.url.mvn.local properties are loaded.
> This causes that in case of assemble Karaf using offline repository, by 
> adjusting:
> {code}
> org.ops4j.pax.url.mvn.localRepository=${karaf.home}/${karaf.default.repository}
> {code}
> Don't really work, because is too late for aether, that is already started.
> Eventually causes an error when karaf starts. The error is quite random, and 
> happens quite often when karaf starts using the wrapper as a windows services.
> By decreasing the aether starts level to any value after felix configadmin, 
> it improves the bootstrap robustness when creating offline distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (KARAF-4757) Decanter: elasticsearch-appender-rest shouldn't be dependent on http

2016-10-11 Thread Achim Nierbeck (JIRA)


 [ 
https://issues.apache.org/jira/browse/KARAF-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Achim Nierbeck resolved KARAF-4757.
---
Resolution: Fixed

fixed with last commit: 
http://git-wip-us.apache.org/repos/asf/karaf-decanter/commit/469591ba

> Decanter: elasticsearch-appender-rest shouldn't be dependent on http
> 
>
> Key: KARAF-4757
> URL: https://issues.apache.org/jira/browse/KARAF-4757
> Project: Karaf
>  Issue Type: Bug
>  Components: decanter
>Affects Versions: decanter-1.2.0
>Reporter: Achim Nierbeck
>Assignee: Achim Nierbeck
> Fix For: decanter-1.3.0
>
>
> Right now the feature of the elasticsearch rest appender requires http, for 
> no reason. The Import-Packages does have javax.servlet as import but non are 
> required. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4757) Decanter: elasticsearch-appender-rest shouldn't be dependent on http

2016-10-11 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on KARAF-4757:


Commit 469591ba9e1bae0349b27443706626846a9ee155 in karaf-decanter's branch 
refs/heads/master from [~achim_nierbeck]
[ https://git-wip-us.apache.org/repos/asf?p=karaf-decanter.git;h=469591b ]

[KARAF-4757] - Decanter: elasticsearch-appender-rest shouldn't be dependent on 
http


> Decanter: elasticsearch-appender-rest shouldn't be dependent on http
> 
>
> Key: KARAF-4757
> URL: https://issues.apache.org/jira/browse/KARAF-4757
> Project: Karaf
>  Issue Type: Bug
>  Components: decanter
>Affects Versions: decanter-1.2.0
>Reporter: Achim Nierbeck
>Assignee: Achim Nierbeck
> Fix For: decanter-1.3.0
>
>
> Right now the feature of the elasticsearch rest appender requires http, for 
> no reason. The Import-Packages does have javax.servlet as import but non are 
> required. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4513) pax-url-aether fails to resolve test-jar artifacts from local repo

2016-10-11 Thread Felix Wassmer (JIRA)


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

Felix Wassmer commented on KARAF-4513:
--

After some further investigation I've discovered that the repo discovery was 
changed in pax-url-aether 2.4.7.
In the default configuration with Pax Exam, pax-url-aether doesn't seem to have 
the local repo added and looks straight in maven-central.

As workarround adding the property "org.ops4j.pax.url.mvn.defaultRepositories" 
with the value ""file://" + System.getProperty( "user.home" ) + 
"/.m2/repository@id=local.repository@snapshots" to the pax exam options helps.

> pax-url-aether fails to resolve test-jar artifacts from local repo
> --
>
> Key: KARAF-4513
> URL: https://issues.apache.org/jira/browse/KARAF-4513
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 4.0.5
> Environment: JDK 1.8, Win7 x64
>Reporter: Felix Wassmer
>
> Since the version upgrade to pax-url-aether 2.4.7 of KARAF-4477 
> Karaf fails to locate maven dependencies of the type test-jar from the local 
> repository and tries to fetch it from central.
> Every other type is properly resolved from the local repo.
> Current use case:
> Pax exam test has a dependency on the artifact
> {code:xml}
> 
> org.broken.test
> broken-test-util
> 1.0.0.POM-TEST
> test-jar
> test
> 
> {code}
> which causes following execption on startup:
> {noformat}
> 2016-04-29T14:26:45,864 | WARN  | pool-11-thread-7 | 5   - 
> 4j.pax.logging.pax-logging-api - 1.8.5  | AetherBasedResolver 
>  | Error resolving artifact 
> org.broken.test:broken-test-util:jar:tests:1.0.0.POM-TEST:Could not find 
> artifact org.broken.test:broken-test-util:jar:tests:1.0.0.POM-TEST in central 
> (http://repo1.maven.org/maven2/)
> shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Could not 
> find artifact org.broken.test:broken-test-util:jar:tests:1.0.0.POM-TEST in 
> central (http://repo1.maven.org/maven2/)
>   at 
> shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:650)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:576)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:550)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:34)
>  [9:org.apache.karaf.features.core:4.0.5]
>   at 
> org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:58)
>  [9:org.apache.karaf.features.core:4.0.5]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  [?:?]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [?:?]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:?]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [?:?]
>   at java.lang.Thread.run(Thread.java:745) [?:?]
> Caused by: shaded.org.eclipse.aether.transfer.ArtifactNotFoundException: 
> Could not find artifact 
> org.broken.test:broken-test-util:jar:tests:1.0.0.POM-TEST in central 
> (http://repo1.maven.org/maven2/)
>   at 
> shaded.org.eclipse.aether.connector.basic.ArtifactTransportListener.transferFailed(ArtifactTransportListener.java:39)
>  ~[?:?]
>   at 
> shaded.org.eclipse.aether.connector.basic.BasicRepositoryConnector$TaskRunner.run(BasicRepositoryConnector.java:355)
>  ~[?:?]
>   at 
>

[jira] [Created] (KARAF-4757) Decanter: elasticsearch-appender-rest shouldn't be dependent on http

2016-10-11 Thread Achim Nierbeck (JIRA)

Achim Nierbeck created KARAF-4757:
-

 Summary: Decanter: elasticsearch-appender-rest shouldn't be 
dependent on http
 Key: KARAF-4757
 URL: https://issues.apache.org/jira/browse/KARAF-4757
 Project: Karaf
  Issue Type: Bug
  Components: decanter
Affects Versions: decanter-1.2.0
Reporter: Achim Nierbeck
Assignee: Achim Nierbeck
 Fix For: decanter-1.3.0


Right now the feature of the elasticsearch rest appender requires http, for no 
reason. The Import-Packages does have javax.servlet as import but non are 
required. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Work started] (KARAF-4757) Decanter: elasticsearch-appender-rest shouldn't be dependent on http

2016-10-11 Thread Achim Nierbeck (JIRA)


 [ 
https://issues.apache.org/jira/browse/KARAF-4757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Work on KARAF-4757 started by Achim Nierbeck.
-
> Decanter: elasticsearch-appender-rest shouldn't be dependent on http
> 
>
> Key: KARAF-4757
> URL: https://issues.apache.org/jira/browse/KARAF-4757
> Project: Karaf
>  Issue Type: Bug
>  Components: decanter
>Affects Versions: decanter-1.2.0
>Reporter: Achim Nierbeck
>Assignee: Achim Nierbeck
> Fix For: decanter-1.3.0
>
>
> Right now the feature of the elasticsearch rest appender requires http, for 
> no reason. The Import-Packages does have javax.servlet as import but non are 
> required. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (KARAF-4513) pax-url-aether fails to resolve test-jar artifacts from local repo

2016-10-11 Thread Felix Wassmer (JIRA)


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

Felix Wassmer edited comment on KARAF-4513 at 10/11/16 1:49 PM:


The test-jar is artifact is a stand alone project, which is being built / 
installed beforehand and referenced by the pax-exam test as dependency (as 
shown in the description).
The artifact "...-tests.jar" exists in the local repo.

Karaf 4.0.4 has no issues to locate the artifact and when switchting 
pax-url-aether to 2.4.5 in Karaf 4.0.5 it also gets resolved without any issues.


was (Author: fwassmer):
The test-jar is artifact is a stand alone project, which is being built / 
installed beforehand and referenced by the pax-exam test as dependency (as 
shown in the description).
The artifact "...-tests.jar" exists in the local repo.

Karaf 4.0.4 has no issues to locate the artifact and when switchting 
pax-url-aether to 2.4.6 in Karaf 4.0.5 it also gets resolved without any issues.

> pax-url-aether fails to resolve test-jar artifacts from local repo
> --
>
> Key: KARAF-4513
> URL: https://issues.apache.org/jira/browse/KARAF-4513
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-core
>Affects Versions: 4.0.5
> Environment: JDK 1.8, Win7 x64
>Reporter: Felix Wassmer
>
> Since the version upgrade to pax-url-aether 2.4.7 of KARAF-4477 
> Karaf fails to locate maven dependencies of the type test-jar from the local 
> repository and tries to fetch it from central.
> Every other type is properly resolved from the local repo.
> Current use case:
> Pax exam test has a dependency on the artifact
> {code:xml}
> 
> org.broken.test
> broken-test-util
> 1.0.0.POM-TEST
> test-jar
> test
> 
> {code}
> which causes following execption on startup:
> {noformat}
> 2016-04-29T14:26:45,864 | WARN  | pool-11-thread-7 | 5   - 
> 4j.pax.logging.pax-logging-api - 1.8.5  | AetherBasedResolver 
>  | Error resolving artifact 
> org.broken.test:broken-test-util:jar:tests:1.0.0.POM-TEST:Could not find 
> artifact org.broken.test:broken-test-util:jar:tests:1.0.0.POM-TEST in central 
> (http://repo1.maven.org/maven2/)
> shaded.org.eclipse.aether.resolution.ArtifactResolutionException: Could not 
> find artifact org.broken.test:broken-test-util:jar:tests:1.0.0.POM-TEST in 
> central (http://repo1.maven.org/maven2/)
>   at 
> shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolve(DefaultArtifactResolver.java:444)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifacts(DefaultArtifactResolver.java:246)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> shaded.org.eclipse.aether.internal.impl.DefaultArtifactResolver.resolveArtifact(DefaultArtifactResolver.java:223)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> shaded.org.eclipse.aether.internal.impl.DefaultRepositorySystem.resolveArtifact(DefaultRepositorySystem.java:294)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:650)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:598)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:576)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.ops4j.pax.url.mvn.internal.AetherBasedResolver.resolve(AetherBasedResolver.java:550)
>  [4:org.ops4j.pax.url.mvn:2.4.7]
>   at 
> org.apache.karaf.features.internal.download.impl.MavenDownloadTask.download(MavenDownloadTask.java:34)
>  [9:org.apache.karaf.features.core:4.0.5]
>   at 
> org.apache.karaf.features.internal.download.impl.AbstractRetryableDownloadTask.run(AbstractRetryableDownloadTask.java:58)
>  [9:org.apache.karaf.features.core:4.0.5]
>   at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) [?:?]
>   at java.util.concurrent.FutureTask.run(FutureTask.java:266) [?:?]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
>  [?:?]
>   at 
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
>  [?:?]
>   at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [?:?]
>   at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [?:?]
>   at java.lang.Thread.run(Thread.java:745) [?:?]
> Caused by: shaded.org.eclipse.aether.transfer.ArtifactNotFoundException: 
> Could not find artifact 
>

[jira] [Commented] (KARAF-4719) Aether cannot to resolve m2 repositories after adjustments in org.ops4j.pax.url.mvn.cfg

2016-10-11 Thread Antonio Maria (JIRA)


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

Antonio Maria commented on KARAF-4719:
--

My workaround doesn't require any "duplications" just modifying:

etc/startup.properties line8
from:
mvn\:org.ops4j.pax.url/pax-url-aether/2.4.7 = 5
to 
mvn\:org.ops4j.pax.url/pax-url-aether/2.4.7 = 14

I just would like not to apply that "workaround" during my build process. In 
other words: To take the change into use in karaf code base.

Does it help if I made a push request?


> Aether cannot to resolve m2 repositories after adjustments in 
> org.ops4j.pax.url.mvn.cfg
> ---
>
> Key: KARAF-4719
> URL: https://issues.apache.org/jira/browse/KARAF-4719
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Antonio Maria
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Start levels for pax-url-aether(5) and org.apache.felix.configadmin(10) are 
> defined in framework xml feature. Therefore pax url aether is configured 
> after org.ops4j.pax.url.mvn.local properties are loaded.
> This causes that in case of assemble Karaf using offline repository, by 
> adjusting:
> {code}
> org.ops4j.pax.url.mvn.localRepository=${karaf.home}/${karaf.default.repository}
> {code}
> Don't really work, because is too late for aether, that is already started.
> Eventually causes an error when karaf starts. The error is quite random, and 
> happens quite often when karaf starts using the wrapper as a windows services.
> By decreasing the aether starts level to any value after felix configadmin, 
> it improves the bootstrap robustness when creating offline distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-3342) Version 3.0.2 ignores maven settings, proxy and mirrors in particular

2016-10-11 Thread Grzegorz Grzybek (JIRA)


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

Grzegorz Grzybek commented on KARAF-3342:
-

This is fixed in pax-web 2.3.0 (https://ops4j1.jira.com/browse/PAXURL-293) → 
Karaf 3.0.3. Karaf 3.0.2 used pax-url 2.2.0.

> Version 3.0.2 ignores maven settings, proxy and mirrors in particular
> -
>
> Key: KARAF-3342
> URL: https://issues.apache.org/jira/browse/KARAF-3342
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 3.0.2
>Reporter: Sergey 
>
> When trying to install almost any feature I'm getting an error:
> Error executing command: Error resolving artifact 
> org.apache.karaf.http:org.apache.karaf.http.core:jar:3.0.2: Could not 
> transfer artifact org.apache.karaf.http:org.apache.karaf.http.core:jar:3.0.2 
> from/to central (http://repo1.maven.org/maven2/): Error transferring file: 
> Server returned HTTP response code: 407 for URL: 
> http://repo1.maven.org/maven2/org/apache/karaf/http/org.apache.karaf.http.core/3.0.2/org.apache.karaf.http.core-3.0.2.jar
>  from 
> http://repo1.maven.org/maven2/org/apache/karaf/http/org.apache.karaf.http.core/3.0.2/org.apache.karaf.http.core-3.0.2.jar
>  with proxyInfo ProxyInfo{host='10.10.100.248', userName='null', port=8080, 
> type='http', nonProxyHosts='null'}
> Where is maven mirror (Nexus server) for * or repositories, and also proxy 
> settings in .m2/settings.xml, looks like both are also ignored partially (no 
> proxy username and no nonProxyHosts in this message).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-2976) Karaf doesn't support encrypted passwords in the Maven settings file

2016-10-11 Thread Grzegorz Grzybek (JIRA)


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

Grzegorz Grzybek commented on KARAF-2976:
-

Karaf 3.0.1 uses pax-url 1.6.0.
https://ops4j1.jira.com/browse/PAXURL-133 was fixed with pax-url 2.0.0.

> Karaf doesn't support encrypted passwords in the Maven settings file
> 
>
> Key: KARAF-2976
> URL: https://issues.apache.org/jira/browse/KARAF-2976
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 3.0.1
> Environment: Mac OS 10.9.2
> Oracle JDK 1.7.0_21
> Apache Maven 3.0.5
>Reporter: Jan Van den Bergh
>
> I use a Maven mirror to retrieve maven artifacts. The password in 
> ~/.m2/settings.xml to access the mirror is encrypted (see 
> http://maven.apache.org/guides/mini/guide-encryption.html). Karaf is unable 
> to download bundles due to an access denied failure.
> When I put my unencrypted password in the file, the download works fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-1674) Abnormal Timeout with multiple maven repositories in pax-url

2016-10-11 Thread Grzegorz Grzybek (JIRA)


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

Grzegorz Grzybek commented on KARAF-1674:
-

https://ops4j1.jira.com/browse/PAXURL-335 fixes usage of timeouts with pax-url 
2.5.0

> Abnormal Timeout with multiple maven repositories in pax-url
> 
>
> Key: KARAF-1674
> URL: https://issues.apache.org/jira/browse/KARAF-1674
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 2.2.8
> Environment: karaf 2.2.8 with equinox running on debian with java 
> 1.7.0_03
>Reporter: Sammy Ramareddy
>
> I'm having a strange issue where karaf needs a lot of time (around 
> 5-10minutes) to generate for the first time the "features" tab in the 
> webconsole or give some feedback to a "features:list" command in the ssh 
> console.
> I currently have the following urls configured in 
> $KARAF_HOME/etc/org.ops4j.pax.url.mvn.cfg:
> org.ops4j.pax.url.mvn.repositories= \
> http://192.168.2.224:8080/artifactory/repo@snapshots, \
> http://i0019231.subdomain.domain.tld:8080/artifactory/repo@snapshots
> The second url is actually pointing to the same artifactory repository as the 
> first one, just running with another IP (within our VPN subnet).
> Once in production, karaf will run outside our network and will need to reach 
> our artifactory server through a VPN connection, hence the need for two urls.
> The problem is the following: when the VPN connection is *not* running, and 
> thus "i0019231.subdomain.domain.tld" is not reachable (its IP is 172.21.x.x), 
> karaf needs 5-10 minutes to be able to start the features-plugin.
> When this is happening, the following entry is in the Karaf log:
> "failed to open bundleresource://78.fwk10937487/"
> where bundle 78 is org.apache.karaf.webconsole.features
> This issue happens only when the VPN client is not running and thus the 
> second repository is not reachable. When the second url is reachable, then 
> everything runs fine.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4719) Aether cannot to resolve m2 repositories after adjustments in org.ops4j.pax.url.mvn.cfg

2016-10-11 Thread Grzegorz Grzybek (JIRA)


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

Grzegorz Grzybek commented on KARAF-4719:
-

This is the same issue as KARAF-4100. With the same _workaround_ - just 
duplicate {{org.ops4j.pax.url.mvn.*}} properties from 
{{etc/org.ops4j.pax.url.mvn.cfg}} in {{etc/config.properties}}.

> Aether cannot to resolve m2 repositories after adjustments in 
> org.ops4j.pax.url.mvn.cfg
> ---
>
> Key: KARAF-4719
> URL: https://issues.apache.org/jira/browse/KARAF-4719
> Project: Karaf
>  Issue Type: Bug
>Affects Versions: 4.0.5, 4.0.6
>Reporter: Antonio Maria
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> Start levels for pax-url-aether(5) and org.apache.felix.configadmin(10) are 
> defined in framework xml feature. Therefore pax url aether is configured 
> after org.ops4j.pax.url.mvn.local properties are loaded.
> This causes that in case of assemble Karaf using offline repository, by 
> adjusting:
> {code}
> org.ops4j.pax.url.mvn.localRepository=${karaf.home}/${karaf.default.repository}
> {code}
> Don't really work, because is too late for aether, that is already started.
> Eventually causes an error when karaf starts. The error is quite random, and 
> happens quite often when karaf starts using the wrapper as a windows services.
> By decreasing the aether starts level to any value after felix configadmin, 
> it improves the bootstrap robustness when creating offline distribution.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-846) Better support of Maven proxies

2016-10-11 Thread Grzegorz Grzybek (JIRA)


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

Grzegorz Grzybek commented on KARAF-846:


pax-url-aether uses wagon-http→httpclient, not 
wagon-http-lightweight→URL.openConnection().

Maven proxies are handled via settings.xml: 
http://ggrzybek.blogspot.com/2016/07/using-maven-with-osgi-part-2.html#org.ops4j.pax.url.mvn.settings

> Better support of Maven proxies
> ---
>
> Key: KARAF-846
> URL: https://issues.apache.org/jira/browse/KARAF-846
> Project: Karaf
>  Issue Type: Improvement
>  Components: karaf-core
>Reporter: Jean-Baptiste Onofré
>
> Currently, to support a Maven proxy, the user has to update the 
> etc/org.ops4j.pax.url.mvn.cfg file to enable the proxy support.
> After enabling the proxy, he has to change the Karaf startup script to add 
> -Dhttp.proxyHost, -Dhttp.proxyPort, etc.
> It could be helpful to handle the proxy URL and/or proxy settings directly in 
> the etc/org.ops4j.pax.url.mvn.cfg file, and avoid to handle that with global 
> System properties.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-955) Confusing behavior of ConfigAdmin

2016-10-11 Thread Grzegorz Grzybek (JIRA)


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

Grzegorz Grzybek commented on KARAF-955:


Yes, it is. It's happening anyway, but {{etc/}} _belongs_ to fileinstall 
component. And fileinstall reads the data, compares if anything has changed and 
updates configadmin configurations then. In the meantime, configadmin component 
does its job as well - serving/providing configuration data to other components.

In OSGi many things happen in parallel. You, by very nature of OSGi, can't 
_shape_ each quantum moment of the framework. You rather tell the framework to 
transition into different state.

> Confusing behavior of ConfigAdmin
> -
>
> Key: KARAF-955
> URL: https://issues.apache.org/jira/browse/KARAF-955
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-config
>Affects Versions: 2.2.4
>Reporter: Sergey Zhemzhitsky
>
> Hi there,
> I've faced with the following behavior of ConfigAdmin which I suppose is a 
> little bit confusing.
> Steps to reproduce:
> # Start Karaf
> # Go to *$\{karaf.home}/data/log* directory
> # *karaf.log* file should be there
> # Stop Karaf
> # Go to *$\{karaf.home}/data/log* directory and delete *karaf.log* file
> # When Karaf is stopped change *log4j.appender.out.file* property in the 
> *$\{karaf.home}/etc/org.ops4j.pax.logging.cfg* file from 
> *$\{karaf.data}/log/karaf.log* to *$\{karaf.data}/log/karaf1.log*
> # Start Karaf
> # Go to *$\{karaf.home}/data/log* directory
> # Only *karaf1.log* file is expected to be there, but empty *karaf.log* that 
> has been deleted on the step 4 is also there.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4100) [karaf-3.0.x] Error resolving artifact of feature due to org.ops4j.pax.url.mvn.cfg not loaded yet

2016-10-11 Thread Grzegorz Grzybek (JIRA)


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

Grzegorz Grzybek commented on KARAF-4100:
-

For me, the workaround was to put exactly the same set of 
{{org.ops4j.pax.url.mvn.*}} properties to {{etc/config.properties}} file.
pax-url-aether, when starting checks if configuration for this PID is available 
(or if configadmin service is available at all). In case it doesn't find the 
config, it calls {{org.osgi.framework.BundleContext#getProperty()}} which uses 
{{etc/config.properties}} as a source.

It's obvious duplication, but it works without problems.

Other solution would be to reimplement 
{{org.ops4j.pax.url.mvn.internal.Activator#start()}}, but this issue should be 
created at https://ops4j1.jira.com/browse/PAXURL.

> [karaf-3.0.x] Error resolving artifact of feature due to 
> org.ops4j.pax.url.mvn.cfg not loaded yet
> -
>
> Key: KARAF-4100
> URL: https://issues.apache.org/jira/browse/KARAF-4100
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 3.0.5
> Environment: Karaf 3.0.4, Windows 7
>Reporter: Jerry Meng
>
> I set the mvn repository to the karaf_home/system directory in 
> org.ops4j.pax.url.mvn.cfg.
> However, I found there is a chance that Karaf was trying to access the 
> Internet and threw an exception since it's in a closed environment.
> {code}
> Error resolving artifact 
> org.apache.karaf.features:enterprise:xml:features:3.0.4: Could not transfer 
> artifact org.apache.karaf.features:enterprise:xml:features:3.0.4 from/to  
> (http://mvn.mycompany.net/content/groups/public): Not authorized , 
> ReasonPhrase:Unauthorized.
> {code}
> Root Cause
> =
> Through further tracking, the root cause may happen in 
> org.ops4j.pax.url.mvn.internal.Activator (pax-url-aether). The pax url fails 
> to load org.ops4j.pax.url.mvn.cfg before Karaf connects the feature url. 
> Therefore Karaf ignores my settings in the configuration file but tries to 
> access default remote repository. Here are some logs to describe the 
> situation...
> {code}
> 1. activator.updated.dictionary: null
> 2. updated directory from safeRegisterService: null
> 3. activator.openConnection: 
> mvn:org.apache.karaf.features/enterprise/3.0.4/xml/features
> 4. Unable to add features repository 
> mvn:org.apache.karaf.features/enterprise/3.0.4/xml/features at startup
> 5. updated directory from safeRegisterService: 
> {felix.fileinstall.filename={file:/D:/karaf/etc/org.ops4j.pax.url.mvn.cfg... }
> 6. activator.updated.dictionary: 
> {felix.fileinstall.filename={file:/D:/karaf/etc/org.ops4j.pax.url.mvn.cfg... }
> {code}
> Workaround
> =
> I'm not sure if I should call this a bug, but in my case I can assume 
> org.ops4j.pax.url.mvn.cfg is existent definitely.
> Therefore, I make Activator.openConnection to wait if the Dictionary is not 
> set.
> Then invoke notifyAll in Activator.updated after receiving an non-null 
> Dictionary.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (KARAF-4756) Redeploying Features in the Deploy directory with install="auto" does not work for same feature versions

2016-10-11 Thread JIRA


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

Jean-Baptiste Onofré commented on KARAF-4756:
-

Thanks for the report. I fixed start attribute support on the bundle. Let me 
check about the install attribute on the feature.

> Redeploying Features in the Deploy directory with install="auto" does not 
> work for same feature versions
> 
>
> Key: KARAF-4756
> URL: https://issues.apache.org/jira/browse/KARAF-4756
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.6, 4.0.7
>Reporter: Cetra Free
>
> If you add a {{-features.xml}} file to the deploy directory, and then make 
> any changes to the file, except the name or version, then the feature will 
> stay uninstalled.
> You can manually install the feature with feature:install, but this defeats 
> the purpose of having install="auto"
> Here's a simple feature:
> {code}
> 
> http://karaf.apache.org/xmlns/features/v1.3.0; 
> name="example" >
>   
> mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
>   
> camel-blueprint
>   
> 
> {code}
> Steps to Reproduce:
> * Plop that example in the deploy directory
> * Notice that the feature is loaded:
> {code}
> feature:list | grep example-feature
> example-feature | 1.0.0| x| 
> Started | example |
> {code}
> * Change and update the file, leaving version and name the same
> * Notice that the feature stays uninstalled:
> {code}
> karaf@root()> feature:list | grep example-feature
> example-feature | 1.0.0|  | 
> Uninstalled | example |
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4756) Redeploying Features in the Deploy directory with install="auto" does not work for same feature versions

2016-10-11 Thread Cetra Free (JIRA)


 [ 
https://issues.apache.org/jira/browse/KARAF-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cetra Free updated KARAF-4756:
--
Description: 
If you add a {{-features.xml}} file to the deploy directory, and then make any 
changes to the file, except the name or version, then the feature will stay 
uninstalled.

You can manually install the feature with feature:install, but this defeats the 
purpose of having install="auto"

Here's a simple feature:

{code}

http://karaf.apache.org/xmlns/features/v1.3.0; name="example" >
  
mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
  
camel-blueprint
  

{code}

Steps to Reproduce:

* Plop that example in the deploy directory
* Notice that the feature is loaded:

{code}
feature:list | grep example-feature
example-feature | 1.0.0| x| Started 
| example |
{code}

* Change and update the file, leaving version and name the same
* Notice that the feature stays uninstalled:


{code}
karaf@root()> feature:list | grep example-feature
example-feature | 1.0.0|  | 
Uninstalled | example |
{code}

  was:
If you add a {{-features.xml}} file to the deploy directory, and then make any 
changes to the file, except the name or version, then the feature will stay 
uninstalled.

You can manually install the feature with feature:install, but this defeats the 
purpose of having install="auto"

Here's a simple feature:

{code}

http://karaf.apache.org/xmlns/features/v1.3.0; name="example" >
  
mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
  
camel-blueprint
  

{code}

Steps to Reproduce:

* Plop that example in the deploy directory
* Notice that the feature is loaded:
{{code}}
feature:list | grep example-feature
example-feature | 1.0.0| x| Started 
| example |
{{code}}
* Change and update the file
* Notice that the feature stays uninstalled
{{code}}
karaf@root()> feature:list | grep example-feature
example-feature | 1.0.0|  | 
Uninstalled | example |
{{code}}


> Redeploying Features in the Deploy directory with install="auto" does not 
> work for same feature versions
> 
>
> Key: KARAF-4756
> URL: https://issues.apache.org/jira/browse/KARAF-4756
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.6, 4.0.7
>Reporter: Cetra Free
>
> If you add a {{-features.xml}} file to the deploy directory, and then make 
> any changes to the file, except the name or version, then the feature will 
> stay uninstalled.
> You can manually install the feature with feature:install, but this defeats 
> the purpose of having install="auto"
> Here's a simple feature:
> {code}
> 
> http://karaf.apache.org/xmlns/features/v1.3.0; 
> name="example" >
>   
> mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
>   
> camel-blueprint
>   
> 
> {code}
> Steps to Reproduce:
> * Plop that example in the deploy directory
> * Notice that the feature is loaded:
> {code}
> feature:list | grep example-feature
> example-feature | 1.0.0| x| 
> Started | example |
> {code}
> * Change and update the file, leaving version and name the same
> * Notice that the feature stays uninstalled:
> {code}
> karaf@root()> feature:list | grep example-feature
> example-feature | 1.0.0|  | 
> Uninstalled | example |
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (KARAF-4756) Redeploying Features in the Deploy directory with install="auto" does not work for same feature versions

2016-10-11 Thread Cetra Free (JIRA)


 [ 
https://issues.apache.org/jira/browse/KARAF-4756?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Cetra Free updated KARAF-4756:
--
Description: 
If you add a {{-features.xml}} file to the deploy directory, and then make any 
changes to the file, except the name or version, then the feature will stay 
uninstalled.

You can manually install the feature with feature:install, but this defeats the 
purpose of having install="auto"

Here's a simple feature:

{code}

http://karaf.apache.org/xmlns/features/v1.3.0; name="example" >
  
mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
  
camel-blueprint
  

{code}

Steps to Reproduce:

* Plop that example in the deploy directory
* Notice that the feature is loaded:
{{code}}
feature:list | grep example-feature
example-feature | 1.0.0| x| Started 
| example |
{{code}}
* Change and update the file
* Notice that the feature stays uninstalled
{{code}}
karaf@root()> feature:list | grep example-feature
example-feature | 1.0.0|  | 
Uninstalled | example |
{{code}}

  was:
If you add a `-features.xml` file to the deploy directory, and then make any 
changes to the file, except the name or version, then the feature will stay 
uninstalled.

You can manually install the feature with feature:install, but this defeats the 
purpose of having install="auto"

Here's a simple feature:

{code}

http://karaf.apache.org/xmlns/features/v1.3.0; name="example" >
  
mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
  
camel-blueprint
  

{code}



> Redeploying Features in the Deploy directory with install="auto" does not 
> work for same feature versions
> 
>
> Key: KARAF-4756
> URL: https://issues.apache.org/jira/browse/KARAF-4756
> Project: Karaf
>  Issue Type: Bug
>  Components: karaf-feature
>Affects Versions: 4.0.6, 4.0.7
>Reporter: Cetra Free
>
> If you add a {{-features.xml}} file to the deploy directory, and then make 
> any changes to the file, except the name or version, then the feature will 
> stay uninstalled.
> You can manually install the feature with feature:install, but this defeats 
> the purpose of having install="auto"
> Here's a simple feature:
> {code}
> 
> http://karaf.apache.org/xmlns/features/v1.3.0; 
> name="example" >
>   
> mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
>   
> camel-blueprint
>   
> 
> {code}
> Steps to Reproduce:
> * Plop that example in the deploy directory
> * Notice that the feature is loaded:
> {{code}}
> feature:list | grep example-feature
> example-feature | 1.0.0| x| 
> Started | example |
> {{code}}
> * Change and update the file
> * Notice that the feature stays uninstalled
> {{code}}
> karaf@root()> feature:list | grep example-feature
> example-feature | 1.0.0|  | 
> Uninstalled | example |
> {{code}}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (KARAF-4756) Redeploying Features in the Deploy directory with install="auto" does not work for same feature versions

2016-10-11 Thread Cetra Free (JIRA)

Cetra Free created KARAF-4756:
-

 Summary: Redeploying Features in the Deploy directory with 
install="auto" does not work for same feature versions
 Key: KARAF-4756
 URL: https://issues.apache.org/jira/browse/KARAF-4756
 Project: Karaf
  Issue Type: Bug
  Components: karaf-feature
Affects Versions: 4.0.7, 4.0.6
Reporter: Cetra Free


If you add a `-features.xml` file to the deploy directory, and then make any 
changes to the file, except the name or version, then the feature will stay 
uninstalled.

You can manually install the feature with feature:install, but this defeats the 
purpose of having install="auto"

Here's a simple feature:

{code}

http://karaf.apache.org/xmlns/features/v1.3.0; name="example" >
  
mvn:org.apache.camel.karaf/apache-camel/2.17.0/xml/features
  
camel-blueprint
  

{code}




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

42 matches

Mail list logo