[ http://issues.apache.org/jira/browse/JCR-57?page=comments#action_60491 ] Felix Meschberger commented on JCR-57: --------------------------------------
An interesting problem it is, really :-) Actually, in the realm of Eclipse, the restriction makes sense. I'm pretty sure I can circumvent in my current use case. And you may be right, that the current implementation of shutting down the repositories on shutdown of Eclipse is not the perfect implementation (this is not an Eclipse problem, just to be clear). Now for the real problem. In my opinion, shutting down should use as scarce resources as possible, actually the issue is to dispose of resources used, so it seems somewhat illogical to first acquire even more resources, to dispose of them immediately. So it is true: shutting down the repository is not optimal at the moment and future extensions/enhancements of the repository should really take care to not acquire new resources just before disposing of all of them. Regarding the shutdown hook: I think it is ok to have a shutdown hook just for stability to do the least possible to try to cleanly shutdown - of course this is only a safety rope if the user of the repository fails to cleanly shutdown. That is the primary means of shutting down the repository must be the client calling RepositoryImpl.shutdown(). This being said, I personally think, it is not the best implementation to from the outside of the observation manager get the listeners and remove them one by one. We prevent the oberservation manager from doing more intelligent resource disposal if we do not inform the observation manager on the real event going on. An then it is not the best solution performance wise. I think, if we dispose of the workspace, the workspace should in turn dispose of the observation manager, which finally knows best how to clean up the listeners and anything else behind itself. The observation manager might even be capable of preventing the allocation of new objects (the iterator and the listener wrappers) just to remove the listeners. Speaking of symetry: The observation manager has a constructor knowing how to set up the class. It is not the workspace setting up the observation manager internall. So why should disposal be different ? > WorkspaceImpl.dispose() might cause ClassNotFoundException > ---------------------------------------------------------- > > Key: JCR-57 > URL: http://issues.apache.org/jira/browse/JCR-57 > Project: Jackrabbit > Type: Bug > Environment: Jackrabbit SVN 156540 > Reporter: Felix Meschberger > > Wenn using Jackrabbit in an environment, where ClassLoaders may get > inactivated in the sense, the loading new classes is not possible anymore, > shutting down the repository may result in a ClassNotFoundException during > WorkspaceImpl.dispose(). > Reason for this is, that in the dispose() method, the ObservationManager is > asked for all registered event listeners for them to be removed from the > ObservationManager one-by-one. Asking for the listeners results in a new > EventListenerIteratorImpl object being created. > If now, this class has never been used during the live time of the > repository, this would cause a ClassNotFoundException because the class > loader is not laoding classes anymore in the specific environment. > The specific environment is Eclipse, where one plugin is managing different > Repository instances provided by separate plugins. When now the Jackrabbit > provider plugin has already been stopped while the managing plugin tries to > shutdown the Jackrabbit repository, the EventListenerIteratorImpl class > cannot be loaded anymore and disposing the WorkspaceImpl in a controlled way > fails. > I suggest adding an ObservationManagerImpl.dispose() method, which is called > by the WorkspaceImpl like : > WorkspaceImpl.dispose() { > if (obsMgr != null) { > obsMgr.dispose(); > obsMgr = null; > } > } > As a side effect of not calling getObservationManager[Impl]() the observation > manager would also not be created if not existing yet. > As a side effect to having the dispose method is, that the > ObservationManagerImpl class could also do other cleanup work in addition to > clearing the listener lists. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira
