Java calls and per-thread model for Spring/Tapestry5 service

[jugglingcats]

Hi, I've done a bit of work to wire Tapestry5 IOC into jBPM4, very similar to the method used by SpringConfiguration in the distro. I can now do Tapestry dependency injection on my classes used by custom/decision/etc nodes which makes me very happy!

Now Tapestry has a @PerThread annotation which can be very useful when using a service which might be used multiple times across multiple services in a thread of execution but needs to be cleaned up when the thread completes.

Is there any suitable point at which we can hook into the completion of a Java call from a node to do the thread cleanup? I think it would be safest initially to do this around each discrete Java call rather than try to be clever and define a wider scope for the thread.

Many thanks, Alfie.

[kukeltje]

As long as there are no asyc activities, jobs or async use of the api involved, the safest place seems to be before you do the last call to the api. Most of the time you know best yourself when this is. But I'm no expert in jPBM 4 yet, so I'm not 100% sure.

[jugglingcats]

The aim is to not have the service aware of how it is being used. The service is returned to jBPM to subsequently invoke method(s), so there is no suitable point in the code to do the thread cleanup.

Imagine that there is some code in jBPM that logically does:

- Get bean from context (invokes the Tapestry/SpringContext in the context chain to get the service bean)

- Invoke service method

<-- here is where we need to do thread cleanup

- Continue with execution

Hope this makes sense.

Alfie.

[jugglingcats]

Sorry should have said there is no suitable place in the service's code or Tapestry/SpringContext. Am hoping there is a suitable hook point in the jBPM code!

Alfie.

[kukeltje]

Sure there is in jBPM. You can put eventlisteners on all kinds of events e.g. on nod leave etc, but then you'd have it all over you definition. Unless you make 'process-global' eventlisteners. Still, feels kind of dirty. You could also override the jBPM activity implementations and use those. Still, why do you need to do thread-cleanup especially when the thread completes? Aren't all objects destroyed anyway?

[kukeltje]

oh... btw... juggling cats? Alfie? http://www.youtube.com/watch?v=2B1QxOmbMZ0?