On 21 avr. 2011, at 05:43, Steve Ebersole wrote: > I think this new API for creating a SessionFactory is starting to firm > up, so I wanted to put out another call for feedback before we get too > close to Alpha3. So at a high level there are 2 pieces of information > needed to build the SessionFactory: the ServiceRegistry and the Metadata. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The ServiceRegistry is built through a ServiceRegistryBuilder (this is a > slight recent change) > > Map config = ...; > ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( config ) > ... > .buildServiceRegistry(); > > The "..." allows you to add service instances and service initiators. > Currently any (map of) configuration values is passed in the > constructor. I can be convinced to allow adding/setting of config > values as well, if everyone has a preference for that approach: > > Map config = ...; > ServiceRegistry serviceRegistry = new ServiceRegistryBuilder() > .setConfigurationData( config ) > .setOption( Environment.SHOW_SQL, > true ) > ... > .buildServiceRegistry(); > > Not sure the best method names there, to be honest which is why I opted > for passing them to ctor. Is that a Map<Object,Object> or something a bit more refined? Regardless of the map being passed to the ctor, I'd think you need to ability to set additional options (like you setOptions) Alternative names: option: setting Not really related but, now that Configuration is gone, we lose some of the type safety (like cfg.setNamingStrategy(new MyNamingStrategy() ), or am I forgetting something in how the service registry works? > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > Metadata is built through a MetadataSources which represents the sources > of metadata information. > > MetadataSources metadataSources = new MetadataSources( serviceRegistry ) > .addResource( "some.hbm.xml" ) > .addAnnotatedClass( SomeEntity.class ); > Metadata metadata = metadataSources.buildMetadata(); > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > The Metadata is then used to obtain a SessionFactory. > > SessionFactory sf = metadata.buildSessionFactory(); > > > Metadata represents the "configuration time" mapping information. As of > now we will allow users to manipulate and otherwise access this > information, hence the seeming "intermediate step". These all work with > chaining: > > SessionFactory sf = new MetadataSources( serviceRegistry ) > .addResource( "some.hbm.xml" ) > .addAnnotatedClass( SomeEntity.class ) > .buildMetadata() > .buildSessionFactory(); > I guess you could have a buildMetadataSources() hosted on ServiceRegistry if you want people to use chaining methods all the way.

My preference would go to a MetadataSources#setMetadata(NamingStrategy) My fear is that more functions could be needed overtime and make the constructor or the buildMetadata signature cluttered and less readable. On 21 avr. 2011, at 15:08, Steve Ebersole wrote: > NamingStrategy is not a service. It is solely a function of building the metadata. > > Currently, again, I have this set up via ctor param passing: > > new MetadataSources( reg, new MyNamingStrategy() ) > > Really its not logically part of the source, its needed during the transition from source->metadata, so an alternative I have been contemplating is: > > new MetadataSources( reg ).buildMetadata( new MyNamingStrategy() ) > > I am open to other suggestions. I really am trying to keep in mind the scope in which stuff is needed/useful/valid. > > > On 04/21/2011 03:11 AM, Emmanuel Bernard wrote: >> >> On 21 avr. 2011, at 05:43, Steve Ebersole wrote: >> >>> I think this new API for creating a SessionFactory is starting to firm >>> up, so I wanted to put out another call for feedback before we get too >>> close to Alpha3. So at a high level there are 2 pieces of information >>> needed to build the SessionFactory: the ServiceRegistry and the Metadata. >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> The ServiceRegistry is built through a ServiceRegistryBuilder (this is a >>> slight recent change) >>> >>> Map config = ...; >>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( config ) >>> ... >>> .buildServiceRegistry(); >>> >>> The "..." allows you to add service instances and service initiators. >>> Currently any (map of) configuration values is passed in the >>> constructor. I can be convinced to allow adding/setting of config >>> values as well, if everyone has a preference for that approach: >>> >>> Map config = ...; >>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder() >>> .setConfigurationData( config ) >>> .setOption( Environment.SHOW_SQL, >>> true ) >>> ... >>> .buildServiceRegistry(); >>> >>> Not sure the best method names there, to be honest which is why I opted >>> for passing them to ctor. >> >> Is that a Map<Object,Object> or something a bit more refined? >> >> Regardless of the map being passed to the ctor, I'd think you need to ability to set additional options (like you setOptions) >> >> Alternative names: >> option: setting >> >> Not really related but, now that Configuration is gone, we lose some of the type safety (like cfg.setNamingStrategy(new MyNamingStrategy() ), or am I forgetting something in how the service registry works? >> >>> >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> Metadata is built through a MetadataSources which represents the sources >>> of metadata information. >>> >>> MetadataSources metadataSources = new MetadataSources( serviceRegistry ) >>> .addResource( "some.hbm.xml" ) >>> .addAnnotatedClass( SomeEntity.class ); >>> Metadata metadata = metadataSources.buildMetadata(); >>> >>> >>> >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>> >>> The Metadata is then used to obtain a SessionFactory. >>> >>> SessionFactory sf = metadata.buildSessionFactory(); >>> >>> >>> Metadata represents the "configuration time" mapping information. As of >>> now we will allow users to manipulate and otherwise access this >>> information, hence the seeming "intermediate step". These all work with >>> chaining: >>> >>> SessionFactory sf = new MetadataSources( serviceRegistry ) >>> .addResource( "some.hbm.xml" ) >>> .addAnnotatedClass( SomeEntity.class ) >>> .buildMetadata() >>> .buildSessionFactory(); >>> >> >> I guess you could have a buildMetadataSources() hosted on ServiceRegistry if you want people to use chaining methods all the way. > > -- > Steve Ebersole&lt;steve(a)hibernate.org&gt; > http://hibernate.org

