I need to write it down but the sum up is there
https://issues.jboss.org/browse/TAG-47 Unfortunately the discussion happened on
a non public mailing list.
The problem always happens at the borders. I cannot in good conscience consider
ConstraintValidator or FieldBridge contracts for advanced us
An SPI is a contract that a user would implement, but also a contract
the need to implement such a contract.
For example, take SessionImplementor from ORM. It is the SPI contract
for Session. Most other SPI contracts pass SessionImplementor as an
argment, or make it available in some fashion
Hi,
> What's your definition of an SPI
I think an SPI is something which the user implements (as you say
typically advanced users which need to plug-in custom functionality
into the framework) opposed to an API, which is something which a user
just uses/invokes.
> That's the proposal I have pus
On 2 avr. 2012, at 11:44, Hardy Ferentschik wrote:
>>
>> What's your definition of an SPI, in the team we have slightly different
>> ones.
>>
>> In Hibernate search an SPI is targeted at frameworks or hyper advanced user
>> who are willing to integrate or enhance Hibernate Search. Otherwise,
On 2 April 2012 10:44, Hardy Ferentschik wrote:
>
> On Apr 2, 2012, at 11:16 AM, Emmanuel Bernard wrote:
>
>> What's your definition of an SPI, in the team we have slightly different
>> ones.
>>
>> In Hibernate search an SPI is targeted at frameworks or hyper advanced user
>> who are willing to
On Apr 2, 2012, at 11:16 AM, Emmanuel Bernard wrote:
> What's your definition of an SPI, in the team we have slightly different ones.
>
> In Hibernate search an SPI is targeted at frameworks or hyper advanced user
> who are willing to integrate or enhance Hibernate Search. Otherwise, they are
What's your definition of an SPI, in the team we have slightly different ones.
In Hibernate search an SPI is targeted at frameworks or hyper advanced user who
are willing to integrate or enhance Hibernate Search. Otherwise, they are
considered APIs - which includes interfaces you might need to i
Hi,
related to my earlier mail on deprecations there's another thought I'd
like to discuss.
When evolving an SPI (typically *implemented* by clients), other
restrictions apply than when evolving an API (typically *used* by
clients). More specifically, it's no problem to add new methods to an
API
