[jira] [Closed] (FELIX-6672) Potentially losing comment state between reads on CommentRemovingReader
[ https://issues.apache.org/jira/browse/FELIX-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu closed FELIX-6672. -- > Potentially losing comment state between reads on CommentRemovingReader > --- > > Key: FELIX-6672 > URL: https://issues.apache.org/jira/browse/FELIX-6672 > Project: Felix > Issue Type: Bug >Affects Versions: cm.json-2.0.4 >Reporter: Dominik Süß > Assignee: Robert Munteanu >Priority: Major > Fix For: cm.json-2.0.6 > > > In more extensive testing on real world data I found a case that was not > properly handled in the rewrite towards BufferedReader. If. a read ends > between the first / and the subsequent / or * for comment start, the > detection will currently fail. > To fix this I refactored the detection logic that should now also be > significantly better readable always capturing the previous char on class > level allowing to check for char double char sequences that may be split by > the reads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Felix cm.json 2.0.6
Hi, The vote has passed with the following result : +1 (binding): Carsten Ziegeler, Karl Pauls, David Bosschaert Can a Felix PMC member please upload the artifacts to the Felix dist directory and release the cm.json-2.0.6 version? I will then promote the artifacts to the central Maven repository. Thanks! Robert
Re: [VOTE] Release Apache Felix cm.json 2.0.6
Hi, On Fri, 2024-01-12 at 14:09 +0100, Robert Munteanu wrote: > Please vote to approve this release: Can two more PMC members please review and vote? Thanks, Robert
[VOTE] Release Apache Felix cm.json 2.0.6
Hi, We solved 1 issues in this release: https://issues.apache.org/jira/browse/FELIX-6672 Staging repository: https://repository.apache.org/content/repositoris/orgapachefelix-1486 You can use this UNIX script to download the release and verify the signatures: https://github.com/apache/felix-dev/blob/master/check_staged_release.sh Usage: sh check_staged_release.sh 1486 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Thanks, Robert
[jira] [Resolved] (FELIX-6672) Potentially losing comment state between reads on CommentRemovingReader
[ https://issues.apache.org/jira/browse/FELIX-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved FELIX-6672. Resolution: Fixed PR merged, thanks [~dsuess]! > Potentially losing comment state between reads on CommentRemovingReader > --- > > Key: FELIX-6672 > URL: https://issues.apache.org/jira/browse/FELIX-6672 > Project: Felix > Issue Type: Bug >Affects Versions: cm.json-2.0.4 >Reporter: Dominik Süß > Assignee: Robert Munteanu >Priority: Major > Fix For: cm.json-2.0.6 > > > In more extensive testing on real world data I found a case that was not > properly handled in the rewrite towards BufferedReader. If. a read ends > between the first / and the subsequent / or * for comment start, the > detection will currently fail. > To fix this I refactored the detection logic that should now also be > significantly better readable always capturing the previous char on class > level allowing to check for char double char sequences that may be split by > the reads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FELIX-6672) Potentially losing comment state between reads on CommentRemovingReader
[ https://issues.apache.org/jira/browse/FELIX-6672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned FELIX-6672: -- Assignee: Robert Munteanu > Potentially losing comment state between reads on CommentRemovingReader > --- > > Key: FELIX-6672 > URL: https://issues.apache.org/jira/browse/FELIX-6672 > Project: Felix > Issue Type: Bug >Affects Versions: cm.json-2.0.4 >Reporter: Dominik Süß > Assignee: Robert Munteanu >Priority: Major > Fix For: cm.json-2.0.6 > > > In more extensive testing on real world data I found a case that was not > properly handled in the rewrite towards BufferedReader. If. a read ends > between the first / and the subsequent / or * for comment start, the > detection will currently fail. > To fix this I refactored the detection logic that should now also be > significantly better readable always capturing the previous char on class > level allowing to check for char double char sequences that may be split by > the reads. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[RESULT] [VOTE] Release Apache Felix cm.json 2.0.4
Hi, The vote has passed with the following result : +1 (binding): Carsten Ziegeler, Karl Pauls, David Bosschaert, Raymond Augé Can a Felix PMC member please upload the artifacts to the Felix dist directory? I will then promote the artifacts to the central Maven repository and close the Jira issues. Thanks! Robert
[VOTE] Release Apache Felix cm.json 2.0.4
Hi, NOTE: I still don't have my GPG key signature to added the dist area. Please use the one marked as ASF ID: rombert LDAP PGP key: 0A66 5C46 70B4 78BF 1223 5CCD 3395 0865 4F63 EC54 from https://dist.apache.org/repos/dist/release/sling/KEYS . And it would be great if someone from the PMC could add it as well. We solved 1 issues in this release: https://issues.apache.org/jira/browse/FELIX-6669 Staging repository: https://repository.apache.org/content/repositoris/orgapachefelix-1480 You can use this UNIX script to download the release and verify the signatures: https://github.com/apache/felix-dev/blob/master/check_staged_release.sh Usage: sh check_staged_release.sh 1480 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Thanks, Robert
[jira] [Resolved] (FELIX-6669) Flaw in OOM Fix for JSON CommentStripping
[ https://issues.apache.org/jira/browse/FELIX-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu resolved FELIX-6669. Resolution: Fixed PR applied, thanks [~dsuess] for the follow-up! > Flaw in OOM Fix for JSON CommentStripping > - > > Key: FELIX-6669 > URL: https://issues.apache.org/jira/browse/FELIX-6669 > Project: Felix > Issue Type: Bug >Affects Versions: cm.json-2.0.2 >Reporter: Dominik Süß > Assignee: Robert Munteanu >Priority: Major > Fix For: cm.json-2.0.4 > > > While applying the patched version to some more real world data I noticed > that I missed a crucial condition that's not been covered in the unit tests > so far: comments and parts of the tokens within String properties. > To fix this I'll provide a patch that will take care of detecting when a > string property or comment is starting and ending and only consider the > handling for the other after the end token has been found. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (FELIX-6669) Flaw in OOM Fix for JSON CommentStripping
[ https://issues.apache.org/jira/browse/FELIX-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu reassigned FELIX-6669: -- Assignee: Robert Munteanu > Flaw in OOM Fix for JSON CommentStripping > - > > Key: FELIX-6669 > URL: https://issues.apache.org/jira/browse/FELIX-6669 > Project: Felix > Issue Type: Bug >Affects Versions: cm.json-2.0.2 >Reporter: Dominik Süß > Assignee: Robert Munteanu >Priority: Major > Fix For: cm.json-2.0.4 > > > While applying the patched version to some more real world data I noticed > that I missed a crucial condition that's not been covered in the unit tests > so far: comments and parts of the tokens within String properties. > To fix this I'll provide a patch that will take care of detecting when a > string property or comment is starting and ending and only consider the > handling for the other after the end token has been found. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (FELIX-6669) Flaw in OOM Fix for JSON CommentStripping
[ https://issues.apache.org/jira/browse/FELIX-6669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-6669: --- Fix Version/s: cm.json-2.0.4 > Flaw in OOM Fix for JSON CommentStripping > - > > Key: FELIX-6669 > URL: https://issues.apache.org/jira/browse/FELIX-6669 > Project: Felix > Issue Type: Bug >Affects Versions: cm.json-2.0.2 >Reporter: Dominik Süß >Priority: Major > Fix For: cm.json-2.0.4 > > > While applying the patched version to some more real world data I noticed > that I missed a crucial condition that's not been covered in the unit tests > so far: comments and parts of the tokens within String properties. > To fix this I'll provide a patch that will take care of detecting when a > string property or comment is starting and ending and only consider the > handling for the other after the end token has been found. -- This message was sent by Atlassian Jira (v8.20.10#820010)
Re: [RESULT] [VOTE] Release Apache Felix cm.json 2.0.2
On Mon, 2023-11-13 at 12:35 +, dav...@apache.org wrote: > Hi Robert, > > I've done the upload and promoted the artifacts in Nexus, they are > visible > here now: > https://repo.maven.apache.org/maven2/org/apache/felix/org.apache.felix.cm.json/2.0.2/ Thanks, David! I also updated the Jira version, we should be done here. Robert
[jira] [Closed] (FELIX-6664) Comment Removing on JSONSupport MemoryInefficient
[
https://issues.apache.org/jira/browse/FELIX-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu closed FELIX-6664.
--
> Comment Removing on JSONSupport MemoryInefficient
> -
>
> Key: FELIX-6664
> URL: https://issues.apache.org/jira/browse/FELIX-6664
> Project: Felix
> Issue Type: Improvement
>Affects Versions: cm.json-2.0.0
>Reporter: Dominik Süß
> Assignee: Robert Munteanu
>Priority: Major
> Fix For: cm.json-2.0.2
>
>
> While using JSONSupport in Context of the Sling Featurelauncher we recently
> stumbled over an OOM exception related to how JSONSupport handles removal of
> comments:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOfRange(Arrays.java:4030)
> at java.base/java.lang.StringUTF16.newString(StringUTF16.java:1025)
> at java.base/java.lang.StringBuilder.toString(StringBuilder.java:454)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.removeComments(JsonSupport.java:308)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.createCommentRemovingReader(JsonSupport.java:244)
> at
> org.apache.felix.cm.json.io.Configurations.jsonCommentAwareReader(Configurations.java:70)
> at
> org.apache.sling.feature.io.json.FeatureJSONReader.readFeature(FeatureJSONReader.java:676)
> {code}
> https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/cm.json/src/main/java/org/apache/felix/cm/json/io/impl/JsonSupport.java#L233-L257
> The code does use a StringWriter to create a full String representation of
> the featuremodel and then acts on that model. As this featuremodel can
> contain a lot of metadata in comments those can get a significant size and
> when being used in a resource constrained environment can lead to memory
> issues.
> I prepared a patch that doesn't touch the removal logic but simply creates a
> custom BufferedReader that performs the removal on read and therefore
> eliminates the most prominent area for resource optimization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[RESULT] [VOTE] Release Apache Felix cm.json 2.0.2
Hi, The vote has passed with the following result : +1 (binding): Carsten Ziegeler, Raymond Augé, Karl Pauls Can a Felix PMC member please upload the artifacts to the Felix dist directory? I will then promote the artifacts to the central Maven repository. Thanks! Robert
[jira] [Resolved] (FELIX-6664) Comment Removing on JSONSupport MemoryInefficient
[
https://issues.apache.org/jira/browse/FELIX-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu resolved FELIX-6664.
Resolution: Fixed
> Comment Removing on JSONSupport MemoryInefficient
> -
>
> Key: FELIX-6664
> URL: https://issues.apache.org/jira/browse/FELIX-6664
> Project: Felix
> Issue Type: Improvement
>Affects Versions: cm.json-2.0.0
>Reporter: Dominik Süß
> Assignee: Robert Munteanu
>Priority: Major
> Fix For: cm.json-2.0.2
>
>
> While using JSONSupport in Context of the Sling Featurelauncher we recently
> stumbled over an OOM exception related to how JSONSupport handles removal of
> comments:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOfRange(Arrays.java:4030)
> at java.base/java.lang.StringUTF16.newString(StringUTF16.java:1025)
> at java.base/java.lang.StringBuilder.toString(StringBuilder.java:454)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.removeComments(JsonSupport.java:308)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.createCommentRemovingReader(JsonSupport.java:244)
> at
> org.apache.felix.cm.json.io.Configurations.jsonCommentAwareReader(Configurations.java:70)
> at
> org.apache.sling.feature.io.json.FeatureJSONReader.readFeature(FeatureJSONReader.java:676)
> {code}
> https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/cm.json/src/main/java/org/apache/felix/cm/json/io/impl/JsonSupport.java#L233-L257
> The code does use a StringWriter to create a full String representation of
> the featuremodel and then acts on that model. As this featuremodel can
> contain a lot of metadata in comments those can get a significant size and
> when being used in a resource constrained environment can lead to memory
> issues.
> I prepared a patch that doesn't touch the removal logic but simply creates a
> custom BufferedReader that performs the removal on read and therefore
> eliminates the most prominent area for resource optimization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[VOTE] Release Apache Felix cm.json 2.0.2
Hi, NOTE: this is my first Felix release and I don't have rights to add my GPG key signature to the dist area. Please use the one marked as ASF ID: rombert LDAP PGP key: 0A66 5C46 70B4 78BF 1223 5CCD 3395 0865 4F63 EC54 from https://dist.apache.org/repos/dist/release/sling/KEYS . We solved 1 issues in this release: https://issues.apache.org/jira/browse/FELIX-6664 Staging repository: https://repository.apache.org/content/repositories/orgapachefelix-1479 You can use this UNIX script to download the release and verify the signatures: https://github.com/apache/felix-dev/blob/master/check_staged_release.sh Usage: sh check_staged_release.sh 1479 /tmp/felix-staging Please vote to approve this release: [ ] +1 Approve the release [ ] -1 Veto the release (please provide specific comments) This vote will be open for 72 hours. Thanks, Robert
[jira] [Commented] (FELIX-6664) Comment Removing on JSONSupport MemoryInefficient
[
https://issues.apache.org/jira/browse/FELIX-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17784366#comment-17784366
]
Robert Munteanu commented on FELIX-6664:
PR merged, thanks [~dsuess] for the contribution!
> Comment Removing on JSONSupport MemoryInefficient
> -
>
> Key: FELIX-6664
> URL: https://issues.apache.org/jira/browse/FELIX-6664
> Project: Felix
> Issue Type: Improvement
>Affects Versions: cm.json-2.0.0
>Reporter: Dominik Süß
> Assignee: Robert Munteanu
>Priority: Major
> Fix For: cm.json-2.0.2
>
>
> While using JSONSupport in Context of the Sling Featurelauncher we recently
> stumbled over an OOM exception related to how JSONSupport handles removal of
> comments:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOfRange(Arrays.java:4030)
> at java.base/java.lang.StringUTF16.newString(StringUTF16.java:1025)
> at java.base/java.lang.StringBuilder.toString(StringBuilder.java:454)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.removeComments(JsonSupport.java:308)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.createCommentRemovingReader(JsonSupport.java:244)
> at
> org.apache.felix.cm.json.io.Configurations.jsonCommentAwareReader(Configurations.java:70)
> at
> org.apache.sling.feature.io.json.FeatureJSONReader.readFeature(FeatureJSONReader.java:676)
> {code}
> https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/cm.json/src/main/java/org/apache/felix/cm/json/io/impl/JsonSupport.java#L233-L257
> The code does use a StringWriter to create a full String representation of
> the featuremodel and then acts on that model. As this featuremodel can
> contain a lot of metadata in comments those can get a significant size and
> when being used in a resource constrained environment can lead to memory
> issues.
> I prepared a patch that doesn't touch the removal logic but simply creates a
> custom BufferedReader that performs the removal on read and therefore
> eliminates the most prominent area for resource optimization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (FELIX-6664) Comment Removing on JSONSupport MemoryInefficient
[
https://issues.apache.org/jira/browse/FELIX-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu reassigned FELIX-6664:
--
Assignee: Robert Munteanu
> Comment Removing on JSONSupport MemoryInefficient
> -
>
> Key: FELIX-6664
> URL: https://issues.apache.org/jira/browse/FELIX-6664
> Project: Felix
> Issue Type: Improvement
>Affects Versions: cm.json-2.0.0
>Reporter: Dominik Süß
> Assignee: Robert Munteanu
>Priority: Major
> Fix For: cm.json-2.0.2
>
>
> While using JSONSupport in Context of the Sling Featurelauncher we recently
> stumbled over an OOM exception related to how JSONSupport handles removal of
> comments:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOfRange(Arrays.java:4030)
> at java.base/java.lang.StringUTF16.newString(StringUTF16.java:1025)
> at java.base/java.lang.StringBuilder.toString(StringBuilder.java:454)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.removeComments(JsonSupport.java:308)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.createCommentRemovingReader(JsonSupport.java:244)
> at
> org.apache.felix.cm.json.io.Configurations.jsonCommentAwareReader(Configurations.java:70)
> at
> org.apache.sling.feature.io.json.FeatureJSONReader.readFeature(FeatureJSONReader.java:676)
> {code}
> https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/cm.json/src/main/java/org/apache/felix/cm/json/io/impl/JsonSupport.java#L233-L257
> The code does use a StringWriter to create a full String representation of
> the featuremodel and then acts on that model. As this featuremodel can
> contain a lot of metadata in comments those can get a significant size and
> when being used in a resource constrained environment can lead to memory
> issues.
> I prepared a patch that doesn't touch the removal logic but simply creates a
> custom BufferedReader that performs the removal on read and therefore
> eliminates the most prominent area for resource optimization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
New versions needed in Jira for release
Hi, Can someone please create new Jira versions in the FELIX project? I want to assign 'cm.json-2.0.2' to https://issues.apache.org/jira/browse/FELIX-6664 but that version does not exist and I can't create it either. Thanks! Robert
[jira] [Updated] (FELIX-6664) Comment Removing on JSONSupport MemoryInefficient
[
https://issues.apache.org/jira/browse/FELIX-6664?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-6664:
---
Affects Version/s: cm.json-2.0.0
> Comment Removing on JSONSupport MemoryInefficient
> -
>
> Key: FELIX-6664
> URL: https://issues.apache.org/jira/browse/FELIX-6664
> Project: Felix
> Issue Type: Improvement
>Affects Versions: cm.json-2.0.0
>Reporter: Dominik Süß
>Priority: Major
>
> While using JSONSupport in Context of the Sling Featurelauncher we recently
> stumbled over an OOM exception related to how JSONSupport handles removal of
> comments:
> {code}
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.util.Arrays.copyOfRange(Arrays.java:4030)
> at java.base/java.lang.StringUTF16.newString(StringUTF16.java:1025)
> at java.base/java.lang.StringBuilder.toString(StringBuilder.java:454)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.removeComments(JsonSupport.java:308)
> at
> org.apache.felix.cm.json.io.impl.JsonSupport.createCommentRemovingReader(JsonSupport.java:244)
> at
> org.apache.felix.cm.json.io.Configurations.jsonCommentAwareReader(Configurations.java:70)
> at
> org.apache.sling.feature.io.json.FeatureJSONReader.readFeature(FeatureJSONReader.java:676)
> {code}
> https://github.com/apache/felix-dev/blob/91432d1a3f08520d5eb75b5c8e3443bb75f7c467/cm.json/src/main/java/org/apache/felix/cm/json/io/impl/JsonSupport.java#L233-L257
> The code does use a StringWriter to create a full String representation of
> the featuremodel and then acts on that model. As this featuremodel can
> contain a lot of metadata in comments those can get a significant size and
> when being used in a resource constrained environment can lead to memory
> issues.
> I prepared a patch that doesn't touch the removal logic but simply creates a
> custom BufferedReader that performs the removal on read and therefore
> eliminates the most prominent area for resource optimization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FELIX-6659) HealthCheckExecutorServlet no longer serving requests to /system/health after upgrading to Jetty 5.1.2
[
https://issues.apache.org/jira/browse/FELIX-6659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774361#comment-17774361
]
Robert Munteanu commented on FELIX-6659:
Thanks [~cziegeler]. I really should to read the HTTP-related specs one day :-)
> HealthCheckExecutorServlet no longer serving requests to /system/health after
> upgrading to Jetty 5.1.2
> --
>
> Key: FELIX-6659
> URL: https://issues.apache.org/jira/browse/FELIX-6659
> Project: Felix
> Issue Type: Bug
> Components: Health Checks, HTTP Service
>Affects Versions: healthcheck.core 2.2.0
>Reporter: Robert Munteanu
>Assignee: Carsten Ziegeler
>Priority: Major
> Attachments: image-2023-10-11-22-17-10-606.png,
> image-2023-10-11-22-18-13-245.png, image-2023-10-11-22-18-50-570.png
>
>
> *Summary:*
> In the Apache Sling Starter 13-SNAPSHOT, after upgrading to
> org.apache.felix.http.jetty 5.1.2 the health checks are no longer served on
> /system/health.
> *Steps to Reproduce:*
> # Check out [https://github.com/apache/sling-org-apache-sling-starter]
> # build with {{mvn clean package}}
> # run with
> {{target/dependency/org.apache.sling.feature.launcher/bin/launcher -f
> target/slingfeature-tmp/feature-oak_tar.json}}
> # wait a bit and run {{[http://localhost:8080/system/health.txt]}}
> *Expected Behaviour: (/)*
> The health check status should be returned. Instead, the SlingMainServlet
> responds with a 404.
> *Additional Details:*
> Using the web console at [http://localhost:8080/system/console/httpservice]
> confirms that th path is served by the Sling Main Servlet.
> *Screenshots:*
> Resolution results
> !image-2023-10-11-22-17-10-606.png!
> Sling servlet context and registration
> !image-2023-10-11-22-18-13-245.png!
> HealthCheck servlet registration using the default servlet context
> !image-2023-10-11-22-18-50-570.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (FELIX-6659) HealthCheckExecutorServlet no longer serving requests to /system/health after upgrading to Jetty 5.1.2
Robert Munteanu created FELIX-6659:
--
Summary: HealthCheckExecutorServlet no longer serving requests to
/system/health after upgrading to Jetty 5.1.2
Key: FELIX-6659
URL: https://issues.apache.org/jira/browse/FELIX-6659
Project: Felix
Issue Type: Bug
Components: Health Checks, HTTP Service
Affects Versions: http.jetty-5.1.2, healthcheck.core 2.2.0
Reporter: Robert Munteanu
Attachments: image-2023-10-11-22-17-10-606.png,
image-2023-10-11-22-18-13-245.png, image-2023-10-11-22-18-50-570.png
*Summary:*
In the Apache Sling Starter 13-SNAPSHOT, after upgrading to
org.apache.felix.http.jetty 5.1.2 the health checks are no longer served on
/system/health.
*Steps to Reproduce:*
# Check out [https://github.com/apache/sling-org-apache-sling-starter]
# build with {{mvn clean package}}
# run with {{target/dependency/org.apache.sling.feature.launcher/bin/launcher
-f target/slingfeature-tmp/feature-oak_tar.json}}
# wait a bit and run {{[http://localhost:8080/system/health.txt]}}
*Expected Behaviour: (/)*
The health check status should be returned. Instead, the SlingMainServlet
responds with a 404.
*Additional Details:*
Using the web console at [http://localhost:8080/system/console/httpservice]
confirms that th path is served by the Sling Main Servlet.
*Screenshots:*
Resolution results
!image-2023-10-11-22-17-10-606.png!
Sling servlet context and registration
!image-2023-10-11-22-18-13-245.png!
HealthCheck servlet registration using the default servlet context
!image-2023-10-11-22-18-50-570.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FELIX-6659) HealthCheckExecutorServlet no longer serving requests to /system/health after upgrading to Jetty 5.1.2
[
https://issues.apache.org/jira/browse/FELIX-6659?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17774217#comment-17774217
]
Robert Munteanu commented on FELIX-6659:
[~cziegeler] - I know you recently worked in this area, maybe you have an idea
where to look for a fix?
> HealthCheckExecutorServlet no longer serving requests to /system/health after
> upgrading to Jetty 5.1.2
> --
>
> Key: FELIX-6659
> URL: https://issues.apache.org/jira/browse/FELIX-6659
> Project: Felix
> Issue Type: Bug
> Components: Health Checks, HTTP Service
>Affects Versions: healthcheck.core 2.2.0, http.jetty-5.1.2
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: image-2023-10-11-22-17-10-606.png,
> image-2023-10-11-22-18-13-245.png, image-2023-10-11-22-18-50-570.png
>
>
> *Summary:*
> In the Apache Sling Starter 13-SNAPSHOT, after upgrading to
> org.apache.felix.http.jetty 5.1.2 the health checks are no longer served on
> /system/health.
> *Steps to Reproduce:*
> # Check out [https://github.com/apache/sling-org-apache-sling-starter]
> # build with {{mvn clean package}}
> # run with
> {{target/dependency/org.apache.sling.feature.launcher/bin/launcher -f
> target/slingfeature-tmp/feature-oak_tar.json}}
> # wait a bit and run {{[http://localhost:8080/system/health.txt]}}
> *Expected Behaviour: (/)*
> The health check status should be returned. Instead, the SlingMainServlet
> responds with a 404.
> *Additional Details:*
> Using the web console at [http://localhost:8080/system/console/httpservice]
> confirms that th path is served by the Sling Main Servlet.
> *Screenshots:*
> Resolution results
> !image-2023-10-11-22-17-10-606.png!
> Sling servlet context and registration
> !image-2023-10-11-22-18-13-245.png!
> HealthCheck servlet registration using the default servlet context
> !image-2023-10-11-22-18-50-570.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (FELIX-6612) Upgrade Apache Felix to Jakarta Servlet API 6.x
[
https://issues.apache.org/jira/browse/FELIX-6612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17752686#comment-17752686
]
Robert Munteanu commented on FELIX-6612:
[~cziegeler] - Michael needs to be part of a group that can be assigned issues,
that's not available to all users. You can check the 'Contributors' group from
the Sling project for an example.
> Upgrade Apache Felix to Jakarta Servlet API 6.x
> ---
>
> Key: FELIX-6612
> URL: https://issues.apache.org/jira/browse/FELIX-6612
> Project: Felix
> Issue Type: New Feature
> Components: Health Checks, HTTP Service, Inventory, iPOJO, JAAS,
> System Ready, Web Console
>Reporter: Michael H. Siemaszko
>Priority: Major
> Attachments: Upgrade Apache Felix to Jakarta Servlet API
> 6.x.20230713.pdf, Upgrade Apache Felix to Jakarta Servlet API
> 6.x.20230731.pdf, Upgrade Apache Felix to Jakarta Servlet API 6.x.pdf
>
>
> Goal is to upgrade all relevant Apache Felix modules, which currently are
> using either +Jakarta Servlet API 5.x+ or J{+}ava Servlet{+}, to {+}Jakarta
> Servlet API 6.x{+}.
> Attached Mikado graph ({color:#80}+[https://mikadomethod.info/]+{color})
> has all so far identified prerequisites listed, as well as progress on path
> to main goal – i.e. items already completed are checked off
> ({*}{color:#57d9a3}green icon{color}{*}). Code is shared via
> [https://github.com/DataInMotion/felix-dev/tree/jakarta-servlet-6-x] (no pull
> request for now – please see sections ‘Questions’ and ‘Next steps’ below).
> Before starting, I asked on Apache Felix Users list
> ({color:#80}+[https://www.mail-archive.com/users@felix.apache.org/msg18693.html]+{color}),
> as well as researched if there is any ongoing effort to upgrade Apache Felix
> to Jakarta Servlet 6.x (issues / pull requests, etc.). Besides
> {color:#80}+https://issues.apache.org/jira/browse/FELIX-6389+{color},
> which resembles this effort, I did not find anything. However, that issue is
> open since 22/02/2021 and there has been no updates since 09/01/2022, as well
> as no code shared as part of it. If any progress was made as part of
> {color:#80}+https://issues.apache.org/jira/browse/FELIX-6389+{color},
> kindly please provide status update and perhaps these efforts can be merged.
> h1. Modules affected
> Modules with dependency on Java Servlet or Jakarta Servlet.
> h2. org.apache.felix.http
> * org.apache.felix.http.parent
> * org.apache.felix.http.base
> * org.apache.felix.http.bridge
> * org.apache.felix.http.inventoryprinter
> * org.apache.felix.http.itest
> * org.apache.felix.http.jetty
> * org.apache.felix.http.proxy
> * org.apache.felix.http.samples.whiteboard
> * org.apache.felix.http.servlet-api
> * org.apache.felix.http.sslfilter
> * org.apache.felix.http.webconsoleplugin
> h2. org.apache.felix.webconsole
> * org.apache.felix.webconsole
> * org.apache.felix.webconsole.plugins.deppack
> * org.apache.felix.webconsole.plugins.ds
> * org.apache.felix.webconsole.plugins.event
> * org.apache.felix.webconsole.plugins.gogo
> * org.apache.felix.webconsole.plugins.memoryusage
> * org.apache.felix.webconsole.plugins.metatype
> * org.apache.felix.webconsole.plugins.obr
> * org.apache.felix.webconsole.plugins.packageadmin
> * org.apache.felix.webconsole.plugins.scriptconsole
> * org.apache.felix.webconsole.plugins.shell
> * org.apache.felix.webconsole.plugins.subsystems
> * org.apache.felix.webconsole.plugins.upnp
> * org.apache.felix.webconsole.plugins.useradmin
> h2. org.apache.felix.healthcheck
> * org.apache.felix.healthcheck.core
> * org.apache.felix.healthcheck.webconsoleplugin
> h2. Other
> * org.apache.felix.jaas
> * org.apache.felix.example.jaas.app
> * org.apache.felix.example.jaas.jdbc-h2
> * org.apache.felix.ipojo.webconsole
> * org.apache.felix.systemready
> * org.apache.felix.servicediagnostics.plugin
> * org.apache.felix.inventory
> h1. Questions
> 1. Regarding modules affected, are there any additional modules which should
> be taken into account?
> 2. Regarding modules affected, should any of the modules listed be dropped
> from that list ? (e.g. some may be out of date / replaced by other already)
> 3. Do you know of any ongoing effort to migrate `org.osgi.service.http`
> specification to Jakarta ? How otherwise should modules currently using
> `org.osgi.service.http` specification API classes and methods be refactored ?
> I am aware of
> {color:#80}+[https://github.com/eclipse-equinox/equinox/issues/1
Re: Apache Felix 7.0.5 still isn't available in the Maven Central
On Fri, 2022-06-03 at 11:38 +0200, David Matějček wrote: > Hi Amit, > > see https://www.mail-archive.com/dev@felix.apache.org/msg53752.html The vote was started but not concluded. Once the vote passess the artifacts will be synced to Maven central. Thanks, Robert
[jira] [Commented] (FELIX-6484) Update logback dependency to overcome CVE-2021-44228
[ https://issues.apache.org/jira/browse/FELIX-6484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17459563#comment-17459563 ] Robert Munteanu commented on FELIX-6484: [~rotty3000] - the text you linked to seems to indicate that this is a different vulnerability. Perhaps it would be clearer if the CVE reference was removed from the issue title. > Update logback dependency to overcome CVE-2021-44228 > > > Key: FELIX-6484 > URL: https://issues.apache.org/jira/browse/FELIX-6484 > Project: Felix > Issue Type: Task > Components: Felix Logback >Reporter: Raymond Augé >Assignee: Raymond Augé >Priority: Major > Fix For: felix-logback-1.0.6 > > > See http://logback.qos.ch/news.html#:~:text=Release%20of%20version%201.2.8 > FYI felix.logback does not contain the affected version of logback. We're > just updating the transitive dependency so that in cases where transitive > deps are used a secured version is used. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (FELIX-6438) Vmstat page reboot button is invalid
[ https://issues.apache.org/jira/browse/FELIX-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17377115#comment-17377115 ] Robert Munteanu commented on FELIX-6438: Apparently I can move the issue to the Felix project but can't move it back to Sling, sorry. > Vmstat page reboot button is invalid > > > Key: FELIX-6438 > URL: https://issues.apache.org/jira/browse/FELIX-6438 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: James Raynor >Priority: Minor > > Goto [http://localhost:8080/system/console/vmstat] > Clicking the restart button tries to restart but it doesn't work, this makes > it less convenient to restart the instance on the server remotely. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6438) Vmstat page reboot button is invalid
[ https://issues.apache.org/jira/browse/FELIX-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376510#comment-17376510 ] Robert Munteanu commented on FELIX-6438: Although this is reproduced in the Sling Starter, the web console page is from Apache Felix - https://github.com/apache/felix-dev/blob/master/webconsole/src/main/java/org/apache/felix/webconsole/internal/system/VMStatPlugin.java > Vmstat page reboot button is invalid > > > Key: FELIX-6438 > URL: https://issues.apache.org/jira/browse/FELIX-6438 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: James Raynor >Priority: Minor > > Goto http://localhost:8080/system/console/vmstat > Clicking the restart button tries to restart but it doesn't work, this makes > it less convenient to restart the instance on the server remotely. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Moved] (FELIX-6438) Vmstat page reboot button is invalid
[ https://issues.apache.org/jira/browse/FELIX-6438?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu moved SLING-10590 to FELIX-6438: Component/s: (was: App CMS) Web Console Key: FELIX-6438 (was: SLING-10590) Affects Version/s: (was: App CMS 1.0.2) Workflow: classic default workflow (was: no-reopen-closed,doc-test-required) Project: Felix (was: Sling) > Vmstat page reboot button is invalid > > > Key: FELIX-6438 > URL: https://issues.apache.org/jira/browse/FELIX-6438 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: James Raynor >Priority: Minor > > Goto http://localhost:8080/system/console/vmstat > Clicking the restart button tries to restart but it doesn't work, this makes > it less convenient to restart the instance on the server remotely. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: Website migration to Antora
On Tue, 2021-05-04 at 13:36 -0700, David Jencks wrote: > As usual I found a way to express myself ambiguously :-) > > I meant more “will if be convenient for everyone to avoid making any > CMS site updates” :-) Ah, got it. I'll avoid that, but then again I don't usually update the site :-) Thanks, Robert
Re: Website migration to Antora
Hi, On Tue, 2021-05-04 at 11:37 -0700, David Jencks wrote: > Would it be practical to avoid further updates to the CMS site? You can ask infra to make a certain part of a svn tree read-only, with optional exceptions for certain users. Thanks, Robert
Application metrics bundles contribution (was: [RESUL][VOTE] Accept the application metrics bundles contribution)
Hi, On Fri, 2020-07-03 at 13:01 +0200, Karl Pauls wrote: > The vote is successful. I will follow-up with Robert to get it in. It's been two months ( give or take a couple of hours ) so it may be time to actually finish contributing the code. https://github.com/apache/felix-dev/tree/master/metrics/osgi Compared to the initial proposal I moved the modules under the org.apache.felix namespace. Thanks, Robert
Re: [healthcheck] Equivalent of SystemReady service?
Hi Georg, On Mon, 2020-06-29 at 17:57 +0200, Georg Henzler wrote: > Hi Robert, > > > > sorry for the delay, but now I'm back on to this and after polishing, > > I'm planning to release everything within the next two weeks. That would be great, thanks! > > > 4. I was also surprised that I needed to create an executor for the > > 'Healthy' event to be registered. I thought that with the > > eventadmin > > requirement the services would be registered automatically, without > > me > > intervening. > > > So no instance of HealthCheckMonitor is active by default currently. > > Configuring one means that the tags as given will be regularly > > executed. To be exactly in line with systemready, you would configure > > an instance of HealthCheckMonitor with tag "systemready" and > > intervalInSec=5. Would you have expected that this config is done > > automatically for the case the event admin is present? (we > > definitely cannot start monitors for all checks by default, that > > would potentially be harmful) Hm, so by definition no checks are executed, even though they are defined? Then probably it does not make sense to execute some of them by default. I though that they would be executed by default once registered. > > > > > 3. I was a bit surprised that hc.core requires the Servlet API. The > > systemready bundle was a bit more lightweight. > > > systemready had the same dependency, just optional. I created > > FELIX-6289 to make it also optional for hc.core. Great, thanks, > > > > > 2. core build fails with pax-exam tests. Perhaps related to Java > > 11? > > > I checked this, it is indeed a Java 11 problem (just checked both > > 1.8 and 11). I'll check and fix. Ack. > > > > > 1. api build fails due to the baselining check > > > this I could not reproduce. It only happens on Java 11, and it looks like a false positive. [INFO] --- [INFO] * org.apache.felix.hc.api.execution changed2.0.0 2.0.0 2.0.1 Version increase required [INFO] ~ class org.apache.felix.hc.api.execution.HealthCheckSelector [INFO] ~ method hashCode() [INFO] - annotated jdk.internal.HotSpotIntrinsicCandidate [INFO] --- [ERROR] org.apache.felix.hc.api.execution: Version increase required; detected 2.0.0, suggested 2.0.1 Not sure if there is anything to be done here. See also https://github.com/bndtools/bnd/issues/2177 for context. Thanks, Robert
[jira] [Updated] (FELIX-6273) Improve behaviour when delimiter is set but the type is not
[
https://issues.apache.org/jira/browse/FELIX-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-6273:
---
Summary: Improve behaviour when delimiter is set but the type is not (was:
Improve behaviour when delimiter is set but type is not an array)
> Improve behaviour when delimiter is set but the type is not
> ---
>
> Key: FELIX-6273
> URL: https://issues.apache.org/jira/browse/FELIX-6273
> Project: Felix
> Issue Type: Improvement
> Components: Configuration Admin
>Affects Versions: configadmin-interpolation-plugin-1.1.0
> Reporter: Robert Munteanu
>Priority: Major
>
> When configuring property values with a delimiter, it is expected that the
> property is an array. Otherwise, the delimited does not make sense IMO.
> Assuming I have exporter {{PROP=foo,bar}}.
> If I configure interpolation for a property value as
> prop="$[env:PROP;delimiter=,]"
> At runtime it get interpolated to {{prop = foo,bar}}, which is
> clearly not what I expected. The correct syntax is
> prop="$[env:PROP;type=String[];delimiter=,]"
> after which the interpolation result is indeed {{ prop = [foo, bar]
> }}.
> There are a number of ways this could be improved
> - fail interpolation with an exception
> - log a WARN/ERROR message
> - assume that if a delimiter is present but the type is not, the type is
> {{String[]}}, and not {{String}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (FELIX-6273) Improve behaviour when delimiter is set but type is not an array
Robert Munteanu created FELIX-6273:
--
Summary: Improve behaviour when delimiter is set but type is not
an array
Key: FELIX-6273
URL: https://issues.apache.org/jira/browse/FELIX-6273
Project: Felix
Issue Type: Improvement
Components: Configuration Admin
Affects Versions: configadmin-interpolation-plugin-1.1.0
Reporter: Robert Munteanu
When configuring property values with a delimiter, it is expected that the
property is an array. Otherwise, the delimited does not make sense IMO.
Assuming I have exporter {{PROP=foo,bar}}.
If I configure interpolation for a property value as
prop="$[env:PROP;delimiter=,]"
At runtime it get interpolated to {{prop = foo,bar}}, which is clearly
not what I expected. The correct syntax is
prop="$[env:PROP;type=String[];delimiter=,]"
after which the interpolation result is indeed {{ prop = [foo, bar]
}}.
There are a number of ways this could be improved
- fail interpolation with an exception
- log a WARN/ERROR message
- assume that if a delimiter is present but the type is not, the type is
{{String[]}}, and not {{String}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Re: Proposal to contribute OSGi application metrics bundles
I'm getting a bit off-topic here, sorry :-) It would actually be quite simple: 1. Install and configure SystemReady/HC 2. Install https://github.com/apache/sling-whiteboard/tree/master/osgi-metrics/collector 3. Create an Decanter appender (event-drive I guess) that implements the StartupMetricsListener interface. Whenever the startup metrics are completed, the onStartupComplete method is invoked. Thanks, Robert On Thu, 2020-04-23 at 15:12 +0200, Jean-Baptiste Onofre wrote: > Definitely I agree with you. I would love to create a new collector > in Decanter ;) > > Regards > JB > > > Le 23 avr. 2020 à 15:10, Robert Munteanu a > > écrit : > > > > Hi JB, > > > > On Tue, 2020-04-21 at 16:21 +0200, Jean-Baptiste Onofre wrote: > > > Hi, > > > > > > Healthcheck can be a place. > > > > This indeed related to the HealthCheck module. It only consumes the > > API, so I would say this should not necessarily be bundled/included > > in > > the HC. > > > > > Karaf Decanter can be another option as well. > > > > Reading on the Decanter, I can see that it's a monitoring solution. > > I > > think there is a link here, as these metrics I'm gathering can be > > wrapped as a Decanter collector and then the output pushed through > > any > > kind of appender. > > > > I would still prefer to make this solution generic, as I'm not > > currently using Decanter. > > > > Thanks, > > Robert > > > > > Regards > > > JB > > > > > > > Le 21 avr. 2020 à 14:25, Robert Munteanu a > > > > écrit : > > > > > > > > Hi, > > > > > > > > I have been working on collecting startup metrics for OSGi > > > > applications. I am interested in finding potentials for > > > > optimising > > > > startup time, so created a set of bundles that record: > > > > > > > > - total startup time > > > > - bundles that are slow to start > > > > - OSGi services that are restarted during startup > > > > > > > > I think the functionality would be useful for the wider > > > > community > > > > and > > > > would like to ask whether the Felix project would be interested > > > > in > > > > hosting it. > > > > > > > > The 'project' consists of two bundles: > > > > > > > > - one that starts as early as possible and collects startup > > > > metrics > > > > - one that contains some out-of-the-box consumers of metrics > > > > - Dropwizard metrics > > > > - slf4j logging > > > > - JSON output to disk > > > > > > > > The bundles are in the Apache Sling whiteboard for now [1], so > > > > no > > > > releases were cut, no documentation to change, no backwards > > > > compatibility to consider. > > > > > > > > Do you think this functionality has its place in Felix? I would > > > > be > > > > happy to contribute it, if the community agrees. > > > > > > > > Thanks, > > > > Robert > > > > > > > > > > > > [1]: > > > > https://github.com/apache/sling-whiteboard/tree/master/osgi-metrics > > > >
Re: Proposal to contribute OSGi application metrics bundles
Hi JB, On Tue, 2020-04-21 at 16:21 +0200, Jean-Baptiste Onofre wrote: > Hi, > > Healthcheck can be a place. This indeed related to the HealthCheck module. It only consumes the API, so I would say this should not necessarily be bundled/included in the HC. > > Karaf Decanter can be another option as well. Reading on the Decanter, I can see that it's a monitoring solution. I think there is a link here, as these metrics I'm gathering can be wrapped as a Decanter collector and then the output pushed through any kind of appender. I would still prefer to make this solution generic, as I'm not currently using Decanter. Thanks, Robert > > Regards > JB > > > Le 21 avr. 2020 à 14:25, Robert Munteanu a > > écrit : > > > > Hi, > > > > I have been working on collecting startup metrics for OSGi > > applications. I am interested in finding potentials for optimising > > startup time, so created a set of bundles that record: > > > > - total startup time > > - bundles that are slow to start > > - OSGi services that are restarted during startup > > > > I think the functionality would be useful for the wider community > > and > > would like to ask whether the Felix project would be interested in > > hosting it. > > > > The 'project' consists of two bundles: > > > > - one that starts as early as possible and collects startup metrics > > - one that contains some out-of-the-box consumers of metrics > > - Dropwizard metrics > > - slf4j logging > > - JSON output to disk > > > > The bundles are in the Apache Sling whiteboard for now [1], so no > > releases were cut, no documentation to change, no backwards > > compatibility to consider. > > > > Do you think this functionality has its place in Felix? I would be > > happy to contribute it, if the community agrees. > > > > Thanks, > > Robert > > > > > > [1]: > > https://github.com/apache/sling-whiteboard/tree/master/osgi-metrics > >
Re: Proposal to contribute OSGi application metrics bundles
Hi Karl, On Tue, 2020-04-21 at 17:39 +0200, Karl Pauls wrote: > Hi Robert, > > it sounds like a reasonable generic solution to me - lets see what > others think but just to make sure: I assume you'd be willing to > maintain it, right? Yes, absolutely. I am running this in production, so I have every interest in maintaining it. Thanks, Robert > > regards, > > Karl > > On Tue, Apr 21, 2020 at 2:25 PM Robert Munteanu > wrote: > > Hi, > > > > I have been working on collecting startup metrics for OSGi > > applications. I am interested in finding potentials for optimising > > startup time, so created a set of bundles that record: > > > > - total startup time > > - bundles that are slow to start > > - OSGi services that are restarted during startup > > > > I think the functionality would be useful for the wider community > > and > > would like to ask whether the Felix project would be interested in > > hosting it. > > > > The 'project' consists of two bundles: > > > > - one that starts as early as possible and collects startup metrics > > - one that contains some out-of-the-box consumers of metrics > > - Dropwizard metrics > > - slf4j logging > > - JSON output to disk > > > > The bundles are in the Apache Sling whiteboard for now [1], so no > > releases were cut, no documentation to change, no backwards > > compatibility to consider. > > > > Do you think this functionality has its place in Felix? I would be > > happy to contribute it, if the community agrees. > > > > Thanks, > > Robert > > > > > > [1]: > > https://github.com/apache/sling-whiteboard/tree/master/osgi-metrics > > > >
[jira] [Commented] (FELIX-6266) ConcurrentModificationException in bundle:manifest on Java 15
[
https://issues.apache.org/jira/browse/FELIX-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089651#comment-17089651
]
Robert Munteanu commented on FELIX-6266:
I think this was already reported as FELIX-6259?
> ConcurrentModificationException in bundle:manifest on Java 15
> -
>
> Key: FELIX-6266
> URL: https://issues.apache.org/jira/browse/FELIX-6266
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-4.2.1
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] --- maven-bundle-plugin:4.2.1:manifest (scr-metadata) @
> oak-jackrabbit-api ---
> [INFO] No previous run data found, generating manifest.
> [ERROR] An internal error occurred
> java.util.ConcurrentModificationException
> at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:742)
> at java.util.TreeMap.computeIfAbsent (TreeMap.java:596)
> at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
> at java.nio.file.Files.walkFileTree (Files.java:2804)
> at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
> at aQute.bnd.osgi.Jar. (Jar.java:119)
> at aQute.bnd.osgi.Jar. (Jar.java:172)
> at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder
> (BundlePlugin.java:604)
> at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer
> (ManifestPlugin.java:285)
> at org.apache.felix.bundleplugin.ManifestPlugin.execute
> (ManifestPlugin.java:111)
> at org.apache.felix.bundleplugin.BundlePlugin.execute
> (BundlePlugin.java:364)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:564)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (FELIX-6266) ConcurrentModificationException in bundle:manifest on Java 15
[
https://issues.apache.org/jira/browse/FELIX-6266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17089651#comment-17089651
]
Robert Munteanu edited comment on FELIX-6266 at 4/22/20, 1:00 PM:
--
I think this was already reported as FELIX-6259
was (Author: rombert):
I think this was already reported as FELIX-6259?
> ConcurrentModificationException in bundle:manifest on Java 15
> -
>
> Key: FELIX-6266
> URL: https://issues.apache.org/jira/browse/FELIX-6266
> Project: Felix
> Issue Type: Bug
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-4.2.1
>Reporter: Julian Reschke
>Priority: Major
>
> {noformat}
> [INFO] --- maven-bundle-plugin:4.2.1:manifest (scr-metadata) @
> oak-jackrabbit-api ---
> [INFO] No previous run data found, generating manifest.
> [ERROR] An internal error occurred
> java.util.ConcurrentModificationException
> at java.util.TreeMap.callMappingFunctionWithCheck (TreeMap.java:742)
> at java.util.TreeMap.computeIfAbsent (TreeMap.java:596)
> at aQute.bnd.osgi.Jar.putResource (Jar.java:288)
> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:202)
> at aQute.bnd.osgi.Jar$1.visitFile (Jar.java:177)
> at java.nio.file.Files.walkFileTree (Files.java:2804)
> at aQute.bnd.osgi.Jar.buildFromDirectory (Jar.java:176)
> at aQute.bnd.osgi.Jar. (Jar.java:119)
> at aQute.bnd.osgi.Jar. (Jar.java:172)
> at org.apache.felix.bundleplugin.BundlePlugin.getOSGiBuilder
> (BundlePlugin.java:604)
> at org.apache.felix.bundleplugin.ManifestPlugin.getAnalyzer
> (ManifestPlugin.java:285)
> at org.apache.felix.bundleplugin.ManifestPlugin.execute
> (ManifestPlugin.java:111)
> at org.apache.felix.bundleplugin.BundlePlugin.execute
> (BundlePlugin.java:364)
> at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo
> (DefaultBuildPluginManager.java:134)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:208)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:154)
> at org.apache.maven.lifecycle.internal.MojoExecutor.execute
> (MojoExecutor.java:146)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:117)
> at
> org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject
> (LifecycleModuleBuilder.java:81)
> at
> org.apache.maven.lifecycle.internal.builder.singlethreaded.SingleThreadedBuilder.build
> (SingleThreadedBuilder.java:51)
> at org.apache.maven.lifecycle.internal.LifecycleStarter.execute
> (LifecycleStarter.java:128)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:309)
> at org.apache.maven.DefaultMaven.doExecute (DefaultMaven.java:194)
> at org.apache.maven.DefaultMaven.execute (DefaultMaven.java:107)
> at org.apache.maven.cli.MavenCli.execute (MavenCli.java:955)
> at org.apache.maven.cli.MavenCli.doMain (MavenCli.java:290)
> at org.apache.maven.cli.MavenCli.main (MavenCli.java:194)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke0 (Native Method)
> at jdk.internal.reflect.NativeMethodAccessorImpl.invoke
> (NativeMethodAccessorImpl.java:62)
> at jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke
> (DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke (Method.java:564)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced
> (Launcher.java:289)
> at org.codehaus.plexus.classworlds.launcher.Launcher.launch
> (Launcher.java:229)
> at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode
> (Launcher.java:415)
> at org.codehaus.plexus.classworlds.launcher.Launcher.main
> (Launcher.java:356)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
Proposal to contribute OSGi application metrics bundles
Hi, I have been working on collecting startup metrics for OSGi applications. I am interested in finding potentials for optimising startup time, so created a set of bundles that record: - total startup time - bundles that are slow to start - OSGi services that are restarted during startup I think the functionality would be useful for the wider community and would like to ask whether the Felix project would be interested in hosting it. The 'project' consists of two bundles: - one that starts as early as possible and collects startup metrics - one that contains some out-of-the-box consumers of metrics - Dropwizard metrics - slf4j logging - JSON output to disk The bundles are in the Apache Sling whiteboard for now [1], so no releases were cut, no documentation to change, no backwards compatibility to consider. Do you think this functionality has its place in Felix? I would be happy to contribute it, if the community agrees. Thanks, Robert [1]: https://github.com/apache/sling-whiteboard/tree/master/osgi-metrics
Re: [healthcheck] Equivalent of SystemReady service?
Hello Georg, Thanks for the implementation, looks good! I took it for a spin and for my scenario it works as expected. In addition to that. I have some notes that you may find useful. 1. api build fails due to the baselining check - org.apache.felix.hc.api.execution: Version increase required; detected 2.0.0, suggested 2.0.1 . 2. core build fails with pax-exam tests. Perhaps related to Java 11? ERROR: Bundle org.apache.felix.http.whiteboard [25] Error starting file:/tmp/1587396148625-0/pax-exam- downloads/org.apache.felix.http.whiteboard_4.0.0.jar (org.osgi.framework.BundleException: Unable to resolve org.apache.felix.http.whiteboard [25](R 25.0): missing requirement [org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package; (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(! (version>=2.0.0))) [caused by: Unable to resolve org.apache.felix.http.jetty [24](R 24.0): missing requirement [org.apache.felix.http.jetty [24](R 24.0)] osgi.wiring.package; (osgi.wiring.package=javax.annotation)] Unresolved requirements: [[org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package; (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(! (version>=2.0.0)))]) org.osgi.framework.BundleException: Unable to resolve org.apache.felix.http.whiteboard [25](R 25.0): missing requirement [org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package; (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(! (version>=2.0.0))) [caused by: Unable to resolve org.apache.felix.http.jetty [24](R 24.0): missing requirement [org.apache.felix.http.jetty [24](R 24.0)] osgi.wiring.package; (osgi.wiring.package=javax.annotation)] Unresolved requirements: [[org.apache.felix.http.whiteboard [25](R 25.0)] osgi.wiring.package; (&(osgi.wiring.package=org.osgi.service.http.context)(version>=1.1.0)(! (version>=2.0.0)))] 3. I was a bit suprised that hc.core requires the Servlet API. The systemready bundle was a bit more lightweight. 4. I was also suprised that I needed to create an executor for the 'Healthy' event to be registered. I thought that with the eventadmin requirement the services would be registered automatically, without me intervening. Anyway, the implementation works for me and I can support both systemready and health checks, which is great. Thanks! Robert On Wed, 2020-04-08 at 11:35 +0200, Georg Henzler wrote: > Hi all, > > so I went ahead with this, see documentation [5] on how it works. Any > feedback is appreciated (best before the release :)) > > -Georg > > > [5] > https://github.com/apache/felix-dev/blob/master/healthcheck/README.md#monitoring-health-checks > > > On 2020-03-28 23:31, Georg Henzler wrote: > > Hi Andrei, > > > > so the marker service SystemReady is intended to be used in the > > exact > > same > > way as the one from systemready bundle [1] (and reacts fix to the > > health > > status of tag 'systemready'). Healthy is the more generic marker > > interface, > > it allows to depend on the healthy status (that is OK or WARN, see > > [2] > > for > > reasoning) of any tag, see [3] for an example. Now a prerequisite > > for > > this > > to work is that the status is regularly polled, this is what the > > HealthCheckMonitor [4] is for (FELIX-6250) > > > > The Unhealthy marker interface is just the opposite, this could be > > useful > > to activate an alternative fallback functionality or some self- > > healing > > mechanism. Now this will be the least-important use case I suppose, > > but > > I > > liked the idea to have a symmetric approach here. > > HealthCheckMonitor > > [4] > > allows to configure if Healthy and/or Unhealthy is registered upon > > status > > changes of the health check (the default will only register > > Healthy). > > > > -Georg > > > > [1] > > https://github.com/apache/felix-dev/blob/master/systemready/src/main/java/org/apache/felix/systemready/SystemReady.java > > [2] > > https://github.com/apache/felix-dev/tree/master/healthcheck#semantic-meaning-of-health-check-results > > [3] > > @Reference(target="(tag=db-available)") > > Healthy dbAvailable; > > > > [4] > > https://github.com/apache/felix-dev/blob/775545aa8f0657d7c5f703bc901693dcdbaff92f/healthcheck/core/src/main/java/org/apache/felix/hc/core/impl/monitor/HealthCheckMonitor.java#L108 > > > >
[jira] [Comment Edited] (FELIX-6245) Allow to depend on a health status of a given tag like e.g. "systemready" via service dependency
[ https://issues.apache.org/jira/browse/FELIX-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077992#comment-17077992 ] Robert Munteanu edited comment on FELIX-6245 at 4/8/20, 9:29 AM: - Looks good, thanks [~henzlerg]! (Maybe you want to set a fix version as well?) -So what would I need to test locally - build from the branch mentioned in FELIX-6250?- _edit_: nevermind, I see FELIX-6250 is fixed as well. I'll give this a shot from master a bit later. was (Author: rombert): Looks good, thanks [~henzlerg]! (Maybe you want to set a fix version as well?) So what would I need to test locally - build from the branch mentioned in FELIX-6250? > Allow to depend on a health status of a given tag like e.g. "systemready" via > service dependency > > > Key: FELIX-6245 > URL: https://issues.apache.org/jira/browse/FELIX-6245 > Project: Felix > Issue Type: New Feature > Components: Health Checks >Reporter: Georg Henzler >Assignee: Georg Henzler >Priority: Major > > It should be possible to depend on a certain HC status (e.g. OK) for a given > tag (e.g. "systemready") via an OSGi service dependency when using a > component framework like SCR. > The solution should be aligned with the Condition Service specification that > is currently in Draft status: > https://github.com/osgi/design/blob/master/rfcs/rfc0242/rfc-0242-Condition-Service.pdf > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (FELIX-6245) Allow to depend on a health status of a given tag like e.g. "systemready" via service dependency
[ https://issues.apache.org/jira/browse/FELIX-6245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17077992#comment-17077992 ] Robert Munteanu commented on FELIX-6245: Looks good, thanks [~henzlerg]! (Maybe you want to set a fix version as well?) So what would I need to test locally - build from the branch mentioned in FELIX-6250? > Allow to depend on a health status of a given tag like e.g. "systemready" via > service dependency > > > Key: FELIX-6245 > URL: https://issues.apache.org/jira/browse/FELIX-6245 > Project: Felix > Issue Type: New Feature > Components: Health Checks >Reporter: Georg Henzler >Assignee: Georg Henzler >Priority: Major > > It should be possible to depend on a certain HC status (e.g. OK) for a given > tag (e.g. "systemready") via an OSGi service dependency when using a > component framework like SCR. > The solution should be aligned with the Condition Service specification that > is currently in Draft status: > https://github.com/osgi/design/blob/master/rfcs/rfc0242/rfc-0242-Condition-Service.pdf > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (FELIX-6248) Unable to use properties and conditions in logback.xml
Robert Munteanu created FELIX-6248:
--
Summary: Unable to use properties and conditions in logback.xml
Key: FELIX-6248
URL: https://issues.apache.org/jira/browse/FELIX-6248
Project: Felix
Issue Type: Bug
Components: Felix Logback
Reporter: Robert Munteanu
Fix For: felix-logback-1.0.2
I am trying to consolidate multiple logback.xml into a single one using
conditional processing and variables ( see
http://logback.qos.ch/manual/configuration.html#definingProps ).
I have updated the logback.xml
{code:xml}
[%thread] %-5level %logger{36} - %msg%n
{code}
and then added two extra bundles to my application:
- {{org.codehaus.janino/janino/3.1.2}}
- {{org.codehaus.janino/commons-compiler/3.1.2}}
When starting my application logback configuration fails with
{noformat}16:44:57,642 |-ERROR in
ch.qos.logback.core.joran.conditional.IfAction - Failed to parse condition
[property("LOGBACK_DEFAULT_LOG_LEVEL").equalsIgnoreCase("INFO")]
org.codehaus.commons.compiler.InternalCompilerExce
ption: Compiling "SC" in Line 1, Column 1: Cannot load class
'ch.qos.logback.core.joran.conditional.PropertyWrapperForScripts' through the
parent loader
at org.codehaus.commons.compiler.InternalCompilerException: Compiling
"SC" in Line 1, Column 1: Cannot load class
'ch.qos.logback.core.joran.conditional.PropertyWrapperForScripts' through the
parent loader
at at
org.codehaus.janino.UnitCompiler.compile2(UnitCompiler.java:358)
at at
org.codehaus.janino.UnitCompiler.access$000(UnitCompiler.java:231)
at at
org.codehaus.janino.UnitCompiler$1.visitCompilationUnit(UnitCompiler.java:322)
at at
org.codehaus.janino.UnitCompiler$1.visitCompilationUnit(UnitCompiler.java:319)
at at
org.codehaus.janino.Java$CompilationUnit.accept(Java.java:367)
at at
org.codehaus.janino.UnitCompiler.compileUnit(UnitCompiler.java:319)
at at
org.codehaus.janino.SimpleCompiler.cook(SimpleCompiler.java:237)
at at
org.codehaus.janino.ClassBodyEvaluator.cook(ClassBodyEvaluator.java:278)
at at
org.codehaus.janino.ClassBodyEvaluator.cook(ClassBodyEvaluator.java:272)
at at
org.codehaus.janino.ClassBodyEvaluator.cook(ClassBodyEvaluator.java:252)
at at org.codehaus.commons.compiler.Cookable.cook(Cookable.java:82)
at at org.codehaus.commons.compiler.Cookable.cook(Cookable.java:77)
at at
ch.qos.logback.core.joran.conditional.PropertyEvalScriptBuilder.build(PropertyEvalScriptBuilder.java:47)
at at
ch.qos.logback.core.joran.conditional.IfAction.begin(IfAction.java:65)
at at
ch.qos.logback.core.joran.spi.Interpreter.callBeginAction(Interpreter.java:269)
at at
ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:145)
at at
ch.qos.logback.core.joran.spi.Interpreter.startElement(Interpreter.java:128)
at at
ch.qos.logback.core.joran.spi.EventPlayer.play(EventPlayer.java:50)
at at
ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:165)
at at
ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:152)
at at
ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:110)
at at
ch.qos.logback.core.joran.GenericConfigurator.doConfigure(GenericConfigurator.java:53)
at at
ch.qos.logback.classic.util.ContextInitializer.configureByResource(ContextInitializer.java:75)
at at
ch.qos.logback.classic.util.ContextInitializer.autoConfig(ContextInitializer.java:150)
at at
org.slf4j.impl.StaticLoggerBinder.init(StaticLoggerBinder.java:84)
at at
org.slf4j.impl.StaticLoggerBinder.(StaticLoggerBinder.java:55)
at at org.slf4j.LoggerFactory.bind(LoggerFactory.java:150)
at at
org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:124)
at at
org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:412)
at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:357)
at at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:383)
at at
org.apache.felix.configadmin.plugin.interpolation.Activator.(Activator.java:40)
at at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at at
java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
at at
java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingCo
[jira] [Created] (FELIX-6208) Allow specifying logback config file using framework properties
Robert Munteanu created FELIX-6208: -- Summary: Allow specifying logback config file using framework properties Key: FELIX-6208 URL: https://issues.apache.org/jira/browse/FELIX-6208 Project: Felix Issue Type: Task Components: Felix Logback Affects Versions: felix-logback-1.0.2 Reporter: Robert Munteanu It is sometimes more convenient to specify the logback config file using system properties. I am using a set of maven plug-ins that launch an OSGi framework in-process (https://github.com/apache/sling-slingfeature-maven-plugin) and can't easily alter the system properties. It would be very convenient if the logback integration would pick up the logback config file using a framework property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
Re: How to unsubscribe from JIRA emails?
Hi Neil, On Mon, 2019-09-09 at 06:29 +0100, Neil Bartlett wrote: > I've just received approximately a gazillion emails from Felix > JIRA... > > Does JIRA seriously not have a way for users to manage their own > notification settings?? What I've seen is most likely an auto-responder gone haywire. I did get a lot of emails, many of them in reply to Jira issues, but none of them came from Jira. Robert
[jira] [Commented] (FELIX-6124) Memoryusage Plugin : single quote in pool name malformed the json
[ https://issues.apache.org/jira/browse/FELIX-6124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16835444#comment-16835444 ] Robert Munteanu commented on FELIX-6124: [~ashokpanghal] - isn't this a duplicate of FELIX-6079 ? > Memoryusage Plugin : single quote in pool name malformed the json > -- > > Key: FELIX-6124 > URL: https://issues.apache.org/jira/browse/FELIX-6124 > Project: Felix > Issue Type: Bug > Components: Web Console >Reporter: Ashok Kumar >Priority: Major > Attachments: malformed_json_with_single_quotes.patch > > > *Issue Summary :* Memory Usage details aren't available in System console > [1]. It happens with Java 11. With Java 8, it loads fine. Pool Name contains > single quotes e.g. 'name':'CodeHeap 'non-nmethods'' breaks the json format > and UI rendering. > [1] [http://localhost:4502/system/console/memoryusage] > > Proposed patch - replace single quote with double quote. Patch Attached > > CC: [~karlpauls] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [VOTE] Release Apache Felix Webconsole Plugins Memory Usage 1.0.10
On Wed, 2019-03-06 at 13:30 +0100, Karl Pauls wrote: > Please vote to approve this release: +1 (non-binding). Thanks, Robert signature.asc Description: This is a digitally signed message part
[jira] [Updated] (FELIX-6079) Web Console memory usage page does not display information on Java 11
[
https://issues.apache.org/jira/browse/FELIX-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-6079:
---
Attachment: FELIX-6079.patch
> Web Console memory usage page does not display information on Java 11
> -
>
> Key: FELIX-6079
> URL: https://issues.apache.org/jira/browse/FELIX-6079
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.8
> Environment: Java 11
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: FELIX-6079.patch
>
>
> When running the web console on Java 11 the page does not contain any
> information. The error is caused by a pool name that contains a quote ({{'}})
> character which makes the generated JSON invalid.
> {code:javascript}var __pools__ = [{'name':'CodeHeap
> 'non-nmethods'','type':'Non-heap memory',
>{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (FELIX-6079) Web Console memory usage page does not display information on Java 11
[
https://issues.apache.org/jira/browse/FELIX-6079?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16785462#comment-16785462
]
Robert Munteanu commented on FELIX-6079:
Updated trivial patch which fixes the problem with Java 11 by escaping single
quotes in the pool names.
> Web Console memory usage page does not display information on Java 11
> -
>
> Key: FELIX-6079
> URL: https://issues.apache.org/jira/browse/FELIX-6079
> Project: Felix
> Issue Type: Bug
> Components: Web Console
>Affects Versions: webconsole-memoryusage-plugin-1.0.8
> Environment: Java 11
>Reporter: Robert Munteanu
>Priority: Major
> Attachments: FELIX-6079.patch
>
>
> When running the web console on Java 11 the page does not contain any
> information. The error is caused by a pool name that contains a quote ({{'}})
> character which makes the generated JSON invalid.
> {code:javascript}var __pools__ = [{'name':'CodeHeap
> 'non-nmethods'','type':'Non-heap memory',
>{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-6079) Web Console memory usage page does not display information on Java 11
Robert Munteanu created FELIX-6079:
--
Summary: Web Console memory usage page does not display
information on Java 11
Key: FELIX-6079
URL: https://issues.apache.org/jira/browse/FELIX-6079
Project: Felix
Issue Type: Bug
Components: Web Console
Affects Versions: webconsole-memoryusage-plugin-1.0.8
Environment: Java 11
Reporter: Robert Munteanu
When running the web console on Java 11 the page does not contain any
information. The error is caused by a pool name that contains a quote ({{'}})
character which makes the generated JSON invalid.
{code:javascript}var __pools__ = [{'name':'CodeHeap
'non-nmethods'','type':'Non-heap memory',
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (FELIX-6067) ClassLoading can fail unpredictably due to interrupts
Robert Munteanu created FELIX-6067: -- Summary: ClassLoading can fail unpredictably due to interrupts Key: FELIX-6067 URL: https://issues.apache.org/jira/browse/FELIX-6067 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-6.0.2 Reporter: Robert Munteanu I noticed an intermittent issue with our Felix-based app (Apache Sling). The flows seems to be the following: (thread 1) - component C is started - component C invokes method on class K1 - class K1 is first accessed now and runs class initializers - K1 static initializer calls method from class K2 - class K2 loading is triggered (thread 2) - component C is stopped ( I _think_ due to configuration coming in ) (thread 1) - during class loading of K2 a RuntimeException is thrown, resulting in all calls to K1 leading to NoClassDefFoundError At this point although the error should be transient the component is unusable since one of the classes it uses is not available. For the record, the stack trace which causes this is 21.02.2019 14:50:50.292 *ERROR* [Apache Sling Repository Startup Thread #1] org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager start: Uncaught Throwable trying to access Repository, calling stopRepository() java.lang.ExceptionInInitializerError: null at org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:144) [org.apache.sling.jcr.oak.server:1.2.0] at org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:481) [org.apache.sling.jcr.base:3.0.6] at org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:86) [org.apache.sling.jcr.base:3.0.6] at org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(AbstractSlingRepositoryManager.java:462) [org.apache.sling.jcr.base:3.0.6] Caused by: java.lang.RuntimeException: java.lang.InterruptedException at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:369) at org.apache.felix.framework.Felix.getService(Felix.java:3954) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2383) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2081) at org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565) at org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79) at org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) at org.apache.jackrabbit.oak.plugins.tree.factories.RootFactory.createSystemRoot(RootFactory.java:80) [org.apache.jackrabbit.oak-core:1.8.8] at org.apache.jackrabbit.oak.InitialContent.initialize(InitialContent.java:134) [org.apache.jackrabbit.oak-core:1.8.8] at org.apache.jackrabbit.oak.InitialContent.createInitialContent(InitialContent.java:74) [org.apache.jackrabbit.oak-core:1.8.8] at org.apache.jackrabbit.oak.InitialContent.(InitialContent.java:70) [org.apache.jackrabbit.oak-core:1.8.8] ... 4 common frames omitted Caused by: java.lang.InterruptedException: null at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1302) at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231) at org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:365) ... 15 common frames omitted (source code for all is available is needed) Starting the component C at any later time fails with 21.02.2019 14:50:50.310 *ERROR* [Apache Sling Repository Startup Thread #2] org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager start: Uncaught Throwable trying to access Repository, calling stopRepository() java.lang.NoClassDefFoundError: Could not initialize class org.apache.jackrabbit.oak.InitialContent at org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:144) [org.apache.sling.jcr.oak.server:1.2.0] at org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:481) [org.apache.sling.jcr.base:3.0.6] at org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:86) [org.apache.sling.jcr.base:3.0.6] at org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(AbstractSlingRepositoryManager.java:462) [org.apache.sling.jcr.base:3.0.6] -- This
[jira] [Updated] (FELIX-6067) ClassLoading can fail unpredictably due to interrupts
[
https://issues.apache.org/jira/browse/FELIX-6067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-6067:
---
Description:
I noticed an intermittent issue with our Felix-based app (Apache Sling). The
flows seems to be the following:
(thread 1)
- component C is started
- component C invokes method on class K1
- class K1 is first accessed now and runs class initializers
- K1 static initializer calls method from class K2
- class K2 loading is triggered
(thread 2)
- component C is stopped ( I _think_ due to configuration coming in )
(thread 1)
- during class loading of K2 a RuntimeException is thrown, resulting in all
calls to K1 leading to NoClassDefFoundError
At this point although the error should be transient the component is unusable
since one of the classes it uses is not available.
For the record, the stack trace which causes this is
{noformat}
21.02.2019 14:50:50.292 *ERROR* [Apache Sling Repository Startup Thread #1]
org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager start:
Uncaught Throwable trying to access Repository, calling stopRepository()
java.lang.ExceptionInInitializerError: null
at
org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:144)
[org.apache.sling.jcr.oak.server:1.2.0]
at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:481)
[org.apache.sling.jcr.base:3.0.6]
at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:86)
[org.apache.sling.jcr.base:3.0.6]
at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(AbstractSlingRepositoryManager.java:462)
[org.apache.sling.jcr.base:3.0.6]
Caused by: java.lang.RuntimeException: java.lang.InterruptedException
at
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:369)
at org.apache.felix.framework.Felix.getService(Felix.java:3954)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.transformClass(BundleWiringImpl.java:2383)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.findClass(BundleWiringImpl.java:2081)
at
org.apache.felix.framework.BundleWiringImpl.findClassOrResourceByDelegation(BundleWiringImpl.java:1565)
at
org.apache.felix.framework.BundleWiringImpl.access$300(BundleWiringImpl.java:79)
at
org.apache.felix.framework.BundleWiringImpl$BundleClassLoader.loadClass(BundleWiringImpl.java:1982)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at
org.apache.jackrabbit.oak.plugins.tree.factories.RootFactory.createSystemRoot(RootFactory.java:80)
[org.apache.jackrabbit.oak-core:1.8.8]
at
org.apache.jackrabbit.oak.InitialContent.initialize(InitialContent.java:134)
[org.apache.jackrabbit.oak-core:1.8.8]
at
org.apache.jackrabbit.oak.InitialContent.createInitialContent(InitialContent.java:74)
[org.apache.jackrabbit.oak-core:1.8.8]
at
org.apache.jackrabbit.oak.InitialContent.(InitialContent.java:70)
[org.apache.jackrabbit.oak-core:1.8.8]
... 4 common frames omitted
Caused by: java.lang.InterruptedException: null
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1302)
at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
at
org.apache.felix.framework.ServiceRegistry.getService(ServiceRegistry.java:365)
... 15 common frames omitted
{noformat}
(source code for all classes is available if needed)
Starting the component C at any later time fails with
{noformat}
21.02.2019 14:50:50.310 *ERROR* [Apache Sling Repository Startup Thread #2]
org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager start:
Uncaught Throwable trying to access Repository, calling stopRepository()
java.lang.NoClassDefFoundError: Could not initialize class
org.apache.jackrabbit.oak.InitialContent
at
org.apache.sling.jcr.oak.server.internal.OakSlingRepositoryManager.acquireRepository(OakSlingRepositoryManager.java:144)
[org.apache.sling.jcr.oak.server:1.2.0]
at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager.initializeAndRegisterRepositoryService(AbstractSlingRepositoryManager.java:481)
[org.apache.sling.jcr.base:3.0.6]
at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager.access$300(AbstractSlingRepositoryManager.java:86)
[org.apache.sling.jcr.base:3.0.6]
at
org.apache.sling.jcr.base.AbstractSlingRepositoryManager$4.run(AbstractSlingRepositoryManager.java:462)
[org.apache.sling.jcr.base:3.0.6]
{noformat}
was:
I noticed an intermittent issue with our Felix-based app (Apache Sling). The
flows seems to be the following:
(thread 1)
- component C is started
Re: [VOTE] Release Felix Logback 1.0.2
On Tue, 2019-01-15 at 09:40 -0500, Raymond Auge wrote: > Please vote to approve this release: +1 (non-binding) Thanks, Robert
[jira] [Updated] (FELIX-5772) Some converter projects do not have svn:ignore set
[
https://issues.apache.org/jira/browse/FELIX-5772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-5772:
---
Attachment: FELIX-5772.patch
Trivial patch attached.
> Some converter projects do not have svn:ignore set
> --
>
> Key: FELIX-5772
> URL: https://issues.apache.org/jira/browse/FELIX-5772
> Project: Felix
> Issue Type: Bug
> Components: Converter
> Reporter: Robert Munteanu
>Priority: Minor
> Attachments: FELIX-5772.patch
>
>
> After building the converter project some I get 'target' folders that are not
> ignored by subversion:
> {noformat}$ svn status
> M converter/persister
> M converter/schematizer
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (FELIX-5772) Some converter projects do not have svn:ignore set
Robert Munteanu created FELIX-5772:
--
Summary: Some converter projects do not have svn:ignore set
Key: FELIX-5772
URL: https://issues.apache.org/jira/browse/FELIX-5772
Project: Felix
Issue Type: Bug
Components: Converter
Reporter: Robert Munteanu
Priority: Minor
Attachments: FELIX-5772.patch
After building the converter project some I get 'target' folders that are not
ignored by subversion:
{noformat}$ svn status
M converter/persister
M converter/schematizer
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
Re: [VOTE] SCR Tooling Release
On Thu, 2018-01-11 at 08:21 +0100, Carsten Ziegeler wrote: > Please vote to approve this release: +1 (non-binding). Checked signatures, validated using previously failing project. Thanks, Robert
[jira] [Updated] (FELIX-5771) Metatype generation via bnd plugin creates incorrect file names
[
https://issues.apache.org/jira/browse/FELIX-5771?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-5771:
---
Attachment: FELIX-5771.patch
> Metatype generation via bnd plugin creates incorrect file names
> ---
>
> Key: FELIX-5771
> URL: https://issues.apache.org/jira/browse/FELIX-5771
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: scr generator 1.17.0
> Reporter: Robert Munteanu
> Attachments: FELIX-5771.patch
>
>
> When using the scr bnd plugin to generate SCR descriptors and an
> `l10n/metatype.properties` file is found, the name of the metatype.properties
> file is incorrect.
> The error I'm getting is {noformat}[ERROR] Manifest
> org.apache.jackrabbit:oak-segment-tar:bundle:1.10-SNAPSHOT : Got unexpected
> exception while analyzing:org.apache.felix.scrplugin.SCRDescriptorException:
> metatype properties file must be stored outside of OSGI-INF/metatype, move it
> to OSGI-INF/l10n{noformat}
> Note the missing '/' between l10n and the file name.
> I've traced it down to a problem in the scr.generator project, I'll attach a
> trivial patch which makes it work.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (FELIX-5771) Metatype generation via bnd plugin creates incorrect file names
Robert Munteanu created FELIX-5771:
--
Summary: Metatype generation via bnd plugin creates incorrect file
names
Key: FELIX-5771
URL: https://issues.apache.org/jira/browse/FELIX-5771
Project: Felix
Issue Type: Bug
Components: SCR Tooling
Affects Versions: scr generator 1.17.0
Reporter: Robert Munteanu
Attachments: FELIX-5771.patch
When using the scr bnd plugin to generate SCR descriptors and an
`l10n/metatype.properties` file is found, the name of the metatype.properties
file is incorrect.
The error I'm getting is {noformat}[ERROR] Manifest
org.apache.jackrabbit:oak-segment-tar:bundle:1.10-SNAPSHOT : Got unexpected
exception while analyzing:org.apache.felix.scrplugin.SCRDescriptorException:
metatype properties file must be stored outside of OSGI-INF/metatype, move it
to OSGI-INF/l10n{noformat}
Note the missing '/' between l10n and the file name.
I've traced it down to a problem in the scr.generator project, I'll attach a
trivial patch which makes it work.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5749) Allow to use components that depend on optional imports
[
https://issues.apache.org/jira/browse/FELIX-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16261056#comment-16261056
]
Robert Munteanu commented on FELIX-5749:
The new problem statement is the one mentioned by Christian in the issue
description:
{quote}I think scr could support such "optional" components without the
disabled trick. We could load the component class and if it fails disable the
component. If it works we enable it.
So if the package is wired later and we get a refresh this approach would
activate the component without any additional effort from the developer
side.{quote}
> Allow to use components that depend on optional imports
> ---
>
> Key: FELIX-5749
> URL: https://issues.apache.org/jira/browse/FELIX-5749
> Project: Felix
> Issue Type: New Feature
>Affects Versions: scr-2.0.12
>Reporter: Christian Schneider
>
> When desigining the scope of a bundle you sometimes have an optional part
> that could be externalized into its own bundle but you decide to keep it in
> your bundle to limit the number of bundles. In this case you have to use an
> optional import and make sure the code that depends on this import only runs
> when this import is wired. This code is often quite awkward and often also
> buggy.
> We discussed on osgi-dev that you can make such code a lot simpler to write
> by using DS.
> This is how the code would look like:
> You externalize the code that depends on the optional import into one or more
> components. These components offer a service interface that is not dependent
> on the optional import. Inside the component you can work freely with the
> optional packages. You have to make sure this component is disabled by
> default. Then you write a "starter" component that enables the component if
> the package is available.
> I think scr could support such "optional" components without the disabled
> trick. We could load the component class and if it fails disable the
> component. If it works we enable it.
> So if the package is wired later and we get a refresh this approach would
> activate the component without any additional effort from the developer side.
>
> Below I am copying a snippet from Ray that details what they did.
> Given your component which has the optional import package (doesn't matter
> how it's used):
> import com.liferay.demo.foo.Foo; // The optional package
> @Component(
> enabled = false // disable by default so DS ignores it
> )
> public class OptionalPackageConsumer implements Foo {...}
> Make sure the component is disabled by default. This will prevent SCR from
> classloading the component class.
> Second, you construct a "starter" component who's job it is to check for the
> available package:
> @Component
> public class OptionalPackageConsumerStarter {
>@Activate
> void activate(ComponentContext componentContext) {
> try {
> Class.forName(com.liferay.demo.foo.Foo.class.getName());
>
> componentContext.enableComponent(OptionalPackageConsumer.class.getName());
> }
> catch (Throwable t) {
> _log.warn("Could not find {}", t.getMessage());
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5749) Allow to use components that depend on optional imports
[
https://issues.apache.org/jira/browse/FELIX-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260925#comment-16260925
]
Robert Munteanu commented on FELIX-5749:
Thanks for the clarification. I was just pasting my initial request to make it
clear what the initial problem statement was.
> Allow to use components that depend on optional imports
> ---
>
> Key: FELIX-5749
> URL: https://issues.apache.org/jira/browse/FELIX-5749
> Project: Felix
> Issue Type: New Feature
>Affects Versions: scr-2.0.12
>Reporter: Christian Schneider
>
> When desigining the scope of a bundle you sometimes have an optional part
> that could be externalized into its own bundle but you decide to keep it in
> your bundle to limit the number of bundles. In this case you have to use an
> optional import and make sure the code that depends on this import only runs
> when this import is wired. This code is often quite awkward and often also
> buggy.
> We discussed on osgi-dev that you can make such code a lot simpler to write
> by using DS.
> This is how the code would look like:
> You externalize the code that depends on the optional import into one or more
> components. These components offer a service interface that is not dependent
> on the optional import. Inside the component you can work freely with the
> optional packages. You have to make sure this component is disabled by
> default. Then you write a "starter" component that enables the component if
> the package is available.
> I think scr could support such "optional" components without the disabled
> trick. We could load the component class and if it fails disable the
> component. If it works we enable it.
> So if the package is wired later and we get a refresh this approach would
> activate the component without any additional effort from the developer side.
>
> Below I am copying a snippet from Ray that details what they did.
> Given your component which has the optional import package (doesn't matter
> how it's used):
> import com.liferay.demo.foo.Foo; // The optional package
> @Component(
> enabled = false // disable by default so DS ignores it
> )
> public class OptionalPackageConsumer implements Foo {...}
> Make sure the component is disabled by default. This will prevent SCR from
> classloading the component class.
> Second, you construct a "starter" component who's job it is to check for the
> available package:
> @Component
> public class OptionalPackageConsumerStarter {
>@Activate
> void activate(ComponentContext componentContext) {
> try {
> Class.forName(com.liferay.demo.foo.Foo.class.getName());
>
> componentContext.enableComponent(OptionalPackageConsumer.class.getName());
> }
> catch (Throwable t) {
> _log.warn("Could not find {}", t.getMessage());
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5749) Allow to use components that depend on optional imports
[
https://issues.apache.org/jira/browse/FELIX-5749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16260906#comment-16260906
]
Robert Munteanu commented on FELIX-5749:
For me the scenario is the following:
Bundle A, with an optional import on {{com.example.foo}}.
In Bundle A, declare the following component
{code:java}
@Component
public class Component {
private @Reference SomeService service;
private @Reference(cardinality = OPTIONAL_UNARY ) private
com.example.foo.BarService bar;
}
{code}
The intention is for the component to work without a reference to
{{BarService}}, even when the optional import is not satisfied. That is not the
case today, since - IIUC - a failure in looking up any bind method results in
the component not being registered - or at least logging a WARN message.
> Allow to use components that depend on optional imports
> ---
>
> Key: FELIX-5749
> URL: https://issues.apache.org/jira/browse/FELIX-5749
> Project: Felix
> Issue Type: New Feature
>Affects Versions: scr-2.0.12
>Reporter: Christian Schneider
>
> When desigining the scope of a bundle you sometimes have an optional part
> that could be externalized into its own bundle but you decide to keep it in
> your bundle to limit the number of bundles. In this case you have to use an
> optional import and make sure the code that depends on this import only runs
> when this import is wired. This code is often quite awkward and often also
> buggy.
> We discussed on osgi-dev that you can make such code a lot simpler to write
> by using DS.
> This is how the code would look like:
> You externalize the code that depends on the optional import into one or more
> components. These components offer a service interface that is not dependent
> on the optional import. Inside the component you can work freely with the
> optional packages. You have to make sure this component is disabled by
> default. Then you write a "starter" component that enables the component if
> the package is available.
> I think scr could support such "optional" components without the disabled
> trick. We could load the component class and if it fails disable the
> component. If it works we enable it.
> So if the package is wired later and we get a refresh this approach would
> activate the component without any additional effort from the developer side.
>
> Below I am copying a snippet from Ray that details what they did.
> Given your component which has the optional import package (doesn't matter
> how it's used):
> import com.liferay.demo.foo.Foo; // The optional package
> @Component(
> enabled = false // disable by default so DS ignores it
> )
> public class OptionalPackageConsumer implements Foo {...}
> Make sure the component is disabled by default. This will prevent SCR from
> classloading the component class.
> Second, you construct a "starter" component who's job it is to check for the
> available package:
> @Component
> public class OptionalPackageConsumerStarter {
>@Activate
> void activate(ComponentContext componentContext) {
> try {
> Class.forName(com.liferay.demo.foo.Foo.class.getName());
>
> componentContext.enableComponent(OptionalPackageConsumer.class.getName());
> }
> catch (Throwable t) {
> _log.warn("Could not find {}", t.getMessage());
> }
> }
> }
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5410) Web console plugin for troubleshooting wiring issues
[ https://issues.apache.org/jira/browse/FELIX-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15665128#comment-15665128 ] Robert Munteanu commented on FELIX-5410: Wow, this looks pretty nice :-) > Web console plugin for troubleshooting wiring issues > > > Key: FELIX-5410 > URL: https://issues.apache.org/jira/browse/FELIX-5410 > Project: Felix > Issue Type: New Feature > Components: Web Console >Reporter: Alexander Klimetschek > Attachments: FELIX-5410.patch, webconsole-troubleshoot.png > > > h4. Feature > Add a new view/plugin to the standard webconsole that helps to pin point > which bundles, services or components are the true source for inactive > bundles or services. > * For *bundles* the underlying assumption would be a healthy system with all > bundles active, and thus any inactive can be shown and analyzed as being > problematic. > * For *services/components* one can look at inactive _immediate_ services > that fail because of unsatisfied references. For others, the user might need > to enter the "problematic" service or component they expect to be running to > start the analysis. > h4. Motivation > In a larger OSGi application with many bundles and components, it can be > difficult to find out the root cause why certain bundles do not start or why > a service is not active, especially for folks new to OSGi or with limited > knowledge about the application. I have seen many people fail, and thus "not > like" OSGi because of such hurdles during development, where it is easy to > update on bundle but miss out on crucial dependencies. > Figuring out is possible through the current web console, but only for > experts, if you click through the bundle or service details. This is usually > tedious work, if for example a lower level bundle is the problem, and 200 > others are not active because of it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-4009) maven bundle plugin should be integrated directly with eclipse
[
https://issues.apache.org/jira/browse/FELIX-4009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15194952#comment-15194952
]
Robert Munteanu commented on FELIX-4009:
{quote}i'm still not shure when this m2e-tycho plugin gets installed. {/quote}
It's the default configurator for maven-bundle-plugin projects in Eclipse, so
if you import such a project it will be highlighted as having errors and you
will have the option to start the m2e extension discovery process.
It's also (slightly relevant to your scenario) pulled in by the Sling IDE
Tooling for Eclipse.
{quote}so my first option would be to make it configurable in the POM whether
SCR metadata and manifest should be generated on incremental builds or
not.{quote}
I have two basic ideas which together might make the plugin work transparently
in Eclipse and in the CLI:
# create (by default) wildcard {{Service-Component}} headers, e.g.
{{Service-Component: OSGI-INF/*.xml}} . That would remove the need for updating
the MANIFEST whenever a SCR file changes
# hold a mapping of SCR annotations which is updated whenever the plugin is
invoked. ISTR that this can be done for m2e-enabled mojos, but I forget whether
this is done by reusing the same mojo instance ( so instance fields will be
kept ) or by another mechanism
> maven bundle plugin should be integrated directly with eclipse
> --
>
> Key: FELIX-4009
> URL: https://issues.apache.org/jira/browse/FELIX-4009
> Project: Felix
> Issue Type: New Feature
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.3.7
>Reporter: Andrei Pozolotin
>Assignee: Carsten Ziegeler
> Labels: m2e
> Fix For: maven-bundle-plugin-3.0.2
>
>
> Stuart:
> 1) currently, to integrate maven-bundle-plugin into m2e, one must use tycho
> configurator
> https://github.com/sonatype/m2eclipse-tycho
> which adds needles complexity, and makes few strange assumptions
> https://github.com/sonatype/m2eclipse-tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/internal/OsgiBundleProjectConfigurator.java#L74
> which no one it seems is there to care to correct
> https://github.com/sonatype/m2eclipse-tycho/pull/8
> 2) instead, I suggest maven-bundle-plugin to provide direct integration with
> eclipse via
> http://wiki.eclipse.org/M2E_compatible_maven_plugins#BuildContext
> which I would expect to be more customizable / flexible for the end user.
> I recently made similar switch with my DS plugin, and life got easier :-)
> https://github.com/carrot-garden/carrot-maven/tree/master/carrot-maven-scr-plugin
> thanks.
> Andrei.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: How do the maven-scr-plugin and maven-bundle-plugin cooperate?
Hi Stefan and Konrad, Your suggetions make sense, it is probably more worthwhile to focus on getting the maven-bundle-plugin m2e-compatible. I was hoping to find a quick fix in the maven-scr-plugin which would make it compatible with newer m2e-tycho releases. (some text snipped, more replies inline) On Fri, 2015-12-04 at 23:36 +, Stefan Seifert wrote: > 4. unlike maven-scr-plugin the maven-bundle-plugin generates the SCR > metadata by default only in the package phase when the "bundle" goal > is executed - this breaks the unit tests with OSGi mocks, they have > to be generated before the tests are executed > 5. in eclipse/m2e the scr metadata was not updated incrementally > because the maven-bundle-plugin does not provide a m2e configuration > unlike the maven-scr-plugin > > i solved these problems by: > 4.: configured an additional execution for manifest goal which > executes in process-classes phase and enable the "exportScr" feature > to make sure they are not only written to the JAR file but to > filesystem as well where they are expected by OSGi mocks > 5.: added a custom m2e config to execute the manifest goal on > incremental builds and configuration as well Shipping our own lifecycle metadata should work given that we adopt the m2e-friendly BuildContext API, so building in Eclipse would work. What m2e-tycho does and I am not sure can be done with the regular BuildContext API is replacing the 'bundle' goal with 'manifest' for Eclipse executions. It does so for both performance and correctness reasons ( build result would conflict with the regular JDT builder ). Did you see any such problems when enabling plugin executions for the maven-bundle-plugin in Eclipse? Thanks, Robert > > you can see my experiments in this snapshot pom at [1] and [2]. the > "intermediate" builds required to test this are located at [3]. > > i would favor as well shipping the maven-bundle-plugin with a > sensible m2e default configuration, if we all agree what this should > include precisely. > > stefan > > [1] https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-g > lobal-parent/pom.xml#L185 > [2] https://github.com/wcm-io/wcm-io-tooling/blob/develop/maven/aem-g > lobal-parent/pom.xml#L410 > [3] http://wcm.io/maven/repositories/apache-intermediate-release/ > > > > > -Original Message- > > From: Konrad Windszus [mailto:konra...@gmx.de] > > Sent: Friday, December 04, 2015 7:02 PM > > To: dev@felix.apache.org > > Subject: Re: How do the maven-scr-plugin and maven-bundle-plugin > > cooperate? > > > > Hi Robert, > > is this really worth the effort? > > I guess we should now focus only on the maven-bundle-plugin as that > > can > > even parse scr-compatible annotations now (compare with http://www. > > mail- > > archive.com/dev@felix.apache.org/msg38291.html). > > That way we don’t need to further examine the communications across > > different plugins, but just fix m2eclipse-tycho to generate the > > manifest > > and the service descriptors whenever some class has been > > added/removed or > > just add the m2e extension to the maven-bundle-plugin itself (you > > suggested > > that already in http://www.mail- > > archive.com/dev@felix.apache.org/msg38332.html). > > Is there any reason why you want m2eclipse-tycho to communicate > > with maven- > > scr-plugin instead of just relying on the internal bnd feature? > > Konrad
How do the maven-scr-plugin and maven-bundle-plugin cooperate?
Hi, I'm looking at the Eclipse integration netweem the maven-bundle-plugin and the maven-scr-plugin. For the bundle plugin this is handled by m2eclipse-tycho [1], while for the scr plugin this is done by the plugin itself, by using a special set of APIs which work in both Eclipse and the CLI. Unfortunately, more recent versions of m2eclipse-tycho are more conservative about regenerating the bundle manifest [2], which means that unless a full build is triggered the manifest does not include changes to the Service-Component header. I am trying to fix this (somehow), but I did not find the way the two plugins cooperate. I see that the scr plugin sets certain project properties related to the Service-Component header [3], but I have no idea where the bundle plugin reads those. If anyone has an idea about how the plugins cooperate, or of any approach which can fix the Eclipse integration, please let me know. Thanks, Robert [1]: https://github.com/tesla/m2eclipse-tycho [2]: https://github.com/tesla/m2eclipse-tycho/commit/85cd048ffcd4702099 2bdec2cd44f1a4945173bf [3]: https://github.com/apache/felix/blob/f6c2e7f15e825521f2a9f778a8ab6 e0cacc208d5/tools/maven-scr- plugin/src/main/java/org/apache/felix/scrplugin/mojo/SCRDescriptorMojo. java#L461-L465
[jira] [Commented] (FELIX-5119) Jaas module build fails with JDK 8
[ https://issues.apache.org/jira/browse/FELIX-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15035614#comment-15035614 ] Robert Munteanu commented on FELIX-5119: Build works fine for me now, thank you! > Jaas module build fails with JDK 8 > -- > > Key: FELIX-5119 > URL: https://issues.apache.org/jira/browse/FELIX-5119 > Project: Felix > Issue Type: Task > Components: JAAS >Reporter: Chetan Mehrotra >Assignee: Chetan Mehrotra > Fix For: jaas-0.0.4 > > > Building trunk with JDK 8 fails with test failures > See http://markmail.org/message/2dvzkkawoe26bw7w -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: git?
On Sun, 2015-10-25 at 07:47 +0100, Christian Schneider wrote: > I am not sure if one git repo for everything would be a good idea. > The > main reason is that in git (unlike in subversion) each branch and tag > you do contains all the other unrelated projects too. > I think it would also be quite difficult to checkout a state of the > repo > where you need bundle A in branch A1 and bundle B in branch B2. > Probably > this would mean that you need to checkout two instances of the repo > to have both branches visisble at the same time. You would then also > have to be really careful to not pick a project from the wrong > checkout > as it would be in kind of an undefined state there. > The other solution of having one git repo per bundle also seems to be > quite difficult to manage as you need to checkout and sync every such > checkout in the correct way. I have seen a project that does this at > a > customer and it is not very easy to work in this structure. > > In the Aries project we went for kind of a compromise. > > We aim for releases by subproject. So each subproject can go into one > git repo. > The advantage is that each tag in git really covers the whole > subproject. So from the git side this is natural. If you have multiple git subprojects you can tie them into one git repository without resorting to submodules. I've used a tool called gitslave [1] with very good results when splitting a large repository into multiple smaller ones ( 94 at the moment ). gitslave allows you to define a single 'master' repository which minimally needs to hold a .gitslave file which points to the child repositories. You can then use the 'gits' command to run commands over multiple repositories, e.g. * gits populate to create the child repositories * gits pull to run 'git pull' over all child repositoroes * gits push to 'run git push' over all child repositories ... I guess you get the idea. HTH, Robert [1]: http://gitslave.sourceforge.net/ > > The downside is of course that in many cases bundles are released > that > did not change at all. > We make sure the package versions are done with semantic > versioning. So > from the OSGi point of view the versioning > is still working as before. > > At the moment we have not yet done the migration to git but it is > planned. We are currently moving each subproject to the release by > subproject model gradually. > Theoretically we can then move each subproject to git independently. > I > am not sure though how to move the change history over in that case. > In any case the Aries JPA project is the first one that is fully > converted to the release by subproject model if you want to take a > look. > https://github.com/apache/aries/tree/trunk/jpa > > Christian > > Am 24.10.2015 um 23:32 schrieb Benson Margulies: > > On Sat, Oct 24, 2015 at 4:21 PM, David Jencks > .com> wrote: > > > I like having several felix subprojects open in one eclipse > > > instance at once, which the current svn structure > > > facilitates. Having just one git svn rebase to run is nice. Is > > > there a way to stitch together several smaller git repos that > > > would work similarly? Not knowing how to do this, I am starting > > > to lean towards one big repo. > > Well, there are git submodules. But I hate to take everyone into > > that > > rabbit hole. I think we should aim to start with one big repo and > > assume we can tame the maven-release-plugin to start with. > > > > > > > FWIW, I’m hoping to move DS onto a gradle based build soon. > > > > > > thanks > > > david jencks > > > > > > > On Oct 24, 2015, at 2:51 PM, Benson Margulies > > > .com> wrote: > > > > > > > > Greeting, Marcel, > > > > > > > > It's not my intention to try to talk anyone into changing how > > > > they > > > > release anything. For the things that are built with Maven, > > > > it's my > > > > preference to avoid exercising the maven-release-plugin's > > > > feature of > > > > handling multiple released items in a repo, but it's just a > > > > preference. If the acceptable compromise is to have less repos > > > > than > > > > releasable items (possibly as few as one repo), I'd personally > > > > rather > > > > do that than not move to git at all. > > > > > > > > regards, > > > > > > > > benson > > > > > > > > > > > > On Sat, Oct 24, 2015 at 2:43 PM, Marcel Offermans > > > > wrote: > > > > > On 24 October 2015 at 11:36:03, Benson Margulies (benson@basi > > > > > stech.com(mailto:ben...@basistech.com)) wrote: > > > > > > > > > > > > So I would definitely argue against getting a Git > > > > > > > repository per bundle. > > > > > > > Per subproject sounds like the right granularity to me. > > > > > > If a subproject is released all at once, then we're > > > > > > completely > > > > > > agreeing. If not, then your preference means exercising the > > > > > > occasionally squishy part of the release plugin; maybe it > > > > > > will get > > > > > > fixed once and for all. > > > > > So for
Re: Building org.apache.felix.jaas fails
Hi Chetan, On Mon, Oct 26, 2015 at 6:48 AM, Chetan Mehrotra wrote: > Hi Robert, > > Whats the mvn+java version you are using. I tried with latest trunk > and it build fine $ mvn -v Apache Maven 3.3.3 (7994120775791599e205a5524ec3e0dfe41d4a06; 2015-04-22T14:57:37+03:00) Maven home: /usr/share/java/maven Java version: 1.8.0_60, vendor: Oracle Corporation Java home: /usr/lib64/jvm/java-1.8.0-openjdk-1.8.0/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "4.2.3-1-default", arch: "amd64", family: "unix" Thanks, Robert > > mvn -v > Apache Maven 3.2.5 (12a6b3acb947671f09b81f49094c53f426d8cea1; > 2014-12-14T22:59:23+05:30) > Maven home: xxx/apache-maven-3.2.5 > Java version: 1.7.0_55, vendor: Oracle Corporation > Java home: xxx/jdk/jdk1.7.0_55/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "3.13.0-37-generic", arch: "amd64", family: "unix" > Chetan Mehrotra > > > On Thu, Oct 22, 2015 at 2:58 PM, Robert Munteanu wrote: >> Hi, >> >> I tried to build the jaas module as of r1709963 . The build fails due >> to the animal-sniffer-maven-plugin: >> >> [INFO] Checking unresolved references to >> org.codehaus.mojo.signature:java15:1.0 >> [ERROR] >> /home/robert/Documents/sources/apache/felix/jaas/src/main/java/org/apac >> he/felix/jaas/internal/ConfigSpiOsgi.java:117: Undefined reference: >> void javax.security.auth.login.ConfigurationSpi.() >> [ERROR] >> /home/robert/Documents/sources/apache/felix/jaas/src/main/java/org/apac >> he/felix/jaas/internal/ConfigSpiOsgi.java:147: Undefined reference: >> javax.security.auth.login.Configuration >> javax.security.auth.login.Configuration.getInstance(String, >> javax.security.auth.login.Configuration.Parameters, String) >> >> [ERROR]/home/robert/Documents/sources/apache/felix/jaas/src/main/java/o >> rg/apache/felix/jaas/internal/ConfigSpiOsgi.java:568: Undefined >> reference: Object[] java.util.Arrays.copyOf(Object[], int) >> >> I added the felix.java.version property with value 6 to the pom, and >> this allowed the build to progress. However, the Pax-Exam tests all >> fail, and the root error seems to be: >> >> ERROR: Bundle org.apache.felix.jaas.sample1 [21] Error starting >> file:/tmp/1445505936570-0/bundles/org.apache.felix.jaas.sample1_0.jar >> (org.osgi.framework.BundleException: Unresolved constraint in bundle >> org.apache.felix.jaas.sample1 [21]: Unable to resolve 21.0: mis >> sing requirement [21.0] osgi.wiring.package; >> (osgi.wiring.package=javax.security.auth)) >> >> org.osgi.framework.BundleException: Unresolved constraint in bundle >> org.apache.felix.jaas.sample1 [21]: Unable to resolve 21.0: missi >> ng requirement [21.0] osgi.wiring.package; >> (osgi.wiring.package=javax.security.auth) >> at >> org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) >> at >> org.apache.felix.framework.Felix.startBundle(Felix.java:1868) >> at >> org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) >> at >> org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLe >> velImpl.java:295) >> at java.lang.Thread.run(Thread.java:745) >> >> Is there anything more I should look into or is this a bug? >> >> Thanks, >> >> Robert >>
[jira] [Commented] (FELIX-5083) Set webconsole.configurationFactory.nameHint for JAAS configurations
[
https://issues.apache.org/jira/browse/FELIX-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14968862#comment-14968862
]
Robert Munteanu commented on FELIX-5083:
Attached [patch|^FELIX-5083.patch] and [screenshot|^FELIX-5083.png] . Note that
I was unable to run the pax-exam tests but i don't think they would be affected
by this change ( see [dev@felix: Build org.apache.felix.jaas
fails|http://markmail.org/message/2dvzkkawoe26bw7w] .
> Set webconsole.configurationFactory.nameHint for JAAS configurations
>
>
> Key: FELIX-5083
> URL: https://issues.apache.org/jira/browse/FELIX-5083
> Project: Felix
> Issue Type: Improvement
> Components: JAAS
>Affects Versions: jaas-0.0.2
>Reporter: Robert Munteanu
>Priority: Minor
> Fix For: jaas-0.0.4
>
> Attachments: FELIX-5083.patch, FELIX-5083.png
>
>
> When working with multiple JAAS configuration in the Felix Web Console it's
> hard to distinguish them.
> Setting the {{webconsole.configurationFactory.nameHint}} property to a
> reasonable default removes this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5083) Set webconsole.configurationFactory.nameHint for JAAS configurations
[
https://issues.apache.org/jira/browse/FELIX-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-5083:
---
Attachment: FELIX-5083.png
> Set webconsole.configurationFactory.nameHint for JAAS configurations
>
>
> Key: FELIX-5083
> URL: https://issues.apache.org/jira/browse/FELIX-5083
> Project: Felix
> Issue Type: Improvement
> Components: JAAS
>Affects Versions: jaas-0.0.2
> Reporter: Robert Munteanu
>Priority: Minor
> Fix For: jaas-0.0.4
>
> Attachments: FELIX-5083.patch, FELIX-5083.png
>
>
> When working with multiple JAAS configuration in the Felix Web Console it's
> hard to distinguish them.
> Setting the {{webconsole.configurationFactory.nameHint}} property to a
> reasonable default removes this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5083) Set webconsole.configurationFactory.nameHint for JAAS configurations
[
https://issues.apache.org/jira/browse/FELIX-5083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-5083:
---
Attachment: FELIX-5083.patch
> Set webconsole.configurationFactory.nameHint for JAAS configurations
>
>
> Key: FELIX-5083
> URL: https://issues.apache.org/jira/browse/FELIX-5083
> Project: Felix
> Issue Type: Improvement
> Components: JAAS
>Affects Versions: jaas-0.0.2
> Reporter: Robert Munteanu
>Priority: Minor
> Fix For: jaas-0.0.4
>
> Attachments: FELIX-5083.patch
>
>
> When working with multiple JAAS configuration in the Felix Web Console it's
> hard to distinguish them.
> Setting the {{webconsole.configurationFactory.nameHint}} property to a
> reasonable default removes this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5083) Set webconsole.configurationFactory.nameHint for JAAS configurations
Robert Munteanu created FELIX-5083:
--
Summary: Set webconsole.configurationFactory.nameHint for JAAS
configurations
Key: FELIX-5083
URL: https://issues.apache.org/jira/browse/FELIX-5083
Project: Felix
Issue Type: Improvement
Components: JAAS
Affects Versions: jaas-0.0.2
Reporter: Robert Munteanu
Priority: Minor
Fix For: jaas-0.0.4
When working with multiple JAAS configuration in the Felix Web Console it's
hard to distinguish them.
Setting the {{webconsole.configurationFactory.nameHint}} property to a
reasonable default removes this problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Building org.apache.felix.jaas fails
Hi, I tried to build the jaas module as of r1709963 . The build fails due to the animal-sniffer-maven-plugin: [INFO] Checking unresolved references to org.codehaus.mojo.signature:java15:1.0 [ERROR] /home/robert/Documents/sources/apache/felix/jaas/src/main/java/org/apac he/felix/jaas/internal/ConfigSpiOsgi.java:117: Undefined reference: void javax.security.auth.login.ConfigurationSpi.() [ERROR] /home/robert/Documents/sources/apache/felix/jaas/src/main/java/org/apac he/felix/jaas/internal/ConfigSpiOsgi.java:147: Undefined reference: javax.security.auth.login.Configuration javax.security.auth.login.Configuration.getInstance(String, javax.security.auth.login.Configuration.Parameters, String) [ERROR]/home/robert/Documents/sources/apache/felix/jaas/src/main/java/o rg/apache/felix/jaas/internal/ConfigSpiOsgi.java:568: Undefined reference: Object[] java.util.Arrays.copyOf(Object[], int) I added the felix.java.version property with value 6 to the pom, and this allowed the build to progress. However, the Pax-Exam tests all fail, and the root error seems to be: ERROR: Bundle org.apache.felix.jaas.sample1 [21] Error starting file:/tmp/1445505936570-0/bundles/org.apache.felix.jaas.sample1_0.jar (org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.felix.jaas.sample1 [21]: Unable to resolve 21.0: mis sing requirement [21.0] osgi.wiring.package; (osgi.wiring.package=javax.security.auth)) org.osgi.framework.BundleException: Unresolved constraint in bundle org.apache.felix.jaas.sample1 [21]: Unable to resolve 21.0: missi ng requirement [21.0] osgi.wiring.package; (osgi.wiring.package=javax.security.auth) at org.apache.felix.framework.Felix.resolveBundleRevision(Felix.java:3826) at org.apache.felix.framework.Felix.startBundle(Felix.java:1868) at org.apache.felix.framework.Felix.setActiveStartLevel(Felix.java:1191) at org.apache.felix.framework.FrameworkStartLevelImpl.run(FrameworkStartLe velImpl.java:295) at java.lang.Thread.run(Thread.java:745) Is there anything more I should look into or is this a bug? Thanks, Robert
Re: Future of maven-scr-plugin
On Sun, 2015-10-11 at 17:09 +0200, Konrad Windszus wrote: > Hi Robert, > I just tried it out, but actually the OSGi-INF part of it is not > properly updated within Eclipse. > By looking at the according m2e plugin ( > https://github.com/tesla/m2eclipse-tycho < > https://github.com/tesla/m2eclipse-tycho>), I am not sure where the > problem is exactly. > > This is what I figured out so far: > > There is a > org.sonatype.tycho.m2e.felix.internal.MavenBundlePluginConfigurator > configured in https://github.com/tesla/m2eclipse-tycho/blob/master/or > g.sonatype.tycho.m2e/plugin.xml <https://github.com/tesla/m2eclipse-t > ycho/blob/master/org.sonatype.tycho.m2e/plugin.xml> > That returns a build participant in https://github.com/tesla/m2eclips > e > -tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/ > felix/internal/MavenBundlePluginConfigurator.java#L87 <https://github > .com/tesla/m2eclipse > -tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/ > felix/internal/MavenBundlePluginConfigurator.java#L87>. > That one executes org.apache.felix.bundleplugin.ManifestPlugin. > Obviously the ManifestPlugin does not create the scr data unless > exportScr is set to true (https://github.com/apache/felix/blob/trunk/ > tools/maven-bundle > -plugin/src/main/java/org/apache/felix/bundleplugin/ManifestPlugin.ja > va#L80 <https://github.com/apache/felix/blob/trunk/tools/maven-bundle > -plugin/src/main/java/org/apache/felix/bundleplugin/ManifestPlugin.ja > va#L80>). Unfortunately the exportScr is not set to true by m2eclipse > -tycho (this is probably a bug in m2eclipse-tycho). > > Also the maven-bundle-plugin does not seem to support writing the > metatype information (seems like a bug in the ManifestPlugin mojo of > the maven-bundle-plugin). > > Also I am not sure if the ManifestPlugin is called often enough by > the MavenBundlePluginConfigurator, the conditions in https://github.c > om/tesla/m2eclipse > -tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/ > felix/internal/MavenBundlePluginConfigurator.java#L103 <https://githu > b.com/tesla/m2eclipse > -tycho/blob/master/org.sonatype.tycho.m2e/src/org/sonatype/tycho/m2e/ > felix/internal/MavenBundlePluginConfigurator.java#L103> look wrong to > me. > E.g. if someone just adds an OSGi component class carrying some > annotations, this will not being picked up until the next full build. > Maybe that is deliberate to increase the build performance, but that > would mean not all changes lead to consistent Manifest/SCR/metatype > informations. > > Maybe someone else can confirm the observed behaviour, then I would > create bug reports for both issues. There was a behaviour change in m2e-tycho [1] which probably accounts for this. Maybe a better way is to let go of the tycho configurator and make the maven-bundle-plugin a m2e-compatible-plugin [2]? That being said, I have not looked at the plugin internals recently so can't comment on how feasible it is. Robert [1]: https://github.com/tesla/m2eclipse-tycho/commit/85cd048ffcd4702099 2bdec2cd44f1a4945173bf [2]: https://wiki.eclipse.org/M2E_compatible_maven_plugins > Konrad > > > > On 09 Oct 2015, at 21:33, Robert Munteanu > > wrote: > > > > Hi Konrad, > > > > > > > > Am 09.10.15 um 18:14 schrieb Konrad Windszus: > > > > > I experimented a bit and using something like this in my > > > > > pom.xml works pretty well. > > > > > > > > > > > > > > > org.apache.felix > > > > > maven-bundle-plugin > > > > > 3.0.0 > > > > > true > > > > > > > > > > > > > > > > > > > > <_dsannotations>* > > > > > > > > > > <_dsannotations-inherit>true > > > > > > > > > > <_metatypeannotations>* > > > > > > > > > > > > > > > <_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlug > > > > > in;destdir=target/classes > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > org.apache.felix > > > > > org.apache.felix.scr.bnd > > > > > 1.4.0 > > > > > > > > > > > > > > > > > > > > > > > > Out of curiosity, have you checked whether the m2e integration with > > Eclipse works? I'm interested in the generation of the manifest but > > also in the generation of the SCR descriptors. > > > > Thanks, > > > > Robert >
Re: Future of maven-scr-plugin
Hi Konrad, >> Am 09.10.15 um 18:14 schrieb Konrad Windszus: >>> I experimented a bit and using something like this in my pom.xml works >>> pretty well. >>> >>> >>> org.apache.felix >>> maven-bundle-plugin >>> 3.0.0 >>> true >>> >>> >>> >>> <_dsannotations>* >>> >>> <_dsannotations-inherit>true >>> >>> <_metatypeannotations>* >>> >>> >>> <_plugin>org.apache.felix.scrplugin.bnd.SCRDescriptorBndPlugin;destdir=target/classes >>> >>> >>> >>> >>> >>> org.apache.felix >>> org.apache.felix.scr.bnd >>> 1.4.0 >>> >>> >>> >>> Out of curiosity, have you checked whether the m2e integration with Eclipse works? I'm interested in the generation of the manifest but also in the generation of the SCR descriptors. Thanks, Robert
Re: [Framework] ServiceRegistry.getService() endless loop with lock?
On Fri, Mar 20, 2015 at 7:41 PM, David Bosschaert
wrote:
> Some more thoughts about this...
>
> The wait() call in the getService() method is as follows:
>
> synchronized (this)
> {
> // First make sure that no existing operation is currently
> // being performed by another thread on the service registration.
> for (Object o = m_lockedRegsMap.get(reg); (o != null); o =
> m_lockedRegsMap.get(reg))
> {
> // We don't allow cycles when we call out to the
> service factory.
> if (o.equals(Thread.currentThread()))
> {
> throw new ServiceException(
> "ServiceFactory.getService() resulted in a cycle.",
> ServiceException.FACTORY_ERROR,
> null);
> }
>
> // Otherwise, wait for it to be freed.
> try
> {
> wait();
> }
> catch (InterruptedException ex)
> {
> Thread.currentThread().interrupt();
> }
> }
>
Resetting the interrupt flag on a thread after it has been interrupted
is a usual practice and it allows the thread pool managing said thread
to to see that a cancellation has been requested. So IMO the interrupt
call should remain.
However, the code should also break out of the loop, as an interrupt
invariably is a request to stop the thread's execution. IMO the code
should end up looking something like
try
{
wait();
}
catch (InterruptedException ex)
{
Thread.currentThread().interrupt();
break;
}
Robert
> I'm wondering why the code doesn't break out of the loop in the catch block?
>
> Cheers,
>
> David
>
> On 20 March 2015 at 12:16, David Bosschaert
> wrote:
>> Hi all,
>>
>> I'm looking at an issue that I'm experiencing (with Felix 4.6.1/Java
>> 7) where the ServiceRegsitry.getService() [1] method seems to be in an
>> endless loop. It doesn't happen very often, but when it does happen
>> the thread executing getService() seems to never exit that method
>> apparently switch between the following two states:
>>
>> 1: Thread 22059: (state = IN_VM)
>> - java.lang.Object.wait(long) @bci=0 (Compiled frame; information may
>> be imprecise)
>> - java.lang.Object.wait() @bci=2, line=503 (Compiled frame)
>> -
>> org.apache.felix.framework.ServiceRegistry.getService(org.osgi.framework.Bundle,
>> org.osgi.framework.ServiceReference, boolean) @bci=86, line=313
>> (Compiled frame)
>>
>> 2: Thread 22059: (state = IN_VM)
>> - java.lang.Throwable.fillInStackTrace(int) @bci=0 (Compiled frame;
>> information may be imprecise)
>> - java.lang.Throwable.fillInStackTrace() @bci=16, line=783 (Compiled frame)
>> - java.lang.Throwable.() @bci=24, line=250 (Compiled frame)
>> - java.lang.Exception.() @bci=1, line=54 (Compiled frame)
>> - java.lang.InterruptedException.() @bci=1, line=57 (Compiled frame)
>> - java.lang.Object.wait(long) @bci=0 (Compiled frame)
>> - java.lang.Object.wait() @bci=2, line=503 (Compiled frame)
>> -
>> org.apache.felix.framework.ServiceRegistry.getService(org.osgi.framework.Bundle,
>> org.osgi.framework.ServiceReference, boolean) @bci=86, line=313
>> (Compiled frame)
>>
>> Even though the thread is executing wait() all of the other Felix
>> SR-accessing threads are blocked on the Service Registry lock. The net
>> effect is that any operation on the Service Registry is blocked.
>> There is one thing that I don't understand and that is that in the
>> above frames the lock should really be released, as the code is in
>> wait(). However, it seems like the lock is still held because none of
>> the other threads are getting access to the Service Registry. For
>> example another such thread is the following which is actually about
>> to decrease the usage count on the service and then call notifyAll():
>>
>> Thread 48643: (state = BLOCKED)
>> -
>> org.apache.felix.framework.ServiceRegistry.getService(org.osgi.framework.Bundle,
>> org.osgi.framework.ServiceReference, boolean) @bci=241, line=367
>> (Compiled frame)
>> -
>> org.apache.felix.framework.util.EventDispatcher.filterListenersUsingHooks(org.osgi.framework.ServiceEvent,
>> org.osgi.framework.launch.Framework, java.util.Map) @bci=349, line=618
>> (Compiled frame)
>> -
>> org.apache.felix.framework.util.EventDispatcher.fireServiceEvent(org.osgi.framework.ServiceEvent,
>> java.util.Dictionary, org.osgi.framework.launch.Framework) @bci=33,
>> line=542 (Interpreted frame)
>> -
>> org.apache.felix.framework.Felix.fireServiceEvent(org.osgi.framework.ServiceEvent,
>> java.util.Dictionary) @bci=7, line=4547 (Compiled frame)
>> -
>> org.apache.felix.framework.Felix.access$000(org.apache.felix.framework.Felix,
>> org.osgi
[jira] [Commented] (FELIX-4666) The baseline goal should print out the resolved version used for comparison
[
https://issues.apache.org/jira/browse/FELIX-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14294210#comment-14294210
]
Robert Munteanu commented on FELIX-4666:
Ping? Would be nice to see this in the next release
> The baseline goal should print out the resolved version used for comparison
> ---
>
> Key: FELIX-4666
> URL: https://issues.apache.org/jira/browse/FELIX-4666
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.5.3
> Reporter: Robert Munteanu
>Priority: Minor
> Attachments: FELIX-4666-1.patch
>
>
> The baseline goal uses a default comparisonVersion of {{,project.version}}
> and prints it out when running the analysis.
> However, it would be more useful to print out the resolved version, e.g.
> instead of {{(,1.0.9-SNAPSHOT)}} print out 1.0.8 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-4666) The baseline goal should print out the resolved version used for comparison
[
https://issues.apache.org/jira/browse/FELIX-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14179932#comment-14179932
]
Robert Munteanu commented on FELIX-4666:
Attached minimal patch which fixes the reported issue.
> The baseline goal should print out the resolved version used for comparison
> ---
>
> Key: FELIX-4666
> URL: https://issues.apache.org/jira/browse/FELIX-4666
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.5.3
> Reporter: Robert Munteanu
>Priority: Minor
> Attachments: FELIX-4666-1.patch
>
>
> The baseline goal uses a default comparisonVersion of {{,project.version}}
> and prints it out when running the analysis.
> However, it would be more useful to print out the resolved version, e.g.
> instead of {{(,1.0.9-SNAPSHOT)}} print out 1.0.8 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-4666) The baseline goal should print out the resolved version used for comparison
[
https://issues.apache.org/jira/browse/FELIX-4666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-4666:
---
Attachment: FELIX-4666-1.patch
> The baseline goal should print out the resolved version used for comparison
> ---
>
> Key: FELIX-4666
> URL: https://issues.apache.org/jira/browse/FELIX-4666
> Project: Felix
> Issue Type: Improvement
> Components: Maven Bundle Plugin
>Affects Versions: maven-bundle-plugin-2.5.3
> Reporter: Robert Munteanu
>Priority: Minor
> Attachments: FELIX-4666-1.patch
>
>
> The baseline goal uses a default comparisonVersion of {{,project.version}}
> and prints it out when running the analysis.
> However, it would be more useful to print out the resolved version, e.g.
> instead of {{(,1.0.9-SNAPSHOT)}} print out 1.0.8 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-4666) The baseline goal should print out the resolved version used for comparison
Robert Munteanu created FELIX-4666:
--
Summary: The baseline goal should print out the resolved version
used for comparison
Key: FELIX-4666
URL: https://issues.apache.org/jira/browse/FELIX-4666
Project: Felix
Issue Type: Improvement
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.5.3
Reporter: Robert Munteanu
Priority: Minor
The baseline goal uses a default comparisonVersion of {{,project.version}} and
prints it out when running the analysis.
However, it would be more useful to print out the resolved version, e.g.
instead of {{(,1.0.9-SNAPSHOT)}} print out 1.0.8 .
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-4639) Document the baseline capabilities of the Maven Bundle Plugin
Robert Munteanu created FELIX-4639: -- Summary: Document the baseline capabilities of the Maven Bundle Plugin Key: FELIX-4639 URL: https://issues.apache.org/jira/browse/FELIX-4639 Project: Felix Issue Type: Bug Components: Documentation, Maven Bundle Plugin Reporter: Robert Munteanu The baseline capabilities introduced in FELIX-4512 should be better documented. I recently needed to point out this feature to someone and I has to send them to the Jira issue, since there is no other documentation. I would be nice to have at lease some minimal documentation for it. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Apache Felix SCR Tooling [2nd]
+1 ( non-binding ) On Mon, Jul 28, 2014 at 4:41 PM, Carsten Ziegeler wrote: > +1 > > > 2014-07-28 15:41 GMT+02:00 Carsten Ziegeler : > >> Hi, >> >> we fixed some bugs in the SCR Tooling. >> >> This vote is about the following releases: >> >> SCR Generator 1.12.0 >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12326942 >> >> Maven SCR Plugin 1.19.0 >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12326944 >> >> SCR Ant Task 1.13.0 >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12326943 >> >> Bnd SCR Plugin 1.3.0 >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12326941 >> >> DS Annotations 1.2.8 >> https://issues.apache.org/jira/browse/FELIX/fixforversion/12324800 >> >> Staging repository: >> https://repository.apache.org/content/repositories/orgapachefelix-1031 >> >> You can use this UNIX script to download the release and verify the >> signatures: >> http://svn.apache.org/repos/asf/felix/trunk/check_staged_release.sh >> >> Usage: >> sh check_staged_release.sh 1031 /tmp/felix-staging >> >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] 0 Don't care >> [ ] -1 Don't release, because ... >> >> This vote will be open for 72 hours. >> >> Regards >> Carsten >> -- >> Carsten Ziegeler >> Adobe Research Switzerland >> cziege...@apache.org >> > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org
[jira] [Commented] (FELIX-4586) A field must be volatile if methods are generated for a dynamic reference
[ https://issues.apache.org/jira/browse/FELIX-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076182#comment-14076182 ] Robert Munteanu commented on FELIX-4586: In this case I would not comment at all, since it is be annoying to write correct bind/unbind methods and still get the warning. The alternative would be to turn off the check altogether, but then I'd miss potential errors in other components. > A field must be volatile if methods are generated for a dynamic reference > - > > Key: FELIX-4586 > URL: https://issues.apache.org/jira/browse/FELIX-4586 > Project: Felix > Issue Type: Bug > Components: SCR Tooling >Affects Versions: maven-scr-plugin 1.17.0, scr ant task 1.11.0, scr > generator 1.10.0 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: maven-scr-plugin 1.18.0, scr ant task 1.12.0, scr > generator 1.11.0 > > > If a field is used for a reference, like > @Reference(policy=DYNAMIC) > private Field myService > and methods are generated for this dynamic reference, the field must be > declared volatile. Otherwise updates to the field are not visible to the > threads calling this component. > If no methods are generated and the reference is dynamic, a warning should be > generated if it is not volatile. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4586) A field must be volatile if methods are generated for a dynamic reference
[
https://issues.apache.org/jira/browse/FELIX-4586?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14076167#comment-14076167
]
Robert Munteanu commented on FELIX-4586:
I've tried the new plugin on a component with the following snippet:
{code}
@Reference(policy = DYNAMIC)
private StringBuilder bla;
protected synchronized void bindBla(StringBuilder newBla) {
this.bla = newBla;
}
protected synchronized void unbindBla(StringBuilder oldBla) {
if ( this.bla == oldBla ) {
this.bla = null;
}
}
{code}
I would not expect to get an error, but I do:
{code}[1:1]: @Reference(bla) : Dynamic field should be declared volatile for
unary references{code}
I would expect this to be triggered only if the methods were generated by the
plugin, which they were not. Either I misunderstood the feature, or generated
methods are not properly taken into account.
> A field must be volatile if methods are generated for a dynamic reference
> -
>
> Key: FELIX-4586
> URL: https://issues.apache.org/jira/browse/FELIX-4586
> Project: Felix
> Issue Type: Bug
> Components: SCR Tooling
>Affects Versions: maven-scr-plugin 1.17.0, scr ant task 1.11.0, scr
> generator 1.10.0
>Reporter: Carsten Ziegeler
>Assignee: Carsten Ziegeler
> Fix For: maven-scr-plugin 1.18.0, scr ant task 1.12.0, scr
> generator 1.11.0
>
>
> If a field is used for a reference, like
> @Reference(policy=DYNAMIC)
> private Field myService
> and methods are generated for this dynamic reference, the field must be
> declared volatile. Otherwise updates to the field are not visible to the
> threads calling this component.
> If no methods are generated and the reference is dynamic, a warning should be
> generated if it is not volatile.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (FELIX-4477) Sporadic failure to resolve jar files embedded in fragment bundles
[
https://issues.apache.org/jira/browse/FELIX-4477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13958777#comment-13958777
]
Robert Munteanu commented on FELIX-4477:
Is this a dupe of FELIX-3701 ?
> Sporadic failure to resolve jar files embedded in fragment bundles
> --
>
> Key: FELIX-4477
> URL: https://issues.apache.org/jira/browse/FELIX-4477
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-4.2.0
>Reporter: Julian Sedding
>
> Scenario:
> - two fragment bundles, f1 and f2, are attached to the same host bundle
> - at least one fragment bundle embeds a jar file, which is mentioned in its
> Bundle-ClassPath header
> - when resolving the host bundle during startup, sometimes the embedded jar
> file cannot be found (at felix.log.level=3 this causes "INFO Class path entry
> not found: enbedded-file.jar" to be logged)
> The consequence is that functionality provided by the embedded jar file is
> unavailable.
> Analysis:
> When calculating the "contentPath" in
> BundleRevisionImpl#initializeContentPath() the implementation assumes that
> the local lists fragments and fragmentContents are sorted and in sync (i.e.
> the same index refers to the same fragment bundle).
> However, this assumption does not hold if two or more fragment bundles are
> attached to the same host bundle.
> The following excerpt from BundleRevisionImpl#initializeContentPath()
> illustrates the problem:
> List fragments = null;
> List fragmentContents = null;
> if (m_wiring != null)
> {
> fragments = Util.getFragments(m_wiring);
> fragmentContents = m_wiring.getFragmentContents();
> }
> if (fragments != null)
> {
> for (int i = 0; i < fragments.size(); i++)
> {
> calculateContentPath(
> fragments.get(i), fragmentContents.get(i), contentList,
> false);
> }
> }
> fragments is initialized via Util.getFragments(m_wiring), while
> fragmentContents is set to m_wiring.getFragmentContents(). Later on, in the
> for loop, the assumption is made that both lists are in sync.
> Looking into m_wiring.getFragmentContents() quickly reveals that
> fragmentContents is sorted using string-comparison of
> BundleRevisionImpl#getId().
> Looking into Util.getFragments(m_wiring) eventually leads to
> BundleRevisionDependencies#m_dependentsMap, which is a Map Map>>. The value of the fragments list
> above is sorted according to the Set part of that type, which
> happens to be a HashSet and thus has no defined order.
> A quick fix (albeit not necessarily the best?) would be to sort {{fragments}}
> after retrieving it, in order to match the order of fragmentContents.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (FELIX-4461) Update to ASM 5 for Java 8 compatibility
[ https://issues.apache.org/jira/browse/FELIX-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-4461: --- Attachment: FELIX-4461-1.patch Attached [^FELIX-4461-1.patch], which bumps the asm-all dependency to 5.0.1 . I have verified that the build still passes and a project compiled with Java 8 which used to fail with previous versions of the maven-scr-plugin now compiles successfully. > Update to ASM 5 for Java 8 compatibility > > > Key: FELIX-4461 > URL: https://issues.apache.org/jira/browse/FELIX-4461 > Project: Felix > Issue Type: Improvement > Components: SCR Tooling > Reporter: Robert Munteanu > Attachments: FELIX-4461-1.patch > > > ASM 5.0 is out (http://mail.ow2.org/wws/arc/asm/2014-03/msg00012.html ) with > Java 8 support. I've validated that the build works just by updating > versions, although I did have to switch to the debug version since asm-all > artifact seems broken ( http://mail.ow2.org/wws/arc/asm/2014-03/msg00020.html > ) . > I'll submit a patch once that artifact gets a proper release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4461) Update to ASM 5 for Java 8 compatibility
[ https://issues.apache.org/jira/browse/FELIX-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-4461: --- Description: ASM 5.0 is out (http://mail.ow2.org/wws/arc/asm/2014-03/msg00012.html ) with Java 8 support. I've validated that the build works just by updating versions, although I did have to switch to the debug version since asm-all artifact seems broken ( http://mail.ow2.org/wws/arc/asm/2014-03/msg00020.html ) . I'll submit a patch once that artifact gets a proper release. was: ASM 5.0 is out ( [announcement|http://mail.ow2.org/wws/arc/asm/2014-03/msg00012.html] ) with Java 8 support. I've validated that the build works just by updating versions, although I did have to switch to the debug version since [asm-all artifact seems broken|http://mail.ow2.org/wws/arc/asm/2014-03/msg00020.html] . I'll submit a patch once that artifact gets a proper release. > Update to ASM 5 for Java 8 compatibility > > > Key: FELIX-4461 > URL: https://issues.apache.org/jira/browse/FELIX-4461 > Project: Felix > Issue Type: Improvement > Components: SCR Tooling >Reporter: Robert Munteanu > > ASM 5.0 is out (http://mail.ow2.org/wws/arc/asm/2014-03/msg00012.html ) with > Java 8 support. I've validated that the build works just by updating > versions, although I did have to switch to the debug version since asm-all > artifact seems broken ( http://mail.ow2.org/wws/arc/asm/2014-03/msg00020.html > ) . > I'll submit a patch once that artifact gets a proper release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (FELIX-4461) Update to ASM 5 for Java 8 compatibility
Robert Munteanu created FELIX-4461: -- Summary: Update to ASM 5 for Java 8 compatibility Key: FELIX-4461 URL: https://issues.apache.org/jira/browse/FELIX-4461 Project: Felix Issue Type: Improvement Components: SCR Tooling Reporter: Robert Munteanu ASM 5.0 is out ( [announcement|http://mail.ow2.org/wws/arc/asm/2014-03/msg00012.html] ) with Java 8 support. I've validated that the build works just by updating versions, although I did have to switch to the debug version since [asm-all artifact seems broken|http://mail.ow2.org/wws/arc/asm/2014-03/msg00020.html] . I'll submit a patch once that artifact gets a proper release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (FELIX-4277) The maven-scr-plugin generates false warnings when using @SlingServlet
[ https://issues.apache.org/jira/browse/FELIX-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13916389#comment-13916389 ] Robert Munteanu edited comment on FELIX-4277 at 3/4/14 4:37 PM: Yes, but there will be a delay :-) _Edit_: fixed a typo was (Author: rombert): Yes, but there will be delay :-) > The maven-scr-plugin generates false warnings when using @SlingServlet > -- > > Key: FELIX-4277 > URL: https://issues.apache.org/jira/browse/FELIX-4277 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin 1.15.0 > Reporter: Robert Munteanu >Priority: Minor > Attachments: FELIX-4277-1.patch > > > I have a class which is annotated with > @SlingServlet(resourceTypes = "slingDemo/conferenceSchedule", selectors = > "rss", methods = "GET", extensions = "xml") > In Eclipse and also using the CLI, I get warnings that > - Property sling.servlet.methods in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.extensions in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.selectors in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.resourceTypes in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > I guess the SlingAnnotationProcessor should not set the propertyPrivate flag > if metatype = false, but I'm not sure that this is the correct change. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (FELIX-4277) The maven-scr-plugin generates false warnings when using @SlingServlet
[ https://issues.apache.org/jira/browse/FELIX-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-4277: --- Attachment: FELIX-4277-1.patch > The maven-scr-plugin generates false warnings when using @SlingServlet > -- > > Key: FELIX-4277 > URL: https://issues.apache.org/jira/browse/FELIX-4277 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin 1.15.0 > Reporter: Robert Munteanu >Priority: Minor > Attachments: FELIX-4277-1.patch > > > I have a class which is annotated with > @SlingServlet(resourceTypes = "slingDemo/conferenceSchedule", selectors = > "rss", methods = "GET", extensions = "xml") > In Eclipse and also using the CLI, I get warnings that > - Property sling.servlet.methods in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.extensions in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.selectors in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.resourceTypes in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > I guess the SlingAnnotationProcessor should not set the propertyPrivate flag > if metatype = false, but I'm not sure that this is the correct change. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4277) The maven-scr-plugin generates false warnings when using @SlingServlet
[ https://issues.apache.org/jira/browse/FELIX-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13919574#comment-13919574 ] Robert Munteanu commented on FELIX-4277: The attached [^FELIX-4277-1.patch] works for me. Warnings are no longer generated when building, and the descriptor is the same. > The maven-scr-plugin generates false warnings when using @SlingServlet > -- > > Key: FELIX-4277 > URL: https://issues.apache.org/jira/browse/FELIX-4277 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin 1.15.0 > Reporter: Robert Munteanu >Priority: Minor > Attachments: FELIX-4277-1.patch > > > I have a class which is annotated with > @SlingServlet(resourceTypes = "slingDemo/conferenceSchedule", selectors = > "rss", methods = "GET", extensions = "xml") > In Eclipse and also using the CLI, I get warnings that > - Property sling.servlet.methods in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.extensions in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.selectors in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.resourceTypes in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > I guess the SlingAnnotationProcessor should not set the propertyPrivate flag > if metatype = false, but I'm not sure that this is the correct change. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (FELIX-4277) The maven-scr-plugin generates false warnings when using @SlingServlet
[ https://issues.apache.org/jira/browse/FELIX-4277?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13916389#comment-13916389 ] Robert Munteanu commented on FELIX-4277: Yes, but there will be delay :-) > The maven-scr-plugin generates false warnings when using @SlingServlet > -- > > Key: FELIX-4277 > URL: https://issues.apache.org/jira/browse/FELIX-4277 > Project: Felix > Issue Type: Bug > Components: Maven SCR Plugin >Affects Versions: maven-scr-plugin 1.15.0 > Reporter: Robert Munteanu >Priority: Minor > > I have a class which is annotated with > @SlingServlet(resourceTypes = "slingDemo/conferenceSchedule", selectors = > "rss", methods = "GET", extensions = "xml") > In Eclipse and also using the CLI, I get warnings that > - Property sling.servlet.methods in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.extensions in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.selectors in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > - Property sling.servlet.resourceTypes in class > de.adaptto.conference_schedule.RssFeedServlet is set as private. This is > redundant as no metatype will be generated. > (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) > I guess the SlingAnnotationProcessor should not set the propertyPrivate flag > if metatype = false, but I'm not sure that this is the correct change. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Updated] (FELIX-4364) Dynamically imported packages no longer excluded from imported packages
[ https://issues.apache.org/jira/browse/FELIX-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-4364: --- Attachment: FELIX-4364-sample.zip > Dynamically imported packages no longer excluded from imported packages > --- > > Key: FELIX-4364 > URL: https://issues.apache.org/jira/browse/FELIX-4364 > Project: Felix > Issue Type: Bug > Components: Maven Bundle Plugin >Affects Versions: maven-bundle-plugin-2.4.0 > Reporter: Robert Munteanu > Attachments: FELIX-4364-sample.zip > > > When upgrading the maven-bundle-plugin version from 2.3.7 to 2.4.0 I noticed > a behaviour change. If the plugin is configured to dynamically import > packages, those packages are no longer removed from the imported packages. > This behaviour is counterintuitive. While I understand that there might be > some edge case where you would want the imported packages imported both > statically and dynamically, I think that the regular use case is to have one > set of packages imported statically, and another dynamically. For > convenience, I'll attach a small and contrived example which shows the > behaviour change between 2.3.7 and 2.4.0 ( just switch the plugin version in > the pom.xml ). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Created] (FELIX-4364) Dynamically imported packages no longer excluded from imported packages
Robert Munteanu created FELIX-4364: -- Summary: Dynamically imported packages no longer excluded from imported packages Key: FELIX-4364 URL: https://issues.apache.org/jira/browse/FELIX-4364 Project: Felix Issue Type: Bug Components: Maven Bundle Plugin Affects Versions: maven-bundle-plugin-2.4.0 Reporter: Robert Munteanu When upgrading the maven-bundle-plugin version from 2.3.7 to 2.4.0 I noticed a behaviour change. If the plugin is configured to dynamically import packages, those packages are no longer removed from the imported packages. This behaviour is counterintuitive. While I understand that there might be some edge case where you would want the imported packages imported both statically and dynamically, I think that the regular use case is to have one set of packages imported statically, and another dynamically. For convenience, I'll attach a small and contrived example which shows the behaviour change between 2.3.7 and 2.4.0 ( just switch the plugin version in the pom.xml ). -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (FELIX-4282) HTTP Bundle 2.2.1 has and incorrect embedded Jetty instance
[ https://issues.apache.org/jira/browse/FELIX-4282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13818902#comment-13818902 ] Robert Munteanu commented on FELIX-4282: +1, would be great to see a 2.2.2 follow-up release. > HTTP Bundle 2.2.1 has and incorrect embedded Jetty instance > --- > > Key: FELIX-4282 > URL: https://issues.apache.org/jira/browse/FELIX-4282 > Project: Felix > Issue Type: Bug > Components: HTTP Service >Reporter: Bruce Jackson > > I've recently downloaded the latest version of the http bundle 2.2.1 which > contains the update to Jetty 7. This seems to have a problem, perhaps > because the Jetty version is a snapshot. > java.lang.NoSuchMethodError: > org.eclipse.jetty.util.QuotedStringTokenizer.unquoteOnly(Ljava/lang/String; > )Ljava/lang/String; > at > org.eclipse.jetty.server.CookieCutter.parseFields(CookieCutter.java:284) > at > org.eclipse.jetty.server.CookieCutter.getCookies(CookieCutter.java:64) > at org.eclipse.jetty.server.Request.getCookies(Request.java:499) > at > org.eclipse.jetty.server.session.SessionHandler.checkRequestedSessionId(Ses > sionHandler.java:260) > at > org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java > :155) > at > org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java > :978) > at > org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:13 > 5) > at > org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHan > dlerCollection.java:255) > at > org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java: > 116) > at org.eclipse.jetty.server.Server.handle(Server.java:369) > at > org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpC > onnection.java:486) > at > org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttp > Connection.java:933) > at > org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComple > te(AbstractHttpConnection.java:995) > at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:630) > at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) > at > org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.jav > a:82) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint > .java:606) > at > org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint. > java:46) > at > org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java > :603) > at > org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java: > 538) > at java.lang.Thread.run(Thread.java:724) > If I build the bundle manually with the 7.4.16 Jetty-all, I don't see this > problem. > I'm using the released HTTP Bundle from the felix download site. If I > manually remove the classes from the exploded jar and replace them with > the contents of the latest release Jetty all build (which is > jetty-all-server-7.6.13.v20130916) then I no longer see this problem. > I suspect that the reason that we see this is that we are using Jetty 7 > continuations (looking at the stack trace, this seems to be an async > operation) and so if you're not using them, you may never have encountered > this problem. -- This message was sent by Atlassian JIRA (v6.1#6144)
[jira] [Commented] (FELIX-4241) Change default output directory for SCR annotations to ${project.build.directory}/classes
[
https://issues.apache.org/jira/browse/FELIX-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794086#comment-13794086
]
Robert Munteanu commented on FELIX-4241:
The conflict seems to be with the explicit pluginExecution definition for the
maven-scr-plugin. If I remove that, all works fine.
We already make sure we run on incremental changes for this version of the
plugin [1], are you sure you still need that block?
[1]:
http://svn.apache.org/repos/asf/felix/trunk/scrplugin/maven-scr-plugin/src/main/resources/META-INF/m2e/lifecycle-mapping-metadata.xml
> Change default output directory for SCR annotations to
> ${project.build.directory}/classes
> -
>
> Key: FELIX-4241
> URL: https://issues.apache.org/jira/browse/FELIX-4241
> Project: Felix
> Issue Type: Improvement
> Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin 1.14.0
>Reporter: Robert Munteanu
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: maven-scr-plugin 1.15.0
>
> Attachments: FELIX-4242-1.patch
>
>
> Currently the plugin outputs the generated files under
> ${project.build.directory}/scr-plugin-generated . This change allows it to
> place its contents in the same place as the java compiled classes and the
> MANIFEST.MF generated by the maven-bundle-plugin.
> The result is that the exploded bundle contents is placed into a single
> directory and can be used by tooling - such as the Sling IDE tools - to
> incrementally update a bundle running in an OSGi container without going
> through a full maven package + deploy cycle.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Commented] (FELIX-4241) Change default output directory for SCR annotations to ${project.build.directory}/classes
[
https://issues.apache.org/jira/browse/FELIX-4241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13793692#comment-13793692
]
Robert Munteanu commented on FELIX-4241:
Can you attach/describe the minimal steps needed to reproduce this? A maven
project would be ideal...
> Change default output directory for SCR annotations to
> ${project.build.directory}/classes
> -
>
> Key: FELIX-4241
> URL: https://issues.apache.org/jira/browse/FELIX-4241
> Project: Felix
> Issue Type: Improvement
> Components: Maven SCR Plugin
>Affects Versions: maven-scr-plugin 1.14.0
>Reporter: Robert Munteanu
>Assignee: Carsten Ziegeler
>Priority: Minor
> Fix For: maven-scr-plugin 1.15.0
>
> Attachments: FELIX-4242-1.patch
>
>
> Currently the plugin outputs the generated files under
> ${project.build.directory}/scr-plugin-generated . This change allows it to
> place its contents in the same place as the java compiled classes and the
> MANIFEST.MF generated by the maven-bundle-plugin.
> The result is that the exploded bundle contents is placed into a single
> directory and can be used by tooling - such as the Sling IDE tools - to
> incrementally update a bundle running in an OSGi container without going
> through a full maven package + deploy cycle.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (FELIX-4277) The maven-scr-plugin generates false warnings when using @SlingServlet
Robert Munteanu created FELIX-4277: -- Summary: The maven-scr-plugin generates false warnings when using @SlingServlet Key: FELIX-4277 URL: https://issues.apache.org/jira/browse/FELIX-4277 Project: Felix Issue Type: Bug Components: Maven SCR Plugin Affects Versions: maven-scr-plugin 1.15.0 Reporter: Robert Munteanu Priority: Minor I have a class which is annotated with @SlingServlet(resourceTypes = "slingDemo/conferenceSchedule", selectors = "rss", methods = "GET", extensions = "xml") In Eclipse and also using the CLI, I get warnings that - Property sling.servlet.methods in class de.adaptto.conference_schedule.RssFeedServlet is set as private. This is redundant as no metatype will be generated. (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) - Property sling.servlet.extensions in class de.adaptto.conference_schedule.RssFeedServlet is set as private. This is redundant as no metatype will be generated. (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) - Property sling.servlet.selectors in class de.adaptto.conference_schedule.RssFeedServlet is set as private. This is redundant as no metatype will be generated. (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) - Property sling.servlet.resourceTypes in class de.adaptto.conference_schedule.RssFeedServlet is set as private. This is redundant as no metatype will be generated. (org.apache.felix:maven-scr-plugin:1.15.0:scr:generate-scr-descriptor:process-classes) I guess the SlingAnnotationProcessor should not set the propertyPrivate flag if metatype = false, but I'm not sure that this is the correct change. -- This message was sent by Atlassian JIRA (v6.1#6144)
