...
We currently have a reasonably large number of jars in shared. Some are API's, and others are there because they need to communicate over multiple webapps. Spring has been placed in shared since it provides the basis for the Component Manager, but since it is in shared space, anything that it depends on has to also be in shared. This pulls in Hibernate which makes it impossible to use anything else that depends on a different Hibernate version, eg Alfresco. Because Hibernate's session handling is essentially static (class-level), having Hibernate in shared also forces Sakai developers to split their persistence-handling code out into its own shared JAR. Since the whole point of Hibernate is to make development faster and more straightforward, this unusual build structure makes Hibernate a much less attractive option.
We could devise clever classloader isolation mechanisms, better jar isolation could also be achieved by removing Spring from shared.
Component Isolation is also about the isolation of components that are exposed or exported to other components or webapps. At present every Spring bean is available by name to every other component. This makes it hard for more sophisticated users of Spring to get correct as they may get references to internal beans when performing wild card queries against the component manager. Less sophisticated developers can easily trample on other components' internal beans without realizing it. Finally, the all-in-one namespace makes it impossible to know which bean properties can be overridden fairly safely and which ones should be left alone.
Reloading Components
In production we need manage the servers and have the ability to fix app servers when they go wrong. Currently when an appserver goes wrong, the users on that app server will experience some loss of service, and then when the app server is restarted they will loose their sessions. The promise of reloadability is to replace or repair individual components within the app server rather than restart it. Component reloading works by emptying a component of active threads by queuing up threads in a safe place, usually a proxy, and then reloading the component - releasing the threads when done. If the component can't be emptied of active threads the reload will fail and the reload can't save components that are causing out of memory errors. The users will notice a period of delay, and if the component fails to restart they will probably notice errors and perhaps loss of session.
An alternative approach to making it possible to manage the app servers without interrupting the users it to make their sessions mobile. If this is achieved it becomes possible to restart entire app servers one by one without impacting the users sessions since each request can use any app server in the Sakai cluster. Reloading individual components is useful when Sakai is hosted on a single box or when users sessions are not mobile between app servers in the cluster.
...
In some areas of Sakai we have Optional or Provider components interfaces that are only used if they exista component named after that interface exists. The current mechanism is to check if the expected bean exists and then use it if it does. Although this works it is not the most elegant way of decoupling provider dependencies (... please edit if you think this is wrong...)Unless special work is done to make the top-level provider a proxy and to make all target provider implementations "lazy", this means that only one binary implementation of a provider interface can be deployed, which in turn forces institutions to edit and build from source code rather than simply configuring a binary distribution of the product. Obviously that doesn't fit well with the original promise of drop-in selectable interfaces.
Reducing Code Maintenance Costs
...
Many modern, and particularly Spring-based libraries, cannot function correctly in Sakai's current ClassLoader environment, since in component code the context ClassLoader is incorrectly set to the most recent webapp which serviced a request. The concept of the context ClassLoader was introduced in Java 2, and an increasing number of libraries are relying on it. With an incorrect context ClassLoader, many packages, such as Alfresco, or ActiveMQ cannot be used without a good deal of custom coding, in the case of Alfreso a prohibitive amount. At a lower level, the incorrect ClassLoader causes unexpected effects with many Spring-based techniques (resource loading, creating proxies etc.) which steepen the learning curve for developers who are familiar with Spring but not Sakai. (For example, transaction proxies in a component can only be defined against targets which have an interface in shared space.) Correcting the context ClassLoader is one of the functions that could be achieved by a proxy-based design (see below).
...