[hibernate-dev] Integrator locator

Steve Ebersole steve at hibernate.org
Wed Mar 30 16:09:11 EDT 2011


What I mean is this...

Lets say we want to allow users to plug in a ConnectionProvider by this 
method.  How do they get configuration information into this service?  Thats 
why our file is slightly different, you have key/value pairs allowed.  The 
required key is implClass to name your impl.  But you might have general 
configuration.

To be honest, whats probably better in our set up is to allow detection of 
what I called service initiators, since the initiator could configure the 
service before returning it.  So maybe this is a moot point.


On Wednesday, March 30, 2011, at 02:45 pm, Gunnar Morling wrote:
> Each provider configuration file can contain multiple implementations
> of the given interface. From the JavaDoc of j.u.ServiceLoader: "The
> file contains a list of fully-qualified binary names of concrete
> provider classes, one per line".
> 
> From how I understood your original requirement/implementation, I
> think j.u.ServiceLoader should be exactly what you need.
> 
> 2011/3/30 Steve Ebersole <steve at hibernate.org>:
> > To be honest not sure what this really buys you. Basically you have to
> > follow the META-INF/service/{intf-name} pattern for naming your locator
> > file and that locator file, as far as I know, can only have a single
> > entry naming the impl class. Which is kind of limiting. What concrete
> > benefits do you actually get then? The actual resolution code is
> > trivial.
> > 
> > On Wednesday, March 30, 2011, at 12:21 pm, Gunnar Morling wrote:
> >> Hi,
> >> 
> >> 
> >> 
> >> since Java 1.6 this functionality is provided by
> >> 
> >> java.util.ServiceLoader [1] so when you are based on JDK 6 anyway you
> >> 
> >> could simply use that class.
> >> 
> >> 
> >> 
> >> When targeting older JDKs one indeed must build it from hand (HV does
> >> 
> >> this for instance, too). Sun's JDK has contained this utility for
> >> 
> >> quite a while, but it was not part of the public API before JDK 6.
> >> 
> >> 
> >> 
> >> --Gunnar
> >> 
> >> 
> >> 
> >> [1]
> >> 
> >> http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.htm
> >> l
> >> 
> >> 2011/3/30 Steve Ebersole <steve at hibernate.org>:
> >> > This is exactly what I have done.  There is no standard java mechanism
> >> > 
> >> > for doing this.  Your link simply shows how one piece of java (Sound
> >> > 
> >> > API) does it.
> >> > 
> >> > On Wednesday, March 30, 2011, at 11:22 am, Adam Warski wrote:
> >> >> Did you think about using the java services mechanism? Essentialy
> >> >> 
> >> >> placing a file in META-INF/services:
> >> >> 
> >> >> 
> >> >> http://download.oracle.com/javase/1.4.2/docs/guide/sound/programmer_g
> >> >> uid
> >> >> 
> >> >> e/ chapter13.html ?
> >> >> 
> >> >> 
> >> >> 
> >> >> I don't think it gives any functionality, but is a standard way for
> >> >> 
> >> >> doing such things.
> >> >> 
> >> >> 
> >> >> 
> >> >> Adam
> >> >> 
> >> >> On Mar 27, 2011, at 7:27 PM, Steve Ebersole wrote:
> >> >> > HHH-5562 is done, which introduces a locator/discovery means for
> >> >> > 
> >> >> > integrating with Hibernate.  Specifically it introduces the
> >> >> > (alternate
> >> >> > 
> >> >> > name suggestions welcome, i am indifferent to this one)
> >> >> > 
> >> >> > org.hibernate.impl.Integrator interface.
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > It does discovery based on a classpath lookup for a well-defined
> >> >> > 
> >> >> > filename (can discover multiple) which names an implementor of this
> >> >> > 
> >> >> > interface. The process occurs in the midst of Sessionfactory
> >> >> > building
> >> >> > 
> >> >> > to account for the main use cases I know of including Envers,
> >> >> > Search,
> >> >> > 
> >> >> > Validation and BV.  Currently I additionally define those 4 as
> >> >> > "built
> >> >> > 
> >> >> > in" integrators, meaning there is no need for them to define
> >> >> > 
> >> >> > auto-discovery files unless we want them to be integrated in that
> >> >> > 
> >> >> > manner (I know for example that Search is interested in this via
> >> >> > 
> >> >> > HSEARCH-595).  Anyway, we should probably decide pretty early which
> >> >> > 
> >> >> > integrations we want done which way.
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > Actually I take one part back.  Envers is actually handed by
> >> >> > discovery
> >> >> > 
> >> >> > due to the fact that it is in a separate project (jar).  The others
> >> >> > 
> >> >> > were done this way because they already had the reflection code in
> >> >> > 
> >> >> > place to do this.  So for it, we need to decide if we want to go
> >> >> > the
> >> >> > 
> >> >> > opposite way.
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > 
> >> >> > ---
> >> >> > 
> >> >> > Steve Ebersole <steve at hibernate.org>
> >> >> > 
> >> >> > http://hibernate.org
> >> >> > 
> >> >> > _______________________________________________
> >> >> > 
> >> >> > hibernate-dev mailing list
> >> >> > 
> >> >> > hibernate-dev at lists.jboss.org
> >> >> > 
> >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> > 
> >> > ---
> >> > 
> >> > Steve Ebersole <steve at hibernate.org>
> >> > 
> >> > http://hibernate.org
> >> > 
> >> > _______________________________________________
> >> > 
> >> > hibernate-dev mailing list
> >> > 
> >> > hibernate-dev at lists.jboss.org
> >> > 
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> > ---
> > 
> > Steve Ebersole <steve at hibernate.org>
> > 
> > http://hibernate.org

---
Steve Ebersole <steve at hibernate.org>
http://hibernate.org



More information about the hibernate-dev mailing list