there are some situations where we need to support passing of environment objects into the service method invocations: * user provided JDBC connection * user provided hibernate session * programmatic specification of the current authenticated user Of coure, we should not add those as optional parameters to all our service method invocations. One solution I thought of was something like this: /** the {@link TaskService task service} that exposes the | * runtime human task lists. */ | TaskService getTaskService(); | | /** the {@link TaskService task service} and supply some | * transactional resources. The given transactional resources will only | * be associated to the returned task service. */ | TaskService getTaskService(Map<String, Object> envObjects); | that way, environment objects could be passed in to the service objects. TaskServices that are created with the second method would typically be used for only one invocation as transactional resources are passed into it. Still trying to figure out how we can cleanly handle typed objects... When the engine e.g. gets the Authentication with Environment.getFromCurrent(Authentication.class) then we should be able to do something like: Map<String, Object> envObjects = new HashMap<String, Object>(); | envObjects.put("authentication", new UserProvidedAuthentication("johndoe")); | TaskService taskService = processEngine.getTaskService(envObjects); | taskService.take(taskdbid); View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218513#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...