[jira] [Created] (FELIX-5325) Patch for embedded DTO (in DTO)
David Leangen created FELIX-5325: Summary: Patch for embedded DTO (in DTO) Key: FELIX-5325 URL: https://issues.apache.org/jira/browse/FELIX-5325 Project: Felix Issue Type: Improvement Components: Converter Reporter: David Leangen Priority: Minor This patch adds support for converting a DTO that contains an embedded DTO. It uses recursive calls to Converter.convert() to accomplish this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5325) Patch for embedded DTO (in DTO)
[
https://issues.apache.org/jira/browse/FELIX-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420938#comment-15420938
]
David Leangen commented on FELIX-5325:
--
Index: src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java
===
--- src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java
(revision 1756057)
+++ src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java
(working copy)
@@ -222,7 +222,7 @@
@SuppressWarnings({ "rawtypes", "unchecked" })
private T convertToDTO(Class targetCls) {
-Map m = mapView(object);
+Map m = mapView(object, converter);
try {
T dto = targetCls.newInstance();
@@ -230,7 +230,11 @@
for (Map.Entry entry : (Set) m.entrySet()) {
try {
Field f = targetCls.getField(entry.getKey().toString());
-f.set(dto, entry.getValue());
+Object fVal = entry.getValue();
+if(DTO.class.isAssignableFrom( f.getType()))
+fVal = converter.convert(fVal).to(f.getType());
+// TODO convert other embedded objects that require
conversion
+f.set(dto, fVal);
} catch (NoSuchFieldException e) {
}
}
@@ -243,7 +247,7 @@
@SuppressWarnings({ "rawtypes", "unchecked" })
private Map convertToMap(Class targetCls, Type[] typeArguments) {
-Map m = mapView(object);
+Map m = mapView(object, converter);
if (m == null)
return null;
Class targetKeyType = null, targetValueType = null;
@@ -287,7 +291,7 @@
private Object createJavaBean(Class targetCls) {
@SuppressWarnings("rawtypes")
-Map m = mapView(object);
+Map m = mapView(object, converter);
try {
Object res = targetCls.getConstructor().newInstance();
for (Method setter : getSetters(targetCls)) {
@@ -308,7 +312,7 @@
@SuppressWarnings("rawtypes")
private Object createProxy(Class targetCls) {
-Map m = mapView(object);
+Map m = mapView(object, converter);
return Proxy.newProxyInstance(targetCls.getClassLoader(), new Class[]
{targetCls},
new InvocationHandler() {
@Override
@@ -476,7 +480,7 @@
}
@SuppressWarnings({ "rawtypes", "unchecked" })
-private static Map createMapFromDTO(Object obj) {
+private static Map createMapFromDTO(Object obj, Converter converter) {
Map result = new HashMap();
for (Field f : obj.getClass().getFields()) {
@@ -484,7 +488,11 @@
continue;
try {
-result.put(f.getName(), f.get(obj)); // TODO handle escaping
+Object fVal = f.get(obj);
+if(fVal instanceof DTO)
+fVal = converter.convert(fVal).to(Map.class);
+// TODO test for other embedded types that need conversion
+result.put(f.getName(), fVal);
} catch (Exception e) {
}
}
@@ -607,13 +615,13 @@
}
}
-private static Map mapView(Object obj) {
+private static Map mapView(Object obj, Converter converter) {
if (obj instanceof Map)
return (Map) obj;
else if (obj instanceof Dictionary)
return null; // TODO
else if (obj instanceof DTO)
-return createMapFromDTO(obj);
+return createMapFromDTO(obj, converter);
else if (obj.getClass().getInterfaces().length > 0)
return createMapFromInterface(obj);
else
Index: src/test/java/org/apache/felix/converter/impl/ConverterServiceTest.java
===
--- src/test/java/org/apache/felix/converter/impl/ConverterServiceTest.java
(revision 1756057)
+++ src/test/java/org/apache/felix/converter/impl/ConverterServiceTest.java
(working copy)
@@ -40,6 +40,8 @@
import java.util.stream.Collectors;
import java.util.stream.Stream;
+import org.apache.felix.converter.impl.MyDTO.Count;
+import org.apache.felix.converter.impl.MyEmbeddedDTO.Alpha;
import org.junit.After;
import org.junit.Before;
import org.junit.Test;
@@ -50,6 +52,7 @@
import static org.junit.Assert.assertArrayEquals;
import static org.junit.Assert.assertEquals;
import static org.junit.Assert.assertFalse;
+import static org.junit.Assert.assertNotNull;
import static org.junit.Assert.assertNotSame;
import static org.junit.Assert.assertNull;
import static org.junit.Assert.assertSame;
@@ -388,15 +391,29 @@
@Test
public void testDTO2Map() {
+MyEmbeddedDTO embedded = new MyEmbeddedDTO();
+embedded.marco = "hohoho";
+embedded.polo = Long.MAX_VALUE;
[jira] [Commented] (FELIX-5325) Patch for embedded DTO (in DTO)
[ https://issues.apache.org/jira/browse/FELIX-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420937#comment-15420937 ] David Leangen commented on FELIX-5325: -- I cannot attach files, so I will paste it in a comment. > Patch for embedded DTO (in DTO) > --- > > Key: FELIX-5325 > URL: https://issues.apache.org/jira/browse/FELIX-5325 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Priority: Minor > > This patch adds support for converting a DTO that contains an embedded DTO. > It uses recursive calls to Converter.convert() to accomplish this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5325) Patch for embedded DTO (in DTO)
[ https://issues.apache.org/jira/browse/FELIX-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15421859#comment-15421859 ] David Leangen commented on FELIX-5325: -- Sent offline. Cheers. > Patch for embedded DTO (in DTO) > --- > > Key: FELIX-5325 > URL: https://issues.apache.org/jira/browse/FELIX-5325 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert >Priority: Minor > > This patch adds support for converting a DTO that contains an embedded DTO. > It uses recursive calls to Converter.convert() to accomplish this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5325) Patch for embedded DTO (in DTO)
[ https://issues.apache.org/jira/browse/FELIX-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5325: - Attachment: patch.diff Ah! I have to go to the menu. This is different from our internal JIRA, so I missed it. > Patch for embedded DTO (in DTO) > --- > > Key: FELIX-5325 > URL: https://issues.apache.org/jira/browse/FELIX-5325 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert >Priority: Minor > Attachments: patch.diff > > > This patch adds support for converting a DTO that contains an embedded DTO. > It uses recursive calls to Converter.convert() to accomplish this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5325) Patch for embedded DTO (in DTO)
[ https://issues.apache.org/jira/browse/FELIX-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5325: - Attachment: (was: patch.diff) > Patch for embedded DTO (in DTO) > --- > > Key: FELIX-5325 > URL: https://issues.apache.org/jira/browse/FELIX-5325 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert >Priority: Minor > > This patch adds support for converting a DTO that contains an embedded DTO. > It uses recursive calls to Converter.convert() to accomplish this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5325) Patch for embedded DTO (in DTO)
[ https://issues.apache.org/jira/browse/FELIX-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5325: - Attachment: patch.diff > Patch for embedded DTO (in DTO) > --- > > Key: FELIX-5325 > URL: https://issues.apache.org/jira/browse/FELIX-5325 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert >Priority: Minor > Attachments: patch.diff > > > This patch adds support for converting a DTO that contains an embedded DTO. > It uses recursive calls to Converter.convert() to accomplish this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5325) Patch for embedded DTO (in DTO)
[ https://issues.apache.org/jira/browse/FELIX-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15422642#comment-15422642 ] David Leangen commented on FELIX-5325: -- Hi [~bosschaert], sorry about that! It is there now. (I replaced the old file with the new one.) > Patch for embedded DTO (in DTO) > --- > > Key: FELIX-5325 > URL: https://issues.apache.org/jira/browse/FELIX-5325 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert >Priority: Minor > Attachments: patch.diff > > > This patch adds support for converting a DTO that contains an embedded DTO. > It uses recursive calls to Converter.convert() to accomplish this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5325) Patch for embedded DTO (in DTO)
[ https://issues.apache.org/jira/browse/FELIX-5325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15424288#comment-15424288 ] David Leangen commented on FELIX-5325: -- Awesome. Thank you! :-) > Patch for embedded DTO (in DTO) > --- > > Key: FELIX-5325 > URL: https://issues.apache.org/jira/browse/FELIX-5325 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert >Priority: Minor > Attachments: patch.diff > > > This patch adds support for converting a DTO that contains an embedded DTO. > It uses recursive calls to Converter.convert() to accomplish this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5326) Add data structure descriptor
David Leangen created FELIX-5326: Summary: Add data structure descriptor Key: FELIX-5326 URL: https://issues.apache.org/jira/browse/FELIX-5326 Project: Felix Issue Type: New Feature Components: Converter Reporter: David Leangen The Converter service does a lot of introspection and parsing of the DTO data structure. In many cases, a DTO is a very simple object structure. However, it can also be a very complex structure, too. According to my understanding of the objectives of the Converter, one important goal is to be able to persist data. The idea is that the DTO describes the data structure. Thus, it is the ideal way to ship the state of the system off to PersistenceLand. If we do buy into this vision, then we may be missing out on a few great opportunities here. When data gets persisted, we often need to understand the relationships between the embedded objects. Or, we may want to be able to create an index on the data. These are a few of the reasons why we would want to have some kind of x-ray vision on the data structure. Since we already go through all the trouble of parsing the data structure in order to convert it, and since this is ~95% of the work, it would be really nice to provide access to this information in order to easily link in services that require this intimate knowledge. Otherwise, all the parsing would have to be done over and over again for each service. I believe that it would only take a few methods to be able to leverage all the parsing work done by the Converter. I can think of: DataTree Converter.toTree(DTO dto); // DataTre gives a tree view of the structure Object tree.valueAt(DTO dto, String path); // Dot-separated path value within the tree structure void tree.set(DTO dto, String path, Object value); // Set the value at the given location in the tree structure void process(DTO dto, Consumer function); // Visit each node for some kind of processing Those are just some examples. Perhaps a new API would be necessary, but my main point here is that since we are going through all this work of implementing a parser, this is the IDEAL time to create this type of view on the data. Also, one of the properties of DTOs is that the DTOs are really, in a way, nothing more than schema. Because of this, it should be (and is) trivial to convert to JSON, XML, YAML, or whatever. If the DTO *is* the data structure, then it should also be trivial to convert the type descriptor (or tree, or whatever) to some kind of schema, like JSON Schema, DTD, XML Schema, RDF… That fits well with one of the features of the Converter: codecs to convert to/from serialized types. RFC 215 defines two portable codecs: JSON and YAML but other implementations can add their own codecs too. We could do the same not just for the live data instance, but for the data schema as well. (Note that this schema generation is not required: we could decide only to implement the data tree structure, and have an outside process generate the scheme, but at least the data tree would enable this). I do understand that it is a step away from a simple “Converter”, but the parsing is essentially the same. Since the hard work is already being done, why not take advantage of it here? Even if this tree view ends up being a completely different service, the same code base could easily serve the two. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5326) Add data structure descriptor
[
https://issues.apache.org/jira/browse/FELIX-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15427695#comment-15427695
]
David Leangen commented on FELIX-5326:
--
Neat!
What is still missing would be:
{code:java}
m.typeOf("embedded");
{code}
This would return some kind of descriptor object (maybe a `java.lang.reflect`
object, maybe something else). This descriptor would allow the client to
retrieve annotations and other useful information about that node. The
annotations should probably be out of scope, but at least this will enable easy
access.
The only other missing thing would be the tree structure. Since we already
parse it, would be useful to share the structure (children(), parent(),
siblings() etc.)
As you say, and I agree, the DTO does indeed represent the schema. Would
therefore be very cool to be able to print [something like
this|http://json-schema.org/].
> Add data structure descriptor
> -
>
> Key: FELIX-5326
> URL: https://issues.apache.org/jira/browse/FELIX-5326
> Project: Felix
> Issue Type: New Feature
> Components: Converter
>Reporter: David Leangen
>
> The Converter service does a lot of introspection and parsing of the DTO data
> structure. In many cases, a DTO is a very simple object structure. However,
> it can also be a very complex structure, too.
> According to my understanding of the objectives of the Converter, one
> important goal is to be able to persist data. The idea is that the DTO
> describes the data structure. Thus, it is the ideal way to ship the state of
> the system off to PersistenceLand.
> If we do buy into this vision, then we may be missing out on a few great
> opportunities here. When data gets persisted, we often need to understand the
> relationships between the embedded objects. Or, we may want to be able to
> create an index on the data. These are a few of the reasons why we would want
> to have some kind of x-ray vision on the data structure. Since we already go
> through all the trouble of parsing the data structure in order to convert it,
> and since this is ~95% of the work, it would be really nice to provide access
> to this information in order to easily link in services that require this
> intimate knowledge. Otherwise, all the parsing would have to be done over and
> over again for each service.
> I believe that it would only take a few methods to be able to leverage all
> the parsing work done by the Converter. I can think of:
> DataTree Converter.toTree(DTO dto); // DataTre gives a tree view of the
> structure
> Object tree.valueAt(DTO dto, String path); // Dot-separated path value
> within the tree structure
> void tree.set(DTO dto, String path, Object value); // Set the value at the
> given location in the tree structure
> void process(DTO dto, Consumer function); // Visit each node for some
> kind of processing
> Those are just some examples. Perhaps a new API would be necessary, but my
> main point here is that since we are going through all this work of
> implementing a parser, this is the IDEAL time to create this type of view on
> the data.
> Also, one of the properties of DTOs is that the DTOs are really, in a way,
> nothing more than schema. Because of this, it should be (and is) trivial to
> convert to JSON, XML, YAML, or whatever. If the DTO *is* the data structure,
> then it should also be trivial to convert the type descriptor (or tree, or
> whatever) to some kind of schema, like JSON Schema, DTD, XML Schema, RDF…
> That fits well with one of the features of the Converter: codecs to convert
> to/from serialized types. RFC 215 defines two portable codecs: JSON and
> YAML but other implementations can add their own codecs too. We could do the
> same not just for the live data instance, but for the data schema as well.
> (Note that this schema generation is not required: we could decide only to
> implement the data tree structure, and have an outside process generate the
> scheme, but at least the data tree would enable this).
> I do understand that it is a step away from a simple “Converter”, but the
> parsing is essentially the same. Since the hard work is already being done,
> why not take advantage of it here? Even if this tree view ends up being a
> completely different service, the same code base could easily serve the two.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5330) Double fields in Map if superclass shares a field name
David Leangen created FELIX-5330:
Summary: Double fields in Map if superclass shares a field name
Key: FELIX-5330
URL: https://issues.apache.org/jira/browse/FELIX-5330
Project: Felix
Issue Type: Bug
Components: Converter
Reporter: David Leangen
If a DTO inherits from an superclass, and both the DTO and the superclass have
a field with the same name, then a converted map has two fields with that name.
Example:
{code}
MyDTOSuper extends DTO {
public String data;
}
MyDTOChild extends MyDTOSuper {
public String data;
}
MyDTOChild dto = new MyDTOChild();
dto.data = "howdy!";
{code}
When converted to Map, it will have 2 fields named "data", one with the value
"howdy!", the other with a null value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5330) Double fields in Map if superclass shares a field name
[
https://issues.apache.org/jira/browse/FELIX-5330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15430505#comment-15430505
]
David Leangen commented on FELIX-5330:
--
Thank you very much, David B.!!
As a workaround, I removed the field in the parent class so I cannot confirm,
but I'm sure that the fix works. :-)
> Double fields in Map if superclass shares a field name
> --
>
> Key: FELIX-5330
> URL: https://issues.apache.org/jira/browse/FELIX-5330
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> If a DTO inherits from an superclass, and both the DTO and the superclass
> have a field with the same name, then a converted map has two fields with
> that name.
> Example:
> {code}
> MyDTOSuper extends DTO {
> public String data;
> }
> MyDTOChild extends MyDTOSuper {
> public String data;
> }
> MyDTOChild dto = new MyDTOChild();
> dto.data = "howdy!";
> {code}
> When converted to Map, it will have 2 fields named "data", one with the value
> "howdy!", the other with a null value.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5332) Serializer
David Leangen created FELIX-5332: Summary: Serializer Key: FELIX-5332 URL: https://issues.apache.org/jira/browse/FELIX-5332 Project: Felix Issue Type: New Feature Components: Converter Reporter: David Leangen Test case and a bit of code to show how a Serializer could work. To work as a Serializer, the type information needs to be embedded into the output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5332: - Attachment: diff-serializer.txt > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > Attachments: diff-serializer.txt > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15435023#comment-15435023 ] David Leangen commented on FELIX-5332: -- On second thought, probably this is not a common enough use case to warrant the complication. On top of that, it does not seem all that difficult to do. So I don't think it's worth including this after all. Sorry for the noise. Will close this issue. > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > Attachments: diff-serializer.txt > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen closed FELIX-5332. Resolution: Won't Fix > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > Attachments: diff-serializer.txt > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15435109#comment-15435109 ] David Leangen commented on FELIX-5332: -- Hmmm. Maybe I should not have acted so quickly. I am finding that this is more difficult than I'd thought because of generic types. If there is a generic type nested deep in the structure, it gets deserialised as a Map, which causes a ClassCastException in the client code. This leads me to believe that the _metadata information may be necessary for all generic types. I'll experiment a bit more. > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > Attachments: diff-serializer.txt > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5335) Addition of copy() method to API
David Leangen created FELIX-5335: Summary: Addition of copy() method to API Key: FELIX-5335 URL: https://issues.apache.org/jira/browse/FELIX-5335 Project: Felix Issue Type: New Feature Components: Converter Reporter: David Leangen Just to keep a record of this somewhere... here is the request I posted to the mail list. bq. Is there a simple way to transform a DTO into an immutable value object? To put my question into context: on the bndtools list, I asked this question, and got this response Peter K.: bq.Not in enRoute and not in the new spec that was inspired by this service. In general you pass copies so they can do whatever they like with them. Fine. But I am not seeing a simple way of creating such copy. Is there a “clone” method of some sort, or do I just convert an object to another object of its own type? Like this: MyDTO copy = cnv.convert( dto ).to( MyDTO.class ); If making copies is indeed how this service is intended to be used, it would be nice to have a more explicit method for this, maybe: MyDTO copy = cnv.copy( dto ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5338) Clarification of Converter.getAdapter()
David Leangen created FELIX-5338:
Summary: Clarification of Converter.getAdapter()
Key: FELIX-5338
URL: https://issues.apache.org/jira/browse/FELIX-5338
Project: Felix
Issue Type: Improvement
Components: Converter
Reporter: David Leangen
Hi!
The intent of Converter.getAdapter() is not quite clear to me.
{code}
/**
* Obtain an adapter to this converter. The adapter behaves just like
the
* converter except for the exception rules registered with is. For more
* details see the {@link Adapter} interface.
*
* @return An adapter to this converter.
*/
Adapter getAdapter();
{code}
Is this supposed to return an *existing* Adapter? Or rather, should it return a
*new* Adapter.
My guess is the latter, and the implementation code aligns with my expectation.
However, it is not clear from the documentation or the API.
Suggestion: the method should be renamed to "newAdapter()".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15462397#comment-15462397 ] David Leangen commented on FELIX-5332: -- I have done some experimenting. Overall conclusion: possible, but much more "complicated" than I had expected. Related code is [here|https://github.com/dleangen/felix/tree/serializer/converter]. I did not want to interfere with the current code base, so I created a few additional services that work in conjunction with Converter and Codec. In order to maintain the same structure and style, I literally copied the Converter and Codec to Schematizer and Serializer, respectively, and refactored from there. In the end, I'm not sure if that was a great idea. The code is not as elegant as I’d like. But it’s good enough for my current needs, and also as a proof of concept to better communicate my thoughts. Here are a few of the insights I gained while going through this discovery process. In a nutshell, I found that there are a few different roles. - Converter: converts an object of one type into an object of another type - Codec: encodes an object to some form (i.e. String), and decodes back into the object - [Schematizer|https://github.com/dleangen/felix/tree/serializer/converter/converter/src/main/java/org/apache/felix/schematizer/impl]: creates the schema based on the static structure of the DTO - [Serializer|https://github.com/dleangen/felix/tree/serializer/converter/codec/src/main/java/org/apache/felix/serializer/impl/json]: serializes an object (i.e. to String), and using the schema deserializes back to object (mostly the same as Codec, but uses the schema for proper typing) The Schematizer can schematize on its own, but in order for it to have any meaning, it needs to be used together with the Serializer, and the Serializer needs to do conversion. So in the end, the Converter, Codec, Schematizer, and Serializer all need to come together. For that reason, keeping them separated as they are now may not be ideal. But integrating them would likely require updates to the API, and I don't know if that's possible. There may be a smart way to somehow integrate the functionality without a major API update. That would be great, but I'm not seeing it right now. Maybe after a few days away from the code I could look at it again with fresh eyes... One observation I had: the Converter acts kind of like an interpretation engine for a DTO, while the Schematizer acts more like a compiler. The Converter does a “real time” conversion, while the Schematizer reads the static structure and keeps a record for later. The advantage of the Converter (relating to this aspect only) is that you do not need to keep anything in memory. The advantage of the Schematizer is that it can be used for deserialisation, which depending on the object structure may not be (easily) possible without a memory of the original object graph. The Converter is much more complex. It can act on DTOs, Maps, and interfaces. I limited the Schematizer to act only on DTOs. It can provide a Map representation, but that’s it. If ever this becomes interesting to somebody, I suppose that flexibility could always be added later. The Schematizer can produce a serialisable version of the DTO schema. I was considering making a quick and dirty prototype for [JSON Schema|http://json-schema.org/], but there is a bit more complexity in there than I am willing to handle right now, so I just did a simple “custom” JSON version of a schema. It merely reflects the state of the Schema object output by the Schematizer. I suppose that it could be possible to implement with JXPath instead, but that seemed a bit heavy handed to me. The purpose here is to specialise for DTOs, and to try to keep it lightweight and free of dependencies. That said, the code is more complex than I think it needs to be. I'm sure it could be simplified quite a bit, but this is quite a complex puzzle with many moving parts. Limitations + things to consider: * Only works with objects that extend DTO * Not thoroughly tested * Not well integrated with Converter / Codec * Perhaps Adapter is not necessary (move everything to Schematizer directly) * Probably much more :-) The Schematizer could eventually be used to output JSON Schema, DTDs, or XML Schema etc. I did not implement that. It could also be used to introspect a DTO, for instance if an object needs to be split up or joined when working with a persistence framework. I have not yet implemented that, either. Look forward to hearing your thoughts about which direction to take with this. > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: D
[jira] [Commented] (FELIX-5332) Serializer
[
https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15464837#comment-15464837
]
David Leangen commented on FELIX-5332:
--
Thank you, [~bosschaert].
{quote}
To me, the serializer/schematizer sounds a bit like a special Codec to me. For
example if you used it with XML it could produce an XML schema as part of the
serialization and then do the deserialization together with the schema.
{quote}
Yes, I agree! I did not want to complicate the existing code, so I put
everything into a separate class, service. What I realised when writing this
code, though, is that my original assumption ("we are parsing the object
anyway, so handing the schema should be easy and we should therefore take
advantage of this") was a bit off. True that we are doing parsing, but parsing
for the Schema turns out to be different enough that either (1) it should be in
a different class, or (2) the algorithms will be significantly complexified.
That said, if the code is well structured, I'm sure it could be done in a nice
way. My experience tells me (and probably you've noticed the same thing) that
working with reflection code on this level can quickly turn into a big mess.
That is my only worry.
{quote}
It would be nice if the codec (or other API) could be such that it would
support such implementations.
{quote}
Yes, I agree!
{quote}
To produce a schema, this might just be done as a by-product of the encoding
process? Maybe additionally configured via ConfigAdmin configuration factories?
Do we need anything extra in the codec API for this?
{quote}
Again, I agree with you. This can, and probably should, be handled behind the
scenes, at least for serialization/deserialization. For deep object
introspection and manipulation, we would actually need access to the Schema
object, which would require updating the API. Perhaps that could be offered as
a "non-standard" service as a pilot to see if anybody would actually use it.
Back to the serialization-only part, though: I am using the [Prevayler
Serializer|https://github.com/jsampson/prevayler/blob/master/core/src/main/java/org/prevayler/foundation/serialization/Serializer.java]
as my test case. I just noticed that the current impl is lacking.
To accomplish what you suggest (i.e. keeping the Schema hidden internally),
what we would need to do is provide a name/alias for each schema, and be able
to save it and invoke it (internally should be ok) by name. Perhaps something
like this in the Adapter:
{code}
Adapter schema(String name, TypeReference type); // No path means the
top level
Adapter schema(String name, String path, TypeReference type); // Path
indicates the object somewhere in the graph
{code}
When "saving" the schema, only the name would be serialized. If we don't do
this, I found that, especially for small objects, there is way too much
output/noise. Using the "alias" as the value to serialize works very nicely.
Also, the above rule would allow for multiple schemas. I just noticed a bug in
my impl: right now you can only save one single schema, which is not useful.
{quote}
For decoding the story is probably different, as you need to be able to pass in
the schema as context of the decode operation.
{quote}
My solution was to ensure that you use the same Adapter, which is already
configured, for deserialisation. The Schema is already saved under an alias.
Example:
{code}
{"schema":"Schema1", "payload":{ ... }}
{code}
The additional chars serialized is quite minimal, and the input is easy to
parse. Since there is a Map in the Adapter that looks up the schema by name (in
this case "Schema1"), then deserialization is quite easy. At least, that is
what I tested, and it seems to work very well.
{quote}
This could potentially be done via configadmin too, but that would be awkward I
think. Maybe if we add a method to the Decoding interface to provide
context/schema it might be useful, so you could do
mySpecialCodec.decode(sometextfile).withSchema(mySchema).to(MyDTO.class)
{quote}
Yes, that would also work!
However, if we work under the assumption that deserialization does not happen
without serialization, and since we (must??) also control the serialization,
then this stuff can be hidden internally, I think.
{quote}
Just an idea. I think it would be great if we could make the API such that
special implementations like your schema-based one work within the general
API...
{quote}
Great ideas! Thanks for supporting this. I personally think it is not only very
important stuff, but *should* be part of the Converter/Codec.
I'll continue working a bit more with Prevayler so I can show you what I come
up with in terms of a client-facing interface. So far, it is turning out to be
quite elegant, actually. (At least from the outside!) :-)
> Serializer
> --
>
> Key: FELIX-5332
>
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15465895#comment-15465895 ] David Leangen commented on FELIX-5332: -- [~bosschaert], I will try to update according to your comments. First, though, I am going to try to get Prevayler working so we can have an "outside" view with "working" code. Please let me know how I should provide these changes. Just continue on this branch in my fork, and you do the merge?? > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > Attachments: diff-serializer.txt > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[
https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15467168#comment-15467168
]
David Leangen commented on FELIX-5332:
--
[~bosschaert], in your example above, you suggest:
{code}
mySpecialCodec.decode(sometextfile).withSchema(mySchema).to(MyDTO.class)
{code}
Do you think we should make Schema a public interface, so mySchema is a Schema
object? Or should Schema be "hidden" in the implementation, so mySchema is the
name of the Schema, and the Schema object is private to the implementation?
If Schema is public, we would need to update the API to include both the Schema
and Node interfaces. Is that ok? I think that would be clearer, and therefore
preferable, but I don't know how much flexibility you have with regards to API
changes.
BTW, I believe that the above would actually be:
{code}
mySpecialCodec.decode(sometextfile).to(mySchema)
{code}
or maybe
{code}
mySpecialCodec.decode(sometextfile).with(mySchema)
{code}
The reason is because including both the Schema *and* the target DTO is
redundant, and could cause problems if there is a conflict between the two
(i.e. the target DTO does not match the schema).
> Serializer
> --
>
> Key: FELIX-5332
> URL: https://issues.apache.org/jira/browse/FELIX-5332
> Project: Felix
> Issue Type: New Feature
> Components: Converter
>Reporter: David Leangen
> Attachments: diff-serializer.txt
>
>
> Test case and a bit of code to show how a Serializer could work.
> To work as a Serializer, the type information needs to be embedded into the
> output.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (FELIX-5335) Addition of copy() method to API
[ https://issues.apache.org/jira/browse/FELIX-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473093#comment-15473093 ] David Leangen commented on FELIX-5335: -- Those are all very good arguments. I suppose that it comes down to precision vs. convenience, because IIUC either way, the behaviour would have to be documented in the API doc. Since it is only a very minor convenience anyway, and the target audience is technical people, I have no problem with choosing precision over convenience. :-) > Addition of copy() method to API > > > Key: FELIX-5335 > URL: https://issues.apache.org/jira/browse/FELIX-5335 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > > Just to keep a record of this somewhere... here is the request I posted to > the mail list. > > bq. Is there a simple way to transform a DTO into an immutable value object? > To put my question into context: on the bndtools list, I asked this question, > and got this response Peter K.: > bq.Not in enRoute and not in the new spec that was inspired by this service. > In general you pass copies so they can do whatever they like with them. > Fine. But I am not seeing a simple way of creating such copy. Is there a > “clone” method of some sort, or do I just convert an object to another object > of its own type? Like this: > MyDTO copy = cnv.convert( dto ).to( MyDTO.class ); > If making copies is indeed how this service is intended to be used, it would > be nice to have a more explicit method for this, maybe: > MyDTO copy = cnv.copy( dto ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FELIX-5338) Clarification of Converter.getAdapter()
[
https://issues.apache.org/jira/browse/FELIX-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Leangen closed FELIX-5338.
> Clarification of Converter.getAdapter()
> ---
>
> Key: FELIX-5338
> URL: https://issues.apache.org/jira/browse/FELIX-5338
> Project: Felix
> Issue Type: Improvement
> Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> Hi!
> The intent of Converter.getAdapter() is not quite clear to me.
> {code}
> /**
>* Obtain an adapter to this converter. The adapter behaves just like
> the
>* converter except for the exception rules registered with is. For more
>* details see the {@link Adapter} interface.
>*
>* @return An adapter to this converter.
>*/
> Adapter getAdapter();
> {code}
> Is this supposed to return an *existing* Adapter? Or rather, should it return
> a *new* Adapter.
> My guess is the latter, and the implementation code aligns with my
> expectation. However, it is not clear from the documentation or the API.
> Suggestion: the method should be renamed to "newAdapter()".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Closed] (FELIX-5335) Addition of copy() method to API
[ https://issues.apache.org/jira/browse/FELIX-5335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen closed FELIX-5335. Resolution: Won't Fix > Addition of copy() method to API > > > Key: FELIX-5335 > URL: https://issues.apache.org/jira/browse/FELIX-5335 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > > Just to keep a record of this somewhere... here is the request I posted to > the mail list. > > bq. Is there a simple way to transform a DTO into an immutable value object? > To put my question into context: on the bndtools list, I asked this question, > and got this response Peter K.: > bq.Not in enRoute and not in the new spec that was inspired by this service. > In general you pass copies so they can do whatever they like with them. > Fine. But I am not seeing a simple way of creating such copy. Is there a > “clone” method of some sort, or do I just convert an object to another object > of its own type? Like this: > MyDTO copy = cnv.convert( dto ).to( MyDTO.class ); > If making copies is indeed how this service is intended to be used, it would > be nice to have a more explicit method for this, maybe: > MyDTO copy = cnv.copy( dto ); -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5338) Clarification of Converter.getAdapter()
[
https://issues.apache.org/jira/browse/FELIX-5338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473095#comment-15473095
]
David Leangen commented on FELIX-5338:
--
Cool, thanks! :-)
> Clarification of Converter.getAdapter()
> ---
>
> Key: FELIX-5338
> URL: https://issues.apache.org/jira/browse/FELIX-5338
> Project: Felix
> Issue Type: Improvement
> Components: Converter
>Reporter: David Leangen
>Assignee: David Bosschaert
>
> Hi!
> The intent of Converter.getAdapter() is not quite clear to me.
> {code}
> /**
>* Obtain an adapter to this converter. The adapter behaves just like
> the
>* converter except for the exception rules registered with is. For more
>* details see the {@link Adapter} interface.
>*
>* @return An adapter to this converter.
>*/
> Adapter getAdapter();
> {code}
> Is this supposed to return an *existing* Adapter? Or rather, should it return
> a *new* Adapter.
> My guess is the latter, and the implementation code aligns with my
> expectation. However, it is not clear from the documentation or the API.
> Suggestion: the method should be renamed to "newAdapter()".
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5341) Exception thrown when field in Map missing from DTO
David Leangen created FELIX-5341: Summary: Exception thrown when field in Map missing from DTO Key: FELIX-5341 URL: https://issues.apache.org/jira/browse/FELIX-5341 Project: Felix Issue Type: Bug Components: Converter Reporter: David Leangen I believe that this is not the correct behaviour, so please correct me if I am mistaken. If a Map (or Map representation of some object) contains a field, when converting to a DTO that does *not* contain that field, instead of just ignoring the field, an Exception is thrown, and the conversion fails. The related code is [here|https://github.com/dleangen/felix/blob/trunk/converter/converter/src/main/java/org/apache/felix/converter/impl/ConvertingImpl.java#L242]. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15473494#comment-15473494 ] David Leangen commented on FELIX-5332: -- Ok, [~bosschaert], I have simplified and integrated into the code base according to my understanding of your suggestions. Please take a look. There are still (at least) two things missing: * Better client integration (will get back to this later) * Handing of Collections (will try to do this very soon) I have attached the patch file. Hope this works, Instead of working via svn, I am now using git, so I created the patch from there. Feel free to go directly to my github clone if that's easier. :-) Look forward to your comments. > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > Attachments: diff-serializer.txt > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5332: - Attachment: patch.diff > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > Attachments: diff-serializer.txt, patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5332: - Attachment: (was: patch.diff) > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5332: - Attachment: (was: diff-serializer.txt) > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15489715#comment-15489715 ] David Leangen commented on FELIX-5332: -- I have made another attempt. Here are a few additional learnings, and a bit of an explanation about what I've done. This patch (which I will submit right away) is up-to-date with the current version HEAD in the felix git repo. In addition to a few API updates and corresponding implementation classes, I have submitted several classes in the test cases. The goal here is to mock what I would consider to be an epitomic use case. Here, I created a mock-up of Prevayler. Prevayler needs to serialize objects (normally to a file on disk), then deserialize the objects. Problem is, there is no way to know which object is being deserialized, and no knowledge about the object, so without some help, deserialization will not work. To give a bit more context: each "transaction" is wrapped in an object prescribed by Prevayler. I created an arbitrary means of wrapping up the transaction as a DTO. Probably, this part needs much more thought. Specifically: what should go into the OSGi Serializer, and what should not. I think some of the stuff going on outside should actually be brought inside, since it is stuff that will *always* have to be done (such as providing an identity for a Schema to avoid having to also serialize the entire schema along with the payload). I think that the Schematizer could eventually be much "smarter" and require fewer hints via rules, but I am running out of time. Working with rules was quicker for me, because it allowed me to dumb down the Schematizer. If there is anything unclear in the code, please ask. I can also submit comments. The code helps in two ways: # Creates a [Schema|https://github.com/dleangen/felix/blob/serializer/converter/converter/src/main/java/org/osgi/service/converter/Schema.java] of the object to serialize, which can provide all the hints necessary to properly deserialize later # Serializes the Schema by means of an alias, so as to not take up disk space unnecessarily I'm sure there is a more intelligent way to serialize the alias, but whatever. This works. :-) I'm sure others will find lots and lots of improvements to make, but as I say, I hope at least that this will start a serious discussion. Some limitations: * Only works with DTOs for now (maybe that is how it should remain, I don't know). * Code could be cleaner (but is a good starting point for discussion). * Introduces new objects into the API (so adoption / agreement may not be easy). BTW, I find it much easier working with git than submitting patches via svn. [Here is the branch on my git clone|https://github.com/dleangen/felix/tree/serializer/converter]. Would it be possible to make a pull request next time instead of submitting a patch? > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5332: - Attachment: patch.diff > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5326) Add data structure descriptor
[ https://issues.apache.org/jira/browse/FELIX-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15504984#comment-15504984 ] David Leangen commented on FELIX-5326: -- Closing, as this is essentially a duplication of [FELIX-5332]. > Add data structure descriptor > - > > Key: FELIX-5326 > URL: https://issues.apache.org/jira/browse/FELIX-5326 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > > The Converter service does a lot of introspection and parsing of the DTO data > structure. In many cases, a DTO is a very simple object structure. However, > it can also be a very complex structure, too. > According to my understanding of the objectives of the Converter, one > important goal is to be able to persist data. The idea is that the DTO > describes the data structure. Thus, it is the ideal way to ship the state of > the system off to PersistenceLand. > If we do buy into this vision, then we may be missing out on a few great > opportunities here. When data gets persisted, we often need to understand the > relationships between the embedded objects. Or, we may want to be able to > create an index on the data. These are a few of the reasons why we would want > to have some kind of x-ray vision on the data structure. Since we already go > through all the trouble of parsing the data structure in order to convert it, > and since this is ~95% of the work, it would be really nice to provide access > to this information in order to easily link in services that require this > intimate knowledge. Otherwise, all the parsing would have to be done over and > over again for each service. > I believe that it would only take a few methods to be able to leverage all > the parsing work done by the Converter. I can think of: > DataTree Converter.toTree(DTO dto); // DataTre gives a tree view of the > structure > Object tree.valueAt(DTO dto, String path); // Dot-separated path value > within the tree structure > void tree.set(DTO dto, String path, Object value); // Set the value at the > given location in the tree structure > void process(DTO dto, Consumer function); // Visit each node for some > kind of processing > Those are just some examples. Perhaps a new API would be necessary, but my > main point here is that since we are going through all this work of > implementing a parser, this is the IDEAL time to create this type of view on > the data. > Also, one of the properties of DTOs is that the DTOs are really, in a way, > nothing more than schema. Because of this, it should be (and is) trivial to > convert to JSON, XML, YAML, or whatever. If the DTO *is* the data structure, > then it should also be trivial to convert the type descriptor (or tree, or > whatever) to some kind of schema, like JSON Schema, DTD, XML Schema, RDF… > That fits well with one of the features of the Converter: codecs to convert > to/from serialized types. RFC 215 defines two portable codecs: JSON and > YAML but other implementations can add their own codecs too. We could do the > same not just for the live data instance, but for the data schema as well. > (Note that this schema generation is not required: we could decide only to > implement the data tree structure, and have an outside process generate the > scheme, but at least the data tree would enable this). > I do understand that it is a step away from a simple “Converter”, but the > parsing is essentially the same. Since the hard work is already being done, > why not take advantage of it here? Even if this tree view ends up being a > completely different service, the same code base could easily serve the two. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5326) Add data structure descriptor
[ https://issues.apache.org/jira/browse/FELIX-5326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen resolved FELIX-5326. -- Resolution: Duplicate > Add data structure descriptor > - > > Key: FELIX-5326 > URL: https://issues.apache.org/jira/browse/FELIX-5326 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen > > The Converter service does a lot of introspection and parsing of the DTO data > structure. In many cases, a DTO is a very simple object structure. However, > it can also be a very complex structure, too. > According to my understanding of the objectives of the Converter, one > important goal is to be able to persist data. The idea is that the DTO > describes the data structure. Thus, it is the ideal way to ship the state of > the system off to PersistenceLand. > If we do buy into this vision, then we may be missing out on a few great > opportunities here. When data gets persisted, we often need to understand the > relationships between the embedded objects. Or, we may want to be able to > create an index on the data. These are a few of the reasons why we would want > to have some kind of x-ray vision on the data structure. Since we already go > through all the trouble of parsing the data structure in order to convert it, > and since this is ~95% of the work, it would be really nice to provide access > to this information in order to easily link in services that require this > intimate knowledge. Otherwise, all the parsing would have to be done over and > over again for each service. > I believe that it would only take a few methods to be able to leverage all > the parsing work done by the Converter. I can think of: > DataTree Converter.toTree(DTO dto); // DataTre gives a tree view of the > structure > Object tree.valueAt(DTO dto, String path); // Dot-separated path value > within the tree structure > void tree.set(DTO dto, String path, Object value); // Set the value at the > given location in the tree structure > void process(DTO dto, Consumer function); // Visit each node for some > kind of processing > Those are just some examples. Perhaps a new API would be necessary, but my > main point here is that since we are going through all this work of > implementing a parser, this is the IDEAL time to create this type of view on > the data. > Also, one of the properties of DTOs is that the DTOs are really, in a way, > nothing more than schema. Because of this, it should be (and is) trivial to > convert to JSON, XML, YAML, or whatever. If the DTO *is* the data structure, > then it should also be trivial to convert the type descriptor (or tree, or > whatever) to some kind of schema, like JSON Schema, DTD, XML Schema, RDF… > That fits well with one of the features of the Converter: codecs to convert > to/from serialized types. RFC 215 defines two portable codecs: JSON and > YAML but other implementations can add their own codecs too. We could do the > same not just for the live data instance, but for the data schema as well. > (Note that this schema generation is not required: we could decide only to > implement the data tree structure, and have an outside process generate the > scheme, but at least the data tree would enable this). > I do understand that it is a step away from a simple “Converter”, but the > parsing is essentially the same. Since the hard work is already being done, > why not take advantage of it here? Even if this tree view ends up being a > completely different service, the same code base could easily serve the two. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15507367#comment-15507367 ] David Leangen commented on FELIX-5332: -- Hi [~bosschaert], yeah, it does make the code much less light-weight. It would appear to roughly double the size, so I think you are right that it should be separated out into a separate API/module. It would appear that I was completely mistaken when I originally assumed that it would overlap with the same code. It could, but it would make the code much more complex, which is not desirable. To keep it separate means that the codebase doubles in size, which is also not desirable. Sigh. :-( I can make this change, but probably can't start until about next week or so. Is that ok? I'm not entirely sure what you mean by withContext(Object obj), so I may need your help. > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15511473#comment-15511473 ] David Leangen commented on FELIX-5332: -- Hey [~bosschaert], it was not really my intent to own a new project (unfortunately, I don't really have the time or energy right now), so I just want to stop and think a bit about what we are doing before I dig myself in any deeper. :-) The code I wrote is a very simplistic example, and needs a lot of work. It "works", in that I am able to do serialization with it, and I am now actually using it internally, but it's nowhere near ready for general use, I think. The main point I was trying to make is that OSGi is creating a "Serialization" spec, does not seem to be giving consideration for what, I believe, is a critical element of serialization: the schema. Without a schema, complex data cannot be deserialized. The only reason this can work without a Schema object is because during deserialization, the application already knows which DTO object (including help from TypeReference) needs to be used. If that context is not there, or if the object is too "complex", then boom! There are a few schema types out there. Here are a few: * xsd * [protobuf|https://developers.google.com/protocol-buffers/] * [Cap'n Proto|https://capnproto.org/] I am sure there are others. (I think the last one is really neat, as it also explicitly deals with generics.) The DTO in OSGi *is* the data schema. If it can not be properly serialized / deserialized, then there is a serious problem, IMHO. I was trying to point out this problem, but it is turning out to be much more involved than I had originally imagined. The above listed solutions are "complete", but they also drag in a log of baggage. It would seem that the last 2 even require a native compiler to be installed. They all seem to work "offline" or during the build, rather than at runtime. It would be awesome to have a language agnostic schema, which could be converted into any of these formats. The DTO has that potential. It would be extremely powerful, combined with the Converter and "Serializer". I think my little experiment here can be considered both a success and a failure. It is a success in that I was able to accomplish the job of serializing somewhat complex data (complex enough that it could not be done without a schema) by way of this simple prototype, but it was a failure in that we have not yet found a good way to integrate it, and I don't think I've yet convinced anybody of its necessity. I think we need to sit back and think of something more convincing, perhaps, before continuing to pursue my experiment. wdyt? BTW, I am having a bit of trouble with naming it a "Serializer" if it cannot completely do the job... Codec actually seemed more appropriate. Just sayin'. :-) > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5358) Cannot deserialize empty Map
David Leangen created FELIX-5358:
Summary: Cannot deserialize empty Map
Key: FELIX-5358
URL: https://issues.apache.org/jira/browse/FELIX-5358
Project: Felix
Issue Type: Bug
Components: Converter
Reporter: David Leangen
This is the stack trace:
{code}
java.lang.IllegalArgumentException: Malformatted JSON key-value pair:
at
org.apache.felix.serializer.impl.json.JsonParser.parseKeyValue(JsonParser.java:93)
at
org.apache.felix.serializer.impl.json.JsonParser.parseObject(JsonParser.java:136)
at
org.apache.felix.serializer.impl.json.JsonParser.(JsonParser.java:79)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:55)
{code}
Here is a test case that fails (with the above Exception):
{code}
@Test
public void testEmptyMapSerialization() {
Map m = new LinkedHashMap<>();
String expected = "{}";
assertEquals(expected, new
JsonSerializerImpl().serialize(m).toString());
Map m2 = new LinkedHashMap<>();
Object o = new JsonSerializerImpl().deserialize( Map.class ).from(
expected );
}
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5332: - Attachment: (was: patch.diff) > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5332: - Attachment: patch.diff Hi [~bosschaert], I have moved out the code into [a separate project|https://github.com/dleangen/felix/tree/schematizer/converter/schematizer], and included the patch. > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15518518#comment-15518518 ] David Leangen edited comment on FELIX-5332 at 9/24/16 6:22 AM: --- Hi [~bosschaert], I have moved out the code into [a separate project|https://github.com/dleangen/felix/tree/schematizer/converter/schematizer], and included the patch. Notes: * I am still not yet sure how this is supposed to integrate with the Serializer, so I ended up duplicating the Serializer code * There is still a Prevayler test case, which should eventually be removed or perhaps moved to a different project Looking forward to your comments. was (Author: dleangen): Hi [~bosschaert], I have moved out the code into [a separate project|https://github.com/dleangen/felix/tree/schematizer/converter/schematizer], and included the patch. > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Serializer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15521550#comment-15521550 ] David Leangen commented on FELIX-5332: -- Thanks, [~bosschaert]! > Serializer > -- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FELIX-5332) Schematizer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen closed FELIX-5332. Thank you very much, [~bosschaert]. I am very pleased that you are taking this into consideration. :-) Please remember that this is only a prototype. It needs lots of work. :-) I will submit anything further in separate JIRA issues. > Schematizer > --- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5332) Schematizer
[ https://issues.apache.org/jira/browse/FELIX-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15525309#comment-15525309 ] David Leangen commented on FELIX-5332: -- Hi [~bosschaert], thanks for getting back to me on this comment. Ok, agree that "Codec Service Specification" isn't right. What about just "Converter Service Specification"? Or maybe "Object Conversion Service Specification"? Just a thought. > Schematizer > --- > > Key: FELIX-5332 > URL: https://issues.apache.org/jira/browse/FELIX-5332 > Project: Felix > Issue Type: New Feature > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > Attachments: patch.diff > > > Test case and a bit of code to show how a Serializer could work. > To work as a Serializer, the type information needs to be embedded into the > output. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5412) Pretty format not implemented in JSON serializer
David Leangen created FELIX-5412: Summary: 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 There is a configuration for "pretty" formatting, but it has not yet been implemented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[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=15665909#comment-15665909 ] David Leangen commented on FELIX-5412: -- I wrote some code in order to submit a patch, but my attempt was too naive, and the output was not very pretty. > 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 > > There is a configuration for "pretty" formatting, but it has not yet been > implemented. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5414) Windows files break the parser
David Leangen created FELIX-5414:
Summary: Windows files break the parser
Key: FELIX-5414
URL: https://issues.apache.org/jira/browse/FELIX-5414
Project: Felix
Issue Type: Bug
Components: Converter
Reporter: David Leangen
The parser outputs this error when attempting to parse a file with Windows
newlines:
{code}
java.lang.IllegalArgumentException: Malformatted JSON key-value pair:
[DATA-DELETED]
at
org.apache.felix.serializer.impl.json.JsonParser.parseKeyValue(JsonParser.java:96)
at
org.apache.felix.serializer.impl.json.JsonParser.parseObject(JsonParser.java:142)
at
org.apache.felix.serializer.impl.json.JsonParser.(JsonParser.java:79)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:68)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:89)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:81)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5414) Windows files break the JSON parser
[
https://issues.apache.org/jira/browse/FELIX-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Leangen updated FELIX-5414:
-
Summary: Windows files break the JSON parser (was: Windows files break the
parser)
> Windows files break the JSON parser
> ---
>
> Key: FELIX-5414
> URL: https://issues.apache.org/jira/browse/FELIX-5414
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>
> The parser outputs this error when attempting to parse a file with Windows
> newlines:
> {code}
> java.lang.IllegalArgumentException: Malformatted JSON key-value pair:
> [DATA-DELETED]
> at
> org.apache.felix.serializer.impl.json.JsonParser.parseKeyValue(JsonParser.java:96)
> at
> org.apache.felix.serializer.impl.json.JsonParser.parseObject(JsonParser.java:142)
> at
> org.apache.felix.serializer.impl.json.JsonParser.(JsonParser.java:79)
> at
> org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:68)
> at
> org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:89)
> at
> org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:81)
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (FELIX-5414) Windows files break the JSON parser
[
https://issues.apache.org/jira/browse/FELIX-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Leangen updated FELIX-5414:
-
Description:
The parser outputs this error when attempting to parse a file with Windows
newlines:
{code}
java.lang.IllegalArgumentException: Malformatted JSON key-value pair:
[DATA-DELETED]
at
org.apache.felix.serializer.impl.json.JsonParser.parseKeyValue(JsonParser.java:96)
at
org.apache.felix.serializer.impl.json.JsonParser.parseObject(JsonParser.java:142)
at
org.apache.felix.serializer.impl.json.JsonParser.(JsonParser.java:79)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:68)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:89)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:81)
{code}
was:
The parser outputs this error when attempting to parse a file with Windows
newlines:
{code}
java.lang.IllegalArgumentException: Malformatted JSON key-value pair:
[DATA-DELETED]
at
org.apache.felix.serializer.impl.json.JsonParser.parseKeyValue(JsonParser.java:96)
at
org.apache.felix.serializer.impl.json.JsonParser.parseObject(JsonParser.java:142)
at
org.apache.felix.serializer.impl.json.JsonParser.(JsonParser.java:79)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:68)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:89)
at
org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:81)
> Windows files break the JSON parser
> ---
>
> Key: FELIX-5414
> URL: https://issues.apache.org/jira/browse/FELIX-5414
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>
> The parser outputs this error when attempting to parse a file with Windows
> newlines:
> {code}
> java.lang.IllegalArgumentException: Malformatted JSON key-value pair:
> [DATA-DELETED]
> at
> org.apache.felix.serializer.impl.json.JsonParser.parseKeyValue(JsonParser.java:96)
> at
> org.apache.felix.serializer.impl.json.JsonParser.parseObject(JsonParser.java:142)
> at
> org.apache.felix.serializer.impl.json.JsonParser.(JsonParser.java:79)
> at
> org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:68)
> at
> org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:89)
> at
> org.apache.felix.serializer.impl.json.JsonDeserializingImpl.from(JsonDeserializingImpl.java:81)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5475) Allow the use of DTO.class to signal that an Object should be treated as a DTO.
David Leangen created FELIX-5475: Summary: 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] [Created] (FELIX-5476) Serializer does not accept empty values
David Leangen created FELIX-5476:
Summary: Serializer does not accept empty values
Key: FELIX-5476
URL: https://issues.apache.org/jira/browse/FELIX-5476
Project: Felix
Issue Type: Bug
Components: Converter
Reporter: David Leangen
Serializer should accept empty values, for both objects {} and arrays [].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5477) DTOs should allow lambdas
David Leangen created FELIX-5477: Summary: DTOs should allow lambdas Key: FELIX-5477 URL: https://issues.apache.org/jira/browse/FELIX-5477 Project: Felix Issue Type: Bug Components: Converter Reporter: David Leangen As far as I understand, the spec does not allow methods, but non-public fields are simply ignored. This should also include fields whose values are lambdas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5478) Dependency on snakeyaml should be private
David Leangen created FELIX-5478: Summary: Dependency on snakeyaml should be private Key: FELIX-5478 URL: https://issues.apache.org/jira/browse/FELIX-5478 Project: Felix Issue Type: Bug Components: Converter Reporter: David Leangen -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5479) Serializer should be more lenient with trailing commas
David Leangen created FELIX-5479: Summary: 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 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.4#6332)
[jira] [Created] (FELIX-5480) Serializer should be more lenient with trailing commas
David Leangen created FELIX-5480: Summary: Serializer should be more lenient with trailing commas Key: FELIX-5480 URL: https://issues.apache.org/jira/browse/FELIX-5480 Project: Felix Issue Type: Improvement Components: Converter Reporter: 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.4#6332)
[jira] [Created] (FELIX-5481) Various updates to Schematizer
David Leangen created FELIX-5481: Summary: Various updates to Schematizer Key: FELIX-5481 URL: https://issues.apache.org/jira/browse/FELIX-5481 Project: Felix Issue Type: Improvement Components: Converter Reporter: David Leangen Schematizer requires updates to sync with recent changes to Converter/Serializer API changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5478) Dependency on snakeyaml should be private
[ https://issues.apache.org/jira/browse/FELIX-5478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15798714#comment-15798714 ] David Leangen commented on FELIX-5478: -- No need for a separate issue. > Dependency on snakeyaml should be private > - > > Key: FELIX-5478 > URL: https://issues.apache.org/jira/browse/FELIX-5478 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5478) Dependency on snakeyaml should be private
[ https://issues.apache.org/jira/browse/FELIX-5478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen resolved FELIX-5478. -- Resolution: Duplicate > Dependency on snakeyaml should be private > - > > Key: FELIX-5478 > URL: https://issues.apache.org/jira/browse/FELIX-5478 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Closed] (FELIX-5478) Dependency on snakeyaml should be private
[ https://issues.apache.org/jira/browse/FELIX-5478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen closed FELIX-5478. > Dependency on snakeyaml should be private > - > > Key: FELIX-5478 > URL: https://issues.apache.org/jira/browse/FELIX-5478 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5476) Serializer does not accept empty values
[
https://issues.apache.org/jira/browse/FELIX-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15812373#comment-15812373
]
David Leangen commented on FELIX-5476:
--
Hi! (This is especially for [~bosschaert])
Is there any plan to take a look at this (and other) issues any time soon?
Not trying to be pushy, just trying to get a gauge on things. :-)
Thanks!
=David
> Serializer does not accept empty values
> ---
>
> Key: FELIX-5476
> URL: https://issues.apache.org/jira/browse/FELIX-5476
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>
> Serializer should accept empty values, for both objects {} and arrays [].
--
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=15824228#comment-15824228 ] David Leangen commented on FELIX-5475: -- If you are referring to the API, then yes, for sure! I think it would be easier. I thought that it was already decided to take this out, though. If it's ok to change the API, I will give it a go. Please let me know. > 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-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=15824248#comment-15824248 ] David Leangen commented on FELIX-5475: -- Ok, I'll do that. I think it would be easier, though to first get the various smaller changes out of the way. I'll try to make separate issues and PRs for each so it is easier for you to review. Then I'll get back to this "big" issue. > 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] [Comment Edited] (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=15824248#comment-15824248 ] David Leangen edited comment on FELIX-5475 at 1/16/17 4:40 PM: --- Agree. Indeed, I found that it was necessary to consider both source and target. It would allow for better control to separate them out. I will give it a go. I think it would be easier, though to first get the various smaller changes out of the way. I'll try to make separate issues and PRs for each so it is easier for you to review. Then I'll get back to this "big" issue. was (Author: dleangen): Ok, I'll do that. I think it would be easier, though to first get the various smaller changes out of the way. I'll try to make separate issues and PRs for each so it is easier for you to review. Then I'll get back to this "big" issue. > 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-5481) Various updates to Schematizer
[ https://issues.apache.org/jira/browse/FELIX-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824262#comment-15824262 ] David Leangen commented on FELIX-5481: -- Will split these into separate issues as requested. > Various updates to Schematizer > -- > > Key: FELIX-5481 > URL: https://issues.apache.org/jira/browse/FELIX-5481 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > Schematizer requires updates to sync with recent changes to > Converter/Serializer API changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5476) Serializer does not accept empty values
[
https://issues.apache.org/jira/browse/FELIX-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824264#comment-15824264
]
David Leangen commented on FELIX-5476:
--
Yes, will try to do that will the various issues.
> Serializer does not accept empty values
> ---
>
> Key: FELIX-5476
> URL: https://issues.apache.org/jira/browse/FELIX-5476
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>
> Serializer should accept empty values, for both objects {} and arrays [].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (FELIX-5490) Update mime type in Schematizer
David Leangen created FELIX-5490: Summary: Update mime type in Schematizer Key: FELIX-5490 URL: https://issues.apache.org/jira/browse/FELIX-5490 Project: Felix Issue Type: Bug Components: Converter Reporter: David Leangen Mimetype needs to be changed from "osgi.codec.mimetype" to just "mimetype". -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5491) Serializer should allow empty key/values pairs when parsing
David Leangen created FELIX-5491: Summary: 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 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-5477) DTOs should allow lambdas
[ https://issues.apache.org/jira/browse/FELIX-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15824316#comment-15824316 ] David Leangen commented on FELIX-5477: -- Will try to dig up an example. > DTOs should allow lambdas > - > > Key: FELIX-5477 > URL: https://issues.apache.org/jira/browse/FELIX-5477 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen > > As far as I understand, the spec does not allow methods, but non-public > fields are simply ignored. This should also include fields whose values are > lambdas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5492) Schematizer POM requires updates
David Leangen created FELIX-5492: Summary: Schematizer POM requires updates Key: FELIX-5492 URL: https://issues.apache.org/jira/browse/FELIX-5492 Project: Felix Issue Type: Bug Components: Converter Reporter: David Leangen Currently does not play well with other bundles due to a few issues with the POM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5492) Schematizer POM requires updates
[ https://issues.apache.org/jira/browse/FELIX-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5492: - Labels: PR (was: ) > Schematizer POM requires updates > > > Key: FELIX-5492 > URL: https://issues.apache.org/jira/browse/FELIX-5492 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen > Labels: PR > > Currently does not play well with other bundles due to a few issues with the > POM. -- 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=15824343#comment-15824343 ] David Leangen commented on FELIX-5475: -- I am already getting a bit confused with all the different branches. Will await review and (hopefully) acceptance of the currently outstanding PRs before resuming work on this one. > 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] [Comment Edited] (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=15824343#comment-15824343 ] David Leangen edited comment on FELIX-5475 at 1/16/17 5:36 PM: --- I am already getting a bit confused with all the different branches. Will await review and (hopefully) acceptance of the currently outstanding PRs before resuming work on this one. Unless somebody can suggest a better way to work with multiple (and dependent) PRs at once?? was (Author: dleangen): I am already getting a bit confused with all the different branches. Will await review and (hopefully) acceptance of the currently outstanding PRs before resuming work on this one. > 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] [Updated] (FELIX-5492) Schematizer POM requires updates
[ https://issues.apache.org/jira/browse/FELIX-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5492: - Labels: (was: PR) > Schematizer POM requires updates > > > Key: FELIX-5492 > URL: https://issues.apache.org/jira/browse/FELIX-5492 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen >Assignee: David Bosschaert > > Currently does not play well with other bundles due to a few issues with the > POM. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Comment Edited] (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:comment-tabpanel&focusedCommentId=15828433#comment-15828433 ] David Leangen edited comment on FELIX-5491 at 1/18/17 5:27 PM: --- I was not able to "prove" one of the changes, so I reverted for now. Otherwise, provided a test case to show when parsing an empty array fails. Please see updated PR. was (Author: dleangen): I was not able to "prove" one of the changes, so I reverted for now. Otherwise, provided a test case to show when parsing an empty array fails. > 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 > Labels: PR > > 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-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:comment-tabpanel&focusedCommentId=15828433#comment-15828433 ] David Leangen commented on FELIX-5491: -- I was not able to "prove" one of the changes, so I reverted for now. Otherwise, provided a test case to show when parsing an empty array fails. > 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 > Labels: PR > > 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=15830571#comment-15830571 ] David Leangen commented on FELIX-5475: -- [~bosschaert], I filed the change request on the OSGi bugzilla as you suggested. BJ immediately replied, saying that this had already been done. Would you kindly make the change to the API? I will work on the impl following that update, and will also consequently update this issue and the PR. Thanks! > 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-5477) DTOs should allow lambdas
[ https://issues.apache.org/jira/browse/FELIX-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15830573#comment-15830573 ] David Leangen commented on FELIX-5477: -- Withdrawing request for now. > DTOs should allow lambdas > - > > Key: FELIX-5477 > URL: https://issues.apache.org/jira/browse/FELIX-5477 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen > > As far as I understand, the spec does not allow methods, but non-public > fields are simply ignored. This should also include fields whose values are > lambdas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5477) DTOs should allow lambdas
[ https://issues.apache.org/jira/browse/FELIX-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen resolved FELIX-5477. -- Resolution: Invalid > DTOs should allow lambdas > - > > Key: FELIX-5477 > URL: https://issues.apache.org/jira/browse/FELIX-5477 > Project: Felix > Issue Type: Bug > Components: Converter >Reporter: David Leangen > > As far as I understand, the spec does not allow methods, but non-public > fields are simply ignored. This should also include fields whose values are > lambdas. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (FELIX-5476) Serializer does not accept empty values
[
https://issues.apache.org/jira/browse/FELIX-5476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Leangen resolved FELIX-5476.
--
Resolution: Duplicate
> Serializer does not accept empty values
> ---
>
> Key: FELIX-5476
> URL: https://issues.apache.org/jira/browse/FELIX-5476
> Project: Felix
> Issue Type: Bug
> Components: Converter
>Reporter: David Leangen
>
> Serializer should accept empty values, for both objects {} and arrays [].
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (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:comment-tabpanel&focusedCommentId=15830578#comment-15830578 ] David Leangen commented on FELIX-5491: -- Ready for review. > 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 > > The Serializer is currently too stringent to not allow empty values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (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 Leangen updated FELIX-5491: - Labels: (was: PR) > 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 > > The Serializer is currently too stringent to not allow empty values. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (FELIX-5508) Multiple JSON Parsers
David Leangen created FELIX-5508: Summary: Multiple JSON Parsers 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 parsers 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 Leangen updated FELIX-5508: - Description: 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? was: There appears to be multiple json parsers in the code base (serializer, schematizer, and even more recently webconsole). Would it be worthwhile to consider consolidating them somehow, to avoid duplicate work? > 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] [Updated] (FELIX-5508) Multiple JSON Serializers
[ https://issues.apache.org/jira/browse/FELIX-5508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5508: - Summary: Multiple JSON Serializers (was: Multiple JSON Parsers) > 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 parsers 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=15832024#comment-15832024 ] David Leangen commented on FELIX-5508: -- Yes, correct. I updated the title and description. Thanks. :-) > 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] [Updated] (FELIX-5475) Implement sourceAsDTO() and targetAsDTO()
[ https://issues.apache.org/jira/browse/FELIX-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5475: - Summary: Implement sourceAsDTO() and targetAsDTO() (was: Allow the use of DTO.class to signal that an Object should be treated as a DTO.) > 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 > > 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-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=15832028#comment-15832028 ] David Leangen commented on FELIX-5475: -- Beautiful, thanks! I haven't yet looked at the changes, but my plan is to update this issue, then begin work on the impl. I think I'll just have to squash all the previous changes into one largish commit. My expectation is that is should be relatively easy to make the change from sourceAs(DTO.class) to sourceAsDTO(), but we'll see! > 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] [Updated] (FELIX-5475) Implement sourceAsDTO() and targetAsDTO()
[ https://issues.apache.org/jira/browse/FELIX-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5475: - Description: 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). was: 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). > 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 > > 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-5481) Various updates to Schematizer
[ https://issues.apache.org/jira/browse/FELIX-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen resolved FELIX-5481. -- Resolution: Duplicate > Various updates to Schematizer > -- > > Key: FELIX-5481 > URL: https://issues.apache.org/jira/browse/FELIX-5481 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > Schematizer requires updates to sync with recent changes to > Converter/Serializer API changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5475) Implement sourceAsDTO() and targetAsDTO()
[ https://issues.apache.org/jira/browse/FELIX-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15832206#comment-15832206 ] David Leangen commented on FELIX-5475: -- The update is completed. I will submit 3 separate PRs in order to make this more manageable, and in this order: # Converter # Serializer # Schematizer > 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 > > 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-5475) Implement sourceAsDTO() and targetAsDTO()
[ https://issues.apache.org/jira/browse/FELIX-5475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15832342#comment-15832342 ] David Leangen commented on FELIX-5475: -- Converter PR has been prepared. No changes to make to Serializer. Will move updates to Schematizer to a different issue in order to expedite review and completion of this issue. --> Ready for review!! > 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 > > 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] [Reopened] (FELIX-5481) Various updates to Schematizer
[ https://issues.apache.org/jira/browse/FELIX-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen reopened FELIX-5481: -- Not a duplicate after all. Moving changes to Schematizer back here. Sorry for the ping pong game. Perhaps the names in the test cases (i.e. "ping" and "pong" were working subliminally??) > Various updates to Schematizer > -- > > Key: FELIX-5481 > URL: https://issues.apache.org/jira/browse/FELIX-5481 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > Schematizer requires updates to sync with recent changes to > Converter/Serializer API changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5481) Synchronize Schematizer to updated Converter API
[ https://issues.apache.org/jira/browse/FELIX-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5481: - Summary: Synchronize Schematizer to updated Converter API (was: Various updates to Schematizer) > Synchronize Schematizer to updated Converter API > > > Key: FELIX-5481 > URL: https://issues.apache.org/jira/browse/FELIX-5481 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > Schematizer requires updates to sync with recent API changes to Converter, > i.e sourceAsDTO() and targetAsDTO(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (FELIX-5481) Synchronize Schematizer to updated Converter API
[ https://issues.apache.org/jira/browse/FELIX-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5481: - Comment: was deleted (was: Will split these into separate issues as requested.) > Synchronize Schematizer to updated Converter API > > > Key: FELIX-5481 > URL: https://issues.apache.org/jira/browse/FELIX-5481 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > Schematizer requires updates to sync with recent API changes to Converter, > i.e sourceAsDTO() and targetAsDTO(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (FELIX-5481) Various updates to Schematizer
[ https://issues.apache.org/jira/browse/FELIX-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5481: - Description: Schematizer requires updates to sync with recent API changes to Converter, i.e sourceAsDTO() and targetAsDTO(). (was: Schematizer requires updates to sync with recent changes to Converter/Serializer API changes.) > Various updates to Schematizer > -- > > Key: FELIX-5481 > URL: https://issues.apache.org/jira/browse/FELIX-5481 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > Schematizer requires updates to sync with recent API changes to Converter, > i.e sourceAsDTO() and targetAsDTO(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Issue Comment Deleted] (FELIX-5481) Synchronize Schematizer to updated Converter API
[ https://issues.apache.org/jira/browse/FELIX-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Leangen updated FELIX-5481: - Comment: was deleted (was: Not a duplicate after all. Moving changes to Schematizer back here. Sorry for the ping pong game. Perhaps the names in the test cases (i.e. "ping" and "pong" were working subliminally??)) > Synchronize Schematizer to updated Converter API > > > Key: FELIX-5481 > URL: https://issues.apache.org/jira/browse/FELIX-5481 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > Schematizer requires updates to sync with recent API changes to Converter, > i.e sourceAsDTO() and targetAsDTO(). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (FELIX-5481) Synchronize Schematizer to updated Converter API
[ https://issues.apache.org/jira/browse/FELIX-5481?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15838380#comment-15838380 ] David Leangen commented on FELIX-5481: -- Rebased to updated trunk. > Synchronize Schematizer to updated Converter API > > > Key: FELIX-5481 > URL: https://issues.apache.org/jira/browse/FELIX-5481 > Project: Felix > Issue Type: Improvement > Components: Converter >Reporter: David Leangen > > Schematizer requires updates to sync with recent API changes to Converter, > i.e sourceAsDTO() and targetAsDTO(). -- 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=15848627#comment-15848627
]
David Leangen commented on FELIX-5508:
--
I am not yet familiar enough with how Felix is organized to directly comment,
but I do have a few things on my mind.
I find that the "danger" of this type of (parser/writer) utility is that it can
quickly turn into a full-fledged parser project. It is a slippery slope. ("Just
need this one more little feature...") That is why there quickly become
numerous similar "utilities" throughout the code base. Reminds me of [this
funny comic|https://xkcd.com/927/]. Not sure how to do it, but there should be
some kind of strict oversight regarding what this "utility" does.
I would propose, for starters:
* NOT user-friendly for use as an all-purpose library
* NOT configurable (or perhaps only "minimally" configurable, but again,
slippery slope)
Should it be only for internal Felix use as a library that gets embedded in the
using bundle (and thus repeated in the live system)?
Should it be more DRY, and maybe accessible to other projects, for instance as
an OSGi service?
I am leaning towards an internal Felix library, in order to try to avoid all
the scope creep. Would putting it in utils solve these issues, do you think?
(Sorry if any of these comments are silly. I'm just trying to find my legs
here. :-)
> 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)
