1 2 Previous Next 18 Replies Latest reply on Feb 6, 2010 6:22 AM by christian garderes

    JBPM4.3 should be JBPM5.0

    christian garderes Newbie
      yes i know, it was the dev api but...
        • 2. Re: JBPM4.3 should be JBPM5.0
          christian garderes Newbie

          well, i've defended the idea that jbpm was quite a good product.

          the articles of tom bayens were great readings for me,
          our whole process use hibernate but with jpa api. don't ask me why, that's it!
          So we developped a nice tool for our users and then it's time to deliver
          quite normal you say, yes that's right
          unfortunaltly jbpm 4.3 appears,

          in a very quick timing after 4.2 (?),

          quite a nice peace of code, with bpmn & Cie
          but jpa 'dirty' compatibility is no more possible...
          do you really think that jpa is anecdotic?

          • 3. Re: JBPM4.3 should be JBPM5.0
            Ronald van Kuijk Master

            hahaha, yes  I was aware that you were promoting jBPM. The only thing is that your post came out of the blue. It looks like a response to something that is not there.

             

            But regarding your statement, let me tell you why I disagree.

             

             

            • BPMN is in incubation.
              • It is not by a long shot as stable (and spec tested) as jPDL is.
              • Only a subset of BPMN2 is implemented (expect more in 4.4)
            • JPDL in jBPM 4 has a lot of room for improvment (see the Jira)
              • History stuff
              • additional fork (for-each)
              • lots of small (not so less visible) improve
              • ID generator issue
              • Task closing issues

             

            Regarding the releases, the choice was made to have periodical releases so users can depend on that. So expect 4.4 not to be far around the corner. The version where we think BPMN implementation is stable might become jBPM 5 Since the BPMN 2 spec is not even finalized yet, it is not valid to make jBPM already a 5 version (but thanks for the compliment....)

             

            Regarding the spring issue, discuss it in the forum and check if there are already Jira issues for it. If not make them after discussing it in the forum first. If there is one, vote for it to give it a 'higher priority' (no guarantee)

             

            Cheers,

             

            Ronald

            • 4. Re: JBPM4.3 should be JBPM5.0
              Tom Baeyens Master

              chrigar wrote:

               

              but jpa 'dirty' compatibility is no more possible...


              We don't target JPA at this time.  We anticipate to move to JPA at some time in the future.  Do I understand you correctly that you're saying that with 4.2 you could use JPA and we have broken that unintended compatibility in 4.3?

               

              If so, is there something we can do to easily fix it?

               

              BTW, what is the big problem with hibernate/JPA?  In essence, jBPM uses a configurable JDBC connection in the end and it can participate in a JTA transaction.  JPA might be more convenient depending on your architecture, but I don't see how this could be a showstopper.  It would be good for us to understand your reasoning if you think differently.

              • 5. Re: JBPM4.3 should be JBPM5.0
                christian garderes Newbie


                Yes i know that the question of jpa/support was evocated then abandoned for the new 4.x architecture.
                I was already disapointed at that time... ;-(


                Nonetheless, until 4.3, we were able to inject the underlying hibernate session factory in jbpm classes


                In 3.x we used this kind of adaptator:


                public class AdaptedJbpmFactoryBean extends LocalJbpmConfigurationFactoryBean {
                @PersistenceContext
                private EntityManager em;
                public void afterPropertiesSet() throws Exception {
                  try {
                   Session session = (Session) em.getDelegate();
                   setSessionFactory(session.getSessionFactory());
                   super.afterPropertiesSet();
                  } catch (Exception e) {}
                }


                In 4.1-2 we rely on:

                 

                /** */
                public class SpringJpaConfiguration extends SpringConfiguration {
                /** */
                @PersistenceContext
                private EntityManager em;
                /** */
                public SpringJpaConfiguration(String jbpmConfigurationLocation) {super(jbpmConfigurationLocation);}
                /** */
                public void initSessionFactory(){
                  setHibernateSessionFactory(((Session) em.getDelegate()).getSessionFactory());
                }

                 

                the classes are loaded and initialized during ApplicationContext loading
                Spring transaction management is used,

                 

                JBPM mapping files are loaded with an added xml persistence unit (jpa)

                 

                <?

                 

                xml version="1.0" encoding="UTF-8"?>

                <

                 

                persistence version="1.0"

                 

                xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

                 

                xsi:schemaLocation="http://java.sun.com/xml/ns/persistence

                http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd"

                 

                >

                 

                 

                 

                <!-- ###################### -->

                 

                <!-- # jbpm mapping files # -->

                 

                <!-- ###################### -->

                 

                 

                <persistence-unit name="xxxx" transaction-type="RESOURCE_LOCAL">

                 

                 

                <mapping-file>jbpm.execution.hbm.xml</mapping-file>

                 

                <mapping-file>jbpm.history.hbm.xml</mapping-file>

                 

                <mapping-file>jbpm.repository.hbm.xml</mapping-file>

                 

                <mapping-file>jbpm.task.hbm.xml</mapping-file>

                 

                <mapping-file>jbpm.identity.hbm.xml</mapping-file>

                 

                 

                <exclude-unlisted-classes>true</exclude-unlisted-classes>

                 

                 

                </persistence-unit>

                </

                 

                persistence>

                 

                 

                 


                In 4.3, we can't find a way to do something similar in org.jbpm.api.ProcessEngine

                jta should be a solution... but we are not working on a full jee stack,
                so we have to make it by hand(?), indeed, if nothing else is found.

                 

                • 6. Re: JBPM4.3 should be JBPM5.0
                  Bernd Ruecker Master

                  Hey Tom.

                   

                  Just a quick remark on JPA: I experienced it to be a political issue already a couple of times. So technically there is no difference, but on the political level it could help soem projects...

                   

                  Cheers

                  Bernd

                  • 7. Re: JBPM4.3 should be JBPM5.0
                    Sebastian Schneider Master

                    I'd love to see more priority on some of the jPDL issues Ronald mentioned because it will still take some time to have a stable BPMN2 implementation. I was under the impression from previous discussions that especially the history issues should have had a bigger priority in upcoming releases. Infact I thought this would be the case for 4.3 already but they are not even part of the planning for 4.4. Maybe they could be taken into account much stronger for 4.5? The further BPMN2 implementation could also benefit from these afterwards IMHO.

                    • 8. Re: JBPM4.3 should be JBPM5.0
                      Josh Long Newbie
                      Support for the various for-each scenarios sure would be appreciated, too!  :-) All I want in jBPM 4.x is iteration without a priori runtime knowledge and I'll be a happy camper. I had a recipe for this using a custom handler in jBPM 3 and before I can move some applications to 4.x, I'll need this figured out or will have to figure it out myself. Thanks.
                      • 10. Re: JBPM4.3 should be JBPM5.0
                        Tom Baeyens Master

                        my fingers are itching a lot !  you guys are pushing exactly for the next features that I want to get in as well

                         

                        1) for each activity (i'ld love to start on this one)

                        2) improve history (this has probably priority over for-each)

                        3) switch to JPA (probably long term as this is a big effort and not yet a big showstopper, it's a jira for jbpm 5 iirc)

                         

                        regards, tom.

                        • 11. Re: JBPM4.3 should be JBPM5.0
                          Sebastian Schneider Master
                          I love to hear that your finger's are already itching, Tom. Do you have any news on the task-closing issue?
                          • 13. Re: JBPM4.3 should be JBPM5.0
                            christian garderes Newbie

                            Hello Bernd Ruecker,

                            sorry, i'm asking to myself, are you from an other planet?

                            • 14. Re: JBPM4.3 should be JBPM5.0
                              Sebastian Schneider Master
                              Is this due to this remark about JPA being a political issue?
                              1 2 Previous Next