[
http://jira.amdatu.org/jira/browse/AMDATU-507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12306#comment-12306
]
Jan Willem Janssen commented on AMDATU-507:
-------------------------------------------
By pushing new Runnable's for each install/update/uninstall to your executor
you're placing them on a queue, which is handled in order. Each runnable
contains the begin/process/prepare/commit calls to your
AutoConfResourceProcessor. If you create a new session for each of those
runnables, and fix the AutoConfResourceProcessor to stick to that single
session, the contract of the FileInstall service & DeploymentAdmin's
ResourceProcessor are met.
Or am I misinterpreting your last remark?
> Code review: fileinstall.autoconf
> ---------------------------------
>
> Key: AMDATU-507
> URL: http://jira.amdatu.org/jira/browse/AMDATU-507
> Project: Amdatu
> Issue Type: Improvement
> Components: Amdatu Core
> Reporter: Jan Willem Janssen
> Assignee: Bram de Kruijff
> Labels: code_review
> Fix For: Sprint 2
>
>
> My code review:
> * redundant service-lifecycle methods (start/stop);
> * the install/uninstall/update methods are using synchronized blocks icw
> framework calls; possible deadlocks!
> * the install/uninstall/update methods want to perform an atomic block, which
> should be implemented in a different way (see Felix'
> AutoConfResourceProcessor for example);
> * possible resource leaks: new FileInputStreams are created, but never closed
> properly;
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
http://jira.amdatu.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
Amdatu-developers mailing list
[email protected]
http://lists.amdatu.org/mailman/listinfo/amdatu-developers