[jbosstools-dev] Hibernate multiversions support

[Max Rydahl Andersen]

Moved to jbosstools-dev - not just for internal discussion.

/max

----- "Vitali Yemialyanchyk" <vyemialyanchyk at exadel.com> wrote:

> Max,
> 
> Here I try to accumulate my thoughts about the problem:
> 
> 
> 
> I’m trying to analyze conception of using other process to Hibernate
> multi versions support and decoupling. I’m suspecting we could choose
> not optimal way for implementation, this is very important decision,
> we should analyze all aspects, why we’ll select a way and technologies
> which java provide. I suspect we can stay in bounds of 1 JVM process
> using classloaders, we should just separate Hibernate jars from
> Hibernate Tools. The idea is to have some “imbedded container” with
> some particular Hibernate version and the user can provide his own
> “container” with his project classpath. This container should interact
> with Hibernate Tools via some circumspect interface (more precise
> Hibernate Tools should interact with container via such interface) (I
> imagine this interface in one place -> currently it diffused all over
> Hibernate Tools – so general purpose no Hibernate imports in Hibernate
> Tools ) and should in general case use Hibernate classes via it string
> names – some particular container implementation can use Hibernate
> classes directly.
> 
> 
> 
> So IMO good start point not implement code generation and query
> execution firstly – good start point is decouple Hibernate interaction
> from Hibernate Tools, good start point is to implement such container
> – firstly it could use Hibernate directly and then via it classes
> name.
> 
> 
> 
> Using other process I can dig into interprocess interaction details
> which could became rather complex - practically this interprocess
> interaction turns into container interface implementation and decouple
> from Hibernate class imports.
> 
> 
> 
> The container interface for Hibernate Tools outline:
> 
> 1) Code generation – input: db connection, java classes, output dir;
> output: signal when sources are generated;
> 
> 2) Query execution – input: query string; output: list of objects;
> 
> 3) Code completion – input and output - ?;
> 
> 4) Object relations resolution (for Mapping Diagram);
> 
> 5) Error display/handling;
> 
> 6) Possibility of external configure for Hibernate configuration (i.e.
> additional mapping files, add/remove jars into classlib);
> 
> 7) Handling of Hibernate session;
> 
> 8) Should be extendable;
> 
> The container should work in its sandbox which Hibernate Console
> Configuration provide (use classes, jars, resources which Hibernate
> Console Configuration provide with its classpath).
> 
> The question is which is a way to organize such sandbox? -> IMO
> possible to use just class loader not other process… Moreover -> when
> we define such interface – we free to choose which sandbox
> implementation is more preferable -> “class loader” or other process.
> 
> 
> 
> 
> 
> Agenda:
> 
> Hibernate Tools – use in general only Eclipse and Java core libs,
> interact with so called “Hibernate Container” via predefined
> interface;
> 
> “Hibernate Container” works in its own classpath sandbox – provide
> information for Hibernate Tools with strings and files – in “ideal”
> case;
> 
> 
> 
> 
> 
> Here is our discussion – to remember purpose why this necessary and
> what using of other process just “ idea of separation ” for “ user
> wishes to use another version than the builtin ”.
> 
> Also, Max, please point the jira issue – is it
> http://opensource.atlassian.com/projects/hibernate/browse/HBX-1160?
> 
> 
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> 
> 
> <vitali> I have some questions about multiple hibernate version
> support - it look like first priority issue?
> 
> <@max_at_hibernate> its one of the issues we need to look into for the
> next major release.
> 
> <@max_at_hibernate> since with Hibernate 3.5 things becomes harder to
> ensure works consistently (as the move to 3.3 have shown)
> 
> <vitali> as I remember you told about execution in different thread
> idea, but it is not clear for me - cause currently we are using some
> specific version of Hibernate (3.3.2) - the idea is to substitute it
> with any Hibernate version - as the user select? this sould be
> configurable via GUI? the user should dpwnload hiberante jars and
> point the place?
> 
> <@max_at_hibernate> the user is supposed to have hibernate configured
> in his project if he wishes to use another version than the builtin.
> 
> <@max_at_hibernate> the idea I had was execute qeries and code
> generation in a separate *process* not just different thread.,
> 
> <vitali> so builtin version exist. "separate *process*" – exactly - I
> remember.
> 
> <@max_at_hibernate> My current thinking is to have a flag on the
> console configuration wether external process should be used or not.
> 
> <@max_at_hibernate> the biggest problem will be the mapping diagram,
> but for now we could just say that requires internal process to work.
> 
> <@max_at_hibernate> code completion could also become tricky - but
> could probably be done by launching a debug process which we could
> call out to for the completions.
> 
> <@max_at_hibernate> alternatively reading code and mapping files and
> building the metadata manually - but that would be a massive work.
> 
> <@max_at_hibernate> the cool thing is if we do this we could decouple
> us from Hibernate and even support other JPA implementations for parts
> of our functionallity.
> 
> <vitali> "external process" - I can imagine this for code generation,
> but to build console configuration - this look rather complex task - I
> sure this possible but now I do not see how to easy implement it with
> small changes - possible to use files to interprocess communicate?
> 
> <@max_at_hibernate> it is not a small change - its a big one.
> 
> <@max_at_hibernate> should be done in a branch probably to not break
> things for everyone else ;)
> 
> <@max_at_hibernate> not sure what you mean with files to interprocess
> communicate ?
> 
> <@max_at_hibernate> you would need the process to run in the
> background - ready to execute the things the user needs.
> 
> <@max_at_hibernate> i.e. for queries.
> 
> <@max_at_hibernate> code generation would just be a separate launch.
> 
> <vitali> " you would need the process to run in the background - ready
> to execute the things the user needs." - a! I remember I did something
> with some other project – so I have the example!
> 
> <vitali> for queries it ok - clear, but for ConsoleConfiguration -
> it's contains hibernate Configuration
> 
> <vitali> from my point of view -> it is necessary to pass this class
> from one process to other
> 
> <@max_at_hibernate> and for what do you need the console configuration
> ? ..
> 
> <@max_at_hibernate> not for querying, not for codegen
> 
> <@max_at_hibernate> only for the mapping diagram and the outline
> 
> <@max_at_hibernate> both could be something we generate by launching
> the external process and generate some data that represents it in a
> canoncial form...
> 
> <vitali> I'll try to rethink all above... I'll create jira issue for
> this.
> 
> <@max_at_hibernate> vitali - I think there already is one, right ?
> 
> <vitali> I remember it should be - but I review issues which assigned
> to me and can't find it - will look one more time
> 
> <@max_at_hibernate> note, doing this for code gen and querying doesn't
> mean that we could still try using console configuration inprocess for
> things that arent moved to external yet.
> 
> <vitali> generally is necessary to have some start point - about
> ConsoleConfiguration -> Configuration and SessionFactory - imo these
> sould be in some canonical form - may be I did not understood you
> correctly - it look like your imagene this in other way...
> 
> <@max_at_hibernate> don't think so ;) What do ou mean ?
> 
> <vitali> uff... may be I miss something - but how you display correct
> tree items for Console Config? imo these should be from user selected
> Hibernate jars
> 
> <@max_at_hibernate> vitali - i'm saying that part is the hard one, but
> you don't *need* them to actually execute queries or generate code.
> 
> <@max_at_hibernate> need *it* I mean.
> 
> <vitali> so you propose "execute queries and generate code" as start
> point?
> 
> <@max_at_hibernate> yes
> 
> <vitali> ok
> 
> 
> 
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> 
> 
> 
> Vitali

-- 
/max