I think we can converge by using the following approach. https://gist.github.com/942450 Check the meeting logs, we have discussed the idea further. BTW it occurred to me that MetadataSources is more a builder than anything else, should it be renamed to align with the service registry approach? On 22 avr. 2011, at 20:43, Steve Ebersole wrote: > I do not disagree, especially about the clutter. I had two related concerns with that this approach though: > 1) minor, but this thing is then no longer just collecting the sources of metadata which is what a MetadataSources is. > 2) this is no longer a "directed API" at all. What do I mean by that? Well: > > MetadataSources sources = new MetadataSources(...); > sources.setNamingStrategy( strategy1 ); > sources.addResource( "some/resource.xml" ); > sources.setNamingStrategy( strategy2 ); > sources.addResource( "some/resource2.xml" ); > > We are not "directing" the users to the correct usage of the API by the design of the API itself. > > > Here is another option: > MetadataSources sources = new MetadataSources(...) > ... > .getMetadataBuilder() > .setNamingStrategy( ... ) > .buildMetadata(); > > Now the naming strategy is associated with this "metadata builder" which is more semantically correct. But this is a bit verbose for today since I can only think of naming strategy as falling into this bucket. > > > On 04/22/2011 03:37 AM, Emmanuel Bernard wrote: >> My preference would go to a MetadataSources#setMetadata(NamingStrategy) >> >> My fear is that more functions could be needed overtime and make the constructor or the buildMetadata signature cluttered and less readable. >> >> >> On 21 avr. 2011, at 15:08, Steve Ebersole wrote: >> >>> NamingStrategy is not a service. It is solely a function of building the metadata. >>> >>> Currently, again, I have this set up via ctor param passing: >>> >>> new MetadataSources( reg, new MyNamingStrategy() ) >>> >>> Really its not logically part of the source, its needed during the transition from source->metadata, so an alternative I have been contemplating is: >>> >>> new MetadataSources( reg ).buildMetadata( new MyNamingStrategy() ) >>> >>> I am open to other suggestions. I really am trying to keep in mind the scope in which stuff is needed/useful/valid. >>> >>> >>> On 04/21/2011 03:11 AM, Emmanuel Bernard wrote: >>>> >>>> On 21 avr. 2011, at 05:43, Steve Ebersole wrote: >>>> >>>>> I think this new API for creating a SessionFactory is starting to firm >>>>> up, so I wanted to put out another call for feedback before we get too >>>>> close to Alpha3. So at a high level there are 2 pieces of information >>>>> needed to build the SessionFactory: the ServiceRegistry and the Metadata. >>>>> >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> >>>>> The ServiceRegistry is built through a ServiceRegistryBuilder (this is a >>>>> slight recent change) >>>>> >>>>> Map config = ...; >>>>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( config ) >>>>> ... >>>>> .buildServiceRegistry(); >>>>> >>>>> The "..." allows you to add service instances and service initiators. >>>>> Currently any (map of) configuration values is passed in the >>>>> constructor. I can be convinced to allow adding/setting of config >>>>> values as well, if everyone has a preference for that approach: >>>>> >>>>> Map config = ...; >>>>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder() >>>>> .setConfigurationData( config ) >>>>> .setOption( Environment.SHOW_SQL, >>>>> true ) >>>>> ... >>>>> .buildServiceRegistry(); >>>>> >>>>> Not sure the best method names there, to be honest which is why I opted >>>>> for passing them to ctor. >>>> >>>> Is that a Map<Object,Object> or something a bit more refined? >>>> >>>> Regardless of the map being passed to the ctor, I'd think you need to ability to set additional options (like you setOptions) >>>> >>>> Alternative names: >>>> option: setting >>>> >>>> Not really related but, now that Configuration is gone, we lose some of the type safety (like cfg.setNamingStrategy(new MyNamingStrategy() ), or am I forgetting something in how the service registry works? >>>> >>>>> >>>>> >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> >>>>> Metadata is built through a MetadataSources which represents the sources >>>>> of metadata information. >>>>> >>>>> MetadataSources metadataSources = new MetadataSources( serviceRegistry ) >>>>> .addResource( "some.hbm.xml" ) >>>>> .addAnnotatedClass( SomeEntity.class ); >>>>> Metadata metadata = metadataSources.buildMetadata(); >>>>> >>>>> >>>>> >>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> >>>>> The Metadata is then used to obtain a SessionFactory. >>>>> >>>>> SessionFactory sf = metadata.buildSessionFactory(); >>>>> >>>>> >>>>> Metadata represents the "configuration time" mapping information. As of >>>>> now we will allow users to manipulate and otherwise access this >>>>> information, hence the seeming "intermediate step". These all work with >>>>> chaining: >>>>> >>>>> SessionFactory sf = new MetadataSources( serviceRegistry ) >>>>> .addResource( "some.hbm.xml" ) >>>>> .addAnnotatedClass( SomeEntity.class ) >>>>> .buildMetadata() >>>>> .buildSessionFactory(); >>>>> >>>> >>>> I guess you could have a buildMetadataSources() hosted on ServiceRegistry if you want people to use chaining methods all the way. >>> >>> -- >>> Steve Ebersole&lt;steve(a)hibernate.org&gt; >>> http://hibernate.org >> > > -- > Steve Ebersole&lt;steve(a)hibernate.org&gt; > http://hibernate.org

