[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181136#comment-14181136
]
Fabio Piro edited comment on SOLR-6645 at 10/23/14 8:45 AM:
Sure [~erickerickson]! Here we go, PATCH added.
was (Author: dewos):
Sure [~erickerickson]! Here we go, PATH added.
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process.
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% BC and the performance impact is void (the logic
> flow is exactly the same as now, and I only changed the bare essentials and
> nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
> public FieldObjectAnnotationListener(AnnotatedElement element,
> FieldObject annotation) {
> super(element, annotation);
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> Object nested = binder.getBean(target.clazz, doc);
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> for (Map.Entry entry : nested.entrySet()) {
> doc.addField(entry.getKey(), entry.getValue());
> }
> }
> }
> {code}
> Or something entirely new like an annotation for ChildDocuments:
> {code:java}
> public class ChildDocumentsAnnotationListener extends
> AccessorAnnotationListener {
> public ChildDocumentsAnnotationListener(AnnotatedElement element,
> ChildDocuments annotation) {
> super(element, annotation);
> if (!target.isInList || target.clazz.isPrimitive()) {
> throw new BindingException("@NestedDocuments is applicable only
> on List.");
> }
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> List nested = new ArrayList<>();
> for (SolrDocument child : doc.getChildDocuments()) {
> nested.add(binder.getBean(target.clazz, child));// this should be
> recursive, but it's only an example
> }
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> doc.addChildDocuments(nested.getChildDocuments());
> }
> }
> {code}
> In addition, all the logic is encapsulated in the listener, so you can make a
> custom FieldAnnotationListener too, and override the default one
> {code:java}
> public class CustomFieldAnnotationListener extends FieldAnnotationListener {
> private boolean isTransentPresent;
> public CustomFieldAnnotationListener(AnnotatedElement element, Field
> annotation) {
> super(element,
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14181136#comment-14181136
]
Fabio Piro edited comment on SOLR-6645 at 10/23/14 3:57 PM:
Sure [~erickerickson]! Here we go, patch added.
was (Author: dewos):
Sure [~erickerickson]! Here we go, PATCH added.
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: New Feature
> Components: clients - java
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process.
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% BC and the performance impact is void (the logic
> flow is exactly the same as now, and I only changed the bare essentials and
> nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
> public FieldObjectAnnotationListener(AnnotatedElement element,
> FieldObject annotation) {
> super(element, annotation);
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> Object nested = binder.getBean(target.clazz, doc);
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> for (Map.Entry entry : nested.entrySet()) {
> doc.addField(entry.getKey(), entry.getValue());
> }
> }
> }
> {code}
> Or something entirely new like an annotation for ChildDocuments:
> {code:java}
> public class ChildDocumentsAnnotationListener extends
> AccessorAnnotationListener {
> public ChildDocumentsAnnotationListener(AnnotatedElement element,
> ChildDocuments annotation) {
> super(element, annotation);
> if (!target.isInList || target.clazz.isPrimitive()) {
> throw new BindingException("@NestedDocuments is applicable only
> on List.");
> }
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> List nested = new ArrayList<>();
> for (SolrDocument child : doc.getChildDocuments()) {
> nested.add(binder.getBean(target.clazz, child));// this should be
> recursive, but it's only an example
> }
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> doc.addChildDocuments(nested.getChildDocuments());
> }
> }
> {code}
> In addition, all the logic is encapsulated in the listener, so you can make a
> custom FieldAnnotationListener too, and override the default one
> {code:java}
> public class CustomFieldAnnotationListener extends FieldAnnotationListener {
> private boolean isTransientPresent;
> public CustomFieldAnnotationListener(AnnotatedElement element, Field
> annotation) {
> super(elemen
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194687#comment-14194687
]
Fabio Piro edited comment on SOLR-6645 at 11/3/14 4:24 PM:
---
__Friendly Reminder #2__
Hello, has anyone by any chance taken a look at the patch, between some trick
or treats?
was (Author: dewos):
_Friendly Reminder #2_
Hello, has anyone by any chance taken a look at the patch, between some trick
or treats?
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process.
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
> public FieldObjectAnnotationListener(AnnotatedElement element,
> FieldObject annotation) {
> super(element, annotation);
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> Object nested = binder.getBean(target.clazz, doc);
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> for (Map.Entry entry : nested.entrySet()) {
> doc.addField(entry.getKey(), entry.getValue());
> }
> }
> }
> {code}
> Or something entirely new like an annotation for ChildDocuments:
> {code:java}
> public class ChildDocumentsAnnotationListener extends
> AccessorAnnotationListener {
> public ChildDocumentsAnnotationListener(AnnotatedElement element,
> ChildDocuments annotation) {
> super(element, annotation);
> if (!target.isInList || target.clazz.isPrimitive()) {
> throw new BindingException("@NestedDocuments is applicable only
> on List.");
> }
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> List nested = new ArrayList<>();
> for (SolrDocument child : doc.getChildDocuments()) {
> nested.add(binder.getBean(target.clazz, child));// this should be
> recursive, but it's only an example
> }
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> doc.addChildDocuments(nested.getChildDocuments());
> }
> }
> {c
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14194687#comment-14194687
]
Fabio Piro edited comment on SOLR-6645 at 11/3/14 4:24 PM:
---
*Friendly Reminder #2*
Hello, has anyone by any chance taken a look at the patch, between some trick
or treats?
was (Author: dewos):
__Friendly Reminder #2__
Hello, has anyone by any chance taken a look at the patch, between some trick
or treats?
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process.
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
> public FieldObjectAnnotationListener(AnnotatedElement element,
> FieldObject annotation) {
> super(element, annotation);
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> Object nested = binder.getBean(target.clazz, doc);
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> for (Map.Entry entry : nested.entrySet()) {
> doc.addField(entry.getKey(), entry.getValue());
> }
> }
> }
> {code}
> Or something entirely new like an annotation for ChildDocuments:
> {code:java}
> public class ChildDocumentsAnnotationListener extends
> AccessorAnnotationListener {
> public ChildDocumentsAnnotationListener(AnnotatedElement element,
> ChildDocuments annotation) {
> super(element, annotation);
> if (!target.isInList || target.clazz.isPrimitive()) {
> throw new BindingException("@NestedDocuments is applicable only
> on List.");
> }
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> List nested = new ArrayList<>();
> for (SolrDocument child : doc.getChildDocuments()) {
> nested.add(binder.getBean(target.clazz, child));// this should be
> recursive, but it's only an example
> }
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> doc.addChildDocuments(nested.getChildDocuments());
> }
> }
> {c
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196627#comment-14196627
]
Fabio Piro edited comment on SOLR-6645 at 11/4/14 7:13 PM:
---
*Friendly Reminder #3*
Hello, after some deep searching, I noticed that this topic came up many times
through the years (since 2011):
again (https://issues.apache.org/jira/browse/SOLR-2708) and
again (https://issues.apache.org/jira/browse/SOLR-2446) and
again (https://issues.apache.org/jira/browse/SOLR-1945) and
again (https://issues.apache.org/jira/browse/SOLR-6539) and
again (https://issues.apache.org/jira/browse/SOLR-1494) and
again (some other links here)...
So, am I missing something here? Or did the holy opensource workflow get stuck
somehow?
In conclusion, I now formally propose a DocumentObjectBinder
Alliance [DOBA?].
Anyone who wants to partecipate at this can join in order to mix up all the
best ideas.
We can make the DocumentObjectBinder more extendible and finally merge
something into the core.
Ping:
[~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42],
[~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900],
[~nagarajan.shanmugam], [~avlesh], [~thalain]
was (Author: dewos):
*Friendly Reminder #3*
Hello, after some deep searching, I noticed that this topic came up many times
through the years (since 2011):
again (https://issues.apache.org/jira/browse/SOLR-2708) and
again (https://issues.apache.org/jira/browse/SOLR-2446) and
again (https://issues.apache.org/jira/browse/SOLR-1945) and
again (https://issues.apache.org/jira/browse/SOLR-6539) and
again (https://issues.apache.org/jira/browse/SOLR-1494) and
again (some other links here)...
So, am I missing something here? Or did the holy opensource workflow get stuck
somehow?
In conclusion, I now formally propose a DocumentObjectBinder
Alliance [DOBA?].
Anyone who wants to partecipate on this can join in order to mix up all the
best ideas
to make the DocumentObjectBinder more extendible and finally merge something
into the core.
Ping:
[~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42],
[~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900],
[~nagarajan.shanmugam], [~avlesh], [~thalain]
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process.
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
> public FieldO
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196627#comment-14196627
]
Fabio Piro edited comment on SOLR-6645 at 11/4/14 7:14 PM:
---
*Friendly Reminder #3*
Hello, after some deep searching, I noticed that this topic came up many times
through the years (since 2011):
again (https://issues.apache.org/jira/browse/SOLR-2708) and
again (https://issues.apache.org/jira/browse/SOLR-2446) and
again (https://issues.apache.org/jira/browse/SOLR-1945) and
again (https://issues.apache.org/jira/browse/SOLR-6539) and
again (https://issues.apache.org/jira/browse/SOLR-1494) and
again (some other links here)...
So, am I missing something here? Or did the holy opensource workflow get stuck
somehow?
In conclusion, I now formally propose a DocumentObjectBinder
Alliance [DOBA?].
Anyone who wants to partecipate at this can join in order to mix up all the
best ideas.
We could make the DocumentObjectBinder more extendible and finally merge
something into the core.
!http://www.giornalettismo.com/wp-content/uploads/2012/07/I-Want-To-Believe-the-Alien-Version_4733-l.jpg!
Ping:
[~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42],
[~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900],
[~nagarajan.shanmugam], [~avlesh], [~thalain]
was (Author: dewos):
*Friendly Reminder #3*
Hello, after some deep searching, I noticed that this topic came up many times
through the years (since 2011):
again (https://issues.apache.org/jira/browse/SOLR-2708) and
again (https://issues.apache.org/jira/browse/SOLR-2446) and
again (https://issues.apache.org/jira/browse/SOLR-1945) and
again (https://issues.apache.org/jira/browse/SOLR-6539) and
again (https://issues.apache.org/jira/browse/SOLR-1494) and
again (some other links here)...
So, am I missing something here? Or did the holy opensource workflow get stuck
somehow?
In conclusion, I now formally propose a DocumentObjectBinder
Alliance [DOBA?].
Anyone who wants to partecipate at this can join in order to mix up all the
best ideas.
We can make the DocumentObjectBinder more extendible and finally merge
something into the core.
Ping:
[~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42],
[~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900],
[~nagarajan.shanmugam], [~avlesh], [~thalain]
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process.
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {c
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[ https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196627#comment-14196627 ] Fabio Piro edited comment on SOLR-6645 at 11/4/14 7:15 PM: --- *Friendly Reminder #3* Hello, after some deep searching, I noticed that this topic came up many times through the years (since 2011): again (https://issues.apache.org/jira/browse/SOLR-2708) and again (https://issues.apache.org/jira/browse/SOLR-2446) and again (https://issues.apache.org/jira/browse/SOLR-1945) and again (https://issues.apache.org/jira/browse/SOLR-6539) and again (https://issues.apache.org/jira/browse/SOLR-1494) and again (some other links here)... So, am I missing something here? Or did the holy opensource workflow get stuck somehow? In conclusion, I now formally propose a DocumentObjectBinder Alliance [DOBA?]. Anyone who wants to partecipate at this can join in order to mix up all the best ideas. We could make the DocumentObjectBinder more extendible and finally merge something into the core. Ping: [~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42], [~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900], [~nagarajan.shanmugam], [~avlesh], [~thalain] was (Author: dewos): *Friendly Reminder #3* Hello, after some deep searching, I noticed that this topic came up many times through the years (since 2011): again (https://issues.apache.org/jira/browse/SOLR-2708) and again (https://issues.apache.org/jira/browse/SOLR-2446) and again (https://issues.apache.org/jira/browse/SOLR-1945) and again (https://issues.apache.org/jira/browse/SOLR-6539) and again (https://issues.apache.org/jira/browse/SOLR-1494) and again (some other links here)... So, am I missing something here? Or did the holy opensource workflow get stuck somehow? In conclusion, I now formally propose a DocumentObjectBinder Alliance [DOBA?]. Anyone who wants to partecipate at this can join in order to mix up all the best ideas. We could make the DocumentObjectBinder more extendible and finally merge something into the core. !http://www.giornalettismo.com/wp-content/uploads/2012/07/I-Want-To-Believe-the-Alien-Version_4733-l.jpg! Ping: [~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42], [~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900], [~nagarajan.shanmugam], [~avlesh], [~thalain] > Refactored DocumentObjectBinder and added AnnotationListeners > - > > Key: SOLR-6645 > URL: https://issues.apache.org/jira/browse/SOLR-6645 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 4.10.2 >Reporter: Fabio Piro > Labels: annotations, binder, listener, solrj > Fix For: 5.0, Trunk > > Attachments: SOLR-6645.patch > > > Hello good people. > It is understandable that the priority of SolrJ is to provide a stable API > for java and not a rich-feature client, I'm well aware of that. On the other > hand more features nowadays mean most of the time Spring Solr Data. Although > I appreciate the enrichment work of that lib, sometimes depending on its > monolithic dependencies and magic is not a valid option. > So, I was thinking that the official DocumentObjectBinder could benefit from > some love, and I had implemented a listener pattern for the annotations. > *Note: No new logic or new annotations were introduced, the patch is only a > refactor to make more extendible (for the user) the current > DocumentObjectBinder and @Field DocField.* > You can register your annotations and they relate listeners in the binder, > and it will invoke the corresponding method in the listener on getBean and on > toSolrInputDocument, therefore granting the chance to do something during the > ongoing process. > Changes are: > * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor > for registering the annotations > * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the > former get(), set(), isArray, isList, isContainedInMap etc... > * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing > with @Field > * [ADD] */AnnotationListener*: the base listener class > * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I > hope it's not a problem). > It's all well documented and the code is very easy to read. Tests are all > green, it should be 100% backward compatible and the performance impact is > void (the logic flow is exactly the same as now, and I only changed the bare > essentials and nothing more, anyway). > Some Examples (they are not part of the pull-request): > The long awaited @FieldObject in 4 lines of code: > https://issues.apache.org/jira/browse/SOLR-1945 >
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196627#comment-14196627
]
Fabio Piro edited comment on SOLR-6645 at 11/4/14 7:15 PM:
---
*Friendly Reminder #3*
Hello, after some deep searching, I noticed that this topic came up many times
through the years (since 2011):
again (https://issues.apache.org/jira/browse/SOLR-2708) and
again (https://issues.apache.org/jira/browse/SOLR-2446) and
again (https://issues.apache.org/jira/browse/SOLR-1945) and
again (https://issues.apache.org/jira/browse/SOLR-6539) and
again (https://issues.apache.org/jira/browse/SOLR-1494) and
again (some other links here)...
So, am I missing something here? Or did the holy opensource workflow get stuck
somehow?
In conclusion, I now formally propose a DocumentObjectBinder
Alliance [DOBA?].
Anyone who wants to partecipate at this can join in order to mix up all the
best ideas is welcome.
We could make the DocumentObjectBinder more extendible and finally merge
something into the core.
Ping:
[~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42],
[~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900],
[~nagarajan.shanmugam], [~avlesh], [~thalain]
was (Author: dewos):
*Friendly Reminder #3*
Hello, after some deep searching, I noticed that this topic came up many times
through the years (since 2011):
again (https://issues.apache.org/jira/browse/SOLR-2708) and
again (https://issues.apache.org/jira/browse/SOLR-2446) and
again (https://issues.apache.org/jira/browse/SOLR-1945) and
again (https://issues.apache.org/jira/browse/SOLR-6539) and
again (https://issues.apache.org/jira/browse/SOLR-1494) and
again (some other links here)...
So, am I missing something here? Or did the holy opensource workflow get stuck
somehow?
In conclusion, I now formally propose a DocumentObjectBinder
Alliance [DOBA?].
Anyone who wants to partecipate at this can join in order to mix up all the
best ideas.
We could make the DocumentObjectBinder more extendible and finally merge
something into the core.
Ping:
[~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42],
[~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900],
[~nagarajan.shanmugam], [~avlesh], [~thalain]
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process.
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196627#comment-14196627
]
Fabio Piro edited comment on SOLR-6645 at 11/4/14 7:16 PM:
---
*Friendly Reminder #3*
Hello, after some deep searching, I noticed that this topic came up many times
through the years (since 2011):
again (https://issues.apache.org/jira/browse/SOLR-2708) and
again (https://issues.apache.org/jira/browse/SOLR-2446) and
again (https://issues.apache.org/jira/browse/SOLR-1945) and
again (https://issues.apache.org/jira/browse/SOLR-6539) and
again (https://issues.apache.org/jira/browse/SOLR-1494) and
again (some other links here)...
So, am I missing something here? Or did the holy opensource workflow get stuck
somehow?
In conclusion, I now formally propose a DocumentObjectBinder
Alliance [DOBA?].
Anyone who wants to partecipate at this can join in order to mix up all the
best ideas.
We could make the DocumentObjectBinder more extendible and finally merge
something into the core.
Ping:
[~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42],
[~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900],
[~nagarajan.shanmugam], [~avlesh], [~thalain]
was (Author: dewos):
*Friendly Reminder #3*
Hello, after some deep searching, I noticed that this topic came up many times
through the years (since 2011):
again (https://issues.apache.org/jira/browse/SOLR-2708) and
again (https://issues.apache.org/jira/browse/SOLR-2446) and
again (https://issues.apache.org/jira/browse/SOLR-1945) and
again (https://issues.apache.org/jira/browse/SOLR-6539) and
again (https://issues.apache.org/jira/browse/SOLR-1494) and
again (some other links here)...
So, am I missing something here? Or did the holy opensource workflow get stuck
somehow?
In conclusion, I now formally propose a DocumentObjectBinder
Alliance [DOBA?].
Anyone who wants to partecipate at this can join in order to mix up all the
best ideas is welcome.
We could make the DocumentObjectBinder more extendible and finally merge
something into the core.
Ping:
[~markrmil...@gmail.com] [~01sas], [~killdash9], [~bertbrecht42],
[~glamdring], [~cmale], [~erikx], [~ps742626], [~mstorfjo], [~marks1900],
[~nagarajan.shanmugam], [~avlesh], [~thalain]
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process.
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196684#comment-14196684
]
Fabio Piro edited comment on SOLR-6645 at 11/4/14 7:42 PM:
---
Hi [~bertbrecht42], thanks for the reply.
A *SolrServer#setBinder(DocumentObjectBinderInterface binder)* could be an easy
and pretty solution, but it wouldn't solve the need to (copy and paste\rewrite)
ALL the current impl (at the moment coupled as an inner private class). My
proposal tried to solve this exact problem.
was (Author: dewos):
Hi [~bertbrecht42], thanks for the reply.
A *SolrServer#setBinder(DocumentObjectBinder binder)* could be an easy and
pretty solution, but it wouldn't solve the need to (copy and paste\rewrite) ALL
the current impl (at the moment coupled as an inner private class). My proposal
tried to solve this exact problem.
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process.
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
> public FieldObjectAnnotationListener(AnnotatedElement element,
> FieldObject annotation) {
> super(element, annotation);
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> Object nested = binder.getBean(target.clazz, doc);
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> for (Map.Entry entry : nested.entrySet()) {
> doc.addField(entry.getKey(), entry.getValue());
> }
> }
> }
> {code}
> Or something entirely new like an annotation for ChildDocuments:
> {code:java}
> public class ChildDocumentsAnnotationListener extends
> AccessorAnnotationListener {
> public ChildDocumentsAnnotationListener(AnnotatedElement element,
> ChildDocuments annotation) {
> super(element, annotation);
> if (!target.isInList || target.clazz.isPrimitive()) {
> throw new BindingException("@NestedDocuments is applicable only
> on List.");
> }
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> List nested = new ArrayList<>();
> for (SolrDocument child : doc.getChildDocuments()) {
> nested.add(binder.getBean
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14196684#comment-14196684
]
Fabio Piro edited comment on SOLR-6645 at 11/4/14 7:56 PM:
---
Hi [~bertbrecht42], thanks for the reply.
A *SolrServer#setBinder(BinderInterface binder)* could be an easy and pretty
solution, but it wouldn't solve the need to (copy and paste\rewrite) ALL the
current impl (at the moment coupled as an inner private class). My proposal
tried to solve this exact problem.
was (Author: dewos):
Hi [~bertbrecht42], thanks for the reply.
A *SolrServer#setBinder(DocumentObjectBinderInterface binder)* could be an easy
and pretty solution, but it wouldn't solve the need to (copy and paste\rewrite)
ALL the current impl (at the moment coupled as an inner private class). My
proposal tried to solve this exact problem.
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process. Like this:
> {code:java}
> public static void main(String[] args) {
> Map, Class AnnotationListener>> annotations = new HashMap<>();
> annotations.put(FieldObject.class,
> FieldObjectAnnotationListener.class);
> annotations.put(Document.class, DocumentAnnotationListener.class);
> DocumentObjectBinder binder = new DocumentObjectBinder(annotations);
> SolrServer server = new HttpSolrServer("...");
> server.setBinder(binder);// reusable on many servers
> }
> {code}
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
> public FieldObjectAnnotationListener(AnnotatedElement element,
> FieldObject annotation) {
> super(element, annotation);
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> Object nested = binder.getBean(target.clazz, doc);
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> for (Map.Entry entry : nested.entrySet()) {
> doc.addField(entry.getKey(), entry.getValue());
> }
> }
> }
> {code}
> Or something entirely new like an annotation for ChildDocuments:
> {code:java}
> public class ChildDocumentsAnnotationListener extends
> AccessorAnnotationListener {
> public ChildDocumentsAnnotationListener(Annotated
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198932#comment-14198932
]
Fabio Piro edited comment on SOLR-6645 at 11/5/14 7:37 PM:
---
*Friendly Reminder #3*
Some ideas:
- Document Object Binder Interface?
- Drop setAccessible(true)?
- Use Inspector for properties handling
- More intensive refactor of "DocField", similar to
https://issues.apache.org/jira/browse/SOLR-2708 but less "abstract" and
invasive (clean up all the code)
was (Author: dewos):
Friendly Reminder #3
Some ideas:
- Document Object Binder Interface?
- Drop setAccessible(true)?
- Use Inspector for properties handling
- More intensive refactor of "DocField", similar to
https://issues.apache.org/jira/browse/SOLR-2708 but less "abstract" and
invasive (clean up all the code)
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process. Like this:
> {code:java}
> public static void main(String[] args) {
> Map, Class AnnotationListener>> annotations = new HashMap<>();
> annotations.put(FieldObject.class,
> FieldObjectAnnotationListener.class);
> annotations.put(Document.class, DocumentAnnotationListener.class);
> DocumentObjectBinder binder = new DocumentObjectBinder(annotations);
> SolrServer server = new HttpSolrServer("...");
> server.setBinder(binder);// reusable on many servers
> }
> {code}
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
> public FieldObjectAnnotationListener(AnnotatedElement element,
> FieldObject annotation) {
> super(element, annotation);
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> Object nested = binder.getBean(target.clazz, doc);
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> for (Map.Entry entry : nested.entrySet()) {
> doc.addField(entry.getKey(), entry.getValue());
> }
> }
> }
> {code}
> Or something entirely new like an annotation for ChildDocuments:
> {code:java}
> public class ChildDocumentsAnnotationListener extends
> AccessorAnnotationListener {
> public ChildDocumentsAnnotationListener(AnnotatedElement element,
> ChildDocuments ann
[jira] [Comment Edited] (SOLR-6645) Refactored DocumentObjectBinder and added AnnotationListeners
[
https://issues.apache.org/jira/browse/SOLR-6645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14198932#comment-14198932
]
Fabio Piro edited comment on SOLR-6645 at 11/5/14 7:37 PM:
---
*Friendly Reminder #4*
Some ideas:
- Document Object Binder Interface?
- Drop setAccessible(true)?
- Use Inspector for properties handling
- More intensive refactor of "DocField", similar to
https://issues.apache.org/jira/browse/SOLR-2708 but less "abstract" and
invasive (clean up all the code)
was (Author: dewos):
*Friendly Reminder #3*
Some ideas:
- Document Object Binder Interface?
- Drop setAccessible(true)?
- Use Inspector for properties handling
- More intensive refactor of "DocField", similar to
https://issues.apache.org/jira/browse/SOLR-2708 but less "abstract" and
invasive (clean up all the code)
> Refactored DocumentObjectBinder and added AnnotationListeners
> -
>
> Key: SOLR-6645
> URL: https://issues.apache.org/jira/browse/SOLR-6645
> Project: Solr
> Issue Type: Improvement
> Components: clients - java
>Affects Versions: 4.10.2
>Reporter: Fabio Piro
> Labels: annotations, binder, listener, solrj
> Fix For: 5.0, Trunk
>
> Attachments: SOLR-6645.patch
>
>
> Hello good people.
> It is understandable that the priority of SolrJ is to provide a stable API
> for java and not a rich-feature client, I'm well aware of that. On the other
> hand more features nowadays mean most of the time Spring Solr Data. Although
> I appreciate the enrichment work of that lib, sometimes depending on its
> monolithic dependencies and magic is not a valid option.
> So, I was thinking that the official DocumentObjectBinder could benefit from
> some love, and I had implemented a listener pattern for the annotations.
> *Note: No new logic or new annotations were introduced, the patch is only a
> refactor to make more extendible (for the user) the current
> DocumentObjectBinder and @Field DocField.*
> You can register your annotations and they relate listeners in the binder,
> and it will invoke the corresponding method in the listener on getBean and on
> toSolrInputDocument, therefore granting the chance to do something during the
> ongoing process. Like this:
> {code:java}
> public static void main(String[] args) {
> Map, Class AnnotationListener>> annotations = new HashMap<>();
> annotations.put(FieldObject.class,
> FieldObjectAnnotationListener.class);
> annotations.put(Document.class, DocumentAnnotationListener.class);
> DocumentObjectBinder binder = new DocumentObjectBinder(annotations);
> SolrServer server = new HttpSolrServer("...");
> server.setBinder(binder);// reusable on many servers
> }
> {code}
> Changes are:
> * [MOD] */beans/DocumentObjectBinder*: The new logic and a new constructor
> for registering the annotations
> * [ADD] */impl/AccessorAnnotationListener*: Abstract utility class with the
> former get(), set(), isArray, isList, isContainedInMap etc...
> * [ADD] */impl/FieldAnnotationListener*: all the rest of DocField for dealing
> with @Field
> * [ADD] */AnnotationListener*: the base listener class
> * [MOD] */SolrServer*: added setBinder (this is the only tricky change, I
> hope it's not a problem).
> It's all well documented and the code is very easy to read. Tests are all
> green, it should be 100% backward compatible and the performance impact is
> void (the logic flow is exactly the same as now, and I only changed the bare
> essentials and nothing more, anyway).
> Some Examples (they are not part of the pull-request):
> The long awaited @FieldObject in 4 lines of code:
> https://issues.apache.org/jira/browse/SOLR-1945
> {code:java}
> public class FieldObjectAnnotationListener extends
> AccessorAnnotationListener {
> public FieldObjectAnnotationListener(AnnotatedElement element,
> FieldObject annotation) {
> super(element, annotation);
> }
> @Override
> public void onGetBean(Object obj, SolrDocument doc, DocumentObjectBinder
> binder) {
> Object nested = binder.getBean(target.clazz, doc);
> setTo(obj, nested);
> }
> @Override
> public void onToSolrInputDocument(Object obj, SolrInputDocument doc,
> DocumentObjectBinder binder) {
> SolrInputDocument nested = binder.toSolrInputDocument(getFrom(obj));
> for (Map.Entry entry : nested.entrySet()) {
> doc.addField(entry.getKey(), entry.getValue());
> }
> }
> }
> {code}
> Or something entirely new like an annotation for ChildDocuments:
> {code:java}
> public class ChildDocumentsAnnotationListener extends
> AccessorAnnotationListener {
> public ChildDocumentsAnnotationListener(AnnotatedElement element,
> ChildDocuments a
