Refactor component manager to remove Spring Framework JARs from shared area
GENERAL
TESTING
GENERAL
TESTING
Description
The errors which occur when deploying tools/components which bundle their own versions of Spring jars (Spring itself, as well as aopalliance and cglib) are rather opaque, and especially offputting to new developers. Also, a centralised version of Spring creates an "unnatural pressure" for Spring versions to be kept up to date throughout the framework.
The Sakai component manager could be refactored to return the classes in the "impl" package of the "component-api" module back into "component-api", thereby insulating developers from the central Spring version. This shouldn't require very much more than adding one API to ComponentManager,
public void loadComponentPackage(File dir);
to receive the impl in SpringCompMgr the current impl in ComponentsLoader. Explicit references to SpringCompMgr throughout the codebase are thankfully light and shouldn't require much upheaval.
[Bulk Comment] This issue is reported as affecting Sakai 1.0, 1.5, 2.0, 2.1, and/or 2.2; however, it is not reported as affecting a currently supported version of Sakai (2.3 or 2.4). If this issue is indeed still a concern for a supported version of Sakai, please do re-open the issue and add the appropriate 2.3 and/or 2.4 version to the Affects Version field. (Please do not remove existing Affects Versions when adding the new Affects Versions.)
Peter Knoop April 24, 2007 at 8:37 AM
Moved to Feature Request until such time as someone is interested in taking this on as active task and clearly defining the issue(s) at hand.
Antranig Basman April 24, 2007 at 3:31 AM
Yes, but my initial comments were a rather simplistic in terms of what it would take to do this for real - various other requirements have been accumulated in the mean time.
The errors which occur when deploying tools/components which bundle their own versions of Spring jars (Spring itself, as well as aopalliance and cglib) are rather opaque, and especially offputting to new developers. Also, a centralised version of Spring creates an "unnatural pressure" for Spring versions to be kept up to date throughout the framework.
The Sakai component manager could be refactored to return the classes in the "impl" package of the "component-api" module back into "component-api", thereby insulating developers from the central Spring version. This shouldn't require very much more than adding one API to ComponentManager,
public void loadComponentPackage(File dir);
to receive the impl in SpringCompMgr the current impl in ComponentsLoader. Explicit references to SpringCompMgr throughout the codebase are thankfully light and shouldn't require much upheaval.
This would also resolve issue SAK-5292.