emmanuel: hello everyone
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
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: Which I think keep the API as he wants while still avoiding the constructor
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
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
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]
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
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
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
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
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
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: 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
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
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
emmanuel: The other approach it seems to me is some kind of "interceptor" let me
hardy: sounds good, but I would not know if it holds all the way
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
- 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
- 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
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
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
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
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
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
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
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,
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: 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,
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
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
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
emmanuel: the API will prevent it
hardy: but as Steve said, setting the naming strategy is not really about collecting
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
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
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
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: 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
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
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
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: 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
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
emmanuel: gbadner: hardy you guys are too yong. Back in my days, DOM4J was the dream of
jpav: It uses a "pull" approach rather than the "push" approach used
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
gbadner: really, that's the part that I like about the jaxb-generated classes
jpav: From where?
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
emmanuel: hardy: sanne about the dead line, I'm tryin to clear the mud and see what it
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