[hibernate-dev] Meeting logs since Max's bot failed us

[Emmanuel Bernard]

emmanuel: hello everyone
gbadner: hi
emmanuel: have you guys started the meeting?
jpav: you just did I think 
hardy: seems like it
sannegrinovero: hi emmanuel, no not yet
jpav: no one started the bot yet
emmanuel: #startmeeting
jpav: I don't think the bot is even running
emmanuel: maxandersen: BOOOOOOOOOT
emmanuel: Ok nevermind let's start
emmanuel: someone can send his logs
emmanuel: Has anyone followed the discussion around the SessionFActory API?
emmanuel: The email thread between Steve and I is the latest I think
emmanuel: What do you think of it?
emmanuel: Thought of improvements?
hardy: not from my side
smarlow [~smarlow at redhat/jboss/smarlow] entered the room. (17:09:07)
emmanuel: Based on the latest exchange from Steve, I thoguht of this
emmanuel: https://gist.github.com/942450
emmanuel: Which I think keep the API as he wants while still avoiding the constructor trap
emmanuel: OK it does not seem people ahve put thoughts on it. Have a look at what has been proposed and trya nd give some feedback to steve in the next day or two.
emmanuel: Topic number 2: what to do with EJB3Configuration?
emmanuel: Let me summarize,
sannegrinovero: it looks like to make sense to me, but I'm not that aware of the core requirements.
gbadner: yes, I like it
stliu: what's the initial idea? merge it into somewhere?
emmanuel: In H4, we now have a ServiceregistryBuilder building a ServiceRegistry
and a MetadataSources object that creates a Metadata object 
From the Metadata object you get the SessionFActory
emmanuel: In H3.x, we had a Configuration object that was responsible for the role taken by ServiceRegistryBuilder/ServiceRegistry and Metadatasources/Metadata
smarlow left the room (quit: Ping timeout: 240 seconds). (17:14:34)
emmanuel: And we had a sister class Ejb3Configuration that was used by users to set some of the properties like NamingStrategy, annotated classes etc
emmanuel: Except that this Ejb3Configuration was building an EntityManagerFactory
emmanuel: So the question is how do we move what Ejb3Cofiguration does today in the H4 model
emmanuel: a. we keep it as is and use the new model underneath
b. we expose a model similar to the new H4 model but that builds an EMF
c. non of the above 
emmanuel: It should be noted that Ejb3configuration has a bunch of rules written in it that are specific to the specification
emmanuel: so this code has to be somewhere
hardy: fyi, this relates to issues HHH-6149 and HHH-6159
jbossbot: jira [HHH-6149] Clean up EJB3Configuration [Open (Unresolved) Improvement, Major, Steve Ebersole] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6149
jbossbot: jira [HHH-6159] Determine best way to handle EntityManagerFactory building (EJB3Configuration) [Open (Unresolved) Task, Major, Steve Ebersole] http://opensource.atlassian.com/projects/hibernate/browse/HHH-6159
emmanuel: hardy: gbadner have you guys had to dig a bit into the Ejb3configuration code?
sannegrinovero: do you want to support building both an EMF and a SessionFactory from the same base metadata ans serviceregistry?
gbadner: no, I haven't
hardy: i have not either yet
emmanuel: sannegrinovero: not necessarily but we need to keep the flexibility for users to set all of the Hibernate concepts in a JPA configuration
sannegrinovero: b. seems to be the most natural approach to me; I assume that the built EntityManagerFactory will be able to properly mandate the spec specifics.. maybe wrapping some metadata it needs with some spec-mandating adaptor.
sannegrinovero is now known as sanne (17:20:16)
emmanuel: sanne: yes I tend to agree with you
emmanuel: I'm not sure we will be able to keep the ServiceRegistryBuilder "as is" or if we will need a JPAServiceREgistryBuilder
emmanuel: (to mandate the rules)
gbadner: emmanuel, in https://gist.github.com/942450 , do you enter a new context by calling .usingContext() again?
sanne: I have no idea, but don't see why the registry would need any specific feature which wouldn't be useful to core as well. it's not that the registry needs to respect the spec.
sanne: so any additional feature you need there, you can make it in the true and only ServiceRegistryBuilder
emmanuel: gbadner: well context might not be the right term but the idea is that you are done with the "sources" and you want to give a different flavor to your Metadata object. For example bu default we use the DEfaultNamibngStrategy but you can override that using unsingContext() to set your own naming strategy
emmanuel: is that clearer?
emmanuel: usingContext() will return a specific object that will host the following methods: setNamingStrategy() and buildMetadata()
gbadner: but how do you leave that context?
emmanuel: note that buildMetadata is a method hosted on MetadataSources as well
emmanuel: buildMetadata() leaves the context
gbadner: hmm
emmanuel: other names: usingContext(), withOptions(), getMetadataWithOptions() etc
emmanuel: It's an approach we have used in Bean Validation to allow extensibility and it has worked well (that's where usingContext() comes from but the name is more appropriate in the BV case)
gbadner: is it necessary to change contexts?
emmanuel: Not if you want to use the default naming strategy
smarlow [~smarlow at redhat/jboss/smarlow] entered the room. (17:28:01)
emmanuel: sanne: for example, the set of event listeners is different in JPA than in raw Hibernate, I forgot where event listeners are defined but I think they are services or provided by a service
gbadner: did you mention it in the email thread?
emmanuel: sanne: so you need to enforce that the right services are used in case you want to build an EMF
emmanuel: gbadner: no it's an new idea or more precisely a twist on the latest proposal by Steve
gbadner: oh, ok; how about if we move the discussion to https://gist.github.com/942450 then
gbadner: I'll add comments there
sanne: emmanuel, right. but the EMF will be able to ask the service registry to "produce" the services it needs and ignore the others.. at least that's what I'd expect.
emmanuel: steve was proposing to go to an intermediary step getMetadataBuilder()
emmanuel: to finally build the SF
emmanuel: My latest proposal avoid this intermediary step *unless* you want to customize NamingStrategy
gbadner: oh, ok; I like this gist thingy
emmanuel: sanne: The EMF is a SessionFactory underneath so it will ask the event listener service or whatever its name it
emmanuel: s
emmanuel: sanne: But n the case of JPA one must enforce that this service is the sanctioned JPA version by default at least
emmanuel: does that make sense?
sanne: yes, but doing so it will "ask" for the EJB3 flavour of the listeners, I guess. I mean it's the EMF which will ask for the specific listeners it wants.
emmanuel: sanne: no, the EMF won't ask for even listeners
emmanuel: the underlying SF will
emmanuel: and this underlying SF does not know it is an EMF core if you will
smarlow left the room (quit: Ping timeout: 260 seconds). (17:33:44)
emmanuel: it will ask for event-listener-service, not jpa-event-listener-service
sjacobs left the room (quit: Quit: Leaving). (17:33:53)
sanne: ahh got it. so let's assume the serviceRegistry is able to produce "flushListeners" and "EJBFlushListeners", but the factory (both type) on top don't know which one they need. there whe can wrap the serviceresgitry to "translate" the generic request for a flushlistener to actually ask for the specific type
sanne: so the ServiceRegistry implementation would be able to produce any kind of service [in knows of], and we can optionally but a thin layer around it to translate request to specific implementations.
emmanuel: sanne: It's more like this. Today the Ejb3Configuration is responsible for pushing a listener service that answers with the EJB3 listeners so it essentially set the ServiceRegistryBuilder with this noew service implementation
emmanuel: sanne: so I was thinking of an JPAServiceRegistryBuilder having different defaults than the RawServiceRegistryBuilder
sanne: right. and nothing stops you to have this implementation as a very small adaptation of the Raw one.
emmanuel: and the ServiceRegistry returned by JPAServiceRegostryBuilder would return the JPAaware listener service
emmanuel: sanne: exactly
emmanuel: And it seems we would have the same logic for the MetadataSources (which is a builder really as well)
emmanuel: I'm not 100% sure this approach will work but I think we should give it a try
hardy: +1
emmanuel: The other approach it seems to me is some kind of "interceptor" let me gist something
hardy: sounds good, but I would not know if it holds all the way
emmanuel: https://gist.github.com/942507
sanne: the pattern sound close to what we did for ages with Search configuration, regarding parameters to apply to batch/transactional/default and for shards too.
sanne: b == builder ?
emmanuel: sanne: yep sorry
emmanuel: fixed now
emmanuel: But for MetadataSources, I think we would need to ahve our own JPAMetadataBuilder implementation
 - we need to return an EMF
