On 7 October 2010 06:55, Mark Diggory mdigg...@atmire.com wrote:
You know I'm for (1) simplified spring only service manager. (2) jdbc
data source delivered by servlet container (3) dropping reflectutils.
Well, the JDBC datasource is a change to dspace-api rather than -services,
but there is no reason why it can't go into DSpace 1.7.
I'm not so sure about dropping the MBean registration completely, the
whole idea was that we could have a container level service manager
and services deployed across webapplications. But I assume this is
just too crazy an approach to maintain and educate others on its
usage. I'm just not convinced we would use a servlet container in
this manner and simplification is no doubt more important...
My default position is to say that if we aren't actively using something, we
shouldn't have it. Whilst the registration technically works, we haven't got
close to properly testing and qualifying sharing resources across contexts
(/classloaders), and people will run into a lot of problems attempting to
use it that way.
Besides which, MBean isn't really the way to share resources in that way -
JNDI is. Although MBeans are available outside a container, whereas JNDI
isn't necessarily. I wouldn't class that as a good reason to use MBeans -
it's a good reason to have that part of the functionality switchable -
rather than a static manager that combines singleton and MBean registration
as conditional logic, it should be a static facade to either a singleton or
Mbean (or JNDI) implementation.
That's slightly beside the point though, as in general, I agree with you -
cross context sharing is a headache, a problem I don't think 'we' want to
try and solve, and difficult for people to understand. If you need that kind
of dynamic/component environment (and I don't think it's that big a deal to
either assemble a web application combining multiple artifacts, or deploying
it as a whole), then there are better ways of dealing with it (either
SpringDM or EJB).
My only concern is that the ability I put inplace for addons to
deliver their own spring config and have the manager load it (in a
SpringDM style manner) be maintained, and I see its still there... :-)
It's possibly an area that could yet be simplified though (I've taken a
somewhat pragmatic approach so far to not rip up any existing public APIs
unless they are problematic in the current form). One question to ask is
would it only need the SpringDM style approach when you would be using
SpringDM (on the assumption that you are using that for a dynamic
environment)?
What if we put it in the dspace-services trunk, adjust the dspace
trunk to use it and use this to get some community testing/feedback?
If it fairs well over the next month... then we can do an official
release of dspace-services just prior to the dspace 1.7.0 release
candidates...
Yes, that sounds like a plan. Although it passes it's unit tests (with only
minor test modifications necessitated by the contract tightening), and I've
used it in a DSpace 1.6.2 application without any direct modifications
(related to the services at least), it does need more extensive
in-application testing.
G
--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3.
Spend less time writing and rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb___
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
