Moved to jbosstools-dev - not just for internal discussion.
----- "Vitali Yemialyanchyk" <vyemialyanchyk(a)exadel.com> wrote:
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
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
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.
Hibernate Tools – use in general only Eclipse and Java core libs,
interact with so called “Hibernate Container” via predefined
“Hibernate Container” works in its own classpath sandbox – provide
information for Hibernate Tools with strings and files – in “ideal”
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
<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
<@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
<@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
<vitali> I'll try to rethink all above... I'll create jira issue for
<@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
<@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