Re: [gatein-dev] RepositoryContainer as the first thing to stop during shutdown

Generally speaking the doc of eXo JCR is hosted on your web site here http://www.jboss.org/exojcr/documentation We don't have any doc that describes how the kernel works as it is implementation specific and it could change from one version to another. For example with the new multi-threaded kernel, the way it is done, is already different from the current kernel. What I meant by "did you check it?", I meant : did you check the code? Let me try to explain simply without getting into too much details (if I can). In your configuration files, you define all the components. According to the location of those files, they can be affected either to the RootContainer or to the PortalContainer(s) in case of the portal mode which is the mode used by Gatein. In case of the standalone mode, they will be affected to the StandaloneContainer. All those containers are ExoContainers, when you start an ExoContainer behind the scene it first gets all the components of type Startable, then it instantiates them, and finally it starts them. Any time a component is instantiated it is added to a List. This List will be used to define the startup sequence. It will also be used to define the shutdown sequence by reversing it. To make it clear, let's give an example, let's say that we have A that depends on B and B that depends on C, and A and C are Startable. The kernel gets all the components of type Startable, so it gets A and C. Then it tries to instantiate them, so first it will try to instantiate A but for that it will need to instantiate C because of B, so the first element in the list will be C, then B, then A. To get our startup sequence we keep only the Startable components of this List, so we will have only C and A. So it will first start C then A, and will stop A then C. So far, I believe that it was clear for you, the use case that you mention is actually a specific one. In the hierarchy of ExoContainers (in portal more), we have first the RootContainer, then we can have one or more PortalContainer(s), then we can have one or more RepositoryContainer(s) (we have one RepositoryContainer per repository) and finally we can have one or more WorkspaceContainer(s) (we have one WorkspaceContainer per workspace). The PortalContainers are created by the RootContainer and the RepositoryContainer(s)/WorkspaceContainer(s) are created, initialized and started by the RepositoryService at startup. Why do I see the RepositoryContainer in the shutdown sequence ? Because the RepositoryContainer is added to the PortalContainer and an ExoContainer is Startable Why the RepositoryContainer is the first element in the shutdown sequence ? Because it is added in the startup phase so all the Startable components are already instantiated and added to the List that defines the startup sequence, which means that it will be the last element in the List so the first element to be stopped Why I don't see the RepositoryContainer in the startup sequence? Because it is added after by the RepositoryService in the startup phase Why do you create/initialize/start the RepositoryContainer in the start method of RepositoryService? Because this service depends on component plugins, so we need to be sure that we have all of them before creating the repositories and the workspaces which is only possible in the start method I hope it is clear enough now On Tue, Nov 12, 2013 at 8:59 AM, Juraci Paixão Kröhling <jcosta(a)redhat.com <mailto:jcosta@redhat.com>> wrote: On 11/11/2013 05:47 PM, Nicolas Filotto wrote: > To be able to understand that you need to understand how the kernel > works, did you check it? To be honest, I couldn't find much information about how the kernel works, other than the overview in the reference guide and by looking at the code, with a debugger attached :-) I'm trying to read as much as I can, but it seems that the information for contributors is spread in some places and not following some structure, making it a bit hard to put the things together. If you could suggest some particular reading or approach, I'd appreciate! Thanks, Juca.