api/spi/internal package split
by Steve Ebersole
OK, now that we have been doing this for a few months and have some actual
experience, I wanted to circle back and talk about this notion of splitting up
packages to denote api/spi/internal intent.
Not so much "should we do it". I think we absolutely should to help do osgi
stuff a little later and now (new major rev) is the time to be changing up
packages.
Not, more I mean the specifics of how we will do this. Currently we took the
approach (mostly) that these distinctions are leaves (as in plural leaf) in
the package name. So for example, we have:
1) org.hibernate.service (api)
2) org.hibernate.service.spi
3) org.hibernate.service.internal
On the plus side this keeps related stuff grouped together. Everything under
org.hibernate.service we know relates to the notion of services. Everything
under org.hibernate.engine we know deals with the internal engine. etc
On the downside (imo) this creates lots of packages. To see what I mean, just
take a look at https://github.com/hibernate/hibernate-
core/tree/master/hibernate-core/src/main/java/org/hibernate/service
The only other option I saw was to make api/spi/internal the top level
packaging construct:
1) org.hibernate.service (still api)
2) org.hibernate.spi.service
3) org.hibernate.internal.service
What's been everyone's experience(s) here?
---
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
12 years, 11 months
Metamodel Tasks
by Gail Badner
I've listed all the metamodel tasks that I know of at: https://gist.github.com/948758 . I have not broken them down by release
Not all tasks have JIRA issues yet, and I forgot to break them down by release. I'll take care of that after getting some feedback.
I'll be online again in 4 hours or so to work.
Regards,
Gail
12 years, 12 months
Default value provider contract
by Emmanuel Bernard
While working on OGM, I found the need to override some of the default values of some Hibernate Core settings, namely:
- TransactionFactory (defaults to JDBCTransactionFactory)
- TransactionManagerLookup (defaults to null)
What do you thing of the idea of having a DefaultValueProvider class that people could extend to override default values.
we would then let people pass hibernate.configuration.default_value_provider = com.acme.MyDefaultValueProvider
Alternatively, I'd need to define:
- hibernate.transaction.default_factory_class
- hibernate.transaction.default_manager_lookup_class
WDYT?
13 years
Hibernate OGM documentation
by Emmanuel Bernard
Hi all
I've been working on Hibernate OGM documentation. I am still very unhappy with what I have but that's a start.
You can read it at http://docs.jboss.org/hibernate/ogm/3.0/reference/en-US/html_single/
You can contribute to it by forking on github https://github.com/hibernate/hibernate-ogm
To build the documentation,
- go to hibernate-ogm-doucumentation/manual
- run mvn install -DbuildDocs=true
You will get the result in target/docbook/publish/en-US
I'm interested in all kind of feedback:
- general feel
- what part is confusing
- what you think is missing (besides the TODOs)
And of course if you can contribute some part, that would be awesome.
Emmanuel
13 years
Building a SessionFactory
by Steve Ebersole
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.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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();
--
Steve Ebersole <steve(a)hibernate.org>
http://hibernate.org
13 years
Re: [hibernate-dev] Integrator and retrieving objects
by Adam Warski
On Apr 6, 2011, at 1:20 PM, Steve Ebersole wrote:
> The phrase 'unwrap' might be a bit misleading there because you may not be dealing with wrapped objects. But the idea itself is still solid I believe. Think of it more as a multi-directional cast
Right, the idea sounds good; so it would be something like a per-session service? :)
Envers could use it as well, right now just as search has Search.getFullTextSession, envers has AuditReaderFactory.getFor
So we could have session.service(AuditReader.class / FullTextSession.class).
Adam
> On Apr 6, 2011 6:15 AM, "Adam Warski" <adam(a)warski.org> wrote:
> >
> >> FullTextSession ftSession = session.unwrap(FullTextSession.class);
> >> //the current approach is via some static helper method
> >> //FullTextSession ftSession = Search.getFullTextSession(session);
> >>
> >> That would mean that the integration point between HSearch and Hibernate would have an unwrap method and Hibernate would delegate the unwrap calls to each integrator until a non null object is returned.
> >>
> >> It's just a thought, WDYT?
> >
> > But while EntityManager wraps a Session object, a Session doesn't wrap a FullTextSession, but the other way round, no?
> >
> > --
> > Adam Warski
> > http://www.warski.org
> > http://www.softwaremill.eu
> >
> >
> >
> >
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Adam Warski
http://www.warski.org
http://www.softwaremill.eu
13 years
Meeting logs since Max's bot failed us
by 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@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
13 years
Hibernate Search 3.5 or 4
by Emmanuel Bernard
Hi,
We have had in our road map an Hibernate Search 3.5 before Hibernate 4. Hibernate 4 is the release where the following should happen:
- split packages into API, SPI and private packages
- use JBoss Logging
- be compliant with Core 4
- break whatever contract we need to break to open up the future
- split dependency between the core of Hibernate Search and Hibernate Core
Do you see more task for 4?
Since Hibernate Core 4 seems to be doing alright and that the time pressure will be strong to get Hibernate Search aligned, I propose to skip 3.5 entirely and focus on 4. We did not that that many new features planned anyways for 3.5, it was more a consolidation release.
Even with skipping 3.5, the 4 release will be a lot of work. We should start early. Any objection or comment?
Changing contracts
We have had a few contracts that we wanted to change to make way for future improvements:
- should a bridge know about the field it changes (make the optimization more efficient)
- rework the backend to let IndexReader and IndexWriter communicate
- rework the backend to support instantiated IndexReaders
Can you help collect the list of changes you would like to see happening?
I would like to get this work started asap, this is really the unknown quantity and we tend to be slow to converge on the things
Split packages in API/SPI/private packages
Hibernate 4 is the ideal time to properly split stuff into API, SPI, private. Moving classes to private packages is the least impacting move for users as these should not be used. The API / SPI split is sometimes difficult to do so if you have a doubt in an area, ask on the ML or on IRC and we can discuss it together. If you need an example, check out the query engine. It is relatively clean now.
We might have to break a few user APIs which is fine but I don't expect too many will be necessary:
- make sure to discuss it when you plan to do one
- list them in the migration guide
I'd say that the package splitting should be done when you have a change and when you work in a specific area. It's more a background task.
Be compliant with Core 4
We can do this one a bit later in the cycle to give time for core to mature.
Split dependency between Hibernate Search and Hibernate Core
I think in practice we are not too far. This work should be done in parallel to the package splitting. If you look at the query engine, we do have specific hibernate packages. We also have a HibernateHelper class of all low level Hibernate contracts like unproxying, initializing etc. We should use that class everywhere instead of relying on the direct Hibernate Core contracts. That will help up to move this class as an implementable contract.
The next step potentially is to actually move Hibernate Core specific code into a separate package.
I don't have much opinion on this but we should definitively discuss it.
Use JBoss Logging
I tend to think we should do this migration late in the game. WDYT?
New features
Do you want any new feature per se? I think this would be a great time to get the community involved to back new features and fix bugs while we do the grunt work for 4. So if you know some shy people motivated or if you are one of them, stand up :)
Note: I have create a vague copy of this email in http://community.jboss.org/wiki/PlansforHibernateSearch4
We can discuss via email but be sure to add the feedback or list of todos in the wiki as well for posterity.
13 years
one-to-one mapping
by Faraz Fallahi
hi
im trying to create a simple one-to-one mapping in my hbm files.
For Example:
<one-to-one name="account" class="kbusy.database.model.Account" />
is in the Tutor.hbm.xml
My many to one, one to many and many to many mappings all work, but
one to one doesnt. i would expect him to create me an account id
column in my tutor table, but he does not.
what am i doing wrond?
greez
13 years
