[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)
[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)
[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)
[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)
[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)
[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=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)
[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=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=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=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/183]+{color}
> but it is not clear to me from that discussion if any such effort will be
> actually made.
> 4. Do you know of any ongoing effort to upgrade `org.osgi.service.servlet` to
> support Jakarta Servlet API 6.x ?
> 5. If `javax.servlet` dependency is removed from
>
[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=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=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=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)
[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)
[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=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=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)
[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=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=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(DelegatingConstructorAccessorImpl.java:45)
at at
[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)
[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=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)
[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=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
-
[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)
[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=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=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=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=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=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)
[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=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)
[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] [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] [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)
[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=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-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] [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-tabpanelfocusedCommentId=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] [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] [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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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-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-tabpanelfocusedCommentId=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:
ListBundleRevision fragments = null;
ListContent 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 MapBundleRevision,
MapBundleCapability, SetBundleWire. The value of the fragments list
above is sorted according to the SetBundleWire 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] [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] [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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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-tabpanelfocusedCommentId=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] [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] [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] [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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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-tabpanelfocusedCommentId=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)
[jira] [Issue Comment Deleted] (FELIX-4249) Make the default error location 1,1 instead of 0,0
[
https://issues.apache.org/jira/browse/FELIX-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-4249:
---
Comment: was deleted
(was: There's a patch attached to this issue, but just in case Jira is flaky:
{code}Index:
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
===
---
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(revision 1526957)
+++
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(working copy)
@@ -102,8 +102,8 @@
private static class Entry {
- static final int LINE_NUMBER_UNKNOWN = 0;
- static final int COLUMN_NUMBER_UNKNOWN = 0;
+static final int LINE_NUMBER_UNKNOWN = 1;
+static final int COLUMN_NUMBER_UNKNOWN = 1;
final String message;
final String location;
{code})
Make the default error location 1,1 instead of 0,0
--
Key: FELIX-4249
URL: https://issues.apache.org/jira/browse/FELIX-4249
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: scr generator 1.8.0
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.15.0, scr ant task 1.9.0, scr
generator 1.8.2
Attachments: FELIX-4249-1.patch
The scr generator's error reporting places the errors by default at the 0,0
coordinates. In practice, this means that in Eclipse the error/warning is
associated with the file and shown in the problems view but not in the editor.
To make this more visible, I suggest that we change the error location to
1,1, which places it in the first line of the file. Should we want to, we can
extract line ( but not column ) information from ASM to place the warning
closer to the source.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Issue Comment Deleted] (FELIX-4249) Make the default error location 1,1 instead of 0,0
[
https://issues.apache.org/jira/browse/FELIX-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-4249:
---
Comment: was deleted
(was: There's a patch attached to this issue, but just in case Jira is flaky:
{code}Index:
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
===
---
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(revision 1526957)
+++
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(working copy)
@@ -102,8 +102,8 @@
private static class Entry {
- static final int LINE_NUMBER_UNKNOWN = 0;
- static final int COLUMN_NUMBER_UNKNOWN = 0;
+static final int LINE_NUMBER_UNKNOWN = 1;
+static final int COLUMN_NUMBER_UNKNOWN = 1;
final String message;
final String location;
{code})
Make the default error location 1,1 instead of 0,0
--
Key: FELIX-4249
URL: https://issues.apache.org/jira/browse/FELIX-4249
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: scr generator 1.8.0
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.15.0, scr ant task 1.9.0, scr
generator 1.8.2
Attachments: FELIX-4249-1.patch
The scr generator's error reporting places the errors by default at the 0,0
coordinates. In practice, this means that in Eclipse the error/warning is
associated with the file and shown in the problems view but not in the editor.
To make this more visible, I suggest that we change the error location to
1,1, which places it in the first line of the file. Should we want to, we can
extract line ( but not column ) information from ASM to place the warning
closer to the source.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Issue Comment Deleted] (FELIX-4249) Make the default error location 1,1 instead of 0,0
[
https://issues.apache.org/jira/browse/FELIX-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-4249:
---
Comment: was deleted
(was: There's a patch attached to this issue, but just in case Jira is flaky:
{code}Index:
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
===
---
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(revision 1526957)
+++
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(working copy)
@@ -102,8 +102,8 @@
private static class Entry {
- static final int LINE_NUMBER_UNKNOWN = 0;
- static final int COLUMN_NUMBER_UNKNOWN = 0;
+static final int LINE_NUMBER_UNKNOWN = 1;
+static final int COLUMN_NUMBER_UNKNOWN = 1;
final String message;
final String location;
{code})
Make the default error location 1,1 instead of 0,0
--
Key: FELIX-4249
URL: https://issues.apache.org/jira/browse/FELIX-4249
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: scr generator 1.8.0
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.15.0, scr ant task 1.9.0, scr
generator 1.8.2
Attachments: FELIX-4249-1.patch
The scr generator's error reporting places the errors by default at the 0,0
coordinates. In practice, this means that in Eclipse the error/warning is
associated with the file and shown in the problems view but not in the editor.
To make this more visible, I suggest that we change the error location to
1,1, which places it in the first line of the file. Should we want to, we can
extract line ( but not column ) information from ASM to place the warning
closer to the source.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Issue Comment Deleted] (FELIX-4249) Make the default error location 1,1 instead of 0,0
[
https://issues.apache.org/jira/browse/FELIX-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-4249:
---
Comment: was deleted
(was: There's a patch attached to this issue, but just in case Jira is flaky:
{code}Index:
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
===
---
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(revision 1526957)
+++
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(working copy)
@@ -102,8 +102,8 @@
private static class Entry {
- static final int LINE_NUMBER_UNKNOWN = 0;
- static final int COLUMN_NUMBER_UNKNOWN = 0;
+static final int LINE_NUMBER_UNKNOWN = 1;
+static final int COLUMN_NUMBER_UNKNOWN = 1;
final String message;
final String location;
{code})
Make the default error location 1,1 instead of 0,0
--
Key: FELIX-4249
URL: https://issues.apache.org/jira/browse/FELIX-4249
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: scr generator 1.8.0
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.15.0, scr ant task 1.9.0, scr
generator 1.8.2
Attachments: FELIX-4249-1.patch
The scr generator's error reporting places the errors by default at the 0,0
coordinates. In practice, this means that in Eclipse the error/warning is
associated with the file and shown in the problems view but not in the editor.
To make this more visible, I suggest that we change the error location to
1,1, which places it in the first line of the file. Should we want to, we can
extract line ( but not column ) information from ASM to place the warning
closer to the source.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Issue Comment Deleted] (FELIX-4249) Make the default error location 1,1 instead of 0,0
[
https://issues.apache.org/jira/browse/FELIX-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-4249:
---
Comment: was deleted
(was: There's a patch attached to this issue, but just in case Jira is flaky:
{code}Index:
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
===
---
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(revision 1526957)
+++
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(working copy)
@@ -102,8 +102,8 @@
private static class Entry {
- static final int LINE_NUMBER_UNKNOWN = 0;
- static final int COLUMN_NUMBER_UNKNOWN = 0;
+static final int LINE_NUMBER_UNKNOWN = 1;
+static final int COLUMN_NUMBER_UNKNOWN = 1;
final String message;
final String location;
{code})
Make the default error location 1,1 instead of 0,0
--
Key: FELIX-4249
URL: https://issues.apache.org/jira/browse/FELIX-4249
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: scr generator 1.8.0
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.15.0, scr ant task 1.9.0, scr
generator 1.8.2
Attachments: FELIX-4249-1.patch
The scr generator's error reporting places the errors by default at the 0,0
coordinates. In practice, this means that in Eclipse the error/warning is
associated with the file and shown in the problems view but not in the editor.
To make this more visible, I suggest that we change the error location to
1,1, which places it in the first line of the file. Should we want to, we can
extract line ( but not column ) information from ASM to place the warning
closer to the source.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Issue Comment Deleted] (FELIX-4249) Make the default error location 1,1 instead of 0,0
[
https://issues.apache.org/jira/browse/FELIX-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-4249:
---
Comment: was deleted
(was: There's a patch attached to this issue, but just in case Jira is flaky:
{code}Index:
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
===
---
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(revision 1526957)
+++
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(working copy)
@@ -102,8 +102,8 @@
private static class Entry {
- static final int LINE_NUMBER_UNKNOWN = 0;
- static final int COLUMN_NUMBER_UNKNOWN = 0;
+static final int LINE_NUMBER_UNKNOWN = 1;
+static final int COLUMN_NUMBER_UNKNOWN = 1;
final String message;
final String location;
{code})
Make the default error location 1,1 instead of 0,0
--
Key: FELIX-4249
URL: https://issues.apache.org/jira/browse/FELIX-4249
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: scr generator 1.8.0
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.15.0, scr ant task 1.9.0, scr
generator 1.8.2
Attachments: FELIX-4249-1.patch
The scr generator's error reporting places the errors by default at the 0,0
coordinates. In practice, this means that in Eclipse the error/warning is
associated with the file and shown in the problems view but not in the editor.
To make this more visible, I suggest that we change the error location to
1,1, which places it in the first line of the file. Should we want to, we can
extract line ( but not column ) information from ASM to place the warning
closer to the source.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Issue Comment Deleted] (FELIX-4249) Make the default error location 1,1 instead of 0,0
[
https://issues.apache.org/jira/browse/FELIX-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-4249:
---
Comment: was deleted
(was: There's a patch attached to this issue, but just in case Jira is flaky:
{code}Index:
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
===
---
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(revision 1526957)
+++
scrplugin/generator/src/main/java/org/apache/felix/scrplugin/helper/IssueLog.java
(working copy)
@@ -102,8 +102,8 @@
private static class Entry {
- static final int LINE_NUMBER_UNKNOWN = 0;
- static final int COLUMN_NUMBER_UNKNOWN = 0;
+static final int LINE_NUMBER_UNKNOWN = 1;
+static final int COLUMN_NUMBER_UNKNOWN = 1;
final String message;
final String location;
{code})
Make the default error location 1,1 instead of 0,0
--
Key: FELIX-4249
URL: https://issues.apache.org/jira/browse/FELIX-4249
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: scr generator 1.8.0
Reporter: Robert Munteanu
Assignee: Carsten Ziegeler
Priority: Minor
Fix For: maven-scr-plugin 1.15.0, scr ant task 1.9.0, scr
generator 1.8.2
Attachments: FELIX-4249-1.patch
The scr generator's error reporting places the errors by default at the 0,0
coordinates. In practice, this means that in Eclipse the error/warning is
associated with the file and shown in the problems view but not in the editor.
To make this more visible, I suggest that we change the error location to
1,1, which places it in the first line of the file. Should we want to, we can
extract line ( but not column ) information from ASM to place the warning
closer to the source.
--
This message was sent by Atlassian JIRA
(v6.1#6144)
[jira] [Created] (FELIX-4249) Make the default error location 1,1 instead of 0,0
Robert Munteanu created FELIX-4249: -- Summary: Make the default error location 1,1 instead of 0,0 Key: FELIX-4249 URL: https://issues.apache.org/jira/browse/FELIX-4249 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: scr generator 1.8.0 Reporter: Robert Munteanu Priority: Minor The scr generator's error reporting places the errors by default at the 0,0 coordinates. In practice, this means that in Eclipse the error/warning is associated with the file and shown in the problems view but not in the editor. To make this more visible, I suggest that we change the error location to 1,1, which places it in the first line of the file. Should we want to, we can extract line ( but not column ) information from ASM to place the warning closer to the source. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4249) Make the default error location 1,1 instead of 0,0
[ https://issues.apache.org/jira/browse/FELIX-4249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-4249: --- Attachment: FELIX-4249-1.patch Make the default error location 1,1 instead of 0,0 -- Key: FELIX-4249 URL: https://issues.apache.org/jira/browse/FELIX-4249 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: scr generator 1.8.0 Reporter: Robert Munteanu Priority: Minor Attachments: FELIX-4249-1.patch The scr generator's error reporting places the errors by default at the 0,0 coordinates. In practice, this means that in Eclipse the error/warning is associated with the file and shown in the problems view but not in the editor. To make this more visible, I suggest that we change the error location to 1,1, which places it in the first line of the file. Should we want to, we can extract line ( but not column ) information from ASM to place the warning closer to the source. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4241) Change default output directory for SCR annotations to ${project.build.directory}/classes
Robert Munteanu created FELIX-4241:
--
Summary: 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
Priority: Minor
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (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:all-tabpanel
]
Robert Munteanu updated FELIX-4241:
---
Attachment: FELIX-4242-1.patch
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
Priority: Minor
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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-4033) Issue warning messages for redundant SCR annotation combinations
Robert Munteanu created FELIX-4033:
--
Summary: Issue warning messages for redundant SCR annotation
combinations
Key: FELIX-4033
URL: https://issues.apache.org/jira/browse/FELIX-4033
Project: Felix
Issue Type: Improvement
Components: Declarative Services (SCR)
Reporter: Robert Munteanu
When using SCR annotations there are some ways of using annotations which are
redundant or useless. We should detect these early and log warning messages to
prevent the user from being suprised when the annotations are ignored.
*1. Labels and descriptions for components with metatype=false*
{code}
@Component(metatype = false,
label = Some label,
description = Some description)
{code}
Since the value of {{metatype}} is false, the label and description will never
be shown. So all three attributes should be removed. The warning message could
be The labell and description are ignored when metatype is false. The warning
should take into account the fact that the metatype defaults to false if not
set.
*2. Redundant combinations of propertyPrivate and metatype*
{code}
@Component(metatype = false)
@Property(name=some.property, value=some.value, propertyPrivate=true)
{code}
The {{propertyPrivate}} flag is useless since there the component will not have
metatype information. The warning message could be Redundant
propertyPrivate=true set for property 'some.property' since the component will
have no metatype information.
*3. Ignored settings for propertyPrivate*
{code}@Property(name=service.ranking, value=10, propertyPrivate=true{code}
This setting has no effect since {{service.ranking}} is private by default. The
warning message could be Redundant propertyPrivate=true set for
'service.ranking', this property is private by default.
Also, this value is ignored for the built-in service.pid, service.description,
service.id, service.vendor, service.bundlelocation and service.factoryPid
values.The warning message could be Ignoring propertyPrivate setting for
property 'service.xxx', this property is not taken into account when generating
metatype.xml.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-4001) SCR annotations should depend on released version of animal-sniffer-annotations
[ https://issues.apache.org/jira/browse/FELIX-4001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-4001: --- Attachment: FELIX-4001-1.patch SCR annotations should depend on released version of animal-sniffer-annotations --- Key: FELIX-4001 URL: https://issues.apache.org/jira/browse/FELIX-4001 Project: Felix Issue Type: Bug Components: Declarative Services (SCR) Affects Versions: scr-1.8.0 Reporter: Robert Munteanu Priority: Minor Attachments: FELIX-4001-1.patch There's no reason to depen on 1.10-SNAPSHOT when 1.9 works just fine and is available outside of the Apache snapshot repo. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3906) Configuration of Http Service context path broken after upgrade to Jetty 7
Robert Munteanu created FELIX-3906: -- Summary: Configuration of Http Service context path broken after upgrade to Jetty 7 Key: FELIX-3906 URL: https://issues.apache.org/jira/browse/FELIX-3906 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.2 Reporter: Robert Munteanu Revision 1346763 updated the Jetty server to 7.6.3 but removed the support for custom context paths. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3906) Configuration of Http Service context path broken after upgrade to Jetty 7
[ https://issues.apache.org/jira/browse/FELIX-3906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-3906: --- Attachment: FELIX-3906-1.diff Trivial patch which restores context path support. Configuration of Http Service context path broken after upgrade to Jetty 7 -- Key: FELIX-3906 URL: https://issues.apache.org/jira/browse/FELIX-3906 Project: Felix Issue Type: Bug Components: HTTP Service Affects Versions: http-2.2.2 Reporter: Robert Munteanu Attachments: FELIX-3906-1.diff Revision 1346763 updated the Jetty server to 7.6.3 but removed the support for custom context paths. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3739) scr-plugin: Annotated method {0} not found
[
https://issues.apache.org/jira/browse/FELIX-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Munteanu updated FELIX-3739:
---
Attachment: FELIX-3739-its.diff
scr-plugin: Annotated method {0} not found
Key: FELIX-3739
URL: https://issues.apache.org/jira/browse/FELIX-3739
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.8.0, scr ant task 1.2.0, scr
generator 1.2.0
Environment: Linux, Maven 3, Java 7
Reporter: Johannes Schneider
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin-1.8.2, scr ant task 1.2.2, scr
generator 1.2.2
Attachments: FELIX-3739-its.diff
I run in to that[1] problem.
The method that is not found looks like that:
@Nonnull public static T Entry? extends T create( @Nonnull T
object,
@Nonnull byte[] expected ) {
}
I have debugged this and it comes to that:
in ClassScanner#237 parameters are compared. The second parameter of
my method (byte[]) has a strange difference here:
parameterTypeName: [B
signature[index].getClassName(): byte[]
So I think this might be related to the asm usage
I *think* instead of signature[index].getClassName() there should be
called
signature[index].getDescriptor()
Any idea how I could work around that problem (without changing my
method's signature)?
Thanks,
Johannes
[1]
[ERROR] Failed to execute goal
org.apache.felix:maven-scr-plugin:1.8.0:scr
(generate-scr-scrdescriptor) on project test-utils:
com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
Annotated method create not found. - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.felix:maven-scr-plugin:1.8.0:scr
(generate-scr-scrdescriptor) on project test-utils:
com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
Annotated method create not found.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException:
com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
Annotated method create not found.
at
org.apache.felix.scrplugin.mojo.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:222)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.felix.scrplugin.SCRDescriptorException:
Annotated method create not found.
at
org.apache.felix.scrplugin.helper.ClassScanner.extractAnnotation(ClassScanner.java:249)
at
org.apache.felix.scrplugin.helper.ClassScanner.processClass(ClassScanner.java:180)
at
org.apache.felix.scrplugin.helper.ClassScanner.scanSources(ClassScanner.java:143)
at
org.apache.felix.scrplugin.SCRDescriptorGenerator.execute(SCRDescriptorGenerator.java:154)
at
org.apache.felix.scrplugin.mojo.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:217)
... 21 more
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly,
[jira] [Commented] (FELIX-3739) scr-plugin: Annotated method {0} not found
[
https://issues.apache.org/jira/browse/FELIX-3739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13503779#comment-13503779
]
Robert Munteanu commented on FELIX-3739:
Since I feel a bit shy about diving deep in the internals of the
maven-scr-plugin without a safety net I added a couple of ITs using the
maven-invoker-plugin.
- basic-build-it which contains a single annotated DS component . This IT
passes.
- external-annotations-it which contains a single annotated DS component which
also contains an external annotation on a constructor. This IT fails.
To make it easy to review patches, I'm submitting this first and then I will
start work on actually fixing the bug.
scr-plugin: Annotated method {0} not found
Key: FELIX-3739
URL: https://issues.apache.org/jira/browse/FELIX-3739
Project: Felix
Issue Type: Bug
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.8.0, scr ant task 1.2.0, scr
generator 1.2.0
Environment: Linux, Maven 3, Java 7
Reporter: Johannes Schneider
Assignee: Carsten Ziegeler
Fix For: maven-scr-plugin-1.8.2, scr ant task 1.2.2, scr
generator 1.2.2
Attachments: FELIX-3739-its.diff
I run in to that[1] problem.
The method that is not found looks like that:
@Nonnull public static T Entry? extends T create( @Nonnull T
object,
@Nonnull byte[] expected ) {
}
I have debugged this and it comes to that:
in ClassScanner#237 parameters are compared. The second parameter of
my method (byte[]) has a strange difference here:
parameterTypeName: [B
signature[index].getClassName(): byte[]
So I think this might be related to the asm usage
I *think* instead of signature[index].getClassName() there should be
called
signature[index].getDescriptor()
Any idea how I could work around that problem (without changing my
method's signature)?
Thanks,
Johannes
[1]
[ERROR] Failed to execute goal
org.apache.felix:maven-scr-plugin:1.8.0:scr
(generate-scr-scrdescriptor) on project test-utils:
com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
Annotated method create not found. - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
execute goal org.apache.felix:maven-scr-plugin:1.8.0:scr
(generate-scr-scrdescriptor) on project test-utils:
com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
Annotated method create not found.
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
Caused by: org.apache.maven.plugin.MojoExecutionException:
com.cedarsoft.serialization.test.utils.AbstractSerializerTest2 :
Annotated method create not found.
at
org.apache.felix.scrplugin.mojo.SCRDescriptorMojo.execute(SCRDescriptorMojo.java:222)
at
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
... 19 more
Caused by: org.apache.felix.scrplugin.SCRDescriptorException:
Annotated method create not found.
at
[jira] [Updated] (FELIX-3643) Use BuildContext for scanning changed files
[ https://issues.apache.org/jira/browse/FELIX-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-3643: --- Attachment: FELIX-3643-incremental-build-3.diff Use BuildContext for scanning changed files --- Key: FELIX-3643 URL: https://issues.apache.org/jira/browse/FELIX-3643 Project: Felix Issue Type: Sub-task Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: maven-scr-plugin-1.8.2 Attachments: FELIX-3643-incremental-build-2.txt, FELIX-3643-incremental-build-3.diff, FELIX-3643-incremental-build.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3643) Use BuildContext for scanning changed files
[ https://issues.apache.org/jira/browse/FELIX-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13471633#comment-13471633 ] Robert Munteanu commented on FELIX-3643: Good idea, this seems to finally fix all cases! I've attached a new patch which includes this functionality. Use BuildContext for scanning changed files --- Key: FELIX-3643 URL: https://issues.apache.org/jira/browse/FELIX-3643 Project: Felix Issue Type: Sub-task Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: maven-scr-plugin-1.8.2 Attachments: FELIX-3643-incremental-build-2.txt, FELIX-3643-incremental-build-3.diff, FELIX-3643-incremental-build.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3358) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations
[ https://issues.apache.org/jira/browse/FELIX-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-3358: --- Attachment: FELIX-3358-BuildContext-message-reporting.txt Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations Key: FELIX-3358 URL: https://issues.apache.org/jira/browse/FELIX-3358 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Environment: Eclipse Indigo or newer Reporter: Robert Munteanu Fix For: maven-scr-plugin-1.8.2 Attachments: FELIX-3358-BuildContext-message-reporting.txt, FELIX-3358-BuildContext-message-reporting.txt, m2e-lifecycle-mapping.diff With the recent changes brought to the Maven Eclipse integration, any unknown [0] plugins are flagged as problematic and an error is reported in the pom.xml . Typically this is solved by writing a thin integration layer between the Eclipse integration and the Maven plugin [1] or by instructing Eclipse to ignore some plugin executions. The new 1.1 version of the m2eclipse plugin will allow a Maven plugin ( with no links to Eclipse plugin development ) to use an enhanced API to become compatible out of the box with the Eclipse integration [2] . The maven-scr-plugin should take advantage of these new APIs to allow seamless integration with Eclipse. [0]: http://wiki.eclipse.org/M2E_plugin_execution_not_covered [1]: http://wiki.eclipse.org/M2E/Extension_Development [2]: http://wiki.eclipse.org/M2E_compatible_maven_plugins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3358) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations
[
https://issues.apache.org/jira/browse/FELIX-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13446677#comment-13446677
]
Robert Munteanu commented on FELIX-3358:
The attached patch is a proof-of-concept implementation, not yet fully polished.
I've adapted the current MavenLog to use the BuildContext whenever an error is
reported with a partial or complete source location. This works in the
following manner:
*CLI*
The error/warning is logged with a specific format, e.g.
{code}
[WARNING]
/home/rmuntean/w/workspace/bundle-sample/src/main/java/rmuntean/bundle_sample/ComplexDSComponent.java
[0:0]: @Component : Lifecycle method deactivate has wrong number of arguments
{code}
*Eclipse*
A marker is attached to the file. However, since I don't have any source
information ( line number and column number would be ideal ) the errors are not
flagged in the editor, but only visible in the Erorrs/Markers view.
I've started adding this lineNumber/columnNumber information to the scrplugin,
but I've stopped for two reasons:
1. I think it's best to add a SourceLocation class to the project to
encapsulate the (file, line, column) information.
2. I realised I need to modify the ASM processing in order to get the
information, which I didn't have enough time to.
All in all, this works right now, with the single caveat that markers are not
deleted on incremental builds in Eclipse. But that will probably come when we
will make full use of the BuildContext.
Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse
integrations
Key: FELIX-3358
URL: https://issues.apache.org/jira/browse/FELIX-3358
Project: Felix
Issue Type: Improvement
Components: Maven SCR Plugin
Affects Versions: maven-scr-plugin-1.8.0
Environment: Eclipse Indigo or newer
Reporter: Robert Munteanu
Fix For: maven-scr-plugin-1.8.2
Attachments: FELIX-3358-BuildContext-message-reporting.txt,
FELIX-3358-BuildContext-message-reporting.txt, m2e-lifecycle-mapping.diff
With the recent changes brought to the Maven Eclipse integration, any unknown
[0] plugins are flagged as problematic and an error is reported in the
pom.xml . Typically this is solved by writing a thin integration layer
between the Eclipse integration and the Maven plugin [1] or by instructing
Eclipse to ignore some plugin executions.
The new 1.1 version of the m2eclipse plugin will allow a Maven plugin ( with
no links to Eclipse plugin development ) to use an enhanced API to become
compatible out of the box with the Eclipse integration [2] .
The maven-scr-plugin should take advantage of these new APIs to allow
seamless integration with Eclipse.
[0]: http://wiki.eclipse.org/M2E_plugin_execution_not_covered
[1]: http://wiki.eclipse.org/M2E/Extension_Development
[2]: http://wiki.eclipse.org/M2E_compatible_maven_plugins
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3358) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations
[ https://issues.apache.org/jira/browse/FELIX-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-3358: --- Attachment: (was: FELIX-3358-BuildContext-message-reporting.txt) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations Key: FELIX-3358 URL: https://issues.apache.org/jira/browse/FELIX-3358 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Environment: Eclipse Indigo or newer Reporter: Robert Munteanu Fix For: maven-scr-plugin-1.8.2 Attachments: FELIX-3358-BuildContext-message-reporting.txt, m2e-lifecycle-mapping.diff With the recent changes brought to the Maven Eclipse integration, any unknown [0] plugins are flagged as problematic and an error is reported in the pom.xml . Typically this is solved by writing a thin integration layer between the Eclipse integration and the Maven plugin [1] or by instructing Eclipse to ignore some plugin executions. The new 1.1 version of the m2eclipse plugin will allow a Maven plugin ( with no links to Eclipse plugin development ) to use an enhanced API to become compatible out of the box with the Eclipse integration [2] . The maven-scr-plugin should take advantage of these new APIs to allow seamless integration with Eclipse. [0]: http://wiki.eclipse.org/M2E_plugin_execution_not_covered [1]: http://wiki.eclipse.org/M2E/Extension_Development [2]: http://wiki.eclipse.org/M2E_compatible_maven_plugins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3643) Use BuildContext for scanning changed files
[ https://issues.apache.org/jira/browse/FELIX-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-3643: --- Attachment: FELIX-3643-incremental-build.txt Use BuildContext for scanning changed files --- Key: FELIX-3643 URL: https://issues.apache.org/jira/browse/FELIX-3643 Project: Felix Issue Type: Sub-task Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Reporter: Carsten Ziegeler Fix For: maven-scr-plugin-1.8.2 Attachments: FELIX-3643-incremental-build.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3643) Use BuildContext for scanning changed files
[ https://issues.apache.org/jira/browse/FELIX-3643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13446702#comment-13446702 ] Robert Munteanu commented on FELIX-3643: Another proof-of-concept patch on how the BuildContext can be used to remove old markers ( untested ) and files generated from previous runs ( tested ) . I have a couple of TODOs left and also converted the existing notes about refreshing the target folder into a TODO. Removing the descriptor/metatype files works in Eclipse after renaming or deleting a class file, but new descriptor files don't show up and updates ones refresh when they are opened. I'll post this here for feedback and I'll be able to put some more time into at the end of the next week. Use BuildContext for scanning changed files --- Key: FELIX-3643 URL: https://issues.apache.org/jira/browse/FELIX-3643 Project: Felix Issue Type: Sub-task Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Reporter: Carsten Ziegeler Fix For: maven-scr-plugin-1.8.2 Attachments: FELIX-3643-incremental-build.txt -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3358) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations
[ https://issues.apache.org/jira/browse/FELIX-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13445744#comment-13445744 ] Robert Munteanu commented on FELIX-3358: In reply to comment #5: Now, I think we could simply create a separate descriptor xml for each component and then use the BuildContext to just process changed files and regenerate the xml for those. Sounds good to me. Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations Key: FELIX-3358 URL: https://issues.apache.org/jira/browse/FELIX-3358 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Environment: Eclipse Indigo or newer Reporter: Robert Munteanu Fix For: maven-scr-plugin-1.8.2 Attachments: m2e-lifecycle-mapping.diff With the recent changes brought to the Maven Eclipse integration, any unknown [0] plugins are flagged as problematic and an error is reported in the pom.xml . Typically this is solved by writing a thin integration layer between the Eclipse integration and the Maven plugin [1] or by instructing Eclipse to ignore some plugin executions. The new 1.1 version of the m2eclipse plugin will allow a Maven plugin ( with no links to Eclipse plugin development ) to use an enhanced API to become compatible out of the box with the Eclipse integration [2] . The maven-scr-plugin should take advantage of these new APIs to allow seamless integration with Eclipse. [0]: http://wiki.eclipse.org/M2E_plugin_execution_not_covered [1]: http://wiki.eclipse.org/M2E/Extension_Development [2]: http://wiki.eclipse.org/M2E_compatible_maven_plugins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3358) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations
[ https://issues.apache.org/jira/browse/FELIX-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13445802#comment-13445802 ] Robert Munteanu commented on FELIX-3358: The BuildContext seems used in regular m2e configurators, see for instance [the xml beans connector|https://github.com/bitstrings/m2e-connectors/blob/master/xmlbeans-m2e-connector/org.bitstrings.eclipse.m2e.connectors.xmlbeans/src/org/bitstrings/eclipse/m2e/connectors/xmlbeans/XmlBeansBuildParticipant.java] As for the tesla version, it seems to be unfinished according to [m2e-dev: Scanning for changed files in a m2e compatible Maven plugin |http://dev.eclipse.org/mhonarc/lists/m2e-dev/msg01056.html] Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations Key: FELIX-3358 URL: https://issues.apache.org/jira/browse/FELIX-3358 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Environment: Eclipse Indigo or newer Reporter: Robert Munteanu Fix For: maven-scr-plugin-1.8.2 Attachments: m2e-lifecycle-mapping.diff With the recent changes brought to the Maven Eclipse integration, any unknown [0] plugins are flagged as problematic and an error is reported in the pom.xml . Typically this is solved by writing a thin integration layer between the Eclipse integration and the Maven plugin [1] or by instructing Eclipse to ignore some plugin executions. The new 1.1 version of the m2eclipse plugin will allow a Maven plugin ( with no links to Eclipse plugin development ) to use an enhanced API to become compatible out of the box with the Eclipse integration [2] . The maven-scr-plugin should take advantage of these new APIs to allow seamless integration with Eclipse. [0]: http://wiki.eclipse.org/M2E_plugin_execution_not_covered [1]: http://wiki.eclipse.org/M2E/Extension_Development [2]: http://wiki.eclipse.org/M2E_compatible_maven_plugins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3358) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations
[ https://issues.apache.org/jira/browse/FELIX-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13445913#comment-13445913 ] Robert Munteanu commented on FELIX-3358: I've tried the latest trunk version of both the plugin and the scr annotations for a simple bundle and the CLI build works as expected, including the interaction with the maven-felix-plugin for adding the Service-Component header. Additionally, the Eclipse plugin creates and updates the service descriptor files for components, which is great. I've noticed that if I rename a component or delete it, the descriptor files still remain in the workspace. Additionally there is one nice-to-have which could be added - the BuildContext seems to be able to add messages to source fiels, so that warnings which are reported on the CLI can be reported inside Eclipse as well. Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations Key: FELIX-3358 URL: https://issues.apache.org/jira/browse/FELIX-3358 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Environment: Eclipse Indigo or newer Reporter: Robert Munteanu Fix For: maven-scr-plugin-1.8.2 Attachments: m2e-lifecycle-mapping.diff With the recent changes brought to the Maven Eclipse integration, any unknown [0] plugins are flagged as problematic and an error is reported in the pom.xml . Typically this is solved by writing a thin integration layer between the Eclipse integration and the Maven plugin [1] or by instructing Eclipse to ignore some plugin executions. The new 1.1 version of the m2eclipse plugin will allow a Maven plugin ( with no links to Eclipse plugin development ) to use an enhanced API to become compatible out of the box with the Eclipse integration [2] . The maven-scr-plugin should take advantage of these new APIs to allow seamless integration with Eclipse. [0]: http://wiki.eclipse.org/M2E_plugin_execution_not_covered [1]: http://wiki.eclipse.org/M2E/Extension_Development [2]: http://wiki.eclipse.org/M2E_compatible_maven_plugins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3358) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations
[ https://issues.apache.org/jira/browse/FELIX-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13445923#comment-13445923 ] Robert Munteanu commented on FELIX-3358: Good point :-) I'll try to dig in and see how these two issues can be fixed. Do you have a plan for when the 1.8.2 version should be released? Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations Key: FELIX-3358 URL: https://issues.apache.org/jira/browse/FELIX-3358 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Environment: Eclipse Indigo or newer Reporter: Robert Munteanu Fix For: maven-scr-plugin-1.8.2 Attachments: m2e-lifecycle-mapping.diff With the recent changes brought to the Maven Eclipse integration, any unknown [0] plugins are flagged as problematic and an error is reported in the pom.xml . Typically this is solved by writing a thin integration layer between the Eclipse integration and the Maven plugin [1] or by instructing Eclipse to ignore some plugin executions. The new 1.1 version of the m2eclipse plugin will allow a Maven plugin ( with no links to Eclipse plugin development ) to use an enhanced API to become compatible out of the box with the Eclipse integration [2] . The maven-scr-plugin should take advantage of these new APIs to allow seamless integration with Eclipse. [0]: http://wiki.eclipse.org/M2E_plugin_execution_not_covered [1]: http://wiki.eclipse.org/M2E/Extension_Development [2]: http://wiki.eclipse.org/M2E_compatible_maven_plugins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (FELIX-3640) Ignore maven-scr-plugin executions in Eclipse
Robert Munteanu created FELIX-3640: -- Summary: Ignore maven-scr-plugin executions in Eclipse Key: FELIX-3640 URL: https://issues.apache.org/jira/browse/FELIX-3640 Project: Felix Issue Type: Sub-task Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.7.4 Reporter: Robert Munteanu Priority: Trivial Attachments: FELIX-3640-1.patch Until the scr plugin receives an overhaul to support execution within Eclipse it makes sense to disable its execution. This happens by default anyway since m2e 1.0 but the plugin is flagged with an error and forces the user to disable it by adding a lifecycle mapping snippet in pom.xml . The attached patch instructs m2e to ignore the scr plugin by default, therefore removing the need to manually ignore it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (FELIX-3640) Ignore maven-scr-plugin executions in Eclipse
[ https://issues.apache.org/jira/browse/FELIX-3640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Munteanu updated FELIX-3640: --- Attachment: FELIX-3640-1.patch Ignore maven-scr-plugin executions in Eclipse - Key: FELIX-3640 URL: https://issues.apache.org/jira/browse/FELIX-3640 Project: Felix Issue Type: Sub-task Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.7.4 Reporter: Robert Munteanu Priority: Trivial Attachments: FELIX-3640-1.patch Until the scr plugin receives an overhaul to support execution within Eclipse it makes sense to disable its execution. This happens by default anyway since m2e 1.0 but the plugin is flagged with an error and forces the user to disable it by adding a lifecycle mapping snippet in pom.xml . The attached patch instructs m2e to ignore the scr plugin by default, therefore removing the need to manually ignore it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3358) Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations
[ https://issues.apache.org/jira/browse/FELIX-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13445258#comment-13445258 ] Robert Munteanu commented on FELIX-3358: In reply to comment #2: I've applied a slightly modified version which ignores the plugin instead of executing it as a first step. WDYT? I think this is a good first step. I've considered implementing a version of the plugin based on the 'm2e compatible maven plugins' approach. However, I recently became aware that the implementation is suboptimal when performing CLI builds, as it considers all source files changed. [1] I'm currently not sure what the best approach is, out of: - using the m2e-compatible approach of a BuildContext - using an annotation processor, which in theory has better change detection - providing an minimal m2e connector which delegates work to the scr plugin when needed [1]: http://dev.eclipse.org/mhonarc/lists/m2e-dev/msg01052.html Enhance the maven-scr-plugin to be compatible with recent Maven/Eclipse integrations Key: FELIX-3358 URL: https://issues.apache.org/jira/browse/FELIX-3358 Project: Felix Issue Type: Improvement Components: Maven SCR Plugin Affects Versions: maven-scr-plugin-1.8.0 Environment: Eclipse Indigo or newer Reporter: Robert Munteanu Fix For: maven-scr-plugin-1.8.2 Attachments: m2e-lifecycle-mapping.diff With the recent changes brought to the Maven Eclipse integration, any unknown [0] plugins are flagged as problematic and an error is reported in the pom.xml . Typically this is solved by writing a thin integration layer between the Eclipse integration and the Maven plugin [1] or by instructing Eclipse to ignore some plugin executions. The new 1.1 version of the m2eclipse plugin will allow a Maven plugin ( with no links to Eclipse plugin development ) to use an enhanced API to become compatible out of the box with the Eclipse integration [2] . The maven-scr-plugin should take advantage of these new APIs to allow seamless integration with Eclipse. [0]: http://wiki.eclipse.org/M2E_plugin_execution_not_covered [1]: http://wiki.eclipse.org/M2E/Extension_Development [2]: http://wiki.eclipse.org/M2E_compatible_maven_plugins -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3550) Reimplement the SCR Generator
[ https://issues.apache.org/jira/browse/FELIX-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13294391#comment-13294391 ] Robert Munteanu commented on FELIX-3550: The implementation can also be based on an annotation processor. Besides being a 'standard' technology it has the benefit of improving integration with yet-unsupported build tools like Gradle and IDEs. Reimplement the SCR Generator - Key: FELIX-3550 URL: https://issues.apache.org/jira/browse/FELIX-3550 Project: Felix Issue Type: Task Components: Maven SCR Plugin Reporter: Carsten Ziegeler Assignee: Carsten Ziegeler Fix For: maven-scr-plugin-1.7.6, scr ant task 1.1.6, scr generator 1.1.6, scr annotations 1.6.2 The current implementation of the maven scr plugin and generator has grown over time and is very complex. It makes a lot of assumptions about hidden datastructures. This is partially due to the use of QDox in the beginning of the plugin As we drop the support for javadoc annotations, we can also drop qdox and clean up the implementation This also makes developing new features easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (FELIX-3296) URLHandlers caches null as values for common protocols
[ https://issues.apache.org/jira/browse/FELIX-3296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13264749#comment-13264749 ] Robert Munteanu commented on FELIX-3296: In reply to comment #1: Yes, I agree - this is a bug. Thanks for reporting - I'll try to get to it asap. Karl, did you manage to look into this? I'm willing to test any patches if needed. URLHandlers caches null as values for common protocols -- Key: FELIX-3296 URL: https://issues.apache.org/jira/browse/FELIX-3296 Project: Felix Issue Type: Bug Components: Framework Affects Versions: framework-3.0.8 Environment: Apache Sling org.apache.sling.launchpad-6.war running in build of current master branch of JBoss Application Server 7 (https://github.com/jbossas/jboss-as). I'm reporting this against framework-3.0.8 as that seems to be what's included in Sling, but a review of the code in 4.0.2 shows the class is the same. Reporter: Brian Stansberry Assignee: Karl Pauls Fix For: framework-4.2.0 A JBoss AS7 user has reported being unable to run the Apache Sling web app in AS 7. I determined that the issue is once org.apache.felix.framework.URLHandlers is installed as the JVM's URLStreamHandlerFactory, URLs with protocol jar can no longer be parsed.[1] Here's the problem. Line references are to [2]: 1) The singleton of this URLHandlers class gets instantiated. It attempts to load and cache standard handlers for common protocols. At L148 it does this for jar. 2) At L353 it's trying to load one of the standard URLStreamHandler impls for the jar protocol, e.g. sun.net.www.protocol.jar.Handler. It uses Class.forName(sun.net.www.protocol.jar.Handler). This fails (returns null) because the JBoss Modules module for this deployment does not have visibility to this class. 3) At L367 it stores null for this protocol in its m_builtIn map under key jar. 4) Thereafter any call to createURLStreamHandler (L390) will call into getBuiltInStreamHandler (L413). That will return null because it will find the null in m_builtIn stored in step 3) above (L330 L332). A fairly simple fix is to at L148 test the result of the getBuiltInStreamHandler call and if null remove the entry from m_builtIn. It should probably do the same kind of thing in the init(String) method (L120). An alternative is to do all the step 1) stuff between L142 and L148 after the try/catch block at L157. At that point a ref to the standard AS7 URLStreamHandlerFactory will be available in field m_streamHandlerFactory and can be used to load the standard handlers rather than relying on Class.forName. [1] http://lists.jboss.org/pipermail/jboss-as7-dev/2012-January/004956.html [2] http://grepcode.com/file/repo1.maven.org/maven2/org.apache.felix/org.apache.felix.framework/2.0.5/org/apache/felix/framework/URLHandlers.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
