[jira] [Assigned] (FELIX-5491) Serializer should allow empty key/values pairs when parsing
[ https://issues.apache.org/jira/browse/FELIX-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-5491: --- Assignee: David Bosschaert > Serializer should allow empty key/values pairs when parsing > --- > > Key: FELIX-5491 > URL: https://issues.apache.org/jira/browse/FELIX-5491 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > The Serializer is currently too stringent to not allow empty values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5491) Serializer should allow empty key/values pairs when parsing
[ https://issues.apache.org/jira/browse/FELIX-5491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-5491. - Resolution: Fixed Thanks [~dleangen] for the patch - it's applied in https://svn.apache.org/viewvc?view=revision&revision=1779589 > Serializer should allow empty key/values pairs when parsing > --- > > Key: FELIX-5491 > URL: https://issues.apache.org/jira/browse/FELIX-5491 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > The Serializer is currently too stringent to not allow empty values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5475) Allow the use of DTO.class to signal that an Object should be treated as a DTO.
[ https://issues.apache.org/jira/browse/FELIX-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15831552#comment-15831552 ] David Bosschaert commented on FELIX-5475: - Hi [~dleangen] Yeah, I went ahead and added the methods to the OSGi API immediately after our discussion so when BJ looked it was already there. I've now updated the codebase in Felix as well: https://svn.apache.org/viewvc?view=revision&revision=1779604 > Allow the use of DTO.class to signal that an Object should be treated as a > DTO. > --- > > Key: FELIX-5475 > URL: https://issues.apache.org/jira/browse/FELIX-5475 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > Sometimes it is useful to treat a class as if it were a DTO, i.e. by ignoring > methods, static fields etc. > This can be done using the sourceAs(Class) method with the DTO.class as the > parameter. This is a non-ambiguous way to signal to the Converter to treat > any Object as if it were a DTO (at the risk of the caller). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5508) Multiple JSON Serializers
[
https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15832033#comment-15832033
]
David Bosschaert commented on FELIX-5508:
-
But both the Serializer and the Schematizer both contain JSON parsers - copies
of the same code actually...
Interestingly enough Java 8 has a built-in JSON parser, via the Nashorn
scripting engine. You can use it like this:
{code}String script = "Java.asJSONCompatible(" + myJSON + ")";
Map res = (Map) new
ScriptEngineManager().getEngineByName("javascript").eval(script);{code}
I wonder can we possibly remove the JSON Parsers and use this instead? It would
introduce a dependency on Java 8...
> Multiple JSON Serializers
> -
>
> Key: FELIX-5508
> URL: https://issues.apache.org/jira/browse/FELIX-5508
> Project: Felix
> Issue Type: Improvement
> Components: Converter
>Reporter: David Leangen
>
> There appears to be multiple json serializers in the code base (serializer,
> schematizer, and even more recently webconsole).
> Would it be worthwhile to consider consolidating them somehow, to avoid
> duplicate work?
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15832063#comment-15832063 ] David Bosschaert commented on FELIX-5508: - [~gnt] in the serializer and schematizer the JsonParser.java are the only ones that actually handle JSON directly. The rest in the ...json... packages is code around it and tests... But yeah, it would be nice if we can get rid of the parsing... > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-5508: --- Assignee: David Bosschaert > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-5508: Assignee: (was: David Bosschaert) > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15833456#comment-15833456 ] David Bosschaert commented on FELIX-5508: - I would be fine with moving ./converter/serializer/src/main/java/org/apache/felix/serializer/impl/json/JsonParser.java into utils. This is the same code as the one in schematizer. Its just a very small JSON parser. Probably not as fully featured as a 'real' JSON parser lib but it does the job without deps. BTW on my earlier comment of using the JSON parser built in to JDK 8 via Nashorn. Using this in general is probably not the best solution as probably not all flavours of Java include Nashorn... > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (FELIX-5475) Implement sourceAsDTO() and targetAsDTO()
[ https://issues.apache.org/jira/browse/FELIX-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-5475: --- Assignee: David Bosschaert > Implement sourceAsDTO() and targetAsDTO() > - > > Key: FELIX-5475 > URL: https://issues.apache.org/jira/browse/FELIX-5475 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > Sometimes it is useful to treat a class as if it were a DTO, i.e. by ignoring > methods, static fields etc. > This can be done using the sourceAsDTO() and targetAsDTO() methods that were > recently added to the spec API. This is a non-ambiguous way to signal to the > Converter to treat any Object as if it were a DTO (at the risk of the caller). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5475) Implement sourceAsDTO() and targetAsDTO()
[ https://issues.apache.org/jira/browse/FELIX-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-5475. - Resolution: Fixed Patch applied with many thanks: https://svn.apache.org/viewvc?view=revision&revision=1779874 > Implement sourceAsDTO() and targetAsDTO() > - > > Key: FELIX-5475 > URL: https://issues.apache.org/jira/browse/FELIX-5475 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > Sometimes it is useful to treat a class as if it were a DTO, i.e. by ignoring > methods, static fields etc. > This can be done using the sourceAsDTO() and targetAsDTO() methods that were > recently added to the spec API. This is a non-ambiguous way to signal to the > Converter to treat any Object as if it were a DTO (at the risk of the caller). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5483) It's impossible to stop bundle using symbolic name if some installed bundle does not have symbolic name
[ https://issues.apache.org/jira/browse/FELIX-5483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15834530#comment-15834530 ] David Bosschaert commented on FELIX-5483: - The patch seems ok to me but AFAIK a bundle must always have a symbolic name, so I'm a little curious when you ever encounter one without it? > It's impossible to stop bundle using symbolic name if some installed bundle > does not have symbolic name > --- > > Key: FELIX-5483 > URL: https://issues.apache.org/jira/browse/FELIX-5483 > Project: Felix > Issue Type: Bug > Components: Gogo Shell >Reporter: Alexandra Vasilyeva > Labels: patch-available > Attachments: ifSymbolicNameNull.diff > > > If some installed bundle does not have symbolic name, it's impossible to stop > any bundle by symbolic name: error "gogo: IllegalArgumentException: Cannot > coerce stop(String) to any of [(boolean, Bundle[])]" is shown in console and > bundle still in active state. > Provided patch checks bundle symbolic name for null equality while searching > needed bundle. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5184) Regression: Native JNA bundle cannot be installed on Windows Server 2012
[
https://issues.apache.org/jira/browse/FELIX-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-5184:
Fix Version/s: (was: framework-5.6.1)
framework-5.6.2
> Regression: Native JNA bundle cannot be installed on Windows Server 2012
>
>
> Key: FELIX-5184
> URL: https://issues.apache.org/jira/browse/FELIX-5184
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.4.0
> Environment: Windows 2012
>Reporter: Stuart McCulloch
>Assignee: David Bosschaert
> Fix For: framework-5.6.2
>
>
> The alias for Windows 2012 seems to have been lost when the "osname" aliases
> were moved to framework/src/main/resources/default.properties (in
> https://github.com/apache/felix/commit/c2b87c099bf3b5efc535cc80abc0d78fe9a7c2c0)
> The following line should be added to
> framework/src/main/resources/default.properties:
> {code}
> felix.native.osname.alias.windowsserver2012=windows server 2012,win32
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5184) Regression: Native JNA bundle cannot be installed on Windows Server 2012
[
https://issues.apache.org/jira/browse/FELIX-5184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15837857#comment-15837857
]
David Bosschaert commented on FELIX-5184:
-
Fixed the release version.
> Regression: Native JNA bundle cannot be installed on Windows Server 2012
>
>
> Key: FELIX-5184
> URL: https://issues.apache.org/jira/browse/FELIX-5184
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.4.0
> Environment: Windows 2012
>Reporter: Stuart McCulloch
>Assignee: David Bosschaert
> Fix For: framework-5.6.2
>
>
> The alias for Windows 2012 seems to have been lost when the "osname" aliases
> were moved to framework/src/main/resources/default.properties (in
> https://github.com/apache/felix/commit/c2b87c099bf3b5efc535cc80abc0d78fe9a7c2c0)
> The following line should be added to
> framework/src/main/resources/default.properties:
> {code}
> felix.native.osname.alias.windowsserver2012=windows server 2012,win32
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15850075#comment-15850075 ] David Bosschaert commented on FELIX-5508: - The parser at ./converter/serializer/src/main/java/org/apache/felix/serializer/impl/json/JsonParser.java would fall in this category. It's simple and a single class and has no deps. > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (FELIX-5529) For overloaded methods in interfaces, ensure there's a default (no-arg) method when converting to Map
[ https://issues.apache.org/jira/browse/FELIX-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-5529: --- Assignee: David Bosschaert > For overloaded methods in interfaces, ensure there's a default (no-arg) > method when converting to Map > - > > Key: FELIX-5529 > URL: https://issues.apache.org/jira/browse/FELIX-5529 > Project: Felix > Issue Type: Bug > Components: Converter > Environment: Any >Reporter: Raymond Augé >Assignee: David Bosschaert > > When an interface implementing single argument methods (for passing default > value) an error occurs when converted to Maps if there's no default (no-arg) > method for the same key, since the backing fails on the method call. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (FELIX-5530) Don't process methods declared on the Annotation class
[
https://issues.apache.org/jira/browse/FELIX-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5530:
---
Assignee: David Bosschaert
> Don't process methods declared on the Annotation class
> --
>
> Key: FELIX-5530
> URL: https://issues.apache.org/jira/browse/FELIX-5530
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> when converting annotations to Maps, don't handle the methods on the
> Annotation class, similar to how those from Object are ignored.
> e.g.
> {code:java}
> Annotation annotation = (Annotation)...;
> Map map = c.convert(annotation).sourceAs(
> annotation.annotationType()).to(
> new TypeReference>(){});
> {code}
> In the above case the detection of properties should include a check like so:
> {code:java}
> if (Object.class.equals(md.getDeclaringClass()) ||
> Annotation.class.equals(md.getDeclaringClass()))
> return null; // do not use any methods on the Object or
> Annotation class as a accessor
> {code}
> to avoid creating properties for annotationType, equals, hashCode, and
> toString (which in it's case are methods declared on the Annotation.class not
> Object.class).
> Also note that it should be made clear when handling annotations that the
> {{sourceAs}} modifier should always be used with the result of
> {{annotation.annotationType()}} result because the {{getClass}} of an
> annotation object always returns the proxy class and not the Annotation type
> which confuses the converter.
> e.g.
> {code:java}
> .sourceAs(annotation.annotationType()).to(...)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Work started] (FELIX-5529) For overloaded methods in interfaces, ensure there's a default (no-arg) method when converting to Map
[ https://issues.apache.org/jira/browse/FELIX-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-5529 started by David Bosschaert. --- > For overloaded methods in interfaces, ensure there's a default (no-arg) > method when converting to Map > - > > Key: FELIX-5529 > URL: https://issues.apache.org/jira/browse/FELIX-5529 > Project: Felix > Issue Type: Bug > Components: Converter > Environment: Any >Reporter: Raymond Augé >Assignee: David Bosschaert > > When an interface implementing single argument methods (for passing default > value) an error occurs when converted to Maps if there's no default (no-arg) > method for the same key, since the backing fails on the method call. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (FELIX-5529) For overloaded methods in interfaces, ensure there's a default (no-arg) method when converting to Map
[ https://issues.apache.org/jira/browse/FELIX-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-5529. - Resolution: Fixed > For overloaded methods in interfaces, ensure there's a default (no-arg) > method when converting to Map > - > > Key: FELIX-5529 > URL: https://issues.apache.org/jira/browse/FELIX-5529 > Project: Felix > Issue Type: Bug > Components: Converter > Environment: Any >Reporter: Raymond Augé >Assignee: David Bosschaert > > When an interface implementing single argument methods (for passing default > value) an error occurs when converted to Maps if there's no default (no-arg) > method for the same key, since the backing fails on the method call. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Work started] (FELIX-5530) Don't process methods declared on the Annotation class
[
https://issues.apache.org/jira/browse/FELIX-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5530 started by David Bosschaert.
---
> Don't process methods declared on the Annotation class
> --
>
> Key: FELIX-5530
> URL: https://issues.apache.org/jira/browse/FELIX-5530
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> when converting annotations to Maps, don't handle the methods on the
> Annotation class, similar to how those from Object are ignored.
> e.g.
> {code:java}
> Annotation annotation = (Annotation)...;
> Map map = c.convert(annotation).sourceAs(
> annotation.annotationType()).to(
> new TypeReference>(){});
> {code}
> In the above case the detection of properties should include a check like so:
> {code:java}
> if (Object.class.equals(md.getDeclaringClass()) ||
> Annotation.class.equals(md.getDeclaringClass()))
> return null; // do not use any methods on the Object or
> Annotation class as a accessor
> {code}
> to avoid creating properties for annotationType, equals, hashCode, and
> toString (which in it's case are methods declared on the Annotation.class not
> Object.class).
> Also note that it should be made clear when handling annotations that the
> {{sourceAs}} modifier should always be used with the result of
> {{annotation.annotationType()}} result because the {{getClass}} of an
> annotation object always returns the proxy class and not the Annotation type
> which confuses the converter.
> e.g.
> {code:java}
> .sourceAs(annotation.annotationType()).to(...)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5529) For overloaded methods in interfaces, ensure there's a default (no-arg) method when converting to Map
[ https://issues.apache.org/jira/browse/FELIX-5529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15858981#comment-15858981 ] David Bosschaert commented on FELIX-5529: - Thanks Ray! It's committed in https://svn.apache.org/viewvc?view=revision&revision=1782289 > For overloaded methods in interfaces, ensure there's a default (no-arg) > method when converting to Map > - > > Key: FELIX-5529 > URL: https://issues.apache.org/jira/browse/FELIX-5529 > Project: Felix > Issue Type: Bug > Components: Converter > Environment: Any >Reporter: Raymond Augé >Assignee: David Bosschaert > > When an interface implementing single argument methods (for passing default > value) an error occurs when converted to Maps if there's no default (no-arg) > method for the same key, since the backing fails on the method call. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (FELIX-5530) Don't process methods declared on the Annotation class
[
https://issues.apache.org/jira/browse/FELIX-5530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-5530.
-
Resolution: Fixed
Thanks Ray! It's committed in
https://svn.apache.org/viewvc?view=revision&revision=1782291
> Don't process methods declared on the Annotation class
> --
>
> Key: FELIX-5530
> URL: https://issues.apache.org/jira/browse/FELIX-5530
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: Raymond Augé
>Assignee: David Bosschaert
>
> when converting annotations to Maps, don't handle the methods on the
> Annotation class, similar to how those from Object are ignored.
> e.g.
> {code:java}
> Annotation annotation = (Annotation)...;
> Map map = c.convert(annotation).sourceAs(
> annotation.annotationType()).to(
> new TypeReference>(){});
> {code}
> In the above case the detection of properties should include a check like so:
> {code:java}
> if (Object.class.equals(md.getDeclaringClass()) ||
> Annotation.class.equals(md.getDeclaringClass()))
> return null; // do not use any methods on the Object or
> Annotation class as a accessor
> {code}
> to avoid creating properties for annotationType, equals, hashCode, and
> toString (which in it's case are methods declared on the Annotation.class not
> Object.class).
> Also note that it should be made clear when handling annotations that the
> {{sourceAs}} modifier should always be used with the result of
> {{annotation.annotationType()}} result because the {{getClass}} of an
> annotation object always returns the proxy class and not the Annotation type
> which confuses the converter.
> e.g.
> {code:java}
> .sourceAs(annotation.annotationType()).to(...)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-5508: --- Assignee: David Bosschaert > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860410#comment-15860410 ] David Bosschaert commented on FELIX-5508: - [~cziegeler] Definitely! I should be able to do this over the coming few days. I've assigned this issue to myself as a reminder :) > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-5508. - Resolution: Fixed Added the JSON Parser in https://svn.apache.org/viewvc?view=revision&revision=1782421 > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-5508: Fix Version/s: utils-1.9.0 > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Fix For: utils-1.9.0 > > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860762#comment-15860762 ] David Bosschaert commented on FELIX-5508: - You are right - we said a single class without additional deps. I've moved the one static method to JSONParser and deleted InputStreams in https://svn.apache.org/viewvc?view=revision&revision=1782431 > Multiple JSON Serializers > - > > Key: FELIX-5508 > URL: https://issues.apache.org/jira/browse/FELIX-5508 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Fix For: utils-1.9.0 > > > There appears to be multiple json serializers in the code base (serializer, > schematizer, and even more recently webconsole). > Would it be worthwhile to consider consolidating them somehow, to avoid > duplicate work? -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5507) ConfigurationAdmin not visible to bundles
[ https://issues.apache.org/jira/browse/FELIX-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15865481#comment-15865481 ] David Bosschaert commented on FELIX-5507: - Hi [~karlpauls], thanks for the analysis and explaining. I still have the feeling though that the implicit bootdelegation is too wide. You say that it was designed for certain JDK/Swing scenarios. If we cannot switch it off by default (which I think would be a better default) - can we then at least limit it to certain packages? > ConfigurationAdmin not visible to bundles > - > > Key: FELIX-5507 > URL: https://issues.apache.org/jira/browse/FELIX-5507 > Project: Felix > Issue Type: Bug > Components: Framework >Affects Versions: framework-5.6.1 >Reporter: Carsten Ziegeler >Assignee: Carsten Ziegeler > Fix For: framework-5.6.2 > > > We have one case where the extended bundles do not see the configuration > admin service. Interestingly the same application runs fine everywhere else, > but just on a special environment (windows, ibm java inside Websphere) we > have this problem reproducibly. > Using the system bundle context instead of the bundle context of the extended > bundle in ConfigAdminTracker solves the problem. > Interestingly only the bundles started last (2 out of probably 80) see the > configuration admin. > It could also be that a faulty service hook is involved, although I'm not yet > aware of such a hook -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-4837) Workaround for JNLPClassLoader in ShutdownHook
[
https://issues.apache.org/jira/browse/FELIX-4837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15874842#comment-15874842
]
David Bosschaert commented on FELIX-4837:
-
The fix looks a bit weird but yeah, if it works around a problem that exists in
JDK 6,7 or 8 then I think we should take it. In any case it won't do any harm
AFAICS.
> Workaround for JNLPClassLoader in ShutdownHook
> ---
>
> Key: FELIX-4837
> URL: https://issues.apache.org/jira/browse/FELIX-4837
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.0.1, framework-5.6.1
> Environment: all
>Reporter: Nicolas Roduit
>Assignee: Karl Pauls
>
> This a workaround of the issue that I submitted on
> https://bugs.openjdk.java.net/browse/JDK-8054639
> The Java Web Start classloader doesn't support to have anonymous classes or
> enum within the shutdown hook.
> The patch below allows to stop all the bundles correctly when calling
> m_felix.stop() in the shutdown hook. Otherwise the framework throws an
> exception and do not call the bundle stop. This is a problem when each bundle
> write its preferences or state during the stop method.
> {code}
> diff --git a/framework/src/main/java/org/apache/felix/framework/Felix.java
> b/framework/src/main/java/org/apache/felix/framework/Felix.java
> index c6b305a..e44ccea 100644
> --- a/framework/src/main/java/org/apache/felix/framework/Felix.java
> +++ b/framework/src/main/java/org/apache/felix/framework/Felix.java
> @@ -1023,7 +1023,7 @@
> {
> // Spec says stop() on SystemBundle should return immediately and
> // shutdown framework on another thread.
> -new Thread(new Runnable() {
> +Thread t = new Thread( "FelixShutdown"){
> public void run()
> {
> try
> @@ -1038,7 +1038,8 @@
> ex);
> }
> }
> -}, "FelixShutdown").start();
> +};
> +t.start();
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5556) JSONParser does not retain object order
[
https://issues.apache.org/jira/browse/FELIX-5556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15875596#comment-15875596
]
David Bosschaert commented on FELIX-5556:
-
We should not do this. JSON Objects are maps and maps are unordered by
definition. Why wouldn't you use an array if you need order?
> JSONParser does not retain object order
> ---
>
> Key: FELIX-5556
> URL: https://issues.apache.org/jira/browse/FELIX-5556
> Project: Felix
> Issue Type: Bug
> Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Stefan Seifert
>Assignee: Stefan Seifert
> Fix For: utils-1.9.2
>
>
> the {{JSONParser}} does not retain the order of objects the JSON files it
> parses. the order is randomly based on the HashMap implementation used
> internally.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5561) Support for merging?
[
https://issues.apache.org/jira/browse/FELIX-5561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15877939#comment-15877939
]
David Bosschaert commented on FELIX-5561:
-
I think this should be considered out of scope. With merging comes conflict
resolution and conflict resolution is domain-specific and often requires manual
intervention. I think that the converter as-is can help preparing objects for a
merge by converting them to the same type, but the actual merge should be done
with another tool IMHO.
> Support for merging?
>
>
> Key: FELIX-5561
> URL: https://issues.apache.org/jira/browse/FELIX-5561
> Project: Felix
> Issue Type: Wish
> Components: Converter
>Reporter: David Leangen
>
> Would it be reasonable for the Converter to support a "merge" operation? Or
> is that just too far out of scope.
> Example - merging a partial map into an existing object:
> Object o2 = converter.merge( m ).into( o1 ).
> Example of "complex" chaining operation - merging two maps, and converting to
> object:
> Object o2 = converter.merge( m1 ).into( m2 ).to( Object.class );
> Just thinking hypothetically for now.
> I can imagine cases where partial updates need to be applied. For instance,
> if a "Contact" object exists, and we only want to update one or two fields,
> the Converter could assist:
> Contact updated = converter.merge( "{name:'Joe Smith', nickname:'joey'}
> ).into( contact );
> If this is too far out of scope, I'll drop it here. Otherwise, I'll play
> around with it a bit and let you know how that goes.
> wdyt?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5555) JSONParser is not handling escape char properly
[
https://issues.apache.org/jira/browse/FELIX-?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15880515#comment-15880515
]
David Bosschaert commented on FELIX-:
-
I can take a look at fixing this soon if nobody else beats me to it...
> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
> Issue Type: Bug
> Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Chetan Mehrotra
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is
> rendered as
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
>
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (FELIX-5564) @Deactivate method with int reason and component property type annotation does not get called
David Bosschaert created FELIX-5564:
---
Summary: @Deactivate method with int reason and component property
type annotation does not get called
Key: FELIX-5564
URL: https://issues.apache.org/jira/browse/FELIX-5564
Project: Felix
Issue Type: Bug
Components: Declarative Services (SCR)
Affects Versions: scr-2.0.6
Reporter: David Bosschaert
I can have @Deactivate method with a component property type (annotation) like
this:
{code}@Deactivate
private void deactivate(Config myCfg){code}
I can also have a @Deactivate method with an int reason like this:
{code}@Deactivate
private void deactivate(int reason){code}
Both of these work.
However combining these does not work:
{code}@Deactivate
private void deactivate(int reason, Config myCfg){code}
In this case my deactivate method never gets called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5564) @Deactivate method with int reason and component property type annotation does not get called
[
https://issues.apache.org/jira/browse/FELIX-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15882235#comment-15882235
]
David Bosschaert commented on FELIX-5564:
-
Hmm, when I try to reproduce this in an isolated testcase it works as well.
I'll close this issue while I figure out how to isolate the testcase.
> @Deactivate method with int reason and component property type annotation
> does not get called
> -
>
> Key: FELIX-5564
> URL: https://issues.apache.org/jira/browse/FELIX-5564
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.6
>Reporter: David Bosschaert
>Assignee: Carsten Ziegeler
>
> I can have @Deactivate method with a component property type (annotation)
> like this:
> {code}@Deactivate
> private void deactivate(Config myCfg){code}
> I can also have a @Deactivate method with an int reason like this:
> {code}@Deactivate
> private void deactivate(int reason){code}
> Both of these work.
> However combining these does not work:
> {code}@Deactivate
> private void deactivate(int reason, Config myCfg){code}
> In this case my deactivate method never gets called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Closed] (FELIX-5564) @Deactivate method with int reason and component property type annotation does not get called
[
https://issues.apache.org/jira/browse/FELIX-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert closed FELIX-5564.
---
Resolution: Works for Me
> @Deactivate method with int reason and component property type annotation
> does not get called
> -
>
> Key: FELIX-5564
> URL: https://issues.apache.org/jira/browse/FELIX-5564
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.6
>Reporter: David Bosschaert
>Assignee: Carsten Ziegeler
>
> I can have @Deactivate method with a component property type (annotation)
> like this:
> {code}@Deactivate
> private void deactivate(Config myCfg){code}
> I can also have a @Deactivate method with an int reason like this:
> {code}@Deactivate
> private void deactivate(int reason){code}
> Both of these work.
> However combining these does not work:
> {code}@Deactivate
> private void deactivate(int reason, Config myCfg){code}
> In this case my deactivate method never gets called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (FELIX-5555) JSONParser is not handling escape char properly
[
https://issues.apache.org/jira/browse/FELIX-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-:
---
Assignee: David Bosschaert
> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
> Issue Type: Bug
> Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Chetan Mehrotra
>Assignee: David Bosschaert
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is
> rendered as
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
>
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Work started] (FELIX-5555) JSONParser is not handling escape char properly
[
https://issues.apache.org/jira/browse/FELIX-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX- started by David Bosschaert.
---
> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
> Issue Type: Bug
> Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Chetan Mehrotra
>Assignee: David Bosschaert
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is
> rendered as
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
>
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (FELIX-5555) JSONParser is not handling escape char properly
[
https://issues.apache.org/jira/browse/FELIX-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-.
-
Resolution: Fixed
Should be fixed in https://svn.apache.org/viewvc?view=revision&revision=1784269
I added a few additional tests as well.
> JSONParser is not handling escape char properly
> ---
>
> Key: FELIX-
> URL: https://issues.apache.org/jira/browse/FELIX-
> Project: Felix
> Issue Type: Bug
> Components: Utils
>Affects Versions: utils-1.9.0
>Reporter: Chetan Mehrotra
>Assignee: David Bosschaert
> Fix For: utils-1.9.2
>
>
> {{JSONWriter}} currently adds an escape char for '/'. So "foo=/bar" is
> rendered as
> {noformat}
> {"foo":"\/bar"}
> {noformat}
> When such a json is read via {{JSONParser}} then the '\' is not removed
> Following test fails
> {code}
> @Test
> public void escapeChar() throws Exception{
> StringWriter sw = new StringWriter();
> JSONWriter js = new JSONWriter(sw);
> js.object().key("foo").value("/bar").endObject().flush();
>
> JSONParser jp = new JSONParser(sw.toString());
> assertEquals("/bar", jp.getParsed().get("foo"));
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5564) @Deactivate method with int reason and component property type annotation does not get called
[
https://issues.apache.org/jira/browse/FELIX-5564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15885529#comment-15885529
]
David Bosschaert commented on FELIX-5564:
-
It seems like this got fixed betweem 2.0.6 and 2.0.8 because with 2.0.8 it
works for me too.
> @Deactivate method with int reason and component property type annotation
> does not get called
> -
>
> Key: FELIX-5564
> URL: https://issues.apache.org/jira/browse/FELIX-5564
> Project: Felix
> Issue Type: Bug
> Components: Declarative Services (SCR)
>Affects Versions: scr-2.0.6
>Reporter: David Bosschaert
>Assignee: Carsten Ziegeler
>
> I can have @Deactivate method with a component property type (annotation)
> like this:
> {code}@Deactivate
> private void deactivate(Config myCfg){code}
> I can also have a @Deactivate method with an int reason like this:
> {code}@Deactivate
> private void deactivate(int reason){code}
> Both of these work.
> However combining these does not work:
> {code}@Deactivate
> private void deactivate(int reason, Config myCfg){code}
> In this case my deactivate method never gets called.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5571) Replace JSONParser in Serializer with the new one from utils
[ https://issues.apache.org/jira/browse/FELIX-5571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15887582#comment-15887582 ] David Bosschaert commented on FELIX-5571: - That would be great, +1! > Replace JSONParser in Serializer with the new one from utils > > > Key: FELIX-5571 > URL: https://issues.apache.org/jira/browse/FELIX-5571 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen >Assignee: David Leangen > > I can do this if there are no objections. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5479) Serializer should be more lenient with trailing commas
[ https://issues.apache.org/jira/browse/FELIX-5479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15906977#comment-15906977 ] David Bosschaert commented on FELIX-5479: - bq. the JSON spec does not permit trailing spaces I guess you mean trailing commas? ;) > Serializer should be more lenient with trailing commas > -- > > Key: FELIX-5479 > URL: https://issues.apache.org/jira/browse/FELIX-5479 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Leangen > > I believe that well-formed JSON does not permit a trailing comma, but > currently error reporting is not very good, so it is extremely tedious to > find parsing problems. Until we have better error reporting, the parser > should be more lenient. Allowing for trailing commas is one area where > leniency would be very beneficial to productivity. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Work started] (FELIX-5593) Specify ARM processor Endianness
[ https://issues.apache.org/jira/browse/FELIX-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-5593 started by David Bosschaert. --- > Specify ARM processor Endianness > > > Key: FELIX-5593 > URL: https://issues.apache.org/jira/browse/FELIX-5593 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-5.6.1 >Reporter: Kerry Billingham >Assignee: David Bosschaert >Priority: Minor > Fix For: framework-5.6.4 > > > In accordance with OSGi core specification, ver. 6 Table 4.2, specifying > processor type 'ARM' is now deprecated. It is now preferred to use the > processor type 'arm_le' or 'arm_be'. > Felix currently determines the processor type by requesting the system > property "os.arch" however this has been found to return the deprecated 'arm' > processor string for example on the RaspberryPi installed with Raspbian OS > and the latest Oracle JDK8 for ARM. > To meet with the above specification it is proposed that Felix be modified to > appropriately to determine the endianness of ARM processors. A PR with > suggested modifications is to follow this Enhancement proposal. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5593) Specify ARM processor Endianness
[ https://issues.apache.org/jira/browse/FELIX-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15936371#comment-15936371 ] David Bosschaert commented on FELIX-5593: - Many thanks for the patch [~jtkb]! It's applied in https://svn.apache.org/viewvc?view=revision&revision=1788110 > Specify ARM processor Endianness > > > Key: FELIX-5593 > URL: https://issues.apache.org/jira/browse/FELIX-5593 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-5.6.1 >Reporter: Kerry Billingham >Assignee: David Bosschaert >Priority: Minor > Fix For: framework-5.6.4 > > > In accordance with OSGi core specification, ver. 6 Table 4.2, specifying > processor type 'ARM' is now deprecated. It is now preferred to use the > processor type 'arm_le' or 'arm_be'. > Felix currently determines the processor type by requesting the system > property "os.arch" however this has been found to return the deprecated 'arm' > processor string for example on the RaspberryPi installed with Raspbian OS > and the latest Oracle JDK8 for ARM. > To meet with the above specification it is proposed that Felix be modified to > appropriately to determine the endianness of ARM processors. A PR with > suggested modifications is to follow this Enhancement proposal. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (FELIX-5593) Specify ARM processor Endianness
[ https://issues.apache.org/jira/browse/FELIX-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-5593. - Resolution: Fixed > Specify ARM processor Endianness > > > Key: FELIX-5593 > URL: https://issues.apache.org/jira/browse/FELIX-5593 > Project: Felix > Issue Type: Improvement > Components: Framework >Affects Versions: framework-5.6.1 >Reporter: Kerry Billingham >Assignee: David Bosschaert >Priority: Minor > Fix For: framework-5.6.4 > > > In accordance with OSGi core specification, ver. 6 Table 4.2, specifying > processor type 'ARM' is now deprecated. It is now preferred to use the > processor type 'arm_le' or 'arm_be'. > Felix currently determines the processor type by requesting the system > property "os.arch" however this has been found to return the deprecated 'arm' > processor string for example on the RaspberryPi installed with Raspbian OS > and the latest Oracle JDK8 for ARM. > To meet with the above specification it is proposed that Felix be modified to > appropriately to determine the endianness of ARM processors. A PR with > suggested modifications is to follow this Enhancement proposal. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (FELIX-5611) BundleRepository must deal properly R5 index file with resources with relative path from the given repository’s URL
[
https://issues.apache.org/jira/browse/FELIX-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5611:
---
Assignee: David Bosschaert
> BundleRepository must deal properly R5 index file with resources with
> relative path from the given repository’s URL
> ---
>
> Key: FELIX-5611
> URL: https://issues.apache.org/jira/browse/FELIX-5611
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>
> I've created some index.xml (R5) files using a tool that was based on old
> bindex tool. since those files will be hosted in a server the url attribute
> of bundles and other resources are using relative path (what I think is the
> right approach since we don't know the real address of the server at this
> time:
> {quote}
>
>value="2ab00a18d414d1c43a7f8ba286f16f323c6b940ca775cdfd974dd6c127a35b25"/>
>value="plugins/ch.qos.logback.core_1.2.1.jar"/>
>
>
>
> {quote}
> But when I try to deploy any bundle using RepositoryAdmin or obr:deploy
> command, I'm getting an exception: java.net.MalformedURLException: no
> protocol: plugins/ch.qos.logback.core_1.2.1.jar
> The proposed solution is to pass the URL of the repository to the parser and
> in case of a non-absolute uri were found it will be resolved against the
> repository uri.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Work started] (FELIX-5611) BundleRepository must deal properly R5 index file with resources with relative path from the given repository’s URL
[
https://issues.apache.org/jira/browse/FELIX-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5611 started by David Bosschaert.
---
> BundleRepository must deal properly R5 index file with resources with
> relative path from the given repository’s URL
> ---
>
> Key: FELIX-5611
> URL: https://issues.apache.org/jira/browse/FELIX-5611
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>
> I've created some index.xml (R5) files using a tool that was based on old
> bindex tool. since those files will be hosted in a server the url attribute
> of bundles and other resources are using relative path (what I think is the
> right approach since we don't know the real address of the server at this
> time:
> {quote}
>
>value="2ab00a18d414d1c43a7f8ba286f16f323c6b940ca775cdfd974dd6c127a35b25"/>
>value="plugins/ch.qos.logback.core_1.2.1.jar"/>
>
>
>
> {quote}
> But when I try to deploy any bundle using RepositoryAdmin or obr:deploy
> command, I'm getting an exception: java.net.MalformedURLException: no
> protocol: plugins/ch.qos.logback.core_1.2.1.jar
> The proposed solution is to pass the URL of the repository to the parser and
> in case of a non-absolute uri were found it will be resolved against the
> repository uri.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Work stopped] (FELIX-5611) BundleRepository must deal properly R5 index file with resources with relative path from the given repository’s URL
[
https://issues.apache.org/jira/browse/FELIX-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5611 stopped by David Bosschaert.
---
> BundleRepository must deal properly R5 index file with resources with
> relative path from the given repository’s URL
> ---
>
> Key: FELIX-5611
> URL: https://issues.apache.org/jira/browse/FELIX-5611
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>
> I've created some index.xml (R5) files using a tool that was based on old
> bindex tool. since those files will be hosted in a server the url attribute
> of bundles and other resources are using relative path (what I think is the
> right approach since we don't know the real address of the server at this
> time:
> {quote}
>
>value="2ab00a18d414d1c43a7f8ba286f16f323c6b940ca775cdfd974dd6c127a35b25"/>
>value="plugins/ch.qos.logback.core_1.2.1.jar"/>
>
>
>
> {quote}
> But when I try to deploy any bundle using RepositoryAdmin or obr:deploy
> command, I'm getting an exception: java.net.MalformedURLException: no
> protocol: plugins/ch.qos.logback.core_1.2.1.jar
> The proposed solution is to pass the URL of the repository to the parser and
> in case of a non-absolute uri were found it will be resolved against the
> repository uri.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (FELIX-5611) BundleRepository must deal properly R5 index file with resources with relative path from the given repository’s URL
[
https://issues.apache.org/jira/browse/FELIX-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5611:
---
Assignee: (was: David Bosschaert)
> BundleRepository must deal properly R5 index file with resources with
> relative path from the given repository’s URL
> ---
>
> Key: FELIX-5611
> URL: https://issues.apache.org/jira/browse/FELIX-5611
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>
> I've created some index.xml (R5) files using a tool that was based on old
> bindex tool. since those files will be hosted in a server the url attribute
> of bundles and other resources are using relative path (what I think is the
> right approach since we don't know the real address of the server at this
> time:
> {quote}
>
>value="2ab00a18d414d1c43a7f8ba286f16f323c6b940ca775cdfd974dd6c127a35b25"/>
>value="plugins/ch.qos.logback.core_1.2.1.jar"/>
>
>
>
> {quote}
> But when I try to deploy any bundle using RepositoryAdmin or obr:deploy
> command, I'm getting an exception: java.net.MalformedURLException: no
> protocol: plugins/ch.qos.logback.core_1.2.1.jar
> The proposed solution is to pass the URL of the repository to the parser and
> in case of a non-absolute uri were found it will be resolved against the
> repository uri.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5611) BundleRepository must deal properly R5 index file with resources with relative path from the given repository’s URL
[
https://issues.apache.org/jira/browse/FELIX-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15963301#comment-15963301
]
David Bosschaert commented on FELIX-5611:
-
As commented on the patch in github, it would be good to have some testcases to
cover the modifications. [~cvgaviao], it would be great if you have some time
to provide those as well.
> BundleRepository must deal properly R5 index file with resources with
> relative path from the given repository’s URL
> ---
>
> Key: FELIX-5611
> URL: https://issues.apache.org/jira/browse/FELIX-5611
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>
> I've created some index.xml (R5) files using a tool that was based on old
> bindex tool. since those files will be hosted in a server the url attribute
> of bundles and other resources are using relative path (what I think is the
> right approach since we don't know the real address of the server at this
> time:
> {quote}
>
>value="2ab00a18d414d1c43a7f8ba286f16f323c6b940ca775cdfd974dd6c127a35b25"/>
>value="plugins/ch.qos.logback.core_1.2.1.jar"/>
>
>
>
> {quote}
> But when I try to deploy any bundle using RepositoryAdmin or obr:deploy
> command, I'm getting an exception: java.net.MalformedURLException: no
> protocol: plugins/ch.qos.logback.core_1.2.1.jar
> The proposed solution is to pass the URL of the repository to the parser and
> in case of a non-absolute uri were found it will be resolved against the
> repository uri.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Work started] (FELIX-5611) BundleRepository must deal properly R5 index file with resources with relative path from the given repository’s URL
[
https://issues.apache.org/jira/browse/FELIX-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5611 started by David Bosschaert.
---
> BundleRepository must deal properly R5 index file with resources with
> relative path from the given repository’s URL
> ---
>
> Key: FELIX-5611
> URL: https://issues.apache.org/jira/browse/FELIX-5611
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>
> I've created some index.xml (R5) files using a tool that was based on old
> bindex tool. since those files will be hosted in a server the url attribute
> of bundles and other resources are using relative path (what I think is the
> right approach since we don't know the real address of the server at this
> time:
> {quote}
>
>value="2ab00a18d414d1c43a7f8ba286f16f323c6b940ca775cdfd974dd6c127a35b25"/>
>value="plugins/ch.qos.logback.core_1.2.1.jar"/>
>
>
>
> {quote}
> But when I try to deploy any bundle using RepositoryAdmin or obr:deploy
> command, I'm getting an exception: java.net.MalformedURLException: no
> protocol: plugins/ch.qos.logback.core_1.2.1.jar
> The proposed solution is to pass the URL of the repository to the parser and
> in case of a non-absolute uri were found it will be resolved against the
> repository uri.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (FELIX-5611) BundleRepository must deal properly R5 index file with resources with relative path from the given repository’s URL
[
https://issues.apache.org/jira/browse/FELIX-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5611:
---
Assignee: David Bosschaert
> BundleRepository must deal properly R5 index file with resources with
> relative path from the given repository’s URL
> ---
>
> Key: FELIX-5611
> URL: https://issues.apache.org/jira/browse/FELIX-5611
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>
> I've created some index.xml (R5) files using a tool that was based on old
> bindex tool. since those files will be hosted in a server the url attribute
> of bundles and other resources are using relative path (what I think is the
> right approach since we don't know the real address of the server at this
> time:
> {quote}
>
>value="2ab00a18d414d1c43a7f8ba286f16f323c6b940ca775cdfd974dd6c127a35b25"/>
>value="plugins/ch.qos.logback.core_1.2.1.jar"/>
>
>
>
> {quote}
> But when I try to deploy any bundle using RepositoryAdmin or obr:deploy
> command, I'm getting an exception: java.net.MalformedURLException: no
> protocol: plugins/ch.qos.logback.core_1.2.1.jar
> The proposed solution is to pass the URL of the repository to the parser and
> in case of a non-absolute uri were found it will be resolved against the
> repository uri.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Reopened] (FELIX-5616) Converter ignores rules of ParameterizedType
[ https://issues.apache.org/jira/browse/FELIX-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reopened FELIX-5616: - [~dleangen] I see that https://svn.apache.org/viewvc?view=revision&revision=1791667 does not contain any unit tests... This gives me the uneasy feeling that this might get broken again in the future without anyone noticing. Would you be able to add some unit tests for the thing that you fixed? Reopening the issue... > Converter ignores rules of ParameterizedType > > > Key: FELIX-5616 > URL: https://issues.apache.org/jira/browse/FELIX-5616 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen >Assignee: David Leangen > > Rules based on ParameterizedTypes are ignored by the Converter. > I will make the simple fix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Assigned] (FELIX-5614) Make isDTOType(Class cls) publicly available
[ https://issues.apache.org/jira/browse/FELIX-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-5614: --- Assignee: David Bosschaert > Make isDTOType(Class cls) publicly available > --- > > Key: FELIX-5614 > URL: https://issues.apache.org/jira/browse/FELIX-5614 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > In ConvertingImpl, which a (bundle private) implementation class, there is a > (class private) method: isDTOType(Class cls) > Since this is a rule based on the definition of a DTO in the spec, it would > be nice to make this test somehow available publicly for general use > (including by other bundles). > It tedious for each user of the API to write their own test if an > authoritative test is already available. > For my particular use case, the Schematizer needs to test a class to > determine whether or not it is a DTO in order to know how to handle it. > Having the test available (without having to copy over the code from the > Converter) would be quite useful.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Work started] (FELIX-5614) Make isDTOType(Class cls) publicly available
[ https://issues.apache.org/jira/browse/FELIX-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-5614 started by David Bosschaert. --- > Make isDTOType(Class cls) publicly available > --- > > Key: FELIX-5614 > URL: https://issues.apache.org/jira/browse/FELIX-5614 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > In ConvertingImpl, which a (bundle private) implementation class, there is a > (class private) method: isDTOType(Class cls) > Since this is a rule based on the definition of a DTO in the spec, it would > be nice to make this test somehow available publicly for general use > (including by other bundles). > It tedious for each user of the API to write their own test if an > authoritative test is already available. > For my particular use case, the Schematizer needs to test a class to > determine whether or not it is a DTO in order to know how to handle it. > Having the test available (without having to copy over the code from the > Converter) would be quite useful.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5614) Make isDTOType(Class cls) publicly available
[ https://issues.apache.org/jira/browse/FELIX-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15972891#comment-15972891 ] David Bosschaert commented on FELIX-5614: - I've separated the method out into a public class: DTOUtil.isDTOType(Class cls) here https://svn.apache.org/viewvc?view=revision&revision=1791797 However, it's now still in the org.apache.felix.converter.impl package which is not exported, so that still won't allow you to use it easily. One thing we could do is put it in its own package, like org.apache.felix.converter.impl.dto or something like that. Then you can embed that package in your own bundles and don't need to import it. Since the package will only contain the one DTOUtil class this will be cheap. Any better ideas? > Make isDTOType(Class cls) publicly available > --- > > Key: FELIX-5614 > URL: https://issues.apache.org/jira/browse/FELIX-5614 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > In ConvertingImpl, which a (bundle private) implementation class, there is a > (class private) method: isDTOType(Class cls) > Since this is a rule based on the definition of a DTO in the spec, it would > be nice to make this test somehow available publicly for general use > (including by other bundles). > It tedious for each user of the API to write their own test if an > authoritative test is already available. > For my particular use case, the Schematizer needs to test a class to > determine whether or not it is a DTO in order to know how to handle it. > Having the test available (without having to copy over the code from the > Converter) would be quite useful.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5611) BundleRepository must deal properly R5 index file with resources with relative path from the given repository’s URL
[
https://issues.apache.org/jira/browse/FELIX-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974393#comment-15974393
]
David Bosschaert commented on FELIX-5611:
-
Pull request committed
https://svn.apache.org/viewvc?view=revision&revision=1791891
Many thanks for the fix [~cvgaviao]!
> BundleRepository must deal properly R5 index file with resources with
> relative path from the given repository’s URL
> ---
>
> Key: FELIX-5611
> URL: https://issues.apache.org/jira/browse/FELIX-5611
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>
> I've created some index.xml (R5) files using a tool that was based on old
> bindex tool. since those files will be hosted in a server the url attribute
> of bundles and other resources are using relative path (what I think is the
> right approach since we don't know the real address of the server at this
> time:
> {quote}
>
>value="2ab00a18d414d1c43a7f8ba286f16f323c6b940ca775cdfd974dd6c127a35b25"/>
>value="plugins/ch.qos.logback.core_1.2.1.jar"/>
>
>
>
> {quote}
> But when I try to deploy any bundle using RepositoryAdmin or obr:deploy
> command, I'm getting an exception: java.net.MalformedURLException: no
> protocol: plugins/ch.qos.logback.core_1.2.1.jar
> The proposed solution is to pass the URL of the repository to the parser and
> in case of a non-absolute uri were found it will be resolved against the
> repository uri.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (FELIX-5611) BundleRepository must deal properly R5 index file with resources with relative path from the given repository’s URL
[
https://issues.apache.org/jira/browse/FELIX-5611?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-5611.
-
Resolution: Fixed
Fix Version/s: bundlerepository-2.0.10
> BundleRepository must deal properly R5 index file with resources with
> relative path from the given repository’s URL
> ---
>
> Key: FELIX-5611
> URL: https://issues.apache.org/jira/browse/FELIX-5611
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.10
>
>
> I've created some index.xml (R5) files using a tool that was based on old
> bindex tool. since those files will be hosted in a server the url attribute
> of bundles and other resources are using relative path (what I think is the
> right approach since we don't know the real address of the server at this
> time:
> {quote}
>
>value="2ab00a18d414d1c43a7f8ba286f16f323c6b940ca775cdfd974dd6c127a35b25"/>
>value="plugins/ch.qos.logback.core_1.2.1.jar"/>
>
>
>
> {quote}
> But when I try to deploy any bundle using RepositoryAdmin or obr:deploy
> command, I'm getting an exception: java.net.MalformedURLException: no
> protocol: plugins/ch.qos.logback.core_1.2.1.jar
> The proposed solution is to pass the URL of the repository to the parser and
> in case of a non-absolute uri were found it will be resolved against the
> repository uri.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5616) Converter ignores rules of ParameterizedType
[ https://issues.apache.org/jira/browse/FELIX-5616?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974515#comment-15974515 ] David Bosschaert commented on FELIX-5616: - Hi [~dleangen], I don't mind a new set of better structured unit tests, but I think we should keep the existing tests in place. This means that some things get tested twice but that doesn't matter because the tests are really fast. I would not be a fan of removing existing unit tests, simply because you're never sure that you're covering all the nuances that the old ones might be covering. So yes, as long as we keep the existing ones, I'm all for adding better structured ones as well :) > Converter ignores rules of ParameterizedType > > > Key: FELIX-5616 > URL: https://issues.apache.org/jira/browse/FELIX-5616 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen >Assignee: David Leangen > > Rules based on ParameterizedTypes are ignored by the Converter. > I will make the simple fix. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5614) Make isDTOType(Class cls) publicly available
[ https://issues.apache.org/jira/browse/FELIX-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974522#comment-15974522 ] David Bosschaert commented on FELIX-5614: - Hi [~dleangen], injecting this rule sounds like an interesting idea, but I'm not sure what it would look like... I think that what you're saying is that you want to specialize isDTO() so that it considers a source or target class as a DTO even though it has a constructor. You can already do this with convert(myDTOWithCtor).sourceAsDTO().to(String.class) ? If this is not what you're thinking of, could you maybe give an example? > Make isDTOType(Class cls) publicly available > --- > > Key: FELIX-5614 > URL: https://issues.apache.org/jira/browse/FELIX-5614 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > In ConvertingImpl, which a (bundle private) implementation class, there is a > (class private) method: isDTOType(Class cls) > Since this is a rule based on the definition of a DTO in the spec, it would > be nice to make this test somehow available publicly for general use > (including by other bundles). > It tedious for each user of the API to write their own test if an > authoritative test is already available. > For my particular use case, the Schematizer needs to test a class to > determine whether or not it is a DTO in order to know how to handle it. > Having the test available (without having to copy over the code from the > Converter) would be quite useful.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5614) Make isDTOType(Class cls) publicly available
[ https://issues.apache.org/jira/browse/FELIX-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974548#comment-15974548 ] David Bosschaert commented on FELIX-5614: - Hi [~dleangen], I've moved the DTOUtil to org.apache.felix.converter and exported that package: https://svn.apache.org/viewvc?view=revision&revision=1791907 With this you can basically do 2 things: * You can import it as you would do with any OSGi imports. * However, you can also embed it which basically means that if you just use this class and don't use anything else from the converter, you don't have to have the runtime dependency. In maven you can embed an entire dependency by not marking it as provided but you can also using the Conditional-Package instruction to just pull in this specific package, more info on that here: http://njbartlett.name/2014/05/26/static-linking.html > Make isDTOType(Class cls) publicly available > --- > > Key: FELIX-5614 > URL: https://issues.apache.org/jira/browse/FELIX-5614 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > In ConvertingImpl, which a (bundle private) implementation class, there is a > (class private) method: isDTOType(Class cls) > Since this is a rule based on the definition of a DTO in the spec, it would > be nice to make this test somehow available publicly for general use > (including by other bundles). > It tedious for each user of the API to write their own test if an > authoritative test is already available. > For my particular use case, the Schematizer needs to test a class to > determine whether or not it is a DTO in order to know how to handle it. > Having the test available (without having to copy over the code from the > Converter) would be quite useful.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (FELIX-5614) Make isDTOType(Class cls) publicly available
[ https://issues.apache.org/jira/browse/FELIX-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974548#comment-15974548 ] David Bosschaert edited comment on FELIX-5614 at 4/19/17 12:38 PM: --- Hi [~dleangen], I've moved the DTOUtil to org.apache.felix.converter and exported that package: https://svn.apache.org/viewvc?view=revision&revision=1791907 With this you can basically do 2 things: * You can import it as you would do with any OSGi imports. * However, you can also embed it which basically means that if you just use this class and don't use anything else from the converter, you don't have to have the runtime dependency. In maven you can embed an entire dependency by not marking it as provided but you can also using the Conditional-Package instruction to just pull in this specific package, more info on that here: http://njbartlett.name/2014/05/26/static-linking.html For the static linking case, it might be better to move it to a package of its own - i.e. org.apache.felix.converter.dto since there might be other things that get added to org.apache.felix.converter in the future and then it becomes less clean to do the static linking without pulling those things in as well... was (Author: bosschaert): Hi [~dleangen], I've moved the DTOUtil to org.apache.felix.converter and exported that package: https://svn.apache.org/viewvc?view=revision&revision=1791907 With this you can basically do 2 things: * You can import it as you would do with any OSGi imports. * However, you can also embed it which basically means that if you just use this class and don't use anything else from the converter, you don't have to have the runtime dependency. In maven you can embed an entire dependency by not marking it as provided but you can also using the Conditional-Package instruction to just pull in this specific package, more info on that here: http://njbartlett.name/2014/05/26/static-linking.html > Make isDTOType(Class cls) publicly available > --- > > Key: FELIX-5614 > URL: https://issues.apache.org/jira/browse/FELIX-5614 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > In ConvertingImpl, which a (bundle private) implementation class, there is a > (class private) method: isDTOType(Class cls) > Since this is a rule based on the definition of a DTO in the spec, it would > be nice to make this test somehow available publicly for general use > (including by other bundles). > It tedious for each user of the API to write their own test if an > authoritative test is already available. > For my particular use case, the Schematizer needs to test a class to > determine whether or not it is a DTO in order to know how to handle it. > Having the test available (without having to copy over the code from the > Converter) would be quite useful.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Comment Edited] (FELIX-5614) Make isDTOType(Class cls) publicly available
[ https://issues.apache.org/jira/browse/FELIX-5614?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15974548#comment-15974548 ] David Bosschaert edited comment on FELIX-5614 at 4/19/17 12:38 PM: --- Hi [~dleangen], I've moved the DTOUtil to org.apache.felix.converter and exported that package: https://svn.apache.org/viewvc?view=revision&revision=1791907 With this you can basically do 2 things: * You can import it as you would do with any OSGi imports. * However, you can also embed it which basically means that if you just use this class and don't use anything else from the converter, you don't have to have the runtime dependency. In maven you can embed an entire dependency by not marking it as provided but you can also using the Conditional-Package instruction to just pull in this specific package, more info on that here: http://njbartlett.name/2014/05/26/static-linking.html Actually, just thinking that for the static linking case, it might be better to move it to a package of its own - i.e. org.apache.felix.converter.dto since there might be other things that get added to org.apache.felix.converter in the future and then it becomes less clean to do the static linking without pulling those things in as well... was (Author: bosschaert): Hi [~dleangen], I've moved the DTOUtil to org.apache.felix.converter and exported that package: https://svn.apache.org/viewvc?view=revision&revision=1791907 With this you can basically do 2 things: * You can import it as you would do with any OSGi imports. * However, you can also embed it which basically means that if you just use this class and don't use anything else from the converter, you don't have to have the runtime dependency. In maven you can embed an entire dependency by not marking it as provided but you can also using the Conditional-Package instruction to just pull in this specific package, more info on that here: http://njbartlett.name/2014/05/26/static-linking.html For the static linking case, it might be better to move it to a package of its own - i.e. org.apache.felix.converter.dto since there might be other things that get added to org.apache.felix.converter in the future and then it becomes less clean to do the static linking without pulling those things in as well... > Make isDTOType(Class cls) publicly available > --- > > Key: FELIX-5614 > URL: https://issues.apache.org/jira/browse/FELIX-5614 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > In ConvertingImpl, which a (bundle private) implementation class, there is a > (class private) method: isDTOType(Class cls) > Since this is a rule based on the definition of a DTO in the spec, it would > be nice to make this test somehow available publicly for general use > (including by other bundles). > It tedious for each user of the API to write their own test if an > authoritative test is already available. > For my particular use case, the Schematizer needs to test a class to > determine whether or not it is a DTO in order to know how to handle it. > Having the test available (without having to copy over the code from the > Converter) would be quite useful.. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Work started] (FELIX-5617) Remove "null" from console messages
[
https://issues.apache.org/jira/browse/FELIX-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5617 started by David Bosschaert.
---
> Remove "null" from console messages
> ---
>
> Key: FELIX-5617
> URL: https://issues.apache.org/jira/browse/FELIX-5617
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>
> When BudleRepository is working with R5 index files the parsed resource will
> not have a presentation name, so every time it tries to show information
> about a resource in the console a "null" will printed instead.
> Example:
> {quote}
> Unsatisfied requirement(s):
> ---
>
> (&(symbolicname=org.eclipse.equinox.common)(bundle-version>=3.2.0)(!(bundle-version>=4.0.0)))
> null
>(&(package=org.osgi.service.prefs)(version>=1.1.0)(!(version>=2.0.0)))
> null
> {quote}
> The proposed fix is to verify whether there is a presentation name, if not
> then use the symbolic name. the expected result is below:
> {quote}
> Unsatisfied requirement(s):
> ---
>
> (&(symbolicname=org.eclipse.equinox.common)(bundle-version>=3.2.0)(!(bundle-version>=4.0.0)))
> org.eclipse.equinox.preferences
>(&(package=org.osgi.service.prefs)(version>=1.1.0)(!(version>=2.0.0)))
> org.lunifera.runtime.kernel.lib
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (FELIX-5617) Remove "null" from console messages
[
https://issues.apache.org/jira/browse/FELIX-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5617:
---
Assignee: David Bosschaert
> Remove "null" from console messages
> ---
>
> Key: FELIX-5617
> URL: https://issues.apache.org/jira/browse/FELIX-5617
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
>
> When BudleRepository is working with R5 index files the parsed resource will
> not have a presentation name, so every time it tries to show information
> about a resource in the console a "null" will printed instead.
> Example:
> {quote}
> Unsatisfied requirement(s):
> ---
>
> (&(symbolicname=org.eclipse.equinox.common)(bundle-version>=3.2.0)(!(bundle-version>=4.0.0)))
> null
>(&(package=org.osgi.service.prefs)(version>=1.1.0)(!(version>=2.0.0)))
> null
> {quote}
> The proposed fix is to verify whether there is a presentation name, if not
> then use the symbolic name. the expected result is below:
> {quote}
> Unsatisfied requirement(s):
> ---
>
> (&(symbolicname=org.eclipse.equinox.common)(bundle-version>=3.2.0)(!(bundle-version>=4.0.0)))
> org.eclipse.equinox.preferences
>(&(package=org.osgi.service.prefs)(version>=1.1.0)(!(version>=2.0.0)))
> org.lunifera.runtime.kernel.lib
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (FELIX-5617) Remove "null" from console messages
[
https://issues.apache.org/jira/browse/FELIX-5617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-5617.
-
Resolution: Fixed
Fix Version/s: bundlerepository-2.0.10
Thanks for the pull request [~cvgaviao]! It's applied in
https://svn.apache.org/viewvc?view=revision&revision=1792040
> Remove "null" from console messages
> ---
>
> Key: FELIX-5617
> URL: https://issues.apache.org/jira/browse/FELIX-5617
> Project: Felix
> Issue Type: Improvement
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Cristiano Gavião
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.10
>
>
> When BudleRepository is working with R5 index files the parsed resource will
> not have a presentation name, so every time it tries to show information
> about a resource in the console a "null" will printed instead.
> Example:
> {quote}
> Unsatisfied requirement(s):
> ---
>
> (&(symbolicname=org.eclipse.equinox.common)(bundle-version>=3.2.0)(!(bundle-version>=4.0.0)))
> null
>(&(package=org.osgi.service.prefs)(version>=1.1.0)(!(version>=2.0.0)))
> null
> {quote}
> The proposed fix is to verify whether there is a presentation name, if not
> then use the symbolic name. the expected result is below:
> {quote}
> Unsatisfied requirement(s):
> ---
>
> (&(symbolicname=org.eclipse.equinox.common)(bundle-version>=3.2.0)(!(bundle-version>=4.0.0)))
> org.eclipse.equinox.preferences
>(&(package=org.osgi.service.prefs)(version>=1.1.0)(!(version>=2.0.0)))
> org.lunifera.runtime.kernel.lib
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (FELIX-5066) BundleRepository should provide osgi.service and osgi.implementation capabilities
[
https://issues.apache.org/jira/browse/FELIX-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-5066.
-
Resolution: Fixed
Fixed in https://svn.apache.org/viewvc?view=revision&revision=1792041
> BundleRepository should provide osgi.service and osgi.implementation
> capabilities
> -
>
> Key: FELIX-5066
> URL: https://issues.apache.org/jira/browse/FELIX-5066
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.6
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.10
>
>
> The OSGi repository spec defines capabilities that a bundlerepository
> implementation should provide. They are:
> {code}Provide-Capability: osgi.implementation;
> osgi.implementation="osgi.repository";
> uses:="org.osgi.service.repository";
> version:Version="1.1"
> {code} and
> {code}Provide-Capability: osgi.service;
> objectClass:List="org.osgi.service.repository.Repository";
> uses:="org.osgi.service.repository"{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (FELIX-5066) BundleRepository should provide osgi.service and osgi.implementation capabilities
[
https://issues.apache.org/jira/browse/FELIX-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5066:
---
Assignee: David Bosschaert
> BundleRepository should provide osgi.service and osgi.implementation
> capabilities
> -
>
> Key: FELIX-5066
> URL: https://issues.apache.org/jira/browse/FELIX-5066
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.6
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.10
>
>
> The OSGi repository spec defines capabilities that a bundlerepository
> implementation should provide. They are:
> {code}Provide-Capability: osgi.implementation;
> osgi.implementation="osgi.repository";
> uses:="org.osgi.service.repository";
> version:Version="1.1"
> {code} and
> {code}Provide-Capability: osgi.service;
> objectClass:List="org.osgi.service.repository.Repository";
> uses:="org.osgi.service.repository"{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Work started] (FELIX-5066) BundleRepository should provide osgi.service and osgi.implementation capabilities
[
https://issues.apache.org/jira/browse/FELIX-5066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on FELIX-5066 started by David Bosschaert.
---
> BundleRepository should provide osgi.service and osgi.implementation
> capabilities
> -
>
> Key: FELIX-5066
> URL: https://issues.apache.org/jira/browse/FELIX-5066
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.6
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.10
>
>
> The OSGi repository spec defines capabilities that a bundlerepository
> implementation should provide. They are:
> {code}Provide-Capability: osgi.implementation;
> osgi.implementation="osgi.repository";
> uses:="org.osgi.service.repository";
> version:Version="1.1"
> {code} and
> {code}Provide-Capability: osgi.service;
> objectClass:List="org.osgi.service.repository.Repository";
> uses:="org.osgi.service.repository"{code}
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (FELIX-5626) Exclude EasyMock from the runtime classpath
[ https://issues.apache.org/jira/browse/FELIX-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-5626: --- Assignee: David Bosschaert > Exclude EasyMock from the runtime classpath > --- > > Key: FELIX-5626 > URL: https://issues.apache.org/jira/browse/FELIX-5626 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-2.0.8 >Reporter: Mykola Nikishov >Assignee: David Bosschaert > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Resolved] (FELIX-5626) Exclude EasyMock from the runtime classpath
[ https://issues.apache.org/jira/browse/FELIX-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-5626. - Resolution: Fixed Fix Version/s: bundlerepository-2.0.12 Thanks for the patch [~man]! It's applied in https://svn.apache.org/viewvc?view=revision&revision=1793018 > Exclude EasyMock from the runtime classpath > --- > > Key: FELIX-5626 > URL: https://issues.apache.org/jira/browse/FELIX-5626 > Project: Felix > Issue Type: Bug > Components: Bundle Repository (OBR) >Affects Versions: bundlerepository-2.0.8 >Reporter: Mykola Nikishov >Assignee: David Bosschaert > Fix For: bundlerepository-2.0.12 > > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (FELIX-5626) Exclude EasyMock from the runtime classpath
[
https://issues.apache.org/jira/browse/FELIX-5626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15988452#comment-15988452
]
David Bosschaert commented on FELIX-5626:
-
[~io7m] wrote:
bq. Related, the `org.apache.felix.gogo.command` bundle has this same issue.
I don't see an EasyMock dependency in the {{org.apache.felix.gogo.command}}
bundle and the Mockito dep in there already has the {{test}} scope...
> Exclude EasyMock from the runtime classpath
> ---
>
> Key: FELIX-5626
> URL: https://issues.apache.org/jira/browse/FELIX-5626
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
>Affects Versions: bundlerepository-2.0.8
>Reporter: Mykola Nikishov
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.12
>
>
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Assigned] (FELIX-5644) Repository#getURI() is no longer unique in case of XML-based repositories
[
https://issues.apache.org/jira/browse/FELIX-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5644:
---
Assignee: David Bosschaert
> Repository#getURI() is no longer unique in case of XML-based repositories
> -
>
> Key: FELIX-5644
> URL: https://issues.apache.org/jira/browse/FELIX-5644
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
>
> Because of a regression introduced by fixing FELIX-5611, the URI returned by
> {{Repository#getURI()}} is no longer unique in case of xml-based repository
> URIs. You cannot delete a repository using
> {{RepositoryAdmin#removeRepository(Repository#getURI()))}} when you use xml
> documents.
> {code}
> Repository firstRepository =
> repositoryAdmin.addRepository("file:///C:/Users/myuser/repo_for_optional_resources.xml");
> System.out.println(firstRepository.getURI());
> Repository secondRepository =
> repositoryAdmin.addRepository("file:///C:/Users/myuser/repo_for_mandatory.xml")
> System.out.println(secondRepository.getURI());
> {code}
> Result:
> {code}
> file:/C:/Users/myuser/
> file:/C:/Users/myuser/
> {code}
> The repositories are registered in the repository map with the original URIs,
> so that there is now way to remove a repository without knowing the initial
> URI under which it was registered.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Resolved] (FELIX-5644) Repository#getURI() is no longer unique in case of XML-based repositories
[
https://issues.apache.org/jira/browse/FELIX-5644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-5644.
-
Resolution: Fixed
Fix Version/s: bundlerepository-2.0.12
The associated pull request https://github.com/apache/felix/pull/109 was
applied in https://svn.apache.org/viewvc?view=revision&revision=1797072 with
many thanks!
> Repository#getURI() is no longer unique in case of XML-based repositories
> -
>
> Key: FELIX-5644
> URL: https://issues.apache.org/jira/browse/FELIX-5644
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
>Reporter: Jens Offenbach
>Assignee: David Bosschaert
> Fix For: bundlerepository-2.0.12
>
>
> Because of a regression introduced by fixing FELIX-5611, the URI returned by
> {{Repository#getURI()}} is no longer unique in case of xml-based repository
> URIs. You cannot delete a repository using
> {{RepositoryAdmin#removeRepository(Repository#getURI()))}} when you use xml
> documents.
> {code}
> Repository firstRepository =
> repositoryAdmin.addRepository("file:///C:/Users/myuser/repo_for_optional_resources.xml");
> System.out.println(firstRepository.getURI());
> Repository secondRepository =
> repositoryAdmin.addRepository("file:///C:/Users/myuser/repo_for_mandatory.xml")
> System.out.println(secondRepository.getURI());
> {code}
> Result:
> {code}
> file:/C:/Users/myuser/
> file:/C:/Users/myuser/
> {code}
> The repositories are registered in the repository map with the original URIs,
> so that there is now way to remove a repository without knowing the initial
> URI under which it was registered.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5641) Add getRepository() to Resource
[
https://issues.apache.org/jira/browse/FELIX-5641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16031518#comment-16031518
]
David Bosschaert commented on FELIX-5641:
-
The pull request contains a change to exported API. I think we can assume that
the Resource is a provider type here - I don't think users ever need to
implement this resource.
Therefore the pull request should be updated to include an update of the
Export-Package definition to:
{code}org.apache.felix.bundlerepository;version="2.2"
{code}
Does anyone see an issue with this?
Note that the https://osgi.org/javadoc/r6/core/org/osgi/resource/Resource.html
(which is a different resource) is a consumer type - any API changes to a
consumer type require a major version update.
> Add getRepository() to Resource
> ---
>
> Key: FELIX-5641
> URL: https://issues.apache.org/jira/browse/FELIX-5641
> Project: Felix
> Issue Type: Bug
> Components: Bundle Repository (OBR)
>Reporter: Jens Offenbach
>
> The method {{RepositoryAdmin#discoverResources}} returns a list of filtered
> resources, but it is currently not efficiently possible to get the
> corresponding repository for a resource. The information is available in
> {{ResourceImpl}}, but not accessible through the API.
> Is it possible to add this?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (FELIX-5666) Serializer goes into infinite loop
[
https://issues.apache.org/jira/browse/FELIX-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16107118#comment-16107118
]
David Bosschaert commented on FELIX-5666:
-
Hi [~dleangen], yes a testcase would be great. Thanks!
> Serializer goes into infinite loop
> --
>
> Key: FELIX-5666
> URL: https://issues.apache.org/jira/browse/FELIX-5666
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>
> I'm only guessing as to what the problem is, following some stepping through
> the code. I could not find any similar existing test cases, but if the
> following does not immediately click for [~bosschaert], I will try to add one.
> It appears that, when serializing an object to a "DTO-Type" object to a Map,
> some kind of backing object is created.
> If the backing object contains a field that instantiates the same DTO, then
> the loop gets created.
> Example:
> {code}
> public class MyDtoType {
> public String id;
> public MyDtoType( String anID ) {
> id = anID;
> }
> public static MyDtoType error() {
> return new MyDtoType( "ERROR" );
> }
> }
> {code}
> It looks like the serializer keeps calling the error() method infinitely, but
> I am not able to easily pinpoint where this happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (FELIX-5666) Serializer goes into infinite loop
[
https://issues.apache.org/jira/browse/FELIX-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5666:
---
Assignee: David Bosschaert
> Serializer goes into infinite loop
> --
>
> Key: FELIX-5666
> URL: https://issues.apache.org/jira/browse/FELIX-5666
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> I'm only guessing as to what the problem is, following some stepping through
> the code. I could not find any similar existing test cases, but if the
> following does not immediately click for [~bosschaert], I will try to add one.
> It appears that, when serializing an object to a "DTO-Type" object to a Map,
> some kind of backing object is created.
> If the backing object contains a field that instantiates the same DTO, then
> the loop gets created.
> Example:
> {code}
> public class MyDtoType {
> public String id;
> public MyDtoType( String anID ) {
> id = anID;
> }
> public static MyDtoType error() {
> return new MyDtoType( "ERROR" );
> }
> }
> {code}
> It looks like the serializer keeps calling the error() method infinitely, but
> I am not able to easily pinpoint where this happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5666) Serializer goes into infinite loop
[
https://issues.apache.org/jira/browse/FELIX-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112559#comment-16112559
]
David Bosschaert commented on FELIX-5666:
-
Hi [~dleangen], just trying to start understanding the problem.
The first test I started looking at is:
JsonBackingObjectSerializationTest.testComplexMapSerializationFirstUsingConversion()
This test creates a DTO: MyDTOishObject and then converts it to a Map. This
conversion seems to work correctly, but then the conversion from that map to
the JSON seems to go wrong. Is this a correct assumption? It looks like the
serialization of a DTO to JSON doesn't work...
Actually I guess the problem can already be observed by calling
{{JsonSerializerImpl().serialize(obj).toString()}} directly on the DTO, as the
result there also contains the {{toString}} key in the JSON.
> Serializer goes into infinite loop
> --
>
> Key: FELIX-5666
> URL: https://issues.apache.org/jira/browse/FELIX-5666
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> I'm only guessing as to what the problem is, following some stepping through
> the code. I could not find any similar existing test cases, but if the
> following does not immediately click for [~bosschaert], I will try to add one.
> It appears that, when serializing an object to a "DTO-Type" object to a Map,
> some kind of backing object is created.
> If the backing object contains a field that instantiates the same DTO, then
> the loop gets created.
> Example:
> {code}
> public class MyDtoType {
> public String id;
> public MyDtoType( String anID ) {
> id = anID;
> }
> public static MyDtoType error() {
> return new MyDtoType( "ERROR" );
> }
> }
> {code}
> It looks like the serializer keeps calling the error() method infinitely, but
> I am not able to easily pinpoint where this happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5666) Serializer goes into infinite loop
[
https://issues.apache.org/jira/browse/FELIX-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112648#comment-16112648
]
David Bosschaert commented on FELIX-5666:
-
Ah yes, exactly. The sourceAsDTO() is context information to the converter in
relation to the provided object. It has no connection to the Json Serializer
and it's also not stored in the converter. So when the serializer is called
that information is simply not there any more.
I guess it might make sense to add things like sourceAsDTO() and others to the
serializer? It might even inherit the Specifying.java interface from the
Converter ([see
here|https://oss.sonatype.org/content/repositories/osgi/org/osgi/org.osgi.util.converter/1.0.0-SNAPSHOT/org.osgi.util.converter-1.0.0-20170803.091235-72-sources.jar])...
WDYT about adding something like this to the serializer?
> Serializer goes into infinite loop
> --
>
> Key: FELIX-5666
> URL: https://issues.apache.org/jira/browse/FELIX-5666
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> I'm only guessing as to what the problem is, following some stepping through
> the code. I could not find any similar existing test cases, but if the
> following does not immediately click for [~bosschaert], I will try to add one.
> It appears that, when serializing an object to a "DTO-Type" object to a Map,
> some kind of backing object is created.
> If the backing object contains a field that instantiates the same DTO, then
> the loop gets created.
> Example:
> {code}
> public class MyDtoType {
> public String id;
> public MyDtoType( String anID ) {
> id = anID;
> }
> public static MyDtoType error() {
> return new MyDtoType( "ERROR" );
> }
> }
> {code}
> It looks like the serializer keeps calling the error() method infinitely, but
> I am not able to easily pinpoint where this happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (FELIX-5666) Serializer goes into infinite loop
[
https://issues.apache.org/jira/browse/FELIX-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5666:
---
Assignee: (was: David Bosschaert)
> Serializer goes into infinite loop
> --
>
> Key: FELIX-5666
> URL: https://issues.apache.org/jira/browse/FELIX-5666
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>
> I'm only guessing as to what the problem is, following some stepping through
> the code. I could not find any similar existing test cases, but if the
> following does not immediately click for [~bosschaert], I will try to add one.
> It appears that, when serializing an object to a "DTO-Type" object to a Map,
> some kind of backing object is created.
> If the backing object contains a field that instantiates the same DTO, then
> the loop gets created.
> Example:
> {code}
> public class MyDtoType {
> public String id;
> public MyDtoType( String anID ) {
> id = anID;
> }
> public static MyDtoType error() {
> return new MyDtoType( "ERROR" );
> }
> }
> {code}
> It looks like the serializer keeps calling the error() method infinitely, but
> I am not able to easily pinpoint where this happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5666) Serializer goes into infinite loop
[
https://issues.apache.org/jira/browse/FELIX-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16112684#comment-16112684
]
David Bosschaert commented on FELIX-5666:
-
Yeah, it would be great if you can think this through, you might even have some
time to prototype or even implement this? Using this to configure the backing
converter sounds like a good idea to me.
BTW the dependency Serializer API -> Converter API is already there.
Serializing.with() and Deserializing.with() already have a Converter as
argument...
> Serializer goes into infinite loop
> --
>
> Key: FELIX-5666
> URL: https://issues.apache.org/jira/browse/FELIX-5666
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> I'm only guessing as to what the problem is, following some stepping through
> the code. I could not find any similar existing test cases, but if the
> following does not immediately click for [~bosschaert], I will try to add one.
> It appears that, when serializing an object to a "DTO-Type" object to a Map,
> some kind of backing object is created.
> If the backing object contains a field that instantiates the same DTO, then
> the loop gets created.
> Example:
> {code}
> public class MyDtoType {
> public String id;
> public MyDtoType( String anID ) {
> id = anID;
> }
> public static MyDtoType error() {
> return new MyDtoType( "ERROR" );
> }
> }
> {code}
> It looks like the serializer keeps calling the error() method infinitely, but
> I am not able to easily pinpoint where this happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (FELIX-5672) Cannot launch Felix on Raspberry Pi: problem with normalizeOSVersion()
David Bosschaert created FELIX-5672:
---
Summary: Cannot launch Felix on Raspberry Pi: problem with
normalizeOSVersion()
Key: FELIX-5672
URL: https://issues.apache.org/jira/browse/FELIX-5672
Project: Felix
Issue Type: Bug
Components: Framework
Affects Versions: framework-5.6.6
Environment: java version "1.8.0_65"
Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
Reporter: David Bosschaert
Launching the Felix Framework on the Raspberry Pi fails with the following
error:
{code}
java -jar bin/felix.jar
Could not create framework: java.lang.IllegalArgumentException: invalid version
"4.9.35.": invalid format
java.lang.IllegalArgumentException: invalid version "4.9.35.": invalid format
at org.osgi.framework.Version.(Version.java:147)
at
org.apache.felix.framework.util.manifestparser.NativeLibraryClause.normalizeOSVersion(NativeLibraryClause.java:770)
at
org.apache.felix.framework.Felix.initializeFrameworkProperties(Felix.java:4617)
at org.apache.felix.framework.Felix.(Felix.java:384)
at
org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
at org.apache.felix.main.Main.main(Main.java:287)
Caused by: java.util.NoSuchElementException
at java.util.StringTokenizer.nextToken(StringTokenizer.java:349)
at java.util.StringTokenizer.nextToken(StringTokenizer.java:377)
at org.osgi.framework.Version.(Version.java:138)
... 5 more
{code}
Seems that the normalizeOSVersion() function can't handle the Pi OS version
number which is reported as:
{code}
uname -a
Linux mypi 4.9.35+ #1014 Fri Jun 30 14:34:49 BST 2017 armv6l GNU/Linux
{code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Assigned] (FELIX-5672) Cannot launch Felix on Raspberry Pi: problem with normalizeOSVersion()
[
https://issues.apache.org/jira/browse/FELIX-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5672:
---
Assignee: David Bosschaert
> Cannot launch Felix on Raspberry Pi: problem with normalizeOSVersion()
> --
>
> Key: FELIX-5672
> URL: https://issues.apache.org/jira/browse/FELIX-5672
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.6.6
> Environment: java version "1.8.0_65"
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
>Reporter: David Bosschaert
>Assignee: David Bosschaert
>
> Launching the Felix Framework on the Raspberry Pi fails with the following
> error:
> {code}
> java -jar bin/felix.jar
> Could not create framework: java.lang.IllegalArgumentException: invalid
> version "4.9.35.": invalid format
> java.lang.IllegalArgumentException: invalid version "4.9.35.": invalid format
> at org.osgi.framework.Version.(Version.java:147)
> at
> org.apache.felix.framework.util.manifestparser.NativeLibraryClause.normalizeOSVersion(NativeLibraryClause.java:770)
> at
> org.apache.felix.framework.Felix.initializeFrameworkProperties(Felix.java:4617)
> at org.apache.felix.framework.Felix.(Felix.java:384)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
> at org.apache.felix.main.Main.main(Main.java:287)
> Caused by: java.util.NoSuchElementException
> at java.util.StringTokenizer.nextToken(StringTokenizer.java:349)
> at java.util.StringTokenizer.nextToken(StringTokenizer.java:377)
> at org.osgi.framework.Version.(Version.java:138)
> ... 5 more
> {code}
> Seems that the normalizeOSVersion() function can't handle the Pi OS version
> number which is reported as:
> {code}
> uname -a
> Linux mypi 4.9.35+ #1014 Fri Jun 30 14:34:49 BST 2017 armv6l GNU/Linux
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Updated] (FELIX-5672) Cannot launch Felix on Raspberry Pi: problem with normalizeOSVersion()
[
https://issues.apache.org/jira/browse/FELIX-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert updated FELIX-5672:
Fix Version/s: framework-5.6.8
> Cannot launch Felix on Raspberry Pi: problem with normalizeOSVersion()
> --
>
> Key: FELIX-5672
> URL: https://issues.apache.org/jira/browse/FELIX-5672
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.6.6
> Environment: java version "1.8.0_65"
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-5.6.8
>
>
> Launching the Felix Framework on the Raspberry Pi fails with the following
> error:
> {code}
> java -jar bin/felix.jar
> Could not create framework: java.lang.IllegalArgumentException: invalid
> version "4.9.35.": invalid format
> java.lang.IllegalArgumentException: invalid version "4.9.35.": invalid format
> at org.osgi.framework.Version.(Version.java:147)
> at
> org.apache.felix.framework.util.manifestparser.NativeLibraryClause.normalizeOSVersion(NativeLibraryClause.java:770)
> at
> org.apache.felix.framework.Felix.initializeFrameworkProperties(Felix.java:4617)
> at org.apache.felix.framework.Felix.(Felix.java:384)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
> at org.apache.felix.main.Main.main(Main.java:287)
> Caused by: java.util.NoSuchElementException
> at java.util.StringTokenizer.nextToken(StringTokenizer.java:349)
> at java.util.StringTokenizer.nextToken(StringTokenizer.java:377)
> at org.osgi.framework.Version.(Version.java:138)
> ... 5 more
> {code}
> Seems that the normalizeOSVersion() function can't handle the Pi OS version
> number which is reported as:
> {code}
> uname -a
> Linux mypi 4.9.35+ #1014 Fri Jun 30 14:34:49 BST 2017 armv6l GNU/Linux
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Resolved] (FELIX-5672) Cannot launch Felix on Raspberry Pi: problem with normalizeOSVersion()
[
https://issues.apache.org/jira/browse/FELIX-5672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert resolved FELIX-5672.
-
Resolution: Fixed
Fixed in https://svn.apache.org/viewvc?view=revision&revision=1804043
> Cannot launch Felix on Raspberry Pi: problem with normalizeOSVersion()
> --
>
> Key: FELIX-5672
> URL: https://issues.apache.org/jira/browse/FELIX-5672
> Project: Felix
> Issue Type: Bug
> Components: Framework
>Affects Versions: framework-5.6.6
> Environment: java version "1.8.0_65"
> Java(TM) SE Runtime Environment (build 1.8.0_65-b17)
> Java HotSpot(TM) Client VM (build 25.65-b01, mixed mode)
>Reporter: David Bosschaert
>Assignee: David Bosschaert
> Fix For: framework-5.6.8
>
>
> Launching the Felix Framework on the Raspberry Pi fails with the following
> error:
> {code}
> java -jar bin/felix.jar
> Could not create framework: java.lang.IllegalArgumentException: invalid
> version "4.9.35.": invalid format
> java.lang.IllegalArgumentException: invalid version "4.9.35.": invalid format
> at org.osgi.framework.Version.(Version.java:147)
> at
> org.apache.felix.framework.util.manifestparser.NativeLibraryClause.normalizeOSVersion(NativeLibraryClause.java:770)
> at
> org.apache.felix.framework.Felix.initializeFrameworkProperties(Felix.java:4617)
> at org.apache.felix.framework.Felix.(Felix.java:384)
> at
> org.apache.felix.framework.FrameworkFactory.newFramework(FrameworkFactory.java:28)
> at org.apache.felix.main.Main.main(Main.java:287)
> Caused by: java.util.NoSuchElementException
> at java.util.StringTokenizer.nextToken(StringTokenizer.java:349)
> at java.util.StringTokenizer.nextToken(StringTokenizer.java:377)
> at org.osgi.framework.Version.(Version.java:138)
> ... 5 more
> {code}
> Seems that the normalizeOSVersion() function can't handle the Pi OS version
> number which is reported as:
> {code}
> uname -a
> Linux mypi 4.9.35+ #1014 Fri Jun 30 14:34:49 BST 2017 armv6l GNU/Linux
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5670) Facade caching for optimisation
[ https://issues.apache.org/jira/browse/FELIX-5670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16114233#comment-16114233 ] David Bosschaert commented on FELIX-5670: - Hi [~dleangen] thanks for the observation, but I have to admit that the bug description is a little bit vague. What areas do you think would benefit from caching? Also before we actually implement such a cache, which might make the implementation larger/more complex, we should ensure that it's really needed. The Java HotSpot sometimes optimizes things out so that manually implemented optimizations become moot... > Facade caching for optimisation > --- > > Key: FELIX-5670 > URL: https://issues.apache.org/jira/browse/FELIX-5670 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Priority: Minor > > When stepping through the code, I noticed that the same blocks were being > called repeatedly. > A little bit of investigation would be good, but I believe that having a > cache for some of the values could provide an opportunity to optimize. > Probably a bit premature for this version, though, so maybe something to get > back to a little later. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Assigned] (FELIX-5666) Serializer goes into infinite loop
[
https://issues.apache.org/jira/browse/FELIX-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Bosschaert reassigned FELIX-5666:
---
Assignee: David Leangen
> Serializer goes into infinite loop
> --
>
> Key: FELIX-5666
> URL: https://issues.apache.org/jira/browse/FELIX-5666
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>Assignee: David Leangen
>
> I'm only guessing as to what the problem is, following some stepping through
> the code. I could not find any similar existing test cases, but if the
> following does not immediately click for [~bosschaert], I will try to add one.
> It appears that, when serializing an object to a "DTO-Type" object to a Map,
> some kind of backing object is created.
> If the backing object contains a field that instantiates the same DTO, then
> the loop gets created.
> Example:
> {code}
> public class MyDtoType {
> public String id;
> public MyDtoType( String anID ) {
> id = anID;
> }
> public static MyDtoType error() {
> return new MyDtoType( "ERROR" );
> }
> }
> {code}
> It looks like the serializer keeps calling the error() method infinitely, but
> I am not able to easily pinpoint where this happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5666) Serializer goes into infinite loop
[
https://issues.apache.org/jira/browse/FELIX-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16118004#comment-16118004
]
David Bosschaert commented on FELIX-5666:
-
Hi [~dleangen] - sounds great! I've assigned the issue to you - hope that makes
sense?
And I guess it can be closed as fixed? Or is there anything still to be done?
> Serializer goes into infinite loop
> --
>
> Key: FELIX-5666
> URL: https://issues.apache.org/jira/browse/FELIX-5666
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>Assignee: David Leangen
>
> I'm only guessing as to what the problem is, following some stepping through
> the code. I could not find any similar existing test cases, but if the
> following does not immediately click for [~bosschaert], I will try to add one.
> It appears that, when serializing an object to a "DTO-Type" object to a Map,
> some kind of backing object is created.
> If the backing object contains a field that instantiates the same DTO, then
> the loop gets created.
> Example:
> {code}
> public class MyDtoType {
> public String id;
> public MyDtoType( String anID ) {
> id = anID;
> }
> public static MyDtoType error() {
> return new MyDtoType( "ERROR" );
> }
> }
> {code}
> It looks like the serializer keeps calling the error() method infinitely, but
> I am not able to easily pinpoint where this happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5666) Serializer goes into infinite loop
[
https://issues.apache.org/jira/browse/FELIX-5666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128934#comment-16128934
]
David Bosschaert commented on FELIX-5666:
-
Hi [~dleangen], only seeing this question now. No I don't really know of such a
tool. You might have to create something like that for the purpose of the
test...
> Serializer goes into infinite loop
> --
>
> Key: FELIX-5666
> URL: https://issues.apache.org/jira/browse/FELIX-5666
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>Assignee: David Leangen
>
> I'm only guessing as to what the problem is, following some stepping through
> the code. I could not find any similar existing test cases, but if the
> following does not immediately click for [~bosschaert], I will try to add one.
> It appears that, when serializing an object to a "DTO-Type" object to a Map,
> some kind of backing object is created.
> If the backing object contains a field that instantiates the same DTO, then
> the loop gets created.
> Example:
> {code}
> public class MyDtoType {
> public String id;
> public MyDtoType( String anID ) {
> id = anID;
> }
> public static MyDtoType error() {
> return new MyDtoType( "ERROR" );
> }
> }
> {code}
> It looks like the serializer keeps calling the error() method infinitely, but
> I am not able to easily pinpoint where this happens.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5678) Allow merging of objects
[
https://issues.apache.org/jira/browse/FELIX-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16128952#comment-16128952
]
David Bosschaert commented on FELIX-5678:
-
Hi [~dleangen], so you really want to convert two objects into one :)
While the converter API isn't really designed for this, you could achieve it
with a custom rule, where the rule is specifically created for this conversion
with the second object as context provided to the rule, i.e.
{code}
Foo f = ...;
ConverterBuilder builder = converter.newConverterBuilder();
builder.rule(new TypeRule<>(Map.class, Foo.class, {v -> merge(f, v)});
Converter c = builder.build();
Foo f2 = c.convert(m).to(Foo.class); // f is already passed to the rule
{code}
Maybe not the most elegant, but it might work?
> Allow merging of objects
>
>
> Key: FELIX-5678
> URL: https://issues.apache.org/jira/browse/FELIX-5678
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>
> Given a typed object O1 and a "partial" representation of an object O2 (for
> instance in the form of a Map), allow O2 to be merged into O1.
> Example:
> {code}
> public class Foo {
> public String a;
> public String b;
> public String c;
> }
> Foo f = new Foo();
> a = "Eh!";
> b = "Be cool.";
> c = "See you later?";
> Map m = new Map<>();
> m.put("b", "Be there or be square");
> Foo f2 = Converter.convert(f).merge(m);
> {code}
> I am sure there are many ways to skin this cat.
> If the Converter API cannot be changed, what would be the best way to tackle
> this problem?
> (In the meantime, while awaiting comments form [~bosschaert], I'll try to run
> a few experiments to see if I can come up with something reasonable.)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (FELIX-5412) Pretty format not implemented in JSON serializer
[ https://issues.apache.org/jira/browse/FELIX-5412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16141468#comment-16141468 ] David Bosschaert commented on FELIX-5412: - Thanks [~dleangen], I left some comments on the PR. Cheers, David > Pretty format not implemented in JSON serializer > > > Key: FELIX-5412 > URL: https://issues.apache.org/jira/browse/FELIX-5412 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen >Assignee: David Leangen > > There is a configuration for "pretty" formatting, but it has not yet been > implemented. -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Commented] (FELIX-5678) Allow merging of objects
[
https://issues.apache.org/jira/browse/FELIX-5678?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16172958#comment-16172958
]
David Bosschaert commented on FELIX-5678:
-
bq. IIUC the API is no longer open for comments, correct? So either we'd have
to go about it this way, or build an extra layer on top of the Converter. Or,
maybe this is something all together different.
Yes, the OSGi Converter API for the R7 release is pretty much locked down now,
but we can still work on enhancements and improvements for R8...
> Allow merging of objects
>
>
> Key: FELIX-5678
> URL: https://issues.apache.org/jira/browse/FELIX-5678
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>
> Given a typed object O1 and a "partial" representation of an object O2 (for
> instance in the form of a Map), allow O2 to be merged into O1.
> Example:
> {code}
> public class Foo {
> public String a;
> public String b;
> public String c;
> }
> Foo f = new Foo();
> a = "Eh!";
> b = "Be cool.";
> c = "See you later?";
> Map m = new Map<>();
> m.put("b", "Be there or be square");
> Foo f2 = Converter.convert(f).merge(m);
> {code}
> I am sure there are many ways to skin this cat.
> If the Converter API cannot be changed, what would be the best way to tackle
> this problem?
> (In the meantime, while awaiting comments form [~bosschaert], I'll try to run
> a few experiments to see if I can come up with something reasonable.)
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Created] (FELIX-5838) Add OSGi Resource implementations to Felix Utils
David Bosschaert created FELIX-5838: --- Summary: Add OSGi Resource implementations to Felix Utils Key: FELIX-5838 URL: https://issues.apache.org/jira/browse/FELIX-5838 Project: Felix Issue Type: Improvement Reporter: David Bosschaert Across a number of OSGi-related Apache Projects OSGi Capabilities, Requirements and Resources are implemented. It would be good to provide one in Apache Felix Utils that can be shared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (FELIX-5838) Add OSGi Resource implementations to Felix Utils
[ https://issues.apache.org/jira/browse/FELIX-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-5838: --- Assignee: David Bosschaert > Add OSGi Resource implementations to Felix Utils > > > Key: FELIX-5838 > URL: https://issues.apache.org/jira/browse/FELIX-5838 > Project: Felix > Issue Type: Improvement >Affects Versions: utils-1.10.2 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > Across a number of OSGi-related Apache Projects OSGi Capabilities, > Requirements and Resources are implemented. It would be good to provide one > in Apache Felix Utils that can be shared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5838) Add OSGi Resource implementations to Felix Utils
[ https://issues.apache.org/jira/browse/FELIX-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-5838: Affects Version/s: utils-1.10.2 > Add OSGi Resource implementations to Felix Utils > > > Key: FELIX-5838 > URL: https://issues.apache.org/jira/browse/FELIX-5838 > Project: Felix > Issue Type: Improvement >Affects Versions: utils-1.10.2 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > Across a number of OSGi-related Apache Projects OSGi Capabilities, > Requirements and Resources are implemented. It would be good to provide one > in Apache Felix Utils that can be shared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Work started] (FELIX-5838) Add OSGi Resource implementations to Felix Utils
[ https://issues.apache.org/jira/browse/FELIX-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on FELIX-5838 started by David Bosschaert. --- > Add OSGi Resource implementations to Felix Utils > > > Key: FELIX-5838 > URL: https://issues.apache.org/jira/browse/FELIX-5838 > Project: Felix > Issue Type: Improvement >Affects Versions: utils-1.10.2 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > Across a number of OSGi-related Apache Projects OSGi Capabilities, > Requirements and Resources are implemented. It would be good to provide one > in Apache Felix Utils that can be shared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (FELIX-5838) Add OSGi Resource implementations to Felix Utils
[ https://issues.apache.org/jira/browse/FELIX-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert reassigned FELIX-5838: --- Assignee: Guillaume Nodet (was: David Bosschaert) > Add OSGi Resource implementations to Felix Utils > > > Key: FELIX-5838 > URL: https://issues.apache.org/jira/browse/FELIX-5838 > Project: Felix > Issue Type: Improvement >Affects Versions: utils-1.10.2 >Reporter: David Bosschaert >Assignee: Guillaume Nodet >Priority: Major > > Across a number of OSGi-related Apache Projects OSGi Capabilities, > Requirements and Resources are implemented. It would be good to provide one > in Apache Felix Utils that can be shared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5838) Add OSGi Resource implementations to Felix Utils
[ https://issues.apache.org/jira/browse/FELIX-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16449503#comment-16449503 ] David Bosschaert commented on FELIX-5838: - I have added the Requirement and Capability implementations and am now done with this. [~gnt] I see that you have also added and expanded the code. I'm assigning this issue to you now so that you can close it when you're done. > Add OSGi Resource implementations to Felix Utils > > > Key: FELIX-5838 > URL: https://issues.apache.org/jira/browse/FELIX-5838 > Project: Felix > Issue Type: Improvement >Affects Versions: utils-1.10.2 >Reporter: David Bosschaert >Assignee: David Bosschaert >Priority: Major > > Across a number of OSGi-related Apache Projects OSGi Capabilities, > Requirements and Resources are implemented. It would be good to provide one > in Apache Felix Utils that can be shared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5838) Add OSGi Resource implementations to Felix Utils
[ https://issues.apache.org/jira/browse/FELIX-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-5838: Fix Version/s: utils-1.11.0 > Add OSGi Resource implementations to Felix Utils > > > Key: FELIX-5838 > URL: https://issues.apache.org/jira/browse/FELIX-5838 > Project: Felix > Issue Type: Improvement >Affects Versions: utils-1.10.2 >Reporter: David Bosschaert >Assignee: Guillaume Nodet >Priority: Major > Fix For: utils-1.11.0 > > > Across a number of OSGi-related Apache Projects OSGi Capabilities, > Requirements and Resources are implemented. It would be good to provide one > in Apache Felix Utils that can be shared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (FELIX-5838) Add OSGi Resource implementations to Felix Utils
[ https://issues.apache.org/jira/browse/FELIX-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert resolved FELIX-5838. - Resolution: Fixed As work seems to have stopped in this area I'm marking this issue as resolved. > Add OSGi Resource implementations to Felix Utils > > > Key: FELIX-5838 > URL: https://issues.apache.org/jira/browse/FELIX-5838 > Project: Felix > Issue Type: Improvement >Affects Versions: utils-1.10.2 >Reporter: David Bosschaert >Assignee: Guillaume Nodet >Priority: Major > Fix For: utils-1.11.0 > > > Across a number of OSGi-related Apache Projects OSGi Capabilities, > Requirements and Resources are implemented. It would be good to provide one > in Apache Felix Utils that can be shared. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (FELIX-5839) Add xml and json repositories implemenation
[ https://issues.apache.org/jira/browse/FELIX-5839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Bosschaert updated FELIX-5839: Fix Version/s: (was: utils-1.10.4) utils-1.11.0 > Add xml and json repositories implemenation > --- > > Key: FELIX-5839 > URL: https://issues.apache.org/jira/browse/FELIX-5839 > Project: Felix > Issue Type: New Feature >Reporter: Guillaume Nodet >Assignee: Guillaume Nodet >Priority: Major > Fix For: utils-1.11.0 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (FELIX-5909) [Converter] Version number contains timestamp
[ https://issues.apache.org/jira/browse/FELIX-5909?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16610398#comment-16610398 ] David Bosschaert commented on FELIX-5909: - Hi [~dleangen] - I'm not seeing that qualifier: http://repo1.maven.org/maven2/org/apache/felix/org.apache.felix.converter/1.0.0/ Where exactly do you see it? > [Converter] Version number contains timestamp > - > > Key: FELIX-5909 > URL: https://issues.apache.org/jira/browse/FELIX-5909 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert >Priority: Major > > Hi [~bosschaert], > The maven release of Converter has the version number "1.0.0.201802012108". > It is my understanding that a release should be "1.0.0" without the timestamp. > My Nexus repository thinks that this is a Snapshot because it includes the > timestamp. > Would it be possible to do a release with only "1.0.0"? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
