Would anyone mind if I added PicoContainer compatability to the ConnectionManager, ThreadManager etc components formerly known as Cornerstone?
you mean addition of various classes like
ConnectionManagerBean extends DefaultConnectionManager
{
public PicoConnectionManager( /* ... stuff goes here ... */ )
{
/** ... stuff goes here ... */
}
}right?
No problem with that per se. I think its an elegant idea and providing some support for it would be nice, but there some potential issues to remove first. IIUC, adding a new dependendency to DefaultConnectionManager would mean that this ConnectionManagerBean its constructor would need to change too. Which means we should be willing to maintain it. Makes one wonder:
- Who is going to maintain that? (only possible good answer: the same people that work on cornerstone)
- Is it possible to automate this maintainance? If so... is it already implemented? Who will implement it? Where will that stuff live? (possible answer: there's a maven-pico-avalon-interop plugin that generates the class based on the @avalon.dependency attributes over at picocontainer.org)
- Are we willing to track PicoContainer developments? (iow what is the vector of change for the constructor argument concept and is that acceptable to us)
- What about backwards compatibility issues where people who just use this stuff as beans depend on the signature of the constructor? (this worries me the most. Adding a dependency might mean code changes to client code.)
maybe it makes sense to do this on a branch first? I don't really feel like adding these classes, releasing, reconsidering, and then alienating users.
Thoughts?
like the idea, but some reservations :D
- LSD
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