Builder is a generic term. The specific function served here is that of a set of sources for metadata. The same does not hold for ServiceRegistryBuilder. It does not hold a singular type of information. In fact initially I shied away from the name ServiceRegistryBuilder because of its genericness. But in the end decided to use it because it would be familiar to developers. On 04/26/2011 11:05 AM, Emmanuel Bernard wrote: > I think we can converge by using the following approach. > https://gist.github.com/942450 > > Check the meeting logs, we have discussed the idea further. > > BTW it occurred to me that MetadataSources is more a builder than > anything else, should it be renamed to align with the service registry > approach? > > On 22 avr. 2011, at 20:43, Steve Ebersole wrote: > >> I do not disagree, especially about the clutter. I had two related >> concerns with that this approach though: >> 1) minor, but this thing is then no longer just collecting the >> sources of metadata which is what a MetadataSources is. >> 2) this is no longer a "directed API" at all. What do I mean by that? >> Well: >> >> MetadataSources sources = new MetadataSources(...); >> sources.setNamingStrategy( strategy1 ); >> sources.addResource( "some/resource.xml" ); >> sources.setNamingStrategy( strategy2 ); >> sources.addResource( "some/resource2.xml" ); >> >> We are not "directing" the users to the correct usage of the API by >> the design of the API itself. >> >> >> Here is another option: >> MetadataSources sources = new MetadataSources(...) >> ... >> .getMetadataBuilder() >> .setNamingStrategy( ... ) >> .buildMetadata(); >> >> Now the naming strategy is associated with this "metadata builder" >> which is more semantically correct. But this is a bit verbose for >> today since I can only think of naming strategy as falling into this >> bucket. >> >> >> On 04/22/2011 03:37 AM, Emmanuel Bernard wrote: >>> My preference would go to a MetadataSources#setMetadata(NamingStrategy) >>> >>> My fear is that more functions could be needed overtime and make the >>> constructor or the buildMetadata signature cluttered and less readable. >>> >>> >>> On 21 avr. 2011, at 15:08, Steve Ebersole wrote: >>> >>>> NamingStrategy is not a service. It is solely a function of >>>> building the metadata. >>>> >>>> Currently, again, I have this set up via ctor param passing: >>>> >>>> new MetadataSources( reg, new MyNamingStrategy() ) >>>> >>>> Really its not logically part of the source, its needed during the >>>> transition from source->metadata, so an alternative I have been >>>> contemplating is: >>>> >>>> new MetadataSources( reg ).buildMetadata( new MyNamingStrategy() ) >>>> >>>> I am open to other suggestions. I really am trying to keep in mind >>>> the scope in which stuff is needed/useful/valid. >>>> >>>> >>>> On 04/21/2011 03:11 AM, Emmanuel Bernard wrote: >>>>> >>>>> On 21 avr. 2011, at 05:43, Steve Ebersole wrote: >>>>> >>>>>> I think this new API for creating a SessionFactory is starting to >>>>>> firm >>>>>> up, so I wanted to put out another call for feedback before we >>>>>> get too >>>>>> close to Alpha3. So at a high level there are 2 pieces of >>>>>> information >>>>>> needed to build the SessionFactory: the ServiceRegistry and the >>>>>> Metadata. >>>>>> >>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> >>>>>> The ServiceRegistry is built through a ServiceRegistryBuilder >>>>>> (this is a >>>>>> slight recent change) >>>>>> >>>>>> Map config = ...; >>>>>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( >>>>>> config ) >>>>>> ... >>>>>> .buildServiceRegistry(); >>>>>> >>>>>> The "..." allows you to add service instances and service >>>>>> initiators. >>>>>> Currently any (map of) configuration values is passed in the >>>>>> constructor. I can be convinced to allow adding/setting of config >>>>>> values as well, if everyone has a preference for that approach: >>>>>> >>>>>> Map config = ...; >>>>>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder() >>>>>> .setConfigurationData( config ) >>>>>> .setOption( Environment.SHOW_SQL, >>>>>> true ) >>>>>> ... >>>>>> .buildServiceRegistry(); >>>>>> >>>>>> Not sure the best method names there, to be honest which is why I >>>>>> opted >>>>>> for passing them to ctor. >>>>> >>>>> Is that a Map<Object,Object> or something a bit more refined? >>>>> >>>>> Regardless of the map being passed to the ctor, I'd think you need >>>>> to ability to set additional options (like you setOptions) >>>>> >>>>> Alternative names: >>>>> option: setting >>>>> >>>>> Not really related but, now that Configuration is gone, we lose >>>>> some of the type safety (like cfg.setNamingStrategy(new >>>>> MyNamingStrategy() ), or am I forgetting something in how the >>>>> service registry works? >>>>> >>>>>> >>>>>> >>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> >>>>>> Metadata is built through a MetadataSources which represents the >>>>>> sources >>>>>> of metadata information. >>>>>> >>>>>> MetadataSources metadataSources = new MetadataSources( >>>>>> serviceRegistry ) >>>>>> .addResource( "some.hbm.xml" ) >>>>>> .addAnnotatedClass( SomeEntity.class ); >>>>>> Metadata metadata = metadataSources.buildMetadata(); >>>>>> >>>>>> >>>>>> >>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>> >>>>>> The Metadata is then used to obtain a SessionFactory. >>>>>> >>>>>> SessionFactory sf = metadata.buildSessionFactory(); >>>>>> >>>>>> >>>>>> Metadata represents the "configuration time" mapping information. >>>>>> As of >>>>>> now we will allow users to manipulate and otherwise access this >>>>>> information, hence the seeming "intermediate step". These all >>>>>> work with >>>>>> chaining: >>>>>> >>>>>> SessionFactory sf = new MetadataSources( serviceRegistry ) >>>>>> .addResource( "some.hbm.xml" ) >>>>>> .addAnnotatedClass( SomeEntity.class ) >>>>>> .buildMetadata() >>>>>> .buildSessionFactory(); >>>>>> >>>>> >>>>> I guess you could have a buildMetadataSources() hosted on >>>>> ServiceRegistry if you want people to use chaining methods all the >>>>> way. >>>> >>>> -- >>>> Steve Ebersole&lt;steve(a)hibernate.org&gt; >>>> http://hibernate.org >>> >> >> -- >> Steve Ebersole&lt;steve(a)hibernate.org&gt; >> http://hibernate.org >

