[jBPM] New message: "Re: Spring Modules and jBPM 3.2.X"
by Ronald van Kuijk
User development,
A new message was posted in the thread "Spring Modules and jBPM 3.2.X":
http://community.jboss.org/message/521574#521574
Author : Ronald van Kuijk
Profile : http://community.jboss.org/people/kukeltje
Message:
--------------------------------------------------------------
>
> Is there any decent Spring support for versions of jBPM 3 higher than 3.1 ?
No
> I read a good tutorial on the use of Spring Module classes such as JBPMTemplate, JBPMCallback, etc but I'm now hearing reports that later versions of jBPM 3 are not compatible.
Correct, some things work, but not everything (hence my 'no' on the 'decent' suppport. otoh, decent could be read as 'good enough' in that case you could give it a try and accept the things that do not work or where you have to create workarounds.
.
>
> Does anyone know if there are plans to address this incompatibility
>
Yes I do know that
> either by Spring or JBoss ?
No there won't be. All effort by JBoss went into spring support for jBPM 4. Supprt for 3 was done by external people and under the Spring umbrella. for 4 JBoss wanted to be in control.
Ronald
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521574#521574
16 years, 3 months
[JBoss Microcontainer] New message: "Re: Undemanding Dependencies"
by David Lloyd
User development,
A new message was posted in the thread "Undemanding Dependencies":
http://community.jboss.org/message/521572#521572
Author : David Lloyd
Profile : http://community.jboss.org/people/david.lloyd@jboss.com
Message:
--------------------------------------------------------------
> alesj wrote:
>
> > In this case, what do you consider "-->" to mean?
> >
> A --> B, by this I mean that from A you can get a hold of B.
> > I'm producing a BeanMetaData but after that I don't have any control over how the beans are installed. I don't see any way to get a ControllerContext or DependencyInfo off of a BMD. I think I see what you're getting at (using a lifecycle callback on the parent to enable the child), I just don't see how to connect the dots.
> Even from BMD you have access to underlying ControllerContext, you just don't know it yet. :-)
> It's the MetaDataVisitorNode methods, that get you that, we just need to properly override them.
>
> BMD.initialVisit(MDVN node) <-- override this
> ControllerContext context = node.getControllerContext();
> DependencyInfo info = context.getDependencyInfo();
> LifecycleCallbackItem item = new MyStarterLCI(); // this is what starts As
> info.addLifecycleCallback(item);
>
> Does this make more sense?
Ah, I see. However I can't affect the parent's BMD in this case - only the child's.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521572#521572
16 years, 3 months
[JBoss Microcontainer] New message: "Re: Undemanding Dependencies"
by Ales Justin
User development,
A new message was posted in the thread "Undemanding Dependencies":
http://community.jboss.org/message/521568#521568
Author : Ales Justin
Profile : http://community.jboss.org/people/alesj
Message:
--------------------------------------------------------------
> In this case, what do you consider "-->" to mean?
>
A --> B, by this I mean that from A you can get a hold of B.
> I'm producing a BeanMetaData but after that I don't have any control over how the beans are installed. I don't see any way to get a ControllerContext or DependencyInfo off of a BMD. I think I see what you're getting at (using a lifecycle callback on the parent to enable the child), I just don't see how to connect the dots.
Even from BMD you have access to underlying ControllerContext, you just don't know it yet. :-)
It's the MetaDataVisitorNode methods, that get you that, we just need to properly override them.
BMD.initialVisit(MDVN node) <-- override this
ControllerContext context = node.getControllerContext();
DependencyInfo info = context.getDependencyInfo();
LifecycleCallbackItem item = new MyStarterLCI(); // this is what starts As
info.addLifecycleCallback(item);
Does this make more sense?
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521568#521568
16 years, 3 months
[JBoss Microcontainer Development] New message: "Re: Pluggable dependency resolver"
by Kabir Khan
User development,
A new message was posted in the thread "Pluggable dependency resolver":
http://community.jboss.org/message/521562#521562
Author : Kabir Khan
Profile : http://community.jboss.org/people/kabir.khan@jboss.com
Message:
--------------------------------------------------------------
I have got contextual injection and basic supply/demand working, so KernelAllTestSuite is down to 18 errors and 32 failures, most of which are related to scoping.
The supply/demand implementation is pretty simple so far. When registered, if a context has demand dependency items, they get recorded. When a context has supplies and its state is incremented, we try to resolve the contexts with demand di's waiting for that state. I hope that will suffice, since I don't want to get involved with the matchers, I might be wrong but I don't think they lend themselves to
Similarly, the contextual injection mechanism is also quite light, we only index the wanted class on registring, and on incrementing the state we check for the classes. I don't do anything about the qualifiers.
One thing I think we're lacking is "wrong order" tests for contextual injection, at least with qualifiers, so I need to add some. The same might be the case for supply/demand, which I need to check.
I've been using concurrent collections in my DependencyResolver and Matchers, which might not be necessary. I thing al the access to the DependencyResolver + Matchers happens with the controller lock taken, but again I need to check that.
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521562#521562
16 years, 3 months
[jBPM] New message: "Re: jbpm 4.3 - org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update"
by Zengping Tian
User development,
A new message was posted in the thread "jbpm 4.3 - org.hibernate.exception.ConstraintViolationException: Could not execute JDBC batch update":
http://community.jboss.org/message/521559#521559
Author : Zengping Tian
Profile : http://community.jboss.org/people/zptian
Message:
--------------------------------------------------------------
Hi Martin
Think we have similar issues. Have read through your issue reported in: https://jira.jboss.org/jira/browse/JBPM-2706. Think they're more or less the same underlying issue.
In our case, we have may process which has several sub-processes and the sub-process actually executes some java/decision activities. THe sub-processes and the java activies are marked as 'async'.
In our test we have 4 job executors.
when using on HSQL, we run into violation of unique constraint, eg,
+Caused by: java.sql.SQLException: Violation of unique constraint $$: duplicate value for column $$: SYS_CT_107322 in statement [update JBPM4_EXECUTION set DBVERSION_=?, ACTIVITYNAME_=?, PROCDEFID_=?, HASVARS_=?, NAME_=?, KEY_=?, ID_=?, STATE_=?, SUSPHISTSTATE_=?, PRIORITY_=?, HISACTINST_=?, PARENT_=?, INSTANCE_=?, SUPEREXEC_=?, SUBPROCINST_=? where DBID_=? and DBVERSION_=?]
+
if we run it on DB2, it gives deadlock issue(which i posted in this forum yesterday):
+### EXCEPTION ###########################################
19:57:51,203 SEV | [AbstractFlushingEventListener] Could not synchronize database state with session
org.hibernate.exception.LockAcquisitionException: pool-1-thread-5: could not update: [org.jbpm.pvm.internal.model.ExecutionImpl#166]
at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:105)
at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2466)
at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:2340)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2653)
at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:115)
at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:279)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:263)
at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:168)
at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:321)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:50)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1028)
at org.jbpm.pvm.internal.tx.HibernateSessionResource.prepare(HibernateSessionResource.java:56)
at org.jbpm.pvm.internal.tx.StandardTransaction.commit(StandardTransaction.java:107)
at org.jbpm.pvm.internal.tx.StandardTransaction.complete(StandardTransaction.java:64)
at org.jbpm.pvm.internal.tx.StandardTransactionInterceptor.execute(StandardTransactionInterceptor.java:61)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.executeInNewEnvironment(EnvironmentInterceptor.java:53)
at org.jbpm.pvm.internal.svc.EnvironmentInterceptor.execute(EnvironmentInterceptor.java:40)
at org.jbpm.pvm.internal.svc.RetryInterceptor.execute(RetryInterceptor.java:55)
at org.jbpm.pvm.internal.svc.SkipInterceptor.execute(SkipInterceptor.java:43)
at org.jbpm.pvm.internal.jobexecutor.JobParcel.run(JobParcel.java:48)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:885)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
Caused by: com.ibm.db2.jcc.c.SqlException: DB2 SQL error: SQLCODE: -911, SQLSTATE: 40001, SQLERRMC: 2
at com.ibm.db2.jcc.c.kh.c(kh.java:1660)
at com.ibm.db2.jcc.b.db.s(db.java:875)
at com.ibm.db2.jcc.b.db.k(db.java:387)
at com.ibm.db2.jcc.b.db.a(db.java:60)
at com.ibm.db2.jcc.b.t.a(t.java:52)
at com.ibm.db2.jcc.b.tb.b(tb.java:202)
at com.ibm.db2.jcc.c.lh.X(lh.java:1842)
at com.ibm.db2.jcc.c.lh.d(lh.java:2411)
at com.ibm.db2.jcc.c.lh.T(lh.java:465)
at com.ibm.db2.jcc.c.lh.executeUpdate(lh.java:448)
at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:2448)
... 24 more+
--------------------------------------------------------------
To reply to this message visit the message page: http://community.jboss.org/message/521559#521559
16 years, 3 months