| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
| ||
|
Qi4j releases version 0.5
The Qi4j community today produced another pre-release, version 0.5, containing a large set of new features and more stable APIs.
hafskghwafibwqkhjvcbqajkbchvabcjvna
Today's release of Qi4j version 0.5 has been long anticipated, containing important milestones and many improvements under the hood.
In previous versions, Qi4j didn't have a distinction between services that were supposed to be managed by Qi4j and those that had their own external management and lifecycle control. This new distinction makes integration with other service oriented frameworks a lot easier.
Magnus Robertsson @ Jayway brought to our attention that Qi4j's APIs were not architecturally sound and recommended us to use Structure-101 to sort these out. This exercise provided an opportunity to clean up the Core API, Core SPI and Core Bootstrap to one gigantic step closer to the final versions. However, endless incompatibilities in terms of new/different package names was a result.
The Qi4j team finally managed to settle on an initial definition on what Values and ValueComposites really encompasses. In the end, values are immutable, only contains Property methods, has no dependency injection other than @PropertyField and @This and equals/hashCode computed automatically from the property values.
In 0.5 we support and encourage the use of property subtypes, such as;
Imported vs Hosted Services
In previous versions, Qi4j didn't have a distinction between services that were supposed to be managed by Qi4j and those that had their own external management and lifecycle control. This new distinction makes integration with other service oriented frameworks a lot easier.
Cleaner Architecture
Magnus Robertsson @ Jayway brought to our attention that Qi4j's APIs were not architecturally sound and recommended us to use Structure-101 to sort these out. This exercise provided an opportunity to clean up the Core API, Core SPI and Core Bootstrap to one gigantic step closer to the final versions. However, endless incompatibilities in terms of new/different package names was a result.
Value Composites
The Qi4j team finally managed to settle on an initial definition on what Values and ValueComposites really encompasses. In the end, values are immutable, only contains Property methods, has no dependency injection other than @PropertyField and @This and equals/hashCode computed automatically from the property values.
Property subtypes
In 0.5 we support and encourage the use of property subtypes, such as;
public interface Name extends Property<String>
{}
{}
which also provides the uncomplicated mechanism of putting concerns on the set()/get() methods of properties.
The previous use of separate types for immutable and computed properties has been removed and we now use annotations instead. This makes the internal code a lot cleaner, and makes it easier to override from for instance property subtypes in their usage contexts.
It is now possible to mark properties or the whole entities as @Queryable(false), and they will not be indexed for searches.
The library-spring now also contains a system on integration of Spring beans as services into Qi4j. The library already contains integration in the opposite direction. This will allow existing Spring applications to be complemented with Qi4j functionality.
All Core jar files should now be proper OSGi bundles and it is possible to create OSGi applications with Qi4j. Qi4j does not currently have any additional support for the dynamic behavior of OSGi, which must be handcoded if to be supported.
@Immutable & @Computed
The previous use of separate types for immutable and computed properties has been removed and we now use annotations instead. This makes the internal code a lot cleaner, and makes it easier to override from for instance property subtypes in their usage contexts.
Non-indexed Properties and Entities
It is now possible to mark properties or the whole entities as @Queryable(false), and they will not be indexed for searches.
SpringFramework integration
The library-spring now also contains a system on integration of Spring beans as services into Qi4j. The library already contains integration in the opposite direction. This will allow existing Spring applications to be complemented with Qi4j functionality.
Increased OSGi support
All Core jar files should now be proper OSGi bundles and it is possible to create OSGi applications with Qi4j. Qi4j does not currently have any additional support for the dynamic behavior of OSGi, which must be handcoded if to be supported.
Qi4j and the Qi4j logo are trademarks of Richard Öberg, Niclas Hedhman and the members of the Qi4j Core Team. See Qi4j licensing for more information.
