15:04:14 <sebersole> #startmeeting
15:04:14 <jbott> Meeting started Mon Jun 20 15:04:14 2011 UTC.  The chair is sebersole. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:04:14 <jbott> Useful Commands: #action #agreed #help #info #idea #link #topic.
15:04:18 <hardy_> even though it was a couple of hours I pulled
15:04:46 <sebersole> so this wed is Beta2
15:05:03 <sebersole> i've already set that up in jira
15:05:52 <hardy_> so we have bi-weekly releases now, right?
15:06:00 <sebersole> hardy_: yep
15:06:27 <sebersole> hardy_: how close do you think you are to building metamodel for the "general" case?
15:07:09 <sebersole> so no secondary tables
15:07:22 <sebersole> hopefully with associations
15:07:28 <hardy_> still a fair bit
15:07:45 <hardy_> i focused initially one as you called it some low hanging fruits
15:08:05 <hardy_> and now I am back and components
15:08:18 <hardy_> but I am also atm in Germany, since I am at Jazoon this week
15:08:19 <sebersole> ok
15:08:46 <sebersole> so components wont get done it sounds like?
15:08:52 <hardy_> i was wondering how the hbm side is progressing
15:09:02 <hardy_> there were not so many checkins recently
15:09:21 <gbadner> I've been focusing on getting stuff into the persisters
15:09:29 <sebersole> i dont think it has
15:09:37 <sebersole> i have been focusing on apis
15:09:46 <sebersole> since thats really the crux for Betas
15:09:56 <hardy_> ok
15:10:09 <sebersole> i had just happened to miss entity mode initially for Beta1
15:10:18 <stliu> i was on the prod said and waiting for hardy :)
15:10:59 <sebersole> hardy_: so, components will or will not be done for wed?
15:11:42 <sebersole> also, are associations handled from annotations side?
15:11:43 <hardy_> no (unless I have an extremely good day torrow)
15:12:13 <hardy_> as much as in the hbm side
15:12:26 <sebersole> so basically none
15:12:43 <hardy_> many to one
15:12:54 <sebersole> yep
15:13:31 <sebersole> well luckily the last api i think we need to address is NamingStrategy
15:13:37 <stliu> hardy_, the change you made all pushed to master or still some on your local?
15:14:06 <hardy_> everything worth pushing is pushed
15:14:14 <sebersole> but we really cannot move on NamingStrategy until the metamodel itself is more stable
15:14:58 <sebersole> oh, and entitymanager
15:15:04 <hardy_> on a side note, could someone please download a dist package from here and tell me whether you can unpack it? I had some problems and don't want to annouce the release until I know it works
15:15:19 <sebersole> for core?
15:15:33 <sebersole> which dist?
15:15:41 <hardy_> Validator 4.2.0.Final
15:15:45 <sebersole> url?
15:15:48 <hardy_> ahh  - I forgot the link http://sourceforge.net/projects/hibernate/files/hibernate-validator/4.2.0.Final/
15:16:08 * sebersole tries
15:16:40 <sebersole> btw, how did you add those notes?
15:17:19 <hardy_> you mean readme and changelog?
15:17:23 <hardy_> I just uploaded them
15:17:48 <hardy_> problem was that I tried first the web ui, but it failed due to my slow connection and then I re-uploaded via sftp
15:18:13 <sebersole> hardy_: so you just upload files with specific names?
15:18:24 <hardy_> yes
15:18:37 <sebersole> hardy_: the tgz opens for me
15:18:46 <hardy_> ok then
15:18:53 <sebersole> did not try zip
15:19:18 <hardy_> cool
15:19:55 <sebersole> i'll talk to you later about notes :)
15:19:59 <hardy_> i might have downloaded the dist bundle while the updated was not yet available on all servers
15:20:02 <stliu> btw, for core, we have some downstream jobs in hudson which download core job's dist artifact and unpack it and using it as dependency for testing
15:20:20 <sebersole> nice
15:20:30 <hardy_> interesting
15:20:34 <sebersole> dist as in SF?
15:21:14 <sebersole> even just a job to download and unpack
15:21:14 <stliu> yep, hibernate core hudson job just build a dist release like what you do in release
15:21:31 <sebersole> right, but not THE dist
15:21:40 <sebersole> not the files from sourceforge
15:21:52 <stliu> right
15:22:08 <stliu> and downstream job (tck jobs) use that dist for testing
15:22:17 <stliu> i guess validator can use this approach too
15:22:18 <hardy_> sebersole: speaking of the dist on sourceforge, did you ever write a script for uploading the packages?
15:22:25 <sebersole> after i automate the uploading to sourceforge i'll add a task to dl it and unpack :)
15:22:33 <sebersole> hardy_: ^^
15:22:36 <sebersole> :D
15:22:45 <hardy_> i think we talked once about further automating the build process
15:22:50 <sebersole> right
15:23:01 <sebersole> docs, sourceforge
15:23:21 <hardy_> exactly
15:23:23 <sebersole> maybe even announcing
15:23:24 <stliu> smarlow, will as7 upgrade to validator 4.2.0.Final?
15:23:50 <smarlow> stliu:  can you ask shelly, she was talking about that
15:24:13 <sebersole> jpav: you almost doen with entity mode?
15:24:21 <hardy_> sebersole: the actually uploads are quite simple, but you need to build in some error handling etc into the scripts
15:24:42 <hardy_> stliu: from my perspective as7 should switch to Validator 4.2.0.Final now
15:24:43 <jpav> It's not entity mode I'm really dealing with, rather the integrators
15:24:55 <jpav> And I'm still a ways off from completing these
15:25:00 <sebersole> integrators how?
15:25:09 <jpav> Need to ask hardy_ some questions after the meeting
15:25:17 <sebersole> wrt classloading?
15:25:19 <jpav> Getting them to work with the new metadata
15:25:36 <hardy_> jpav: ok
15:25:38 <jpav> no, wrt how entitylisteners are dealt with by jandex
15:25:48 <sebersole> ok
15:26:03 <sebersole> so then you are not doing anything with the model and entity mode?
15:26:25 <jpav> no, those questions I had before were just for my own understanding
15:26:31 <sebersole> didnt we talk about that
15:26:33 <sebersole> ah
15:26:34 <sebersole> ok
15:27:01 <gbadner> I was going to work on entity modes
15:27:05 <jpav> That all started from some code in the integrator that was dealing with only one mode, so I was just curious as to why the other modes were excluded
15:27:10 <sebersole> gbadner: in the model?
15:27:17 <gbadner> but I'm just focusing on pojo for now
15:27:23 <sebersole> i already did the runtime changes
15:27:31 <gbadner> yeah, I saw that
15:27:58 <gbadner> I saw there were changes; haven't had a chance to see what changed though
15:28:04 <gbadner> did you change it in the model?
15:28:11 <sebersole> gbadner: not yet
15:28:17 <sebersole> not in the build time model
15:28:22 <gbadner> ok, are you doing that then?
15:28:26 <sebersole> in the persisters/tuplizers yes
15:28:32 <sebersole> i can
15:28:37 <sebersole> its a trivial change in the metamodel
15:28:49 <gbadner> basically just have one?
15:28:56 <gbadner> instead of all 3?
15:29:08 <sebersole> each "thing" needs to have a field to state what its mode is
15:29:15 <sebersole> so entity, component
15:29:22 <sebersole> not sure about collections
15:29:34 <sebersole> currently it just inherits its owners mode
15:29:45 <sebersole> i was more focused on the api changes
15:30:46 <sebersole> currently it leverages the pre-existing hasPojoRepresentation() method
15:31:01 <gbadner> what I mean is at https://gist.github.com/1023221
15:31:13 <gbadner> well, that's for Entity
15:31:28 <sebersole> dunno
15:31:55 <sebersole> maybe
15:32:17 <sebersole> maybe all it needs is `private EntityMode entityMode;`
15:32:44 <gbadner> and getEntityModeEntitySpecifics()
15:32:51 <sebersole> dunno
15:33:46 <gbadner> are you thinking the metamodel could have > 1 entity mode for a particular Entity?
15:34:11 <gbadner> > 1 in the metamodel, but only 1 in the SessionFactory?
15:34:25 <sebersole> well thats one option
15:34:37 <hardy_> i thought that's how it is
15:34:55 <sebersole> hardy_: today, no, its you have all 3 in both places
15:35:29 <sebersole> for sure we only want one in the sessionfactory
15:35:36 <hardy_> right
15:35:41 <sebersole> however, thats not why i said 'dunno' gbadner
15:36:08 <gbadner> I can add:
15:36:09 <sebersole> i said i do not know because not sure there is need for this distinction
15:36:24 <sebersole> especially with dom4j gone
15:36:26 <gbadner> public EntityMode getEntityMode()
15:36:41 <sebersole> well the contract you mentioned already had that
15:36:41 <gbadner> oh, ok;
15:36:54 <sebersole> EntityModeEntitySpecifics.getEntityMode
15:37:20 <gbadner> yeah, but if Entity has 2 types of EntityModeEntitySpecifics
15:37:21 <sebersole> its just that really MapEntitySpecifics adds no value
15:37:27 <sebersole> gbadner: well yes
15:37:33 <sebersole> but
15:37:43 <sebersole> again look at the actual "specifics"
15:37:52 <sebersole> not much there
15:38:00 <gbadner> oh, ok
15:38:29 <gbadner> so hasPojoRepresentation() may be enough
15:39:39 <gbadner> ok, I see you said something about that above; wasn't sure what you meant
15:39:41 <sebersole> well thats in the existing code for building persisters/tuplizers from o.h.mapping
15:40:00 <sebersole> i just leveraged an existing piece of logic
15:40:16 <sebersole> to minimize changes in code we are going to toss
15:40:20 <gbadner> I see that the code also allows for custom entity modes
15:40:40 <sebersole> but we never exposed that
15:40:45 <sebersole> and
15:40:51 <sebersole> EntityMode is an enum
15:40:54 <sebersole> so
15:41:09 <gbadner> yeah, I was wondering about that
15:41:12 <sebersole> anyway
15:41:28 <gbadner> oh, ok; so I'll remove the custom entity mode stuff
15:41:29 <sebersole> i do not know about EntityModeEntitySpecifics
15:41:39 <sebersole> gbadner: ?
15:41:45 <sebersole> custom entity modes?
15:41:47 <sebersole> or
15:41:51 <sebersole> custom tuplizers?
15:41:56 <gbadner> custom entity modes
15:42:04 <sebersole> from where?
15:42:15 <sebersole> the tuplizer mappings?
15:42:25 <gbadner> somewhere in there
15:42:28 <gbadner> have to look for it
15:42:41 <sebersole> you might want to rebase
15:42:45 <sebersole> those classes are gone
15:42:54 <gbadner> yeah I just pulled
15:43:02 <gbadner> but couldn't build
15:43:12 <gbadner> anyhow, yes, I'll rebase before I do anything more
15:43:22 <sebersole> i did a full clean/test before i pushed
15:43:37 <gbadner> I think my laptop needs a reboot
15:43:52 <sebersole> yes, linux does not save you from reboots i have found :)
15:43:54 <hardy_> gbadner: btw, I checked. I am up to date and everything builds
15:43:55 <gbadner> it was in hibernate and I don't think it came out of it very well
15:44:07 <gbadner> I'm also getting a weird failure from yum
15:45:32 <gbadner> I wanted to discuss classloading
15:45:36 <sebersole> ok
15:46:04 <gbadner> I'm finding it kind of a pain to only have the class name in Entity
15:46:07 <sebersole> thats a topic near and dear to maxandersen's heart too
15:46:23 <sebersole> gbadner: i totally agree
15:46:26 <sebersole> but
15:46:35 <gbadner> so I created a ClassHolder
15:46:41 <sebersole> we have to consider these reveng sort of cases
15:46:53 <hardy_> ClassHolder?
15:46:59 <sebersole> so long as it handles that class not being available
15:47:00 <gbadner> yeah
15:47:04 <gbadner> yes
15:47:38 <gbadner> yes, it can hold a "deferred" class
15:47:40 <hardy_> so what do you put into class holder?
15:47:43 <gbadner> or a "loaded" class
15:47:57 <sebersole> gbadner: code is better
15:47:58 <gbadner> I was going to create pull request after rebasing
15:48:07 <sebersole> you can just gist it too
15:48:41 <gbadner> ok, sec, I'll push to my fork
15:49:04 <sebersole> personally i have a hard enough time keeping code i have locally in my ram
15:49:12 <sebersole> let alone code you wrote :)
15:49:21 <gbadner> I'm not asking you to download it
15:49:34 <sebersole> i am talking about in my brain
15:51:34 <gbadner> https://github.com/gbadner/hibernate-core/commit/78c3549100567f53ecf5e7c76b56fbe88c61e60f
15:51:35 <jbossbot> git [hibernate-core] 78c3549.. Gail Badner deferred class - no field
15:51:54 <gbadner> ugh
15:52:11 <gbadner> that's not a good diff
15:52:51 <sebersole> gbadner: just gist us the ClassHolder code
15:52:55 <sebersole> thats good enough
15:52:59 <gbadner> yes, doing that
15:53:02 <sebersole> k
15:54:32 <gbadner> https://gist.github.com/1035866
15:55:16 <gbadner> there are 2 factory methods to create a ClassHolder
15:57:05 <sebersole> ok, i thought ClassHolder was a class
15:57:17 <sebersole> maybe you can show us the impls and this factory
15:57:34 <gbadner> yes that was the interface
15:58:17 <gbadner> here's how metadataImpl uses them: https://gist.github.com/1035874
15:58:26 <hardy_> gbadner: is this not a little bit of an overkill
15:58:56 <gbadner> true, metadataImpl may not need to track ClassHolder objects
15:59:33 <hardy_> why is it so painful to just have the class name in Entity?
16:00:22 <gbadner> ClassHolderImpl: https://gist.github.com/1035881
16:00:31 <jpav> I'm assuming this is to avoid loading the classloader service and using classForName every time you want to work with the class?
16:00:39 <gbadner> yes
16:01:05 <sebersole> could we maybe just have EntityClassName?
16:01:09 <gbadner> basically, the class won't be loaded unless ClassHolder.getLoadedClass() is called
16:01:31 <gbadner> I think this can be useful for other Classes that may not be available for reveng
16:01:35 <gbadner> like persisters
16:02:08 <hardy_> if we just need this for Entity in the domain model I would also call it EntityClassName
16:02:09 <gbadner> I also added a factory method for creating a ClassHolder when the Class has already been loaded
16:02:12 <gbadner> like in annotations
16:02:14 <sebersole> well we should not be calling the getLoadedClass() until we start building the runtime model (persisters) generally speaking
16:02:19 <hardy_> like in annotations?
16:02:43 <gbadner> don't you already load the entity classes?
16:02:50 <gbadner> when you're processing annotations?
16:03:02 <hardy_> sure, but I don't need a ClassHolder for that
16:03:19 <jpav> no, I believe jandex does that using its own method for reading class data
16:03:27 <jpav> I don't think the classloaders get involved
16:03:29 <hardy_> nope
16:03:34 <hardy_> yes they do
16:03:48 <hardy_> jandex gives me just the annotations defined in the entities
16:03:55 <hardy_> it's a annotation repository/index
16:03:58 <jpav> are they temporary class loaders then?
16:04:10 <hardy_> i still need to load the classes to reflect on them to find the persistent fields
16:04:13 <jpav> Yeah, I get that, but I thought jandex read the raw class data directly
16:04:23 <hardy_> jpa does not require each persistent field to be annotated
16:04:28 <gbadner> if you just use the loaded class when creating a ClassHolder then we don't have to call Class.forName()
16:04:38 <hardy_> if I have @Entity on a class
16:04:47 <hardy_> and maybe one @Id somewhere
16:04:50 <sebersole> reading annotations is inherently different
16:04:55 <sebersole> you have a class
16:05:07 <hardy_> I don't have to place any additonal annotations on other fields/properties
16:05:24 <hardy_> they are persistent per default unless they are marked @Transient
16:05:27 <hardy_> sebersole: exactly
16:05:46 <gbadner> using a ClassHolder, it makes the processing bindings the same, whether the classes have been loaded or not
16:05:47 <sebersole> hbm and reveng are not so
16:05:58 <sebersole> gbadner: i get the desire to use it
16:06:15 <sebersole> personally just think it might be a tad overly complex
16:06:22 <hardy_> +1
16:06:44 <gbadner> having it available makes things a lot tidier
16:06:59 <gbadner> the persister's just get the loaded class
16:07:32 <gbadner> I don't need any visitors to load the classes
16:07:58 <gbadner> it's not just entity names
16:08:04 <gbadner> also field class names
16:08:19 <gbadner> tuplizer names
16:08:35 <sebersole> https://gist.github.com/1035899
16:08:56 <sebersole> gbadner: this is the same net effect iiuc
16:09:01 <sebersole> but simplier
16:09:14 <sebersole> imho
16:09:52 <gbadner> I was allowing for the cases where the classes were already loaded
16:10:01 <sebersole> from where?
16:11:05 <gbadner> it's already available in ConfiguredClass
16:11:26 <sebersole> well i have no idea what ConfiguredClass is
16:11:39 <sebersole> so then
16:12:04 <hardy_> ConfiguredClass is a helper class used by annotation processing
16:12:13 <gbadner> ok, what about field class names, tuplizer class names
16:12:18 <gbadner> persister class names
16:12:32 <sebersole> https://gist.github.com/1035899
16:12:54 <sebersole> tuplizers are not subject to this lazy loading
16:13:09 <sebersole> this is what maxandersen and i were discussing on the email list
16:13:26 <sebersole> not sure what you mean by "field class names"
16:13:35 <gbadner> Entity does not have a ConfiguredClass
16:13:38 <sebersole> you mean the attribute types?
16:13:48 <sebersole> did i say this was part of entity?
16:14:02 <sebersole> persoanlly i'd make it a innner of MetaImpl
16:14:13 <sebersole> ymmv
16:14:23 <gbadner> so you're saying that annotations and hbm would have impls for EntityClassName
16:14:43 <gbadner> different impls for EntityClassName
16:14:48 <sebersole> nope
16:14:54 <gbadner> I see no problem making an internal class
16:15:02 <jpav> I think he's saying that Entity would have a field for the EntityClassName, right?
16:15:11 <sebersole> jpav: right
16:15:16 <gbadner> or a ClassHolder
16:15:30 <gbadner> and Attribute could have a ClassHolder
16:15:31 <sebersole> ClassHolder is a bad name
16:15:47 <gbadner> ok, I'm open to suggestions
16:15:50 <gbadner> for names
16:15:55 <sebersole> really this is a more general issue
16:16:06 <gbadner> yes, that's why I gave it a general name
16:16:11 <sebersole> an "initialize once" filed
16:16:14 <sebersole> field
16:16:19 <sebersole> we do this all the time
16:16:32 <sebersole> maybe we just need to encapsulate that
16:17:02 <gbadner> tbh, I think I did that
16:17:10 <gbadner> https://gist.github.com/1035881
16:17:43 <gbadner> if there's no need for MetadatImpl to track them, then I can remove that
16:18:30 <sebersole> gbadner: you do it *specifically*
16:18:32 <sebersole> not generally
16:18:34 <sebersole> sec...
16:18:42 <gbadner> ?
16:20:55 <sebersole> https://gist.github.com/1035918
16:21:00 <sebersole> there is a generic solution
16:22:20 <gbadner> so the class name would go in the initializer?
16:22:51 <gbadner> then Initializer needs:
16:22:57 <gbadner> public String getName()
16:23:43 <gbadner> then we need a ClassLoadingInitializer
16:24:00 <sebersole> sec...
16:24:01 <sebersole> :)
16:24:10 <sebersole> for someone who hates to be rushed...
16:25:07 <gbadner> and also a LoadedClassInitializer
16:25:11 <sebersole> https://gist.github.com/1035899
16:25:37 <sebersole> gbadner: i still do not get this distinction you are trying to make
16:25:40 <gbadner> that's just for annotaitons
16:25:46 <gbadner> hbm doesn't have ConfiguredClass
16:25:52 <sebersole> so then dont do it
16:26:04 <sebersole> and simply use the classloader
16:26:05 <gbadner> hbm is the one that doesn't have a loaded class
16:26:11 <sebersole> so then dont do it
16:26:14 <sebersole> and simply use the classloader
16:26:26 <sebersole> or make simple things complex
16:26:50 <sebersole> thats what this distinction seems like to me
16:27:05 <sebersole> but if everyone else thinks its better...
16:27:38 <hardy_> i like sebersole generic approach
16:27:51 <gbadner> there are 2 cases
16:27:52 <hardy_> maybe just InitializeOnce insteadof InitializeOnceField
16:27:57 <hardy_> or DeferredInitalizer
16:27:57 <gbadner> one where it's already initialized
16:28:11 <sebersole> hardy_: yeah deferred is good
16:28:22 <hardy_> gbadner but you don't have to
16:28:27 <sebersole> gbadner: like i said, i think thats not an important distinction
16:28:36 <hardy_> even right now you are calling ConfiguredClass.getClass.getName
16:28:43 <gbadner> I'm not
16:28:53 <hardy_> ?
16:29:08 <hardy_> maybe not in your local code, but in the latest on master it does, right?
16:29:14 <gbadner> ?
16:29:22 <gbadner> where is this?
16:29:37 <hardy_> what I am saying is that you don't need a special case for annotations
16:29:54 <gbadner> the class is already loaded, isn't it?
16:30:12 <sebersole> gbadner: so you propse saving exactly one classloader lookup
16:30:37 <sebersole> for imo addtional complexity
16:31:10 <hardy_> i think the same way
16:31:14 <sebersole> gbadner: and yes, you are right
16:31:20 <sebersole> you will need something for attributes
16:31:34 <sebersole> since they could be components/entities as well
16:32:05 <gbadner> fine, I'll get rid of the factory method and constructor for the loaded Class
16:32:20 <jpav> It sounds to me like you guys are talking past each other a bit.  Maybe we should defer this conv. until we clarify some things after the meeting.
16:32:41 <sebersole> well i think the meeting is pretty much done
16:32:49 <sebersole> unless someone has something else
16:32:50 <sebersole> ?
16:33:01 <gbadner> type resolution
16:33:21 <sebersole> this does not need to be part of the meeting either
16:33:26 <sebersole> #endmeeting