On 2 Jan 2014, at 23:20, Emmanuel Bernard wrote:
> Hardy, I am starting to come along your side on this discussion. They key
> things that made me swing is that if a user needs a special annotation to
> customize the bridge, then it’s equivalent to a @FieldBridge.
Exactly. And parameters you
On 2 April 2014 22:20, Emmanuel Bernard wrote:
> Please everyone and especially Sanne, read this branch of the exchange Hardy
> and I have. We need another pair of eyes to make sure we don’t mess things up
> as it is an important departure compared to how things are done today (and in
> my prot
Please everyone and especially Sanne, read this branch of the exchange Hardy
and I have. We need another pair of eyes to make sure we don’t mess things up
as it is an important departure compared to how things are done today (and in
my prototype).
Hardy, I am starting to come along your side on
On 2 Jan 2014, at 17:37, Emmanuel Bernard wrote:
> Yes your analysis is correct.
Cool, so we seem to be on the same page then.
> I do think 3 is the most valuable but that 2c is a relatively close second.
+1 for case #3 being the most important one. I would even go so far to say that
this is
Yes your analysis is correct.
I would clarify that 3 or 2c don’t have to apply on already supported return
types, it is more likely custom types like JodaTime types.
I do think 3 is the most valuable but that 2c is a relatively close second.
Now the @Spatial and @TikaBridge annotations do have a
On 1 Jan 2014, at 22:07, Hardy Ferentschik wrote:
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
>> ## Handling duplicates
>>
>> I had in mind the following logic.
>>
>> Prevent custom bridge providers to offer bridges in the same situation.
I am still trying to wrap my head around
On 2 Jan 2014, at 03:04, Sanne Grinovero wrote:
> On 1 April 2014 21:19, Hardy Ferentschik wrote:
>>
>> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>>
>>> ## Splitting the BridgeProvider in two methods
>>>
>>> A way make the inelegant code structure
>>>
>>> FieldBridge bridge = prov
On 1 Jan 2014, at 22:55, Gunnar Morling wrote:
> 2014-04-01 22:19 GMT+02:00 Hardy Ferentschik :
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
> > ## Splitting the BridgeProvider in two methods
>
>
> FWIW, I side with those preferring a single method and doing a null check.
>
> It'
On 1 April 2014 21:19, Hardy Ferentschik wrote:
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
>> ## Splitting the BridgeProvider in two methods
>>
>> A way make the inelegant code structure
>>
>>FieldBridge bridge = provider.provide(…);
>>if ( bridge != null ) {
>>return
2014-04-01 22:19 GMT+02:00 Hardy Ferentschik :
>
> On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
>
> > ## Splitting the BridgeProvider in two methods
> >
> > A way make the inelegant code structure
> >
> >FieldBridge bridge = provider.provide(...);
> >if ( bridge != null ) {
> >
On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
> ## Implementation of the service loader based discovery
>
> Hardy proposes to make each BridgeProvider a Service in the ServiceManager
> sense.
It is right? We allow users to provide their implementations.
> The idea being that when we make
On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
> ## AnnotatedElement
>
> Hardy does not like us being tied to the actual physical annotation objects.
> I tend to agree with him as we would need to fake it for free-form entities.
> Since he worked on Jandex and the ORM side of parsing, he wil
On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
> ## Splitting the BridgeProvider in two methods
>
> A way make the inelegant code structure
>
>FieldBridge bridge = provider.provide(…);
>if ( bridge != null ) {
>return bridge
>}
>
> Is to ask of the provider to answer two
On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
> ## Handling duplicates
>
> I had in mind the following logic.
>
> Prevent custom bridge providers to offer bridges in the same situation.
What do you mean with "in the same situation”? You mean there cannot be two
bridge providers for the sa
On 1 Jan 2014, at 16:36, Emmanuel Bernard wrote:
> ## References to field bridges
>
> Despite being on an internal class, some implementations (Infinispan remove
> query at least) uses direct references to FieldBridge.SOME_BRIDGE.
IMO, they should not. There is a unnecessary coupling here. Ea
There has been a lot of discussions on the PR. Let me try and sum up my next
steps and bootstrap some discussions.
To comment on a specific subject, create a separate thread per subject or this
thread will be come a huge radiated tree :)
## @IndexedEmbedded and null
Apparently both Sanne and I
16 matches
Mail list logo
