[hibernate-dev] [HSEARCH] [Autodiscoverable] Splitting the BridgeProvider in two methods

[Emmanuel Bernard]

On 02 Apr 2014, at 03:04, Sanne Grinovero <sanne at hibernate.org> wrote:
>>> Another concern is that if the answer to can… and create… are inconsistent, we are in trouble.
>> 
>> Well, if canProvideBridgeFor returns true it should create the bridge when provide is called. Unless there is of course an (runtime) error when creating
>> the bridge. However, this would throw an exception. If the bridge provider does not behave this way, you have indeed a bug, but I don’t see the big difference
>> to this type of bug to any other implementation error.
> 
> What I meant is that in certain situations the state of the
> underlaying service might change between invocations. Let's say your
> bridge implementor is configured via an external resource, containing
> like a list of things it's supposed to handle. Now let's assume that
> this can be reconfigured at runtime (crazy stuff which seems common in
> OSGi world, but also not too unusual via JMX): at one moment of time,
> your implementation could say "yes I can", and right after be forced
> to return null or throw an exception.
> True, you could classify this as an "implementation error" .. but if I
> where that developer I wouldn't be sure how to fix it, while a single
> method API would have been straight forward.
> 
> We might not expect these things to be configured at runtime, but we
> had several examples in which things which where expected to be quite
> "static" have later needed to be refactored in mutable things. If you
> take the MutableSearchFactory and our complex boot, I guess you
> immediatly see what kind of pain I'm referring to when we need to fix
> such an assumption in a second phase.


I don’t think you argument is relevant in this situation.
The situation you describe would also mean that we should guessType every time we need a bridge rather than onces at startup. It would also mean that because of the shape of the moon the application would boot or fail (see duplication logic). In other wiords, having two methods would be the least of our problems :)