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

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@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@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@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@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@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@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@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@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