TimerBoundaryEvent - Not recognizing Spring Bean in Loop

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-02-2011 09:44 PM
Hi all,
I have a tricky problem that I've been trying to solve all day, and can't seem to figure out. Hoping you can help…
I have a TimerBoundaryEvent placed on a Java Receive Task in my process flow. The flow itself is somewhat of a loop. The way that my process flow works is as follows: (simplified for forum purposes):
The error that I receive is a standard one I'd expect to see when not properly specifying the bean:
But note that this error DOES NOT OCCUR the first time I enter the Service Task wherein "myAdapter.doSomething()" is invoked … only on subsequent calls after looping back to that Service Task.
I was thinking that it had something to do with the loop itself … maybe looping back to a task that has already been created, used, and completed is not allowed? Maybe I should pull the "looping" out into it's own Spring Bean, use my own threading/executor, and not use the TimerBoundaryEvent at all?
Any advice or comments would be very much appreciated. I can provide more information on this issue if needed.
Thanks,
Tom
I have a tricky problem that I've been trying to solve all day, and can't seem to figure out. Hoping you can help…
I have a TimerBoundaryEvent placed on a Java Receive Task in my process flow. The flow itself is somewhat of a loop. The way that my process flow works is as follows: (simplified for forum purposes):
- 1. Start Task
2. Service Task (invokes Spring Bean "myAdapter.doSomething()" in an expression)
3. XOR Gateway (checks whether we have what we need. If not, continues to java receive task. If so, goes to the End Task)
4. Java Receive Task (waits indefinitely, until interrupted by Timer Boundary Event)
5. Timer Boundary Event (interrupts Java Receive Task)
6. XOR Gateway (Determine whether we've reached a maximum number of loops. If not, continue back up to the Service Task in step #2. If so, goes to the End Task)
7. End Task
The error that I receive is a standard one I'd expect to see when not properly specifying the bean:
Caused by: org.activiti.engine.impl.javax.el.PropertyNotFoundException: Cannot resolve identifier 'myAdapter' at org.activiti.engine.impl.juel.AstIdentifier.eval(AstIdentifier.java:83) at org.activiti.engine.impl.juel.AstMethod.invoke(AstMethod.java:79)
But note that this error DOES NOT OCCUR the first time I enter the Service Task wherein "myAdapter.doSomething()" is invoked … only on subsequent calls after looping back to that Service Task.
I was thinking that it had something to do with the loop itself … maybe looping back to a task that has already been created, used, and completed is not allowed? Maybe I should pull the "looping" out into it's own Spring Bean, use my own threading/executor, and not use the TimerBoundaryEvent at all?
Any advice or comments would be very much appreciated. I can provide more information on this issue if needed.
Thanks,
Tom
Labels:
- Labels:
-
Archive
2 REPLIES 2
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-06-2011 04:20 AM
Tom,
The bean you are referring to, is this a Session-scoped bean or just a regular one? Perhaps something to do with the fact the job's are executed in another thread.
Can you create a simple test-case with a process that shows the bug you are describing?
The bean you are referring to, is this a Session-scoped bean or just a regular one? Perhaps something to do with the fact the job's are executed in another thread.
Can you create a simple test-case with a process that shows the bug you are describing?

Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
06-06-2011 09:30 PM
Hi Frederik,
Thanks so much for getting back…
This is just a standard Spring bean.
Yeah, I was kind of thinking the same thing. It's almost like the reference to the Spring context is getting put up for garbage collection on the original thread, given the inconsistency across executions. If the original context was tied to the process execution prior to the job, then if that process execution goes away, the context would, potentially, do the same? But then I suppose this would likely be seen in other scenarios that didn't involve looping. Hmmm….
No problem, I'll put something together and reply to this post with the sample. It would probably be good for me to dial down my process into the essential elements causing this anyways. I'll post back soon.
Thanks again,
Tom
Thanks so much for getting back…
The bean you are referring to, is this a Session-scoped bean or just a regular one?
This is just a standard Spring bean.
Perhaps something to do with the fact the job's are executed in another thread.
Yeah, I was kind of thinking the same thing. It's almost like the reference to the Spring context is getting put up for garbage collection on the original thread, given the inconsistency across executions. If the original context was tied to the process execution prior to the job, then if that process execution goes away, the context would, potentially, do the same? But then I suppose this would likely be seen in other scenarios that didn't involve looping. Hmmm….
Can you create a simple test-case with a process that shows the bug you are describing?
No problem, I'll put something together and reply to this post with the sample. It would probably be good for me to dial down my process into the essential elements causing this anyways. I'll post back soon.
Thanks again,
Tom