I've forked your gist adding comments and my own proposal https://gist.github.com/943902 On 27 avr. 2011, at 00:51, Gail Badner wrote: > I was getting lost trying to follow this email thread, IRC logs, private conversations, and the confusion due to a typo, so I created a gist page (https://gist.github.com/943347). > > I've tried to summarizes the alternatives and added a couple of my own. I've also included some open questions that need to be resolved. > > I've omitted stuff from when we were confused by the typo. > > Maybe it confuses things even more to put info in yet another place (gist), but I was getting so confused, it's at least helped me to get things straight. > > ----- Original Message ----- > From: "Steve Ebersole&quot;&lt;steve(a)hibernate.org&gt; > To: "Emmanuel Bernard&quot;&lt;emmanuel(a)hibernate.org&gt; > Cc: hibernate-dev(a)lists.jboss.org > Sent: Tuesday, April 26, 2011 11:47:12 AM > Subject: Re: [hibernate-dev] Building a SessionFactory > > John just pointed out a type here that caused everyone some confusion. > I apologize. > > MetadataSources sources = new MetadataSources(...) > ... > .getMetadataBuilder() > .setNamingStrategy( ... ) > .buildMetadata(); > > should really read: > > Metadata metadata = new MetadataSources(...) > ... > .getMetadataBuilder() > .setNamingStrategy( ... ) > .buildMetadata(); > > > On 04/26/2011 11:43 AM, Steve Ebersole wrote: >> Builder is a generic term. The specific function served here is that of >> a set of sources for metadata. >> >> The same does not hold for ServiceRegistryBuilder. It does not hold a >> singular type of information. In fact initially I shied away from the >> name ServiceRegistryBuilder because of its genericness. But in the end >> decided to use it because it would be familiar to developers. >> >> On 04/26/2011 11:05 AM, Emmanuel Bernard wrote: >>> I think we can converge by using the following approach. >>> https://gist.github.com/942450 >>> >>> Check the meeting logs, we have discussed the idea further. >>> >>> BTW it occurred to me that MetadataSources is more a builder than >>> anything else, should it be renamed to align with the service registry >>> approach? >>> >>> On 22 avr. 2011, at 20:43, Steve Ebersole wrote: >>> >>>> I do not disagree, especially about the clutter. I had two related >>>> concerns with that this approach though: >>>> 1) minor, but this thing is then no longer just collecting the >>>> sources of metadata which is what a MetadataSources is. >>>> 2) this is no longer a "directed API" at all. What do I mean by that? >>>> Well: >>>> >>>> MetadataSources sources = new MetadataSources(...); >>>> sources.setNamingStrategy( strategy1 ); >>>> sources.addResource( "some/resource.xml" ); >>>> sources.setNamingStrategy( strategy2 ); >>>> sources.addResource( "some/resource2.xml" ); >>>> >>>> We are not "directing" the users to the correct usage of the API by >>>> the design of the API itself. >>>> >>>> >>>> Here is another option: >>>> MetadataSources sources = new MetadataSources(...) >>>> ... >>>> .getMetadataBuilder() >>>> .setNamingStrategy( ... ) >>>> .buildMetadata(); >>>> >>>> Now the naming strategy is associated with this "metadata builder" >>>> which is more semantically correct. But this is a bit verbose for >>>> today since I can only think of naming strategy as falling into this >>>> bucket. >>>> >>>> >>>> On 04/22/2011 03:37 AM, Emmanuel Bernard wrote: >>>>> My preference would go to a MetadataSources#setMetadata(NamingStrategy) >>>>> >>>>> My fear is that more functions could be needed overtime and make the >>>>> constructor or the buildMetadata signature cluttered and less readable. >>>>> >>>>> >>>>> On 21 avr. 2011, at 15:08, Steve Ebersole wrote: >>>>> >>>>>> NamingStrategy is not a service. It is solely a function of >>>>>> building the metadata. >>>>>> >>>>>> Currently, again, I have this set up via ctor param passing: >>>>>> >>>>>> new MetadataSources( reg, new MyNamingStrategy() ) >>>>>> >>>>>> Really its not logically part of the source, its needed during the >>>>>> transition from source->metadata, so an alternative I have been >>>>>> contemplating is: >>>>>> >>>>>> new MetadataSources( reg ).buildMetadata( new MyNamingStrategy() ) >>>>>> >>>>>> I am open to other suggestions. I really am trying to keep in mind >>>>>> the scope in which stuff is needed/useful/valid. >>>>>> >>>>>> >>>>>> On 04/21/2011 03:11 AM, Emmanuel Bernard wrote: >>>>>>> >>>>>>> On 21 avr. 2011, at 05:43, Steve Ebersole wrote: >>>>>>> >>>>>>>> I think this new API for creating a SessionFactory is starting to >>>>>>>> firm >>>>>>>> up, so I wanted to put out another call for feedback before we >>>>>>>> get too >>>>>>>> close to Alpha3. So at a high level there are 2 pieces of >>>>>>>> information >>>>>>>> needed to build the SessionFactory: the ServiceRegistry and the >>>>>>>> Metadata. >>>>>>>> >>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>> >>>>>>>> The ServiceRegistry is built through a ServiceRegistryBuilder >>>>>>>> (this is a >>>>>>>> slight recent change) >>>>>>>> >>>>>>>> Map config = ...; >>>>>>>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder( >>>>>>>> config ) >>>>>>>> ... >>>>>>>> .buildServiceRegistry(); >>>>>>>> >>>>>>>> The "..." allows you to add service instances and service >>>>>>>> initiators. >>>>>>>> Currently any (map of) configuration values is passed in the >>>>>>>> constructor. I can be convinced to allow adding/setting of config >>>>>>>> values as well, if everyone has a preference for that approach: >>>>>>>> >>>>>>>> Map config = ...; >>>>>>>> ServiceRegistry serviceRegistry = new ServiceRegistryBuilder() >>>>>>>> .setConfigurationData( config ) >>>>>>>> .setOption( Environment.SHOW_SQL, >>>>>>>> true ) >>>>>>>> ... >>>>>>>> .buildServiceRegistry(); >>>>>>>> >>>>>>>> Not sure the best method names there, to be honest which is why I >>>>>>>> opted >>>>>>>> for passing them to ctor. >>>>>>> >>>>>>> Is that a Map<Object,Object> or something a bit more refined? >>>>>>> >>>>>>> Regardless of the map being passed to the ctor, I'd think you need >>>>>>> to ability to set additional options (like you setOptions) >>>>>>> >>>>>>> Alternative names: >>>>>>> option: setting >>>>>>> >>>>>>> Not really related but, now that Configuration is gone, we lose >>>>>>> some of the type safety (like cfg.setNamingStrategy(new >>>>>>> MyNamingStrategy() ), or am I forgetting something in how the >>>>>>> service registry works? >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>> >>>>>>>> Metadata is built through a MetadataSources which represents the >>>>>>>> sources >>>>>>>> of metadata information. >>>>>>>> >>>>>>>> MetadataSources metadataSources = new MetadataSources( >>>>>>>> serviceRegistry ) >>>>>>>> .addResource( "some.hbm.xml" ) >>>>>>>> .addAnnotatedClass( SomeEntity.class ); >>>>>>>> Metadata metadata = metadataSources.buildMetadata(); >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>>>>> >>>>>>>> The Metadata is then used to obtain a SessionFactory. >>>>>>>> >>>>>>>> SessionFactory sf = metadata.buildSessionFactory(); >>>>>>>> >>>>>>>> >>>>>>>> Metadata represents the "configuration time" mapping information. >>>>>>>> As of >>>>>>>> now we will allow users to manipulate and otherwise access this >>>>>>>> information, hence the seeming "intermediate step". These all >>>>>>>> work with >>>>>>>> chaining: >>>>>>>> >>>>>>>> SessionFactory sf = new MetadataSources( serviceRegistry ) >>>>>>>> .addResource( "some.hbm.xml" ) >>>>>>>> .addAnnotatedClass( SomeEntity.class ) >>>>>>>> .buildMetadata() >>>>>>>> .buildSessionFactory(); >>>>>>>> >>>>>>> >>>>>>> I guess you could have a buildMetadataSources() hosted on >>>>>>> ServiceRegistry if you want people to use chaining methods all the >>>>>>> way. >>>>>> >>>>>> -- >>>>>> Steve Ebersole&lt;steve(a)hibernate.org&gt; >>>>>> http://hibernate.org >>>>> >>>> >>>> -- >>>> Steve Ebersole&lt;steve(a)hibernate.org&gt; >>>> http://hibernate.org >>> >> > > -- > Steve Ebersole&lt;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