This is a great overview of framework usage and library popularity in JAVA. Clearly presents statistics on uptake of specific solutions for webapplication frameworks and scripting languages.
|What Does 2012 Hold for Java?
|Sponsored by: ZeroTurnaround
|Analyzing your data to find business insights is always an exciting activity, but can be extremely tedious. Thankfully, that job has already been done for you in this year’s Java EE Productivity Report.
Read this report to find a selection of technologies and tools available for Java development teams to choose from. Gain deeper a comprehension of how developers spend their time and what elements of the developer work life increases or decreases efficiency. Other topics include:
- Developer tools and technologies usage report
- Developer timesheet
- Developer efficiency
- And developer stress.
To continue evolving towards DSpace 2.0 goals this year, @mire will continue to provide further refactorings of the DSpace legacy codebase. These refactoring efforts are focused now on resurrecting and completing the the DAO prototype work of past Hewlett Packard developer, James Rutherford. This work includes efforts to separate the legacy DSpace codebase into a separate Domain Model and Data Access Services. Once integrated into DSpace 1.8, new DSpace Services for legacy DSpace objects will provide a common API for both the DSpace Application tier and external addon modules.
Find out more about this project in the Development Proposals section of the DSpace wiki.
After some discussion todays DSpace Committer meeting its apparent that others are just not getting the point of using the DSpace Service Manager. I’ve decided to start a series of articles to address this in the community. Please feel free to comment on this topic. I’ve written the article in the DSpace wiki at the following location (with the ambition being that it can be used as future documentation).
I released a new version of DSpace Services (2.0.1) we will use in DSpace 1.6.1. This version includes some minor bug fixes and improvements which include the following:
1.) Look in the correct locations for dspace.cfg and local properties. There were problems with these that just were not evident in the Unit testing.
2.) Use of the classpath*: Resource resolution scheme when searching the classpath for dspace-core-services.xml spring files. This allows DSpace Addon Modules to Properly introduce Services , Activators and Beans into the Spring ServiceManager for use in DSpace
Find out more at:
These new features should make creating DSpace Addon Modules a little bit more accessible.
I’ve recently been working on the DSpace Services implementation. I’ve no doubt that in our current case, such Service implementations should be initialized by Spring. However, the current DSpace ServiceManager currently utilizes a great deal of Spring Auto-wiring and Dependency Injection to be initialized into existence. For instance within the CachingServiceImpl, we see much of this:
However, just a few lines lower we see.
This infers that once we have the Service manager, we can now acquire just about any service we need to work with in the initialization and runtime activities of the current module, theres much less of a need to inject.
I find this very inspiring. I think this will be the bridge point between DSpace Services and OSGi / SpringDM environments. The predominant concern however, is that the ServiceManager shouldn’t be interrogated until it is properly started, which happens after Spring has finished initializing. So we should restrict ourselves from using it to wire bean properties in place of Spring. In fact, we should avoid retaining references to the services outside the scope of its usage within the class.
My recommendation now for DSpace Services is to go through and start to limit the current usage of DI within Services to the Addon Module Project the Service Resides in. Not that we can’t use it within the context of the DSpace Addon Modules configuration for defining implementation centric DI Configuration. But just that we should define best practices concerning the boundaries that we should expose Service wiring across. Take for instance, the following as still a valid practice:
I think that maybe its better to reserve the power of Spring IoC / DI to the same scope as its applied in SpringDM, utilizing it to act to initialize resources locally within the bundle. I think the real power of this is that when services are truly delivered by something like OSGi Bundles, making sure that our Addon Modules get their services from the ServiceManager at Runtime and not from Spring at instantiation time will assure that much of the code depending on these services will not need to change when DSpace is run in an OSGi environment.