click here for details... Sakai Executive Director Position Search now open
Issue Details (XML | Word | Printable)

Key: SAK-12237
Type: Task Task
Status: Resolved Resolved
Resolution: Fixed
Priority: Major Major
Assignee: Ray Davis
Reporter: Ray Davis
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Sakai

Support local configuration of complex objects

Created: 19-Nov-2007 14:08   Updated: 27-Oct-2009 13:43
Component/s: Component service (Pre-K1/2.6)
Affects Version/s: 2.5.0
Fix Version/s: 2.6.0

Time Tracking:
Not Specified

Issue Links:
Depend
 
Relate
 

2.6.x Status: None
2.5.x Status: None
2.4.x Status: None


 Description  « Hide
The resolutions of SAK-10057 and SAK-11347 demonstrated two approaches to support of optional "service provider" components which could be safely deployed as inactive binaries, possibly with a default implementation, and then selected (and made active) at runtime via a local "sakai.properties" file:

1) Define the service as a proxy around a target implementation ID.

2) Define a settable ID property in a central "provider selector" (e.g., UserDirectoryService's "providerName").

However, these only assume configuration specifications consisting of property strings, and only take care of on-or-off configuration. To allow for production deployment of binary service implementations which integrate with complex systems such as LDAP, we also need to support no-compile configuration of attribute-to-property maps and other more complex objects.


 All   Comments   Work Log   Change History   Subversion Commits   git Commits      Sort Order: Ascending order - Click to sort in descending order
Ray Davis added a comment - 20-Nov-2007 14:15
In working through a code review from Antranig, it became clear that I needed to be explicit about a restriction I'd been taking for granted:

Any beans _defined_ by "sakai-configuration.xml" should refer only to Java classes available at the "shared" level of classloading. That is, the "class" attribute of the bean definition should be standard JDK, or a Spring kernel class, or a domain model class deployed as part of a "shared/lib" API.

Ray Davis added a comment - 03-Jan-2008 14:00
Merged branch into trunk at revision: 39741.

John Bush added a comment - 21-Aug-2008 15:03
At first this restriction scared me, but can't you workaround it by using spring's ProxyFactoryBean. Say you want to override some default sakai service, just deploy your new service with a new name as a normal component, and then in the sakai-configuration.xml create a ProxyFactoryBean to delegate to your new service. This way you won't have to put all your impl's jars in shared. Do you think this would work ?

Ray Davis added a comment - 21-Aug-2008 15:26
Shouldn't be necessary to jump through those hoops. By definition, if you've deployed a service as a normal component, it must be reachable via at least one shared-accessible interface, and I believe that will remain the case even in an OSGi world. In sakai-configuration.xml, alias to your component bean and you should be fine, since that's read at the same level as all the other component definitions.

If you're interested, I'd be glad to work through a specific case with you. It would probably help with finishing up the documentation, too. :)