sanne: and would the "wash" implementation actually change the ServiceRegistryBuilder or return a wrapper ?
emmanuel: sanne: no in this case we could return a raw ServiceRegistryBuilder
emmanuel: I guess
sanne: I'd prefer to consider the original builder as an immutable thing, and return the EJB3ServiceRegistryBuilder as an adaptor on top of the original
emmanuel: But for MetadataSources, I think we would need to ahve our own JPAMetadataBuilder implementation
 - we need to return an EMF
 - we need to look for sources via META-INF/persistence.xml
 - we need to implement PersistenceProvider contracts
gbadner: is there an advantage of "washing" over using JPAServiceRegistryBuilder?
emmanuel: sanne: yes I like that too but historically speaking, maintaining Ejb3configuration and Configuration was an annoyance
emmanuel: gbadner: it avoids the duplication of code (API)
emmanuel: but it's less natural for the user I think
sanne: sure, but having "if (ejb3) then / else" in most methods .. any better ?
gbadner: couldn't JPAServiceRegistryBuilder extend ServiceRegistryBuilder ?
emmanuel: sanne: no the washer would not have if(ejb3)...
smarlow [~smarlow at redhat/jboss/smarlow] entered the room. (17:47:03)
sanne: (again, I have no experience maintaining this so please do as your instinct tells)
emmanuel: it would force the builder settings
emmanuel: and then let it go with these new settings
emmanuel: I think it's easy enough to try both approaches but since we will very likely need a JPAMetadataSources class, being consistent and ahve a JPAServiceRegistryBuilder seems cleaner to me
gbadner: sorry, I'm not following; probably because I'm not familiar w/ the differences
emmanuel: gbadner: that's ok, it's fine if at least one of you challenge me so that I can get all of my ideas out and Steve can crunch all these logs and understand the problem better 
emmanuel: I think we have put a lot of material and options already
gbadner: I'm kind of foggy in the head
gbadner: I like the "wash" idea if there will be other types
emmanuel: Third topic
"package name changes, core is moving along, but i do not think  
any other modules have even been started.  Do we want to do that in  
bulk?" Steve is talking about envers, entitymanager, etc I think
emmanuel: I don't have much opinion.
gbadner: emmanuel, actually, I think I may have a lucid comment about "wash" vs JPAServiceRegistryBuilder
gbadner: where would JPAWash or JPAServiceRegistryBuilder live?
hardy: emmanuel: I don't think package renames are so important atm
emmanuel: in the entitymanager module
gbadner: ok, then JPAWash would not be able to take advantage of package-protected methods
hardy: i think we can do this in bulk once we have all these other things in place
emmanuel: gbadner: unlikely. That can be a problem indeed
gbadner: I really don't like public setters
emmanuel: though it could use the classes int he private packages
gbadner: I would really prefer subclassing w/ protected setters
emmanuel: gbadner: I've had realllllly bad experiences with subclassing. Check AnnotationConfiguration
gbadner: oh, ok;
emmanuel: It was basically a mess
smarlow left the room (quit: Read error: Connection reset by peer). (17:56:00)
gbadner: I'll take a look
emmanuel: Not that Ejb3Configuration (which uses delegation) is much better  but at least Ejb3Configuration is doing a lot of work
hardy: was this hte reason for using delegation in the firt place?
emmanuel: hardy: yep
hardy: Steve and I were wondering the other day why EJB3Configuration was different
emmanuel: and the fact that we needed to return EMF
emmanuel: and not SF
hardy: ok
kevinpollet left the room (quit: Quit: kevinpollet). (17:57:47)
smarlow [~smarlow at redhat/jboss/smarlow] entered the room. (17:58:04)
emmanuel: gbadner: you had a question on overriding of @Entity, @Mappedsuperclass, @Embeddable
gbadner: yes
sanne: actually it could use package protected methods, as long as you use the same packages. not sure that's the plan of course 
gbadner: emmanuel, I have some other ideas about JPAServiceRegistryBuilder
emmanuel: I think the answer is yes you can override them as long as they "fully" override the metadata for a class
gbadner: but, I'll add them as comments
emmanuel: gbadner: go ahead if you want
gbadner: ok
gbadner: as it stands today, overriding fundamentally changes the metadata
hardy: gbadner: ?
gbadner: for example, an EntityBinding might have to be replaced by a ComponentBinding
hardy: for a single configuration a class cannot be an Entity and Mappedsuperclass
stliu: gbadner, override a @Entity with <mappedsuperclass> is undefinded in spec, right?
gbadner: emmanuel says that it is possible
hardy: say a class is annotated with @Entity and we have a xml configuration which is meta data complete and configured the class as MappedSuperClass
gbadner: yeah
emmanuel: gbadner: whoever builds the EntityBinding/ComponentBinding etc must take both XML and annotations into consideration and chose the right binding object
hardy: in the end you have a MappedSuperClass
gbadner: I'm thinking that we have to really process all the sources (including overrides) before building the final bindings
hardy: exactly
emmanuel: +1
stliu: yes, that's the idea
gbadner: we've talked about having multiple buildMetadata() in different contexts
gbadner: we really need to have a final "really build the full metamodel" step
hardy: buildMetadata()  - that's it
hardy: once that is called we build the metadata
gbadner: hardy, look at https://gist.github.com/942450
hardy: buildMetadata() is buildMetadata()
gbadner: iiuc, there can be multiple buildMetadata() in different contexts
gbadner: sec, I'll add to that page
smarlow left the room (quit: Ping timeout: 250 seconds). (18:09:31)
jpav: in the gist example, is there any reason why you wouldn't use something that reads more like .usingAnnotatedClasses(…).usingNamingStrategy(…).buildMetadata()?
jpav: I guess I still don't get the purpose of the usingContext() piece in the middle
smarlow [~smarlow at redhat/jboss/smarlow] entered the room. (18:10:28)
hardy: i think we are trying to solve a different problem here
gbadner: I just added to https://gist.github.com/942450#comments
hardy: obviously you could have setNamingStrategy( new MyNamingStrategy() ) on MetadataSource as well
emmanuel: gbadner: you cannot add a resource once either usingContext or buildMetadata has been called
emmanuel: the API will prevent it
hardy: but as Steve said, setting the naming strategy is not really about collecting sources
hardy: right
hardy: usingContext just creates  a hopefully more understandable api for the user
gbadner: can there only be 1 naming stategy?
hardy: for a single MetadataSources yes
gbadner: I thought there was just one MetadataSources?
emmanuel: hardy: actually for a single Metadata object
hardy: fair enough
emmanuel: but from the same MetadataSources, you can create many Metadata objects and thus set them to different NStragegies
emmanuel: At least in theory
emmanuel: I'm not sure we will implement this for 4.0
gbadner: there can be multiple Metadata?
smarlow left the room (quit: Ping timeout: 250 seconds). (18:16:27)
emmanuel: gbadner: let me rephrase it. One SessionFactory comes from One Metadata which comes from one MetadataSources which is associated with One ServiceRegistry which comes from OneServiceRegistryBuilder
gbadner: ok, yes, that was what I thought
emmanuel: but from one ServiceRegistry I could in theory create multiple MetadataSources etc incl SessionFActories
emmanuel: so is that a wrap for the meeting?
emmanuel: Can somebody with a decent logging system push the logs to hibernate-dev for Steve
emmanuel: IRC logs I mean
hardy: I wanted to discuss jaxb again 
gbadner: hardy, will you be around for a bit?
hardy: gbadner: a bit
emmanuel: ahah ok
emmanuel: TBH I wanted to discuss HSearch 4 as well
gbadner: I'd like to get more into this MetadataSources stuff
emmanuel: but that can be between hardy and sanne
hardy: on the core mailing list related to the AS 7 beta 3 release they were talking about jaxb again
emmanuel: hardy: yes they tread JAXB like the root of all evil 
hardy: as max pointed out today again, there they moved away from jaxb
hardy: right
emmanuel: s/tread/treat/
hardy: Infinispan uses Jaxb
hardy: but there is an issue for looking for improvements / alternatives as well
hardy: the thing is no one seems to have real numbers
gbadner: these jaxb-generated classes are a whole lot nicer to work with than dom4j
sanne: well as JAXB is part of JRE with Java6, I didn't understand where the "rule" to stay away from jaxb comes from. unlikely to be a classload isolation problem?
jpav: What are the prominent issues with JAXB?
emmanuel: hardy: it was speed
hardy: we also use a StAX + JAXB approach where the input source comes via a StAX reader whatever that means
emmanuel: most XML was parsed with JAXB in JBoss AS and it was a significant part of their boot time for 7
emmanuel: so they got rid of it
hardy: right, but did they do JAX out of the box or the JAXB + StAX approach?
hardy: and what are we going to do?
emmanuel: hardy: I don't know the various dialects of chinese 
hardy: he he
emmanuel: hardy: ask them
hardy: right, we definitely should
hardy: we could also compare the parsing times between the existing DOM apporach and JAXB just to have numbers
sanne: and even if it's 2% slower, it's not realy that hibernate is parsing XMLs all the time..
hardy: provided of course we think that using JAXB makes parsing really easier
hardy: sanne: that's what I am thinking
gbadner: using JAXB makes parsing much easier
emmanuel: sanne: well HbmBinder was 20 or 25% slower than AnnotationBinder
emmanuel: it's not 2% we're talking about
emmanuel: and init time is something people yell about 
emmanuel: (in Hibernate)
stliu: curious, how many improvement AS get after get rid of jaxb?
hardy: the question is what we are talking about (time wise)
emmanuel: but as I said, ask them on the ml and make your case
emmanuel: that'll be instructive for all of us
sanne: emmanuel, yes that;s a point, even for our own tests. but I wonder if those numbers are still like that with a modern jaxb (it wasn't jaxb you're referring to right?)
sanne: stliu, no doubt AS7 is impressively fast, would be sad if it where to slow down because of us only.
emmanuel: sanne: it was JBossXB our impl of JAXB
emmanuel: which was faster than Sun's
sanne: ho!
hardy: never heard of JBossXB
emmanuel: but unless we have a full chain it will be hard to see what is slow
stliu: me either...
smarlow_ [~smarlow at redhat/jboss/smarlow] entered the room. (18:29:52)
gbadner: tbh, I think it's worthwhile to get things worked out using jaxb, even if we ultimately have to go back to dom4j
hardy: wau
hardy: well, I don't think that dom4j is the option
hardy: afaiu it would be the pure StAX API
hardy: however this looks like
gbadner: oh, ok
hardy: personally I would like to avoid to cut all this code first against JAXB, just to replace it afterwards
emmanuel: hardy: so I'd say trya and get something up and running from start to end even if you don't support everything
emmanuel: and in parallel go and have fun on the ml and argue with these guys 
emmanuel: Anything else?
hardy: not from my side
gbadner: Stax API looks similar to dom4j
hardy: that's my understanding as well
gbadner: yuck
jpav: Stax is far more efficient, and doesn't build an entire model like dom4j does
gbadner: but parsing is fugly
jpav: But its API is similar to dom4j, so it doesn't "look" like you're parsing
emmanuel: gbadner: hardy you guys are too yong. Back in my days, DOM4J was the dream of parsing 
jpav: It uses a "pull" approach rather than the "push" approach used by dom4j
hardy: emmanuel: yeah right
gbadner: yeah, I'm too young; people tell me that all the time
jpav: IOW, tree components are built only after you ask for them
gbadner: jpav, is there a way to programatically access the xsd to know what the valid attributes/elements are?
gbadner: really, that's the part that I like about the jaxb-generated classes
jpav: From where?
gbadner: hmm
smarlow_ left the room (quit: Ping timeout: 250 seconds). (18:40:43)
jpav: I guess you mean the stax parser itself?  If so, not that I know of
gbadner: the thing that's a real pain w/ dom4j is that it's easy to ask for an attribute that does not exist
gbadner: w/ the jaxb-generated classes, it would be a compile-failure
emmanuel: hardy: sanne: About HSearch 4: Sorry I had to kick the bee's nest
galderz left the room (quit: Quit: Leaving.). (18:42:47)
sanne: emmanuel, well done. problem is you didn't expect such a wishlist 
emmanuel: Let's do two setps:
 - finish the collect and put stuff in the wiki
sanne: are you serious about the june deadline ?
galderz [~Adium at redhat/jboss/galderz] entered the room. (18:43:21)
hardy: the deadline is a killer
emmanuel:  - order the list into must have, nice to have etc
smarlow_ [~smarlow at redhat/jboss/smarlow] entered the room. (18:43:59)
emmanuel: then we can split the time into must do and "free" time to get what is dear to ones heart in the release
sanne: ok
hardy: ok
emmanuel: hardy: sanne about the dead line, I'm tryin to clear the mud and see what it really is
emmanuel: but get the collect and fill the wiki
emmanuel: I think we are done for the meeting, so let's call it a day. gbadner and hardy needed to talk

Emmanuel