[Design of JBoss jBPM] - Re: db properties reorg
by tom.baeyens@jboss.com
"heiko.braun(a)jboss.com" wrote : Another requirement is to switch between hibernate managed connections (simple tests, jdbc properties) to container managed connections (intgeration tests, datasources).
|
that was the use case what i forgot
i don't like the current set up yet. i got the feeling that it must be possible to make it less complex.
but i'll give it some time to get used to it and then see where and how (if at all) things need to be improved.
one thing that i haven't figured out yet is the configuration variation for the pvm tests. in the pvm, we need a jbpm.cfg.xml which is almost as the full configuration file, but it should exclude the jpdl things (only one or two things).
i'm still chewing on how we can get to one unified configuration source for all modules... not trivial.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206896#4206896
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206896
16 years, 8 months
[Design of JBoss jBPM] - Re: db properties reorg
by heiko.braun@jboss.com
anonymous wrote :
| Ideally i would like to move to the following situation:
|
| * a config module that has the default persistence configuration and produces it in a jar file in the repo.
|
right, that something we agree upon. Just that the current configuration resides with the jpdl module which produces a a config jar that goes into the repo: jbpm-jpdl-4.0.0-SNAPSHOT-config.jar
Another requirement is to switch between hibernate managed connections (simple tests, jdbc properties) to container managed connections (intgeration tests, datasources). This is something we already did in jBPM3
and I simply wanted to leverage the existing build, which is non trivial.
Hence the change from hibnerate.cfg.xml+hibernate.properties to a single hibernate.cfg.xml which includes the connection settings.
So basically, the db.properties (i.e. mysql.properties) disappeared and have been replaced by hibernate.mysql.cfg.xml, which ship with the jpdl-config.jar.
Currently this get's expanded into every module that needs db connection settings and is used by the installer to finally create hibernate.cfg.xml and *-ds.xml for deployment into the AS.
The build is driven by profiles.xml which contains the connection properties (i.e. Qa on your local box vs. jboss QA environment) and by the 'mvn -Ddatabase=mysql' switch, that defaults to hsqldb.
Does that answer your question?
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206862#4206862
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206862
16 years, 8 months
[Design of JBoss jBPM] - db properties reorg
by tom.baeyens@jboss.com
heiko,
can you explain the purpose of the reorg of the db properties? i couldn't find what was extra things became possible. probably there is some aspect that i didn't get.
ideally i would like to move to the following situation:
* a config module that has the default persistence configuration and produces it in a jar file in the repo.
jbpm configuration would contain a reference to hibernate.cfg.xml *and* hibernate.properties
hibernate.properties would contain the hypersonic in memory configs.
* the db module approx as it was: containing ${database}.properties files for all the db's
in the parent pom, there is a section that takes the specific database properties file, resolves the properties and overwrites the default hibernate.properties with it.
------------------------------------------------------------------------
do you see problems with this approach ? things that would be invalidated that you've build just now ?
the difference between how it was originally is that by extracting the default configs in a separate module, we remove the necessity for each module to have its own configuration files in the resources. so we can prevent spreading copies all over the code base that have to be kept in sync.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4206858#4206858
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4206858
16 years, 8 months
Re: jbpm-3.2.5.SP
by Alejandro Guizar
Today I ported JBPM-1903 to 3.2.5.SP because it was relevant to the
upcoming migration to JMS.
Regarding JBPM-1452, the enterprise services have to be enabled in the
SOA-P jBPM configuration file. I made a few remarks to Jiri's setup
instructions directly in JIRA.
As for JBPM-1453, the feature requested there is unfeasible. We cannot
disable optimistic locking with a switch. We would need an alternate JAR
with no version columns declared in the mapping files.
-Alejandro
El mar, 03-02-2009 a las 16:30 +0000, trevor kirby escribió:
> Thanks for the branch and the work so far guys. The two issues
> mentioned below are now a blocker for the SOA CP because of NTT, so I
> would appreciate it if you could get the fixes into the 3.2.5 sp branch
> as quickly as you can. I've included Julian Coleman on the CC, can you
> make sure you include him on any emails about these JIRA's or NTT.
>
> Trev
>
>
> > Hi Alejandro,
> >
> > thanks for all you effort to keep the jbpm3 code base in prime shape
> >
> > http://jbpm.dyndns.org:8280/hudson/job/jBPM3-Container-Matrix/
> >
> > After a conversation with Trevor, I created a jbpm-3.2.5.SP1 branch
> > that is going to take the place of 3.2.4.SP1 in the SOA platform. The
> > benefit is that we don't have to merge stuff back to 3.2.4.SP that was
> > already fixed in 3.2.5.GA.
> >
> > I already merged the changes from 3.2.4.SP to 3.2.5.SP there there is
> > (hopefully) nothing more for you to do.
> >
> > Trevor also mentioned the importance of NTT issues again.
> >
> > https://jira.jboss.org/jira/browse/JBPM-1952
> > https://jira.jboss.org/jira/browse/JBPM-1953
> >
> > Perhaps you could have a look at those next and if possible also apply
> > the necessary changes to 3.2.5.SP?
> >
> > The jbpm-3.2.5.SP QA is here
> >
> > http://jbpm.dyndns.org:8180/hudson
> >
> > cheers
> > -thomas
>
16 years, 8 months