Posts tagged CDI
Jakarta EE 10, the first major release of the platform since it was transferred to the Eclipse Foundation, did come with a slew of changes and updates to many of its constituent specifications. One such specification that received updates is the Jakarta Contexts and Dependency Injection specification. The specification release version for Jakarta EE 10 is Jakarta CDI 4.0, which came with major changes.
Two of such major changes are the split of the specification into a Lite and Full profiles and the change in default behaviour for an empty beans.xml file. In this blog post, we take a quick look at getting started with Jakarta CDI, in my view, the single most influential specification on the Jakarta EE Platform.
The Jakarta Contexts and Dependency Injection API is the standard dependency injection framework on the Jakarta EE Platform. The latest version of the CDI specification that shipped withJakarta EE 10 is CDI 4.0. This release features a split of the core CDI API into Lite and Full. CDI Lite is designed to run in more restricted environments, and features a subset of the original features. CDI Full contains the Lite and all other features that were in core CDI in previous Jakarta EE releases.
The capability to disable implicit CDI scanning was already added to the previous Payara Server releases but the default admin console setting was to enable it at deploy time. We have now made a change so that the value added to the deployment descriptor is the overriding setting and the admin console setting will be ignored.
For even more control, we have added the ability to explicitly include or exclude JARs within an Application Deployment from CDI scanning. You can now, for example, include all JARs by default and exclude some named ones, or do the opposite and exclude all by default and only include some named ones.
Another quarter, another release! After an eventful 2016, November brings with it the final release of the year for Payara Server. This year, we've seen new services like Request Tracing and Health Check added, as well as the Slow SQL logger and SQL Trace Listeners. Revisiting the version of the documentation from 1 year ago and comparing the amount we have added since then is, frankly, astonishing!
Despite a bumper year for both new features and bug fixes, work continues apace! Below is a short summary of some of the things to look out for in a release that caps an incredible 12 months.
Back in June we announced MicroProfile with RedHat, IBM, Tomitribe, LJC and SouJava and Microprofile.io was launched as a location for community collaboration on Enterprise Java Microservices. In the announcement each of the vendors promised to have a MicroProfile runtime ready and available in time for JavaOne. Well after much beavering away here in the Payara Engineering team we have just pushed onto Maven Central our 1.0 release of Payara MicroProfile.
Any project, large or small, would ultimately like to follow industry best practices, such as continuous deployment. In order to support this, applications must be deployed early and often. This, in turn, triggers downtime and the users get affected by it because they could be logged out of the website, or worse, their work gets lost because the application's intermediate state is not saved - never mind the actual downtime during the application deployment process.
Rolling upgrades solve this problem in an efficient way!
As we enter the third quarter of the year, that can only mean one thing: Payara Server 163 is here! With this release, we’ve managed to cram in 44 bug fixes, 34 enhancements, 6 new features and 6 component upgrades. One of these new features is the tech preview of our new Request Tracing service, which I’ll explain in more detail below.