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(a)hibernate.org&gt; http://hibernate.org

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_guide/ 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(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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.html 2011/3/30 Steve Ebersole <steve(a)hibernate.org&gt;: > 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_guid >> 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(a)hibernate.org&gt; >> > http://hibernate.org >> > _______________________________________________ >> > hibernate-dev mailing list >> > hibernate-dev(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > --- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)hibernate.org&gt;: > 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(a)hibernate.org&gt;: >> > 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(a)hibernate.org&gt; >> >> > >> >> > http://hibernate.org >> >> > >> >> > _______________________________________________ >> >> > >> >> > hibernate-dev mailing list >> >> > >> >> > hibernate-dev(a)lists.jboss.org >> >> > >> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > >> > --- >> > >> > Steve Ebersole <steve(a)hibernate.org&gt; >> > >> > http://hibernate.org >> > >> > _______________________________________________ >> > >> > hibernate-dev mailing list >> > >> > hibernate-dev(a)lists.jboss.org >> > >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > --- > > Steve Ebersole <steve(a)hibernate.org&gt; > > http://hibernate.org

On Mar 30, 2011, at 8:46 PM, Steve Ebersole wrote: > 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. Well, just that when users (programmers) see such a file there's a higher chance that they know what it's doing and how is the services discovery working. Apart from that, can't think of anything :)

Heh sorry, pasted the wrong link :) This should be the right one: http://java.sun.com/developer/technicalArticles/javase/extensible/index.htm l Anyway, the mechanism/names were standardized as part of Java 6. That's e.g. how CDI extensions are discovered: http://docs.jboss.org/weld/reference/1.1.0.Final/en-US/html/extend.html#d0 e4848 It also looks like there is some support in Java6: http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html But as Hibernate aims Java5 we can't use that, although we can use the same file name. Adam On Mar 30, 2011, at 6:40 PM, Steve Ebersole wrote: > 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_gui > > de/ 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(a)hibernate.org&gt; > > > http://hibernate.org > > > _______________________________________________ > > > hibernate-dev mailing list > > > hibernate-dev(a)lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > --- > Steve Ebersole <steve(a)hibernate.org&gt; > http://hibernate.org

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(a)hibernate.org&gt; http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

btw. any way to disable specific discovery items ? i.e. I would like to not have search and envers enabled when the tools are doing query plans/executions since it then suddenly requires much more configuration to have it setup and run.

There is one for search too. But should we have a global flag to disable all integrations? Does it makes sense (what about Bean Validation for example? On 31 mars 2011, at 20:08, Adam Warski wrote: > On Mar 31, 2011, at 12:05 PM, Max Rydahl Andersen wrote: >> btw. any way to disable specific discovery items ? >> i.e. I would like to not have search and envers enabled when the tools >> are doing query plans/executions since it then suddenly requires much >> more configuration to have it setup and run. > > There's a > > hibernate.listeners.envers.autoRegister > > config property, is that what you need? _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev