"I love Jakarta Blogs "

2022-05-09 11:42:10

Skip to main content Manage Cookies About Add your blog Community Marketplace Events Planet Eclipse Newsletter Videos Blogs Participate Report a Bug Forums Mailing Lists Wiki IRC Research Eclipse IDE Download Documentation Getting Started / Support How to Contribute IDE and Tools Newcomer Forum More About Jakarta EE Frequently Asked Questions Become a Member Stay Connected 2018 Developer Survey Working Group Charter Technical Direction Newsletter Archives Meeting Minutes Trademark Guidelines Toggle navigation Home Blogs Follow @JakartaEEBlogs Latest Posts Blogs May 08, 2022 Ivar Grimstad Hashtag Jakarta EE #123 by Ivar Grimstad at May 08, 2022 09:59 AM Welcome to issue number one hundred and twenty-three of Hashtag Jakarta EE!The Jakarta EE 10 release is on track! All specifications targeting this release have started their release reviews. The focus of the Jakarta EE Platform project in the coming weeks will be to wrap up the changes for the Platform-, Web-, and Core Profile specifications as well as to ensure that a compatible implementation (or implementations) passes the Platform CTS.Good news! All specifications targeting @JakartaEE 10 is in ballot. So you will get all your 5 favorites #JakartaEE#EclipseFoundation#Community— Ivar Grimstad (@ivar_grimstad) May 5, 2022I am happy to see the activity going on in the Eclipse Starter for Jakarta EE project. Exciting things are about to happen at https://start.jakarta.ee! Make sure to check out the Java EE – Jakarta EE Initializr blog post by Ivo Woltring.The month of May is busy with conferences. This week, I was in Stockholm for Jfokus, and next week I am going to Kraków for GeeCON 2022. It is my first time speaking at GeeCON, so I am really looking forward to it.On the topic of conferences, the CFP for EclipseCon 2022 is open until June 15. Here’s a carrot for you if you’re planning to submit your talk. If you submit it before June 1, you have a chance to be picked as an early bird submission. by Ivar Grimstad at May 08, 2022 09:59 AM May 07, 2022 Adam Bien AWS Lambda with Provisioned Concurrency: How to use the latest deployment with HTTP API Gateway by admin at May 07, 2022 06:37 AM To use the latest AWS Lambda deployment with HTTP API Gateway (or REST API Gateway):import software.amazon.awscdk.services.apigatewayv2.alpha.HttpApi;import software.amazon.awscdk.services.apigatewayv2.integrations.alpha.HttpLambdaIntegration;//...void integrateWithHTTPApiGateway(IFunction function) { var lambdaIntegration = HttpLambdaIntegration.Builder.create("HttpApiGatewayIntegration", function).build(); var httpApiGateway = HttpApi.Builder.create(this, "HttpApiGatewayIntegration") .defaultIntegration(lambdaIntegration).build(); var url = httpApiGateway.getUrl(); CfnOutput.Builder.create(this, "HttpApiGatewayUrlOutput").value(url).build();}...configured with provisioned concurrency, you need to create an alias function.addAlias("XYZ"); (this convenience method was introduced with CDK v2.23.0) in addition to the version and use the function instance for the integration: import software.amazon.awscdk.Duration;import software.amazon.awscdk.services.lambda.Architecture;import software.amazon.awscdk.services.lambda.Code;import software.amazon.awscdk.services.lambda.Function;import software.amazon.awscdk.services.lambda.Runtime;import software.amazon.awscdk.services.lambda.Version;import software.constructs.Construct;public class QuarkusLambda extends Construct { static String lambdaHandler = "io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest"; static int memory = 1024; // ~0.5 vCPU static int provisionedConcurrency = 1; static int timeout = 10; Function function; public QuarkusLambda(Construct scope, String functionName) { super(scope, "QuarkusLambda"); this.function = createFunction(functionName, lambdaHandler, memory, timeout); Version.Builder.create(this, "ProvisionedConcurrencyVersion") .lambda(function) .provisionedConcurrentExecutions(provisionedConcurrency) .build(); function.addAlias("recent"); integrateWithHTTPApiGateway(function); } Function createFunction(String functionName, String functionHandler, int memory, int timeout) { return Function.Builder.create(this, functionName) .runtime(Runtime.JAVA_11) .architecture(Architecture.ARM_64) .code(Code.fromAsset("../lambda/target/function.zip")) .handler(functionHandler) .memorySize(memory) .functionName(functionName) .timeout(Duration.seconds(timeout)) .build(); }}The code is based on quarkus AWS Lambda template. by admin at May 07, 2022 06:37 AM May 06, 2022 Adam Bien How Pulumi for Java Happened--airhacks.fm podcast by admin at May 06, 2022 01:56 PM Subscribe to airhacks.fm podcast via: spotify|iTunes|RSSThe #189 airhacks.fm episode with Joe Duffy (@funcofjoe) about:Java, Infrastructure as Code, Pulumi's architecture, Java support and thoughts on public clouds and serverless computingis available for download. by admin at May 06, 2022 01:56 PM Ivar Grimstad Jfokus 2022 by Ivar Grimstad at May 06, 2022 07:57 AM That was Jfokus 2022. As usual, an excellent conference hosted by Mattias and his team!My talk titled Get Ready for Jakarta EE 10 went well. A couple of hours before the talk, I added a brand new demo of the Java SE Bootstrap feature of Jakarta RESTful Web Services 3.1. I also did the Jakarta EE 8 to Jakarta EE 9.1 migration demo and decided on stage to take it all the way to Jakarta EE 10 instead. Some unexpected hiccups and surprises with the milestone build of GlassFish I was using, but that is sort of expected of a live demo…Thanks, Mohammed for the picture and tweet of me on stage during the demo!I have a dream: deploying my code to prod with the same confidence @ivar_grimstad write fresh demos and deploy them pic.twitter.com/BVb0CmXZpC— Mohammed Aboullaite (@laytoun) May 4, 2022On Wednesday morning, we had the first annual Jfokus morning run. I brought Jakarta EE shirts to all attendees as you can see from the picture below. Next Jfokus will probably be at the usual time in February, so I guess I will have to bring something a little warmer than t-shirts then… by Ivar Grimstad at May 06, 2022 07:57 AM May 05, 2022 Ivo Woltring Java EE - Jakarta EE Initializr May 05, 2022 02:23 PM Getting started with Jakarta EE just became even easier!Get startedJava EE /Jakarta EE - InitializrHot new Update!Moved from the Apache 2 license to the Eclipse Public License v2 for the newest version of the archetype as described below.As a start for a possible collaboration with the Eclipse start project.New Archetype with JakartaEE 9JakartaEE 9 + Payara 5.2022.2 + MicroProfile 4.1 running on Java 17And the docker image is also ready for x86_64 (amd64) AND aarch64 (arm64/v8) architectures! May 05, 2022 02:23 PM May 04, 2022 Thorben Janssen @Incubating features in Hibernate 6 by Thorben Janssen at May 04, 2022 01:42 PM The post @Incubating features in Hibernate 6 appeared first on Thorben Janssen.If you tried Hibernate 6, you might have recognized the new @Incubating annotation. The Hibernate team introduces it to tell users about new APIs and…The post @Incubating features in Hibernate 6 appeared first on Thorben Janssen. by Thorben Janssen at May 04, 2022 01:42 PM Thorben Janssen Hibernate’s ResultTransformer in Hibernate 4, 5 & 6 by Thorben Janssen at May 04, 2022 12:29 PM The post Hibernate’s ResultTransformer in Hibernate 4, 5 & 6 appeared first on Thorben Janssen.Hibernate implements JPA’s standardized constructor expressions and @SqlResultSetMappings to map the results of your queries. And it also supports proprietary ResultTransformers. They provide a powerful…The post Hibernate’s ResultTransformer in Hibernate 4, 5 & 6 appeared first on Thorben Janssen. by Thorben Janssen at May 04, 2022 12:29 PM The Payara Team The Payara Monthly Catch: April 2022 by Priya Khaira-Hanks at May 04, 2022 09:25 AM Every month, we collate the very best content for our specific enterprise Java - Java EE, Jakarta EE and MicroProfile - community. We also look further afield, and where it applies, include interesting blogs, videos and articles on subjects such as DevOps, cloud computing, microservices, software architecture and more.  TL;DR: We know our audience and if we think you will find something very useful when developing enterprise Java applications - it makes the cut!  by Priya Khaira-Hanks at May 04, 2022 09:25 AM May 03, 2022 The Payara Team How Does Payara 6 Affect Your Application’s Future? by Priya Khaira-Hanks at May 03, 2022 01:47 PM The release of Payara 6 Community in a few weeks will be a turning point for many of our users. It's important you review all possibilities in advance. Consider migration to be supported, secure and maintain peace of mind!   We recommend moving to Payara Enterprise,  which we consider the most cost-effective and business-savvy choice. In this blog we explain 5 different scenarios. by Priya Khaira-Hanks at May 03, 2022 01:47 PM May 02, 2022 Francesco Marchioni How to use Camel extensions in Quarkus by F.Marchioni at May 02, 2022 04:37 PM Camel is the open source swiss knife framework for integration, with over 300 components allowing the integration between external systems. In this article we will learn how to use Camel extensions for Quarkus to build powerful Java Integrations. Using Camel with Quarkus Firstly, let’s see which extensions you need to develop Camel applications with Quarkus. ... Read moreThe post How to use Camel extensions in Quarkus appeared first on Mastertheboss. by F.Marchioni at May 02, 2022 04:37 PM April 30, 2022 Markus Karg [DEUTSCH] Von COM zu Jakarta EE (Teil 2 von 3) | Aus der Mottenkiste | Head Crashing Informatics 51 by Markus Karg at April 30, 2022 03:00 PM Dieses Video ist der zweite Teil einer dreiteiligen Serie, die sich mit dem Ursprung von #JakartaEE beschäftigt. Diesmal spreche ich über ISAPI/COM+/#CORBA/#DNA und #Servlets/RMI/EJB/JRMP/#SunONE.Wenn Dir dieses Video gefällt, dann gib ihm bitte einen Daumen hoch, empfehle es weiter, abonniere meinen Kanal, oder werden mein Unterstützer https://www.patreon.com/mkarg. Danke! Stay safe and… Party On! by Markus Karg at April 30, 2022 03:00 PM April 27, 2022 Tanja Obradovic Getting really close to Jakarta EE 10! by Tanja Obradovic at April 27, 2022 05:51 PM The Jakarta EE community teamwork is amazing!  They are completely focused on Jakarta EE 10 release plan and following the Jakarta EE Specification Process we have more progress on the individual specifications.The Release Review is now completed for the following specifications:Jakarta Persistence 3.1 - https://github.com/jakartaee/specifications/pull/442Jakarta Interceptors 2.1 - https://github.com/jakartaee/specifications/pull/450Jakarta JSON Processing 2.1 - https://github.com/jakartaee/specifications/pull/432Jakarta XML Binding 4.0 - https://github.com/jakartaee/specifications/pull/443Jakarta CDI 4.0 - https://github.com/jakartaee/specifications/pull/439Jakarta XML Web Services 4.0 - https://github.com/jakartaee/specifications/pull/445Jakarta RESTful Web Services 3.1 - https://github.com/jakartaee/specifications/pull/430Stay tuned for  more progress in the upcoming weeks or monitor progress on individual specifications release reviews!Please see the other posts specifications with already completed Release Review:Even closer to Jakarta EE 10!Getting closer to the Jakarta EE 10 release! by Tanja Obradovic at April 27, 2022 05:51 PM April 19, 2022 Francesco Marchioni How to manage Transactions in Quarkus by F.Marchioni at April 19, 2022 10:40 AM This article launches you on a tour of Transaction Management in Quarkus applications by focusing on the standard declarative approach and the new programmatic transaction API. Quarkus narayana extension Quarkus, just like other Enterprise applications, uses a Transaction Manager to coordinate and expose transactions to your applications. At its core, Quarkus uses Narayana Transaction Manager, ... Read moreThe post How to manage Transactions in Quarkus appeared first on Mastertheboss. by F.Marchioni at April 19, 2022 10:40 AM April 16, 2022 Markus Karg [DEUTSCH] Aus der Mottenkiste: Von COM zu Jakarta EE (Teil 1 von 3) | Head Crashing Informatics 50 by Markus Karg at April 16, 2022 03:00 PM Dieses Video ist der erste Teil einer dreiteiligen Serie, die sich mit dem Ursprung von #JakartaEE beschäftigt. In der erste Folge spreche ich darüber, wie Ende der 90er Jahre Microsoft auf Basis von C++ die Technologie #COM+ entwickelte, und #SunMicrosystems eine Java-basierte Reaktion darauf plante, um ihre proprietäre Serverhardware besser mit Anwendungssoftware abdecken zu können.Wenn Dir dieses Video gefällt, dann gib ihm bitte einen Daumen hoch, empfehle es weiter, abonniere meinen Kanal, oder werden mein Unterstützer https://www.patreon.com/mkarg. Danke! Stay safe and… Party On! by Markus Karg at April 16, 2022 03:00 PM April 14, 2022 Ivo Woltring Java EE - Jakarta EE Initializr April 14, 2022 10:00 PM Getting started with Jakarta EE just became even easier!Get startedJava EE /Jakarta EE - InitializrHot new Update!New Archtetype with JakartaEE 9JakartaEE 9 + Payara 5.2022.1 + MicroProfile 4.1 running on Java 17And the docker image is also ready for x86_64 (amd64) AND aarch64 (arm64/v8) architectures! April 14, 2022 10:00 PM April 12, 2022 Open Liberty Learn MicroProfile 5.0 and Jakarta EE 9.1 from our newly enhanced cloud-hosted guides April 12, 2022 12:00 AM To learn how to develop cloud-native Java applications and microservices on Open Liberty with MicroProfile 5.0 and Jakarta EE 9.1, you can try out our updated guides. You can run our guides in a hosted environment with enhanced interfaces, without having to worry about local setup and prerequisites. We recently updated 31 of our guides for compatibility with MicroProfile 5 and Jakarta EE 9. The Maven project pom.xml and Liberty configuration server.xml files in these guides are updated to use new Jakarta EE 9.1 and MicroProfile 5.0 APIs and features. Also, all Java classes now use the jakarta package namespace instead of javax, as shown in the following example.To learn more about what changed in Jakarta EE 9.1, see the Jakarta EE 9.1 feature updates documentation. To learn about the differences between MicroProfile 5.0 and 4.1, see the Differences between MicroProfile 5.0 and 4.1 documentation.What are the new enhancements in the cloud-hosted guides?The cloud-hosted guides are enhanced with a new look and updated features. Whether or not you’ve tried them yet, now is the time to experience how easily you can learn to build applications with MicroProfile and Jakarta EE APIs.You can access any of our updated MircoProfile or Jakarta EE cloud-hosted guides by clicking one of the links at the end of this post, or choose from our full collection of guides. After you choose a guide, click the Run in cloud button, as shown in the following image:We’ve enhanced these guides to make them easier to navigate and to simplify running commands and managing files.The following screenshot shows the new look for our cloud-hosted guides. You can navigate to different sections of the guide by clicking the Table of Contents menu:You can also navigate through the guide by clicking the blue progress bar after the Table of Contents menu:Instead of copying and pasting the commands in terminal, you can now run the commands on an active terminal by simply clicking on the Execute >_ icon in the code window.You can now directly open a file by clicking the Open …​ in IDE button, instead of browsing to it from the File > Open menu.Also, you can launch an application simply by clicking the Visit…​ button. The application URL opens on a new browser tab.Which guides are updated?The following 31 guides are updated to use MicroProfile 5.0 and Jakarta EE 9.1 features:Accessing and persisting data in microservices using Java Persistence API (JPA)Adding health reports to microservicesAuthenticating users through social media providersBuilding a web application with MavenBuilding fault-tolerant microservices with the @Fallback annotationChecking the health of microservices on KubernetesConfiguring microservicesConfiguring microservices running in KubernetesConsuming a RESTful web serviceConsuming a RESTful web service with AngularConsuming RESTful services with template interfacesContainerizing microservicesCreating a hypermedia-driven RESTful web serviceCreating a multi-module applicationCreating a RESTful web serviceDeploying microservices to KubernetesDeveloping fault-tolerant microservices with Istio Retry and MicroProfile FallbackDocumenting RESTful APIsEnabling Cross-Origin Resource Sharing (CORS)Enabling distributed tracing in microservices with JaegerGetting started with Open LibertyInjecting dependencies into microservicesManaging microservice traffic using IstioPersisting data with MongoDBProviding metrics from a microserviceSecuring a web applicationSecuring microservices with JSON Web TokensTesting microservices with consumer-driven contractsTesting microservices with the Arquillian managed containerUsing Docker containers to develop microservicesValidating constraints with microservicesWe welcome your feedbackTell us about your experience with our guides by responding to the questions in the Summary section at the end of each guide. We’d love to hear from you! April 12, 2022 12:00 AM April 04, 2022 Open Liberty MicroProfile, Jakarta EE, and Open Liberty at DevNexus 2022 April 04, 2022 12:00 AM DevNexus, the longest-running and largest Java Conference in the USA will be happening this year in Atlanta, GA, from April 12-14. As in-person conferences make a comeback in 2022, this will be a great opportunity to re-connect with the Java community.And of course, members of the Open Liberty team will be on-site hosting multiple sessions and running demonstrations and labs in the IBM booth. If you’re also going to be there, deciding which of the great talks to see can be a bit of a challenge. So we’ve put together a helpful summary of the sessions on MicroProfile, Jakarta EE and Open Liberty.Talks at DevNexus 2022A selection of Jakarta EE, MicroProfile, and Open Liberty talks on Wednesday and Thursday:Wednesday 13thExploring Stateful Microservices in the Cloud Native WorldOpen Liberty’s Grace Jansen and Chicago JUG’s Mary Grygleski discuss how to handle persisting data with containerized microservices in a Cloud Native world.Mother Nature vs Java - the security face offJava Evangelist Steve Poole and Open Liberty’s Grace Jansen explore where software and biology overlap when it comes to security, and lessons we can learn from nature to improve our own application security.Simple tweaks to get the most out of your JVMOpen Liberty’s Jamie Coleman will go through all the different JVM options and give you some easy and simple advice on how to get the most out of your JVM to save not only money but also energy on the cloud.Landscape of MicroProfile and Jakarta EE ToolsOpen Liberty’s YK Chang and Kathryn Kodama will examine the tools that are available to make your life easier as you code MicroProfile and Jakarta EE-based applications. These tools help developers throughout the development lifecycle, from creating a new application, working with compatible runtimes and your favourite editor, to testing your application.Using byte-code analysis to modernize your Java EE applicationsOpen Liberty’s Cindy High will demonstrate how to analyze your Java EE applications using a simple command-line tool that will provide reports on your application structure and detailed analysis of potential issues when moving to a new Java SE or EE level or to cloud environments.Thursday 14thMicroProfile - The Current and The FutureJava Champion Emily Jiang is going to bring you up to date with the latest MicroProfile release and then briefly discuss the future road map for MicroProfile. Come along to listen in or ask questions.Join usAll conference attendees are invited to join us at the IBM booth where you can check out our new Space Rover demo, challenge yourself with one or more Quick Labs, and get some great SWAG. IBMers will also be available at the Eclipse Foundation booth.We’d love to see you at these key activities!Jakarta EE Reception - Tuesday, April 12 @ 17:00 to 19:30 (room #412)Join the Jakarta EE community for some great discussions on the ever-changing landscape in enterprise Java and the future of cloud-native innovation that Jakarta EE represents, while enjoying drinks and snacks on IBM.Book Signing - Wednesday, April 13 @ 15:20 (IBM Booth)Join IBMer, Java Champion, and co-author of a new eBook, “Practical cloud-native Java development with MicroProfile”, Emily Jiang as she signs and gives away copies of this popular publication.Open Liberty Space Rover Challenge - Daily at the IBM BoothNavigate the planets and get your rover safely to your destination in the stars. Take control of a spaceship and use hand signals to direct its flight from planet to planet. Climb the rankings on your way to become top cadet in Star Academy. Our Space Rover Challenge leverages a variety of technologies, including hardware, and modern Java technology. While you’re with us, ask our developers about the underlying technologies they’ve used to create the demo, including Open Liberty, also known as “the most flexible server runtime in the cosmos”, Jakarta EE, MicroProfile, and OpenJ9.Check out IBM’s presence at DevNexus as well as the full schedule on the conference website. April 04, 2022 12:00 AM March 21, 2022 Tanja Obradovic Take the 2022 Jakarta EE Developer Survey Today! by Tanja Obradovic at March 21, 2022 08:51 PM A great way to get involved, provide input and insights of Java enterprise industry is taking part in our fifth annual 2022 Jakarta EE Developer Survey. It takes less than 6 minutes of your time, but the impact is extremely important: it gives, the Jakarta EEworking group and community opportunity to better understand the top priorities for future Jakarta EE releases.This year’s survey asks developers to share their future plans for building modern enterprise applications and their choices for architectures, technologies, and tools in the new cloud era. Take the survey today and let us know about the Java industry landscape, needs of Java enterprise developers in order to help shape up the future and direction of Jakarta EE specifications.  by Tanja Obradovic at March 21, 2022 08:51 PM March 09, 2022 Mike Milinkovich Take the 2022 Jakarta EE Developer Survey by Mike Milinkovich at March 09, 2022 02:14 PM In less than six minutes of your time, you can let the entire cloud native Java industry know what you need to support modern enterprise applications. The Jakarta EE Developer Survey is one of the largest developer surveys in the Java landscape, and the number of responses it generates clearly shows the Java ecosystem believes the results are important.Since we first released the annual Jakarta EE Developer Survey in 2018, thousands of software developers, architects, and decision-makers from around the world have completed the survey.  They see their participation as an opportunity to:Build awareness around their development focus area Share their perceptions of the cloud native Java industry with the broader ecosystem Identify their preferences and priorities for cloud native Java architectures, technologies, and toolsTell the World What You Need in the Cloud EraThis year, we’re asking survey respondents to look ahead and share their future plans for building modern enterprise applications in the new cloud era. It’s a great way to let Java platform vendors, enterprises, and developers know where you see cloud native Java going and the types of technologies and tools you’ll need to help it get there. With this insight, everyone in the Java ecosystem — you included — will have updated information about how cloud native Java is unfolding and what it means for their strategies and businesses.The survey is also an excellent opportunity to help the Jakarta EE Working Group understand how it can best evolve Jakarta EE to meet your cloud development requirements and goals. Working Group members are always listening carefully to Java ecosystem requirements so they can ensure Jakarta EE continues to evolve in alignment with the top industry focus areas and priorities. They want to hear from you, and completing the survey is one of the easiest and most effective ways to give them your input.Survey Results Provide Essential InsightsOver the years, the Jakarta EE Developer Survey has provided many valuable insights into the state of the cloud native Java ecosystem, and the 2021 survey was no exception. Completed by more than 950 individuals, last year’s survey revealed some very interesting trends, including the:Fast-growing adoption of Jakarta EE, making it the second-place cloud native framework for the second straight yearIncreased interest in cloud native Java overallIncreased use of microservices architectures and the decline of monolithic approaches in favor of hybrid architecturesNeed for flexible platforms that can be used to build traditional and cloud native business applicationsExpected growth rates for Java apps in the cloudTo understand the full value of the survey results, read the 2021 Jakarta EE Developer Survey report.Complete the Jakarta EE Developer Survey TodayWe encourage all developers, architects, and decision-makers in the Java ecosystem to add their voice to the survey and help the industry gain the broadest possible view of the state of enterprise cloud native Java.Participate in the survey here. by Mike Milinkovich at March 09, 2022 02:14 PM February 21, 2022 Reza Rahman FOSDEM 2022 Conference Report by Reza Rahman at February 21, 2022 12:24 AM FOSDEM took place February 5-6. The European based event is one of the most significant gatherings worldwide focused on all things Open Source. Named the “Friends of OpenJDK”, in recent years the event has added a devroom/track dedicated to Java. The effort is lead by my friend and former colleague Geertjan Wielenga. Due to the pandemic, the 2022 event was virtual once again. I delivered a couple of talks on Jakarta EE as well as Diversity & Inclusion.Fundamentals of Diversity & Inclusion for TechnologistsI opened the second day of the conference with my newest talk titled “Fundamentals of Diversity and Inclusion for Technologists”. I believe this is an overdue and critically important subject. I am very grateful to FOSDEM for accepting the talk. The reality for our industry remains that many people either have not yet started or are at the very beginning of their Diversity & Inclusion journey. This talk aims to start the conversation in earnest by explaining the basics. Concepts covered include unconscious bias, privilege, equity, allyship, covering and microaggressions. I punctuate the topic with experiences from my own life and examples relevant to technologists. The slides for the talk are available on SpeakerDeck. The video for the talk is now posted on YouTube.Jakarta EE – Present and FutureLater the same day, I delivered my fairly popular talk – “Jakarta EE – Present and Future”. The talk is essentially a state of the union for Jakarta EE. It covers a little bit of history, context, Jakarta EE 8, Jakarta EE 9/9.1 as well as what’s ahead for Jakarta EE 10. One key component of the talk is the importance and ways of direct developer contributions into Jakarta EE, if needed with help from the Jakarta EE Ambassadors. Jakarta EE 10 and the Jakarta Core Profile should bring an important set of changes including to CDI, Jakarta REST, Concurrency, Security, Faces, Batch and Configuration. The slides for the talk are available on SpeakerDeck. The video for the talk is now posted on YouTube.I am very happy to have had the opportunity to speak at FOSDEM. I hope to contribute again in the future. by Reza Rahman at February 21, 2022 12:24 AM January 18, 2022 Otavio Santana Making Readable Code With Dependency Injection and Jakarta CDI by otaviojava at January 18, 2022 03:53 PM Learn more about dependency injection with Jakarta CDI and enhance the effectiveness and readability of your code. Link: https://dzone.com/articles/making-readable-code-with-dependency-injection-and-jakarta-cdi by otaviojava at January 18, 2022 03:53 PM January 01, 2022 Reza Rahman JConf Peru 2021 Conference Report by Reza Rahman at January 01, 2022 09:31 PM JConf Peru 2021 took place November 27th. This was the third time the event was held and due to the pandemic, the 2021 event was virtual and free. I am very proud to have participated as an invited speaker – the JConf series is an admirable effort by the Spanish speaking Java community to hold world-class events. My friend and Peru JUG leader Jose Diaz and his wife Miryan Ramirez have worked hard to make JConf Peru a reality. Jakarta EE had a strong presence at the event including talks on Quarkus and TomEE. I delivered three talks at the conference focused on Jakarta EE and Azure.Powering Java on Azure with Open Liberty and OpenShiftEarly in the morning I delivered my slide free talk titled “Powering Java on Azure with Open Liberty and OpenShift”. The material covers the key work Microsoft and IBM is doing to enable Jakarta EE, MicroProfile, Open Liberty and OpenShift on Azure. I demo in real time how to stand up an OpenShift cluster on Azure quickly and deploy a realistic Java EE/Jakarta EE/MicroProfile application that integrates with some services on the cloud such as a database. The essential material for the talk is available on the Microsoft documentation site as a how-to guide. A recording of the talk is now available on YouTube.Effective Kubernetes for Jakarta EE and MicroProfile DevelopersTowards mid-day, I delivered another entirely slide-free talk – “Effective Kubernetes for Jakarta EE and MicroProfile Developers”. The talk covers some of the key things Jakarta EE and MicroProfile developers need to know while using Kubernetes. This includes:How Kubernetes primitives (such as deployments, services and ingress controllers) align with application server administration, clustering, auto-scaling, auto-discovery, and load-balancing.How to add self-healing capabilities using Kubernetes probes and monitoring with open source tools like Prometheus/Grafana.How Kubernetes can be extended using Operators to effectively manage application server clusters.How the CI/CD pipeline of your application can be adapted to Kubernetes.A recording of the talk is now available on YouTube.All the material for the talk is available in self-paced workshop format on GitHub. The material will take you about a day to complete end-to-end (please reach out if you need any help).Why Jakarta EE Developers are First-Class Citizens on AzureI wrapped up the conference by delivering my talk titled “Why Jakarta EE Developers are First-Class Citizens on Azure”. This talk covers all the work Microsoft is doing by partnering with companies like Oracle, IBM and Red Hat to support Jakarta EE developers on Azure. This includes fully enabling runtimes such as WebLogic, WebSphere Traditional, WebSphere Liberty, Open Liberty and JBoss EAP on virtual machines, the Azure Kubernetes Service (AKS) and App Service (the premier PaaS platform for Azure). I also cover important work such as supporting JMS in Azure Service Bus as a well as the Jakarta EE on Azure roadmap.There is a brief end-to-end demo that is part of the talk. You can run the demo yourself using step-by-step instructions available on GitHub to get a feel for how the Jakarta EE on Azure experience looks like (please reach out if you need help). The slides for the talk are available on Speaker Deck. The video for the talk is now posted on YouTube.It is worth reminding that myself and my team are always ready to work closely with Java/Jakarta EE developers on Azure migrations – completely for free. To take advantage of this, you simply need to fill this survey out or reach out to me directly.Beautiful PeruPeru is a country rich in heritage and natural beauty. It is one of the six cradles of civilization and the center of the mighty Inca entire. I am proud to say I got to see a bit of this amazing country as part of my brief trip for the first JConf Peru. Just check out the album below of photos I took (click this link to view the album if the embedded slideshow is not working)!All in all, I am happy to have had the opportunity to speak at JConf Peru again. I am very glad the event continued in virtual format despite the pandemic. I hope to speak there again and hopefully visit beautiful Peru again in the future. by Reza Rahman at January 01, 2022 09:31 PM December 12, 2021 Sergii Kostenko Infinispan Apache Log4j 2 CVE-2021-44228 vulnerability December 12, 2021 10:00 PM Infinispan 10+ uses Log4j version 2.0+ and can be affected by vulnerability CVE-2021-44228, which has a 10.0 CVSS score. The first fixed Log4j version is 2.15.0.So, until official patch is coming, - you can update used logger version to the latest in few simple stepsDownload Log4j version 2.15.0: https://www.apache.org/dyn/closer.lua/logging/log4j/2.15.0/apache-log4j-2.15.0-bin.zipUnpack distributiveReplace affected librarieswget https://downloads.apache.org/logging/log4j/2.15.0/apache-log4j-2.15.0-bin.zipunzip apache-log4j-2.15.0-bin.zipcd /opt/infinispan-server-10.1.8.Final/lib/rm log4j-*.jarcp ~/Downloads/apache-log4j-2.15.0-bin/log4j-api-2.15.0.jar ./cp ~/Downloads/apache-log4j-2.15.0-bin/log4j-core-2.15.0.jar ./cp ~/Downloads/apache-log4j-2.15.0-bin/log4j-jul-2.15.0.jar ./cp ~/Downloads/apache-log4j-2.15.0-bin/log4j-slf4j-impl-2.15.0.jar ./Please, note - patch above is not official, but according to initial tests it works with no issues December 12, 2021 10:00 PM November 18, 2021 Vladimir V. Bychkov JPA query methods: influence on performance by Vladimir Bychkov at November 18, 2021 07:22 AM Specification JPA 2.2/Jakarta JPA 3.0 provides for several methods to select data from database. In this article we research how these methods affect on performance by Vladimir Bychkov at November 18, 2021 07:22 AM October 27, 2021 Webtide Blog Eclipse Jetty Servlet Survey by jesse at October 27, 2021 01:25 PM This short 5-minute survey is being presented to the Eclipse Jetty user community to validate conjecture the Jetty developers have for how users will leverage JakartaEE servlets and the Jetty project. We have some features we are gauging interest in by jesse at October 27, 2021 01:25 PM October 21, 2021 Jan Supol Jersey 2.35, and Jersey 3.0.3 by Jan at October 21, 2021 11:25 PM Jersey 2.35 and corresponding Jersey 3.0.3 have been released recently. There is a number of new features. We support JDK 17, JDK 16, JDK 15, JDK 14, JDK 13, JDK 12, JDK 11, and JDK 8. It means, Jersey is … Continue reading → by Jan at October 21, 2021 11:25 PM September 30, 2021 Tomitribe Custom Identity Store with Jakarta Security in TomEE by Jean-Louis Monteiro at September 30, 2021 11:42 AM In the previous post, we saw how to use the built-in ‘tomcat-users.xml’ identity store with Apache TomEE. While this identity store is inherited from Tomcat and integrated into Jakarta Security implementation in TomEE, this is usually good for development or simple deployments, but may appear too simple or restrictive for production environments. This blog will focus on how to implement your own identity store. TomEE can use LDAP or JDBC identity stores out of the box. We will try them out next time.Let’s say you have your own file store or your own data store like an in-memory data grid, then you will need to implement your own identity store.What is an identity store?An identity store is a database or a directory (store) of identity information about a population of users that includes an application’s callers. In essence, an identity store contains all information such as caller name, groups or roles, and required information to validate a caller’s credentials.How to implement my own identity store?This is actually fairly simple with Jakarta Security. The only thing you need to do is create an implementation of `jakarta.security.enterprise.identitystore.IdentityStore`. All methods in the interface have default implementations. So you only have to implement what you need.public interface IdentityStore { Set DEFAULT_VALIDATION_TYPES = EnumSet.of(VALIDATE, PROVIDE_GROUPS); default CredentialValidationResult validate(Credential credential) { } default Set getCallerGroups(CredentialValidationResult validationResult) { } default int priority() { } default Set validationTypes() { } enum ValidationType { VALIDATE, PROVIDE_GROUPS }}By default, an identity store is used for both validating user credentials and providing groups/roles for the authenticated user. Depending on what #validationTypes() will return, you will have to implement #validate(…) and/or #getCallerGroups(…) #getCallerGroups(…) will receive the result of #valide(…). Let’s look at a very simple example:@ApplicationScopedpublic class TestIdentityStore implements IdentityStore { public CredentialValidationResult validate(Credential credential) { if (!(credential instanceof UsernamePasswordCredential)) { return INVALID_RESULT; } final UsernamePasswordCredential usernamePasswordCredential = (UsernamePasswordCredential) credential; if (usernamePasswordCredential.compareTo("jon", "doe")) { return new CredentialValidationResult("jon", new HashSet(asList("foo", "bar"))); } if (usernamePasswordCredential.compareTo("iron", "man")) { return new CredentialValidationResult("iron", new HashSet(Collections.singletonList("avengers"))); } return INVALID_RESULT; }}In this simple example, the identity store is hardcoded. Basically, it knows only 2 users, one of them has some roles, while the other has another set of roles.You can easily extend this example and query a local file, or an in-memory data grid if you need. Or use JPA to access your relational database.IMPORTANT: for TomEE to pick it up and use it in your application, the identity store must be a CDI bean.The complete and runnable example is available under https://github.com/apache/tomee/tree/master/examples/security-custom-identitystoreThe post Custom Identity Store with Jakarta Security in TomEE appeared first on Tomitribe. by Jean-Louis Monteiro at September 30, 2021 11:42 AM September 24, 2021 Víctor Orozco Book Review: Practical Cloud-Native Java Development with MicroProfile September 24, 2021 12:00 AM General informationPages: 403Published by: PacktRelease date: Aug 2021Disclaimer: I received this book as a collaboration with Packt and one of the authors (Thanks Emily!)A book about Microservices for the Java Enterprise-shopsYear after year many enterprise companies are struggling to embrace Cloud Native practices that we tend to denominate as Microservices, however Microservices is a metapattern that needs to follow a well defined approach, like:(We aim for) reactive systems(Hence we need a methodology like) 12 Cloud Native factors(Implementing) well-known design patterns(Dividing the system by using) Domain Driven Design(Implementing microservices via) Microservices chassis and/or service mesh(Achieving deployments by) Containers orchestrationMany of these concepts require a considerable amount of context, but some books, tutorials, conferences and YouTube videos tend to focus on specific niche information, making difficult to have a "cold start" in the microservices space if you have been developing regular/monolithic software. For me, that's the best thing about this book, it provides a holistic view to understand microservices with Java and MicroProfile for "cold starter developers".About the bookUsing a software architect perspective, MicroProfile could be defined as a set of specifications (APIs) that many microservices chassis implement in order to solve common microservices problems through patterns, lessons learned from well known Java libraries, and proposals for collaboration between Java Enterprise vendors.Subsequently if you think that it sounds a lot like Java EE, that's right, it's the same spirit but on the microservices space with participation for many vendors, including vendors from the Java EE space -e.g. Red Hat, IBM, Apache, Payara-.The main value of this book is the willingness to go beyond the APIs, providing four structured sections that have different writing styles, for instance:Section 1: Cloud Native Applications - Written as a didactical resource to learn fundamentals of distributed systems with Cloud Native approachSection 2: MicroProfile Deep Dive - Written as a reference book with code snippets to understand the motivation, functionality and specific details in MicroProfile APIs and the relation between these APIs and common Microservices patterns -e.g. Remote procedure invocation, Health Check APIs, Externalized configuration-Section 3: End-to-End Project Using MicroProfile - Written as a narrative workshop with source code already available, to understand the development and deployment process of Cloud Native applications with MicroProfileSection 4: The standalone specifications - Written as a reference book with code snippets, it describes the development of newer specs that could be included in the future under MicroProfile's umbrellaFirst sectionThis was by far my favorite section. This section presents a well-balanced overview about Cloud Native practices like:Cloud Native definitionThe role of microservices and the differences with monoliths and FaaSData consistency with event sourcingBest practicesThe role of MicroProfileI enjoyed this section because my current role is to coach or act as a software architect at different companies, hence this is good material to explain the whole panorama to my coworkers and/or use this book as a quick reference.My only concern with this section is about the final chapter, this chapter presents an application called IBM Stock Trader that (as you probably guess) IBM uses to demonstrate these concepts using MicroProfile with OpenLiberty. The chapter by itself presents an application that combines data sources, front/ends, Kubernetes; however the application would be useful only on Section 3 (at least that was my perception). Hence you will be going back to this section once you're executing the workshop.Second sectionThis section divides the MicroProfile APIs in three levels, the division actually makes a lot of sense but was evident to me only during this review:The base APIs to create microservices (JAX-RS, CDI, JSON-P, JSON-B, Rest Client)Enhancing microservices (Config, Fault Tolerance, OpenAPI, JWT)Observing microservices (Health, Metrics, Tracing)Additionally, section also describes the need for Docker and Kubernetes and how other common approaches -e.g. Service mesh- overlap with Microservice Chassis functionality.Currently I'm a MicroProfile user, hence I knew most of the APIs, however I liked the actual description of the pattern/need that motivated the inclusion of the APIs, and the description could be useful for newcomers, along with the code snippets also available on GitHub.If you're a Java/Jakarta EE developer you will find the CDI section a little bit superficial, indeed CDI by itself deserves a whole book/fascicle but this chapter gives the basics to start the development process.Third sectionThis section switches the writing style to a workshop style. The first chapter is entirely focused on how to compile the sample microservices, how to fulfill the technical requirements and which MicroProfile APIs are used on every microservice.You must notice that this is not a Java programming workshop, it's a Cloud Native workshop with ready to deploy microservices, hence the step by step guide is about compilation with Maven, Docker containers, scaling with Kubernetes, operators in Openshift, etc.You could explore and change the source code if you wish, but the section is written in a "descriptive" way assuming the samples existence.Fourth sectionThis section is pretty similar to the second section in the reference book style, hence it also describes the pattern/need that motivated the discussion of the API and code snippets. The main focus of this section is GraphQL, Reactive Approaches and distributed transactions with LRA.This section will probably change in future editions of the book because at the time of publishing the Cloud Native Container Foundation revealed that some initiatives about observability will be integrated in the OpenTelemetry project and MicroProfile it's discussing their future approach.Things that could be improvedAs any review this is the most difficult section to write, but I think that a second edition should:Extend the CDI section due its foundational statusSwitch the order of the Stock Tracer presentationExtend the data consistency discussión -e.g. CQRS, Event Sourcing-, hopefully with advances from LRAThe last item is mostly a wish since I'm always in the need for better ways to integrate this common practices with buses like Kafka or Camel using MicroProfile. I know that some implementations -e.g. Helidon, Quarkus- already have extensions for Kafka or Camel, but the data consistency is an entire discussion about patterns, tools and best practices.Who should read this book?Java developers with strong SE foundations and familiarity with the enterprise space (Spring/Java EE) September 24, 2021 12:00 AM September 21, 2021 Tetiana Fydorenchyk GlassFish & Payara Auto-Clustering: Running Jakarta EE Highly-Available Applications in the Cloud by Tetiana Fydorenchyk at September 21, 2021 11:19 AM Explore automatic clusterization of Glassfish and Payara in one click with no manual configurations required. The main advantage of this solution is in automatic interconnection of multiple application server instances upon the application topology change, which implements the commonly used clustering configuration. Find out how to get auto-clustered highly available Java servers up and running in the cloud in a matter of minutes.READ MORE by Tetiana Fydorenchyk at September 21, 2021 11:19 AM September 14, 2021 Tomitribe #156 Bash, Apple and EJB, TomEE, Geronimo and Jakarta EE by David Blevins at September 14, 2021 02:07 PM New podcast episode with Adam Bien & David Blevins.  Apple and EJB, @ApacheTomEE, @tomitribe, @JakartaEE, the benefits of code generation with bash, and over-engineering”–the 156th http://airhacks.fmThe post #156 Bash, Apple and EJB, TomEE, Geronimo and Jakarta EE appeared first on Tomitribe. by David Blevins at September 14, 2021 02:07 PM Mike Milinkovich Top Trends in the Jakarta EE Developer Survey Results by Mike Milinkovich at September 14, 2021 11:00 AM Our annual Jakarta EE Developer Survey results gives everyone in the Java ecosystem insight into how the cloud native world for enterprise Java is unfolding and what the latest developments mean for their strategies and businesses. Here’s a brief look at the top technology trends revealed in this year’s survey.For context, this year’s survey was completed by almost 950 software developers, architects, and decision-makers around the world. I’d like to sincerely thank everyone who took the time to complete the survey, particularly our survey partners, Jakarta EE Working Group members Fujitsu, IBM, Jelastic, Oracle, Payara, Red Hat, and Tomitribe, who shared the survey with their communities. Your support is crucial to help ensure the survey results reflect the viewpoints of the broadest possible Java developer audience.Jakarta EE Continues to Deliver on Its PromiseMultiple data points from this year’s survey confirm that Jakarta EE is fulfilling its promise to accelerate business application development for the cloud.As in the 2020 survey results, Jakarta EE emerged as the second-place cloud native framework with 47 percent of respondents saying they use the technologies. That’s an increase of 12 percent over the 2020 survey results, reflecting the industry’s increasing recognition that Jakarta EE delivers important strategic and technical benefits.Almost half of the survey respondents have either already migrated to Jakarta EE or plan to within the next six to 24 months. Together, Java EE 8, Jakarta EE 8, and Jakarta EE 9 are now used by 75 percent of survey respondents. And Jakarta EE 9 usage reached nine percent despite the fact the software was only released in December 2020.With the rise of Jakarta EE, it’s not surprising that developers are also looking for faster support from Java EE/Jakarta EE and cloud vendors.Microservices Usage Continues to IncreaseInterestingly, the survey revealed that monolithic approaches are declining in favor of hybrid architectures. Only 18 percent of respondents said they’re maintaining a monolithic approach, compared to 29 percent who have adopted a hybrid approach and 43 percent who are using microservices.A little over a year ago, monolithic implementations were outpacing hybrid approaches, showing just how quickly the cloud native Java world is evolving. In alignment with these architectural trends, MicroProfile adoption is up five percent over last year to 34 percent.Download the Complete Survey ResultsFor additional insight and access to all of the data collected in our 2021 Jakarta EE Developer survey, we invite everyone to download the survey results. by Mike Milinkovich at September 14, 2021 11:00 AM August 18, 2021 Tetiana Fydorenchyk Tomcat and TomEE Clustering Automation by Tetiana Fydorenchyk at August 18, 2021 11:29 AM Explore the tips on how to install automatically clustered Tomcat and TomEE servers to get a highly available solution that can efficiently serve a large number of users, process a lot of traffic, and be reliable.READ MORE by Tetiana Fydorenchyk at August 18, 2021 11:29 AM July 28, 2021 Jakarta EE Ambassadors Jakarta Community Acceptance Testing (JCAT) by javaeeguardian at July 28, 2021 05:41 AM Today the Jakarta EE Ambassadors are announcing the start of the Jakarta EE Community Acceptance (JCAT) Testing initiative. The purpose of this initiative is to test Jakarta EE 9/9.1 implementations testing using your code and/or applications. Although Jakarta EE is extensively tested by the TCK, container specific tests, and QA, the purpose of JCAT is for developers to test the implementations.Jakarta EE 9/9.1 did not introduce any new features. In Jakarta EE 9 the APIs changed from javax to jakarta. Jakarta EE 9.1 raised the supported floor to Java 11 for compatible implementations. So what are we testing?Testing individual spec implementations standalone with the new namespace. Deploying existing Java EE/Jakarta EE applications to EE 9/9.1.Converting Java EE/Jakarta EE applications to the new namespace.Running applications on Java 11 (Jakarta EE 9.1)Participating in this initiative is easy:Download a Jakarta EE implementation:Java 8 / Jakarta EE 9 ContainersJava 11+ / Jakarta EE 9.1 ContainersDeploy code:Port or run your existing Jakarta EE applicationTest out a feature using a starter templateTo join this initiative, please take a moment to fill-out the form: Sign-up Form To submit results or feedback on your experiences with Jakarta EE 9/9.1:  Jakarta EE 9 / 9.1 Feedback FormResources:Jakarta EE Ambassadors Google Group ListJakarta EE Amabassors TwitterJakarta EE StarterJakarta EE 9 BoilerplateJakarta EE MigrationStart Date: July 28, 2021End Date: December 31st, 2021 by javaeeguardian at July 28, 2021 05:41 AM May 11, 2021 Jakarta EE Ambassadors Jakarta EE Ambassadors Joint Position on Jakarta EE and MicroProfile Alignment by javaeeguardian at May 11, 2021 03:32 AM The Jakarta EE Ambassadors are encouraged by the continued progress and relevance of both Jakarta EE and MicroProfile. We believe a clear, collaborative, and complementary relationship between Jakarta EE and MicroProfile is very important for the Java ecosystem. Unfortunately the relationship has been unclear to many in the Java community, sometimes appearing to be disconnected, overlapping and competitive. MicroProfile builds on top of some Jakarta EE specifications and many Jakarta EE applications now use MicroProfile APIs. For the success of both, it is imperative that the technology sets clarify alignment to ensure continuity and predictability. The Cloud Native for Java (CN4J) Alliance was recently formed to address these concerns. The alliance is composed of members from both the Jakarta EE and MicroProfile working groups. The Jakarta EE Ambassadors view this as a positive step.  This joint position statement and the additional slide deck linked below summarize what the Jakarta EE Ambassadors would like to see from CN4J as well as the alignment between Jakarta EE and MicroProfile. We see Jakarta EE and MicroProfile fulfilling distinctly important roles. Jakarta EE will continue to be the stable core for a very broad ecosystem. MicroProfile will continue to strongly focus on microservices, velocity, and innovation. Our perspective on each is as follows:Jakarta EEOne major release per yearTargets monolithic applications, microservices and standalone (Java SE/command line) applications – both on premises and on the cloudMaintains a stronger commitment to backwards compatibilityEnables specifications to be used independentlyEnables the ecosystem to build on Jakarta EE technologies, including MicroProfile and SpringMicroProfileMultiple releases per yearTargets microservices and cloud native applicationsStrongly focuses on innovation and velocity including domains such as OpenTelemetry, gRPC, and GraphQLDepends on core technologies from Jakarta EELess stringent requirements on backwards compatibilityIt does appear the majority of our community would like to see eventual convergence between the technology sets. It is nonetheless understood this may not be practical in the short term or without its drawbacks. It is also clear that some very mature MicroProfile specifications like Configuration need to be used by Jakarta EE. We believe the best way to meet this need is to move these specifications from MicroProfile to Jakarta EE. The specifications being moved should adopt the jakarta.* namespace. The transition should be a collaborative effort. This is in accordance with what we believe developers have said they want, including through multiple surveys over time.Jakarta EE also needs to make some significant changes to better serve the needs of MicroProfile and the Java ecosystem.  One key aspect of this is enabling specifications to be used independently, including standalone TCKs. Another key aspect is focusing on Jakarta EE Profiles that make the most sense today:Core ProfileCore Jakarta EE specifications needed by MicroProfileSome specifications moved from MicroProfile such as ConfigurationCDI LiteFull ProfileAll Jakarta EE specificationsDeprecate/make optional older technologiesJakarta EE and MicroProfile are both critical to the continued success of Java. We are committed to working with all key stakeholders towards a strong alignment between these technology sets. We invite all developers to join us in ensuring a bright future for both Jakarta EE and MicroProfile.Additional MaterialJakarta EE/MicroProfile alignment slide deckJakarta EE/MicroProfile alignment survey results by javaeeguardian at May 11, 2021 03:32 AM May 10, 2021 Otavio Santana An Overview Between Java 8 and Java 11 by otaviojava at May 10, 2021 07:33 PM This tutorial covers the basics of Java 8 and Java 11; it is a start to prepare you for the next LTS: Java 17. https://dzone.com/articles/an-overview-between-java-8-and-java-11 by otaviojava at May 10, 2021 07:33 PM April 17, 2021 Dmitry Kornilov Your Voice Matters: Take the Jakarta EE Developer Survey by dmitrykornilov at April 17, 2021 11:36 AM The Jakarta EE Developer Survey is in its fourth year and is the industry’s largest open source developer survey. It’s open until April 30, 2021. I am encouraging you to add your voice. Why should you do it? Because Jakarta EE Working Group needs your feedback. We need to know the challenges you facing and suggestions you have about how to make Jakarta EE better.Last year’s edition surveyed developers to gain on-the-ground understanding and insights into how Jakarta solutions are being built, as well as identifying developers’ top choices for architectures, technologies, and tools. The 2021 Jakarta EE Developer Survey is your chance to influence the direction of the Jakarta EE Working Group’s approach to cloud native enterprise Java.The results from the 2021 survey will give software vendors, service providers, enterprises, and individual developers in the Jakarta ecosystem updated information about Jakarta solutions and service development trends and what they mean for their strategies and businesses. Additionally, the survey results also help the Jakarta community at the Eclipse Foundation better understand the top industry focus areas and priorities for future project releases.A full report from based on the survey results will be made available to all participants.The survey takes less than 10 minutes to complete. We look forward to your input. Take the survey now! by dmitrykornilov at April 17, 2021 11:36 AM April 13, 2021 Webtide Blog Less is More? Evolving the Servlet API! by gregw at April 13, 2021 06:19 AM With the release of the Servlet API 5.0 as part of Eclipse Jakarta EE 9.0 the standardization process has completed its move from the now-defunct Java Community Process (JCP) to being fully open source at the Eclipse Foundation, including the by gregw at April 13, 2021 06:19 AM April 02, 2021 Sergii Kostenko Undertow AJP balancer. UT005028: Proxy request failed: java.nio.BufferOverflowException April 02, 2021 09:00 PM Wildfly provides great out of the box load balancing support by Undertow and modcluster subsystemsUnfortunately, in case HTTP headers size is huge enough (close to 16K), which is so actual in JWT era - pity error happened:ERROR [io.undertow.proxy] (default I/O-10) UT005028: Proxy request to /ee-jax-rs-examples/clusterdemo/serverinfo failed: java.io.IOException: java.nio.BufferOverflowException at io.undertow.server.handlers.proxy.ProxyHandler$HTTPTrailerChannelListener.handleEvent(ProxyHandler.java:771) at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:646) at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction$1.completed(ProxyHandler.java:561) at io.undertow.client.ajp.AjpClientExchange.invokeReadReadyCallback(AjpClientExchange.java:203) at io.undertow.client.ajp.AjpClientConnection.initiateRequest(AjpClientConnection.java:288) at io.undertow.client.ajp.AjpClientConnection.sendRequest(AjpClientConnection.java:242) at io.undertow.server.handlers.proxy.ProxyHandler$ProxyAction.run(ProxyHandler.java:561) at io.undertow.util.SameThreadExecutor.execute(SameThreadExecutor.java:35) at io.undertow.server.HttpServerExchange.dispatch(HttpServerExchange.java:815)...Caused by: java.nio.BufferOverflowException at java.nio.Buffer.nextPutIndex(Buffer.java:521) at java.nio.DirectByteBuffer.put(DirectByteBuffer.java:297) at io.undertow.protocols.ajp.AjpUtils.putString(AjpUtils.java:52) at io.undertow.protocols.ajp.AjpClientRequestClientStreamSinkChannel.createFrameHeaderImpl(AjpClientRequestClientStreamSinkChannel.java:176) at io.undertow.protocols.ajp.AjpClientRequestClientStreamSinkChannel.generateSendFrameHeader(AjpClientRequestClientStreamSinkChannel.java:290) at io.undertow.protocols.ajp.AjpClientFramePriority.insertFrame(AjpClientFramePriority.java:39) at io.undertow.protocols.ajp.AjpClientFramePriority.insertFrame(AjpClientFramePriority.java:32) at io.undertow.server.protocol.framed.AbstractFramedChannel.flushSenders(AbstractFramedChannel.java:603) at io.undertow.server.protocol.framed.AbstractFramedChannel.flush(AbstractFramedChannel.java:742) at io.undertow.server.protocol.framed.AbstractFramedChannel.queueFrame(AbstractFramedChannel.java:735) at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.queueFinalFrame(AbstractFramedStreamSinkChannel.java:267) at io.undertow.server.protocol.framed.AbstractFramedStreamSinkChannel.shutdownWrites(AbstractFramedStreamSinkChannel.java:244) at io.undertow.channels.DetachableStreamSinkChannel.shutdownWrites(DetachableStreamSinkChannel.java:79) at io.undertow.server.handlers.proxy.ProxyHandler$HTTPTrailerChannelListener.handleEvent(ProxyHandler.java:754)The same request directly to backend server works well. Tried to play with ajp-listener and mod-cluster filter "max-*" parameters, but have no luck.Possible solution here is switch protocol from AJP to HTTP which can be bit less effective, but works well with big headers:/profile=full-ha/subsystem=modcluster/proxy=default:write-attribute(name=listener, value=default) April 02, 2021 09:00 PM March 13, 2021 Vladimir V. Bychkov Jakarta EE Tutorial russian translation by Vladimir Bychkov at March 13, 2021 07:22 PM Translation of Jakarta EE Tutorial into russian by Vladimir Bychkov at March 13, 2021 07:22 PM January 08, 2021 Dmitry Kornilov Oracle Joins MicroProfile Working Group by dmitrykornilov at January 08, 2021 06:02 PM I am very pleased to announce that since the beginning of 2021 Oracle is officially a part of MicroProfile Working Group. In Oracle we believe in standards and supporting them in our products. Standards are born in blood, toil, tears, and sweat. Standards are a result of collaboration of experts, vendors, customers and users. Standards bring the advantages of portability between different implementations that make standard-based solutions vendor-neutral.We created Java EE which was the first enterprise Java standard. We opened it and moved it to the Eclipse Foundation to make its development truly open source and vendor neutral. Now we are joining MicroProfile which in the last few years has become a leading standard for cloud-native solutions.We’ve been supporting MicroProfile for years before officially joining the Working Group. We created project Helidon which has supported MicroProfile APIs since MicroProfile version 1.1. Contributing to the evolution and supporting new versions of MicroProfile is one of our strategic goals.I like the community driven and enjoyable approach of creating cloud-native APIs invented by MicroProfile. I believe that our collaboration will be effective and together we will push MicroProfile forward to a higher level. by dmitrykornilov at January 08, 2021 06:02 PM December 24, 2020 Edwin Derks A fishing day with Jakarta EE and MicroProfile by Edwin Derks at December 24, 2020 09:23 AM Over the years, several implementations of the Jakarta EE and MicroProfile platforms have been developed by vendors. Some implementations are fully compatible with these platforms, others support a subset of specifications from the platforms, or are building on top of these. Implementations are often built as an open-source project and shipped by a vendor as a product for their customers. One of the things I noticed over the years, is that these projects are often named after animals. More particularly, there are currently three Jakarta EE / MicroProfile supporting runtimes available that refer to… fish. The members of this trio in question are:ProductNameLinkEclipse GlassFishhttps://glassfish.orgPayarahttps://www.payara.fishPiranhahttps://piranha.cloudSince they share a common aspect in their product name, does that mean that they have something other in common, or is this just a coincidence? Let’s go over the high-level purpose and product definitions to find that out.Eclipse GlassFishIf we look at the Jakarta EE compatible products page, Eclipse GlassFish shows up as both a Jakarta EE 8 and Jakarta EE 9 compatible application server. Looking at the history of Eclipse GlassFish, this is not a surprise. Until this project was moved from Oracle to the Eclipse Foundation in 2017, it was the reference implementation application server for Java EE. After moving Java EE to the Eclipse Foundation and rebranding the platform as Jakarta EE, the official concept of a reference implementation has been dropped. Although, technically speaking, Eclipse GlassFish remains the “unofficial” reference implementation of new versions of Jakarta EE. This means that for future versions of Jakarta EE, Eclipse GlassFish can be used to test-drive updates to, or implementation of, new specifications that are going to be supported by Jakarta EE. In addition, speaking hypothetically, if no other vendors would be around to implement Jakarta EE, the Eclipse Foundation would still have its own implementation of Jakarta EE under their own roof. This is important because, without any implementations, the Jakarta EE platform is just a set of specifications that be used to build enterprise applications, but not run them. As a developer, you can easily download Eclipse GlassFish and use this application server to start a project in order to build enterprise applications. However, there are two things noteworthy that you should know:This application server only implements the Jakarta EE platform. It lacks the cloud-native capabilities that the MicroProfile specifications add when compared to other application servers that implement both Jakarta EE and MicroProfile;There is currently no commercial support available for Eclipse GlassFish. If you want to use this application server for your projects in production, that is perfectly fine. However, without such a support contract, in case you run into problems and are in need of a patch or fix, you are at the mercy of the community. You can file an issue in the open-source project or provide a patch there yourself in order to eventually release a new version of Eclipse GlassFish containing the fix.PayaraSimply put, Payara is a commercially supported project that builds on Eclipse GlassFish while building their own commercial features on top of it. When we look at the Jakarta EE compatible products page, Payara shows up as a Jakarta EE 8 compatible application server. However, since Jakarta EE 9 has been released this month, and having a compatible Eclipse GlassFish application server around the corner, we can expect a Jakarta EE 9 compatible version of Payara shortly. Over the years, Payara has built an ever-growing set of commercial features in their product. These features often aim at cloud-native development. This makes Payara a good fit for running instances in microservices architectures deployed on cloud environments. In addition, the company aims to support the latest LTS releases of Java, even providing support for various JVMs that you can use to run Payara. Speaking of running Payara, you also have the option of using the full-blown application server, or a slimmed down runtime in the form of Payara Micro. In case you are a fan of Uber/Fat JAR’s, you even have the option of generating such artifacts with Payara Micro. In short, as a developer, you can use Payara for building and deploying enterprise applications in modern, cloud-native environments using some of your favorite flavors for packaging and running your applications. A few things noteworthy to mention for Payara are:Payara provides support for migration from another application server to Payara in case you are interested in such a migration;Payara supports both Jakarta EE and MicroProfile in order to make it a fit for running in cloud-native environments;Payara provides several features for optimizing resource consumption of running Payara instances.PiranhaAlthough this product references a fish, it is a new kid on the block and doesn’t share any particular existing base for Jakarta EE or MicroProfile. Piranha is not compatible with Jakarta EE or MicroProfile (yet) but supports a large part of the specifications in enterprise applications that you can build and run on Piranha. Like some other newer runtimes on the market that support Jakarta EE and/or MicroProfile specifications, it uses the best breeds of implementations or provides its own. Having that said, what are Piranha’s goals? The product definition states that you can use Piranha to build Jakarta EE and MicroProfile based applications (among other frameworks or libraries), aiming for the smallest runtime possible in order to run them. Ship less, consume less, spend less seems to be the goal, which makes sense in cloud-native environments where spending resources cost money and spending less can be beneficial. When you are interested in using Piranha as a developer, you should know these things:Piranha is brand new and, as far as I know, doesn’t provide commercial support yet. However, if you are in the situation of building a non-mission-critical application from the ground up with cost efficiency in mind, starting off with Piranha should not hurt. With your feedback, you can help shape and mature the product, which can benefit you in the long run;Piranha supports or integrates with other frameworks and libraries that might be a good fit for your project. This even includes GUI’s and testing, so be sure to check these out!ConclusionNext to these “fishy” runtimes from the Jakarta EE and MicroProfile ecosystems, there are of course several other runtimes available that you can check and try out in order to see if these are a fit for your project. I’m curious if there will be any future implementations referring to a fish, and what the idea or vision behind the name would be. How would you name your “fishy” runtime? Please reach out to me on my Twitter when you have an idea, and who knows we can start a trend or project that makes it happen. by Edwin Derks at December 24, 2020 09:23 AM Jan Supol Very Merry Christmas with Jersey 2.33 by Jan at December 24, 2020 12:09 AM Jersey 2.33 is out! As usually, right before Christmas we put together as many fixes and new features as possible to deliver new Jersey for you, the Jersey customers. During the work on Jersey 2.33, we already delivered Jersey 3.0.0, … Continue reading → by Jan at December 24, 2020 12:09 AM November 14, 2020 Jean-François James An introduction to MicroProfile GraphQL by Jean-François James at November 14, 2020 05:05 PM If you’re interested in MicroProfile and APIs, please checkout my presentation Boost your APIs with GraphQL. I did it at EclipseCon 2020. Thanks to the organizers for the invitation! The slide deck is on Slideshare. I’ve tried to be high-level and explain how GraphQL differentiates from REST and how easy it is to implement a […] by Jean-François James at November 14, 2020 05:05 PM September 23, 2020 Víctor Orozco General considerations on updating Enterprise Java projects from Java 8 to Java 11 September 23, 2020 12:00 AM The purpose of this article is to consolidate all difficulties and solutions that I've encountered while updating Java EE projects from Java 8 to Java 11 (and beyond). It's a known fact that Java 11 has a lot of new characteristics that are revolutionizing how Java is used to create applications, despite being problematic under certain conditions.This article is focused on Java/Jakarta EE but it could be used as basis for other enterprise Java frameworks and libraries migrations.Is it possible to update Java EE/MicroProfile projects from Java 8 to Java 11?Yes, absolutely. My team has been able to bump at least two mature enterprise applications with more than three years in development, being:A Management Information System (MIS)Time for migration: 1 weekModules: 9 EJB, 1 WAR, 1 EARClasses: 671 and countingCode lines: 39480Project's beginning: 2014Original platform: Java 7, Wildfly 8, Java EE 7Current platform: Java 11, Wildfly 17, Jakarta EE 8, MicroProfile 3.0Web client: AngularMobile POS and Geo-fenceTime for migration: 3 weekModules: 5 WAR/MicroServicesClasses: 348 and countingCode lines: 17160Project's beginning: 2017Original platform: Java 8, Glassfish 4, Java EE 7Current platform: Java 11, Payara (Micro) 5, Jakarta EE 8, MicroProfile 3.2Web client: AngularWhy should I ever consider migrating to Java 11?As everything in IT the answer is "It depends . . .". However there are a couple of good reasons to do it:Reduce attack surface by updating project dependencies proactivelyReduce technical debt and most importantly, prepare your project for the new and dynamic Java worldTake advantage of performance improvements on new JVM versionsTake advantage from improvements of Java as programming languageSleep better by having a more secure, efficient and quality productWhy Java updates from Java 8 to Java 11 are considered difficult?From my experience with many teams, because of this:Changes in Java release cadenceCurrently, there are two big branches in JVMs release model:Java LTS: With a fixed lifetime (3 years) for long term support, being Java 11 the latest oneJava current: A fast-paced Java version that is available every 6 months over a predictable calendar, being Java 15 the latest (at least at the time of publishing for this article)The rationale behind this decision is that Java needed dynamism in providing new characteristics to the language, API and JVM, which I really agree.Nevertheless, it is a know fact that most enterprise frameworks seek and use Java for stability. Consequently, most of these frameworks target Java 11 as "certified" Java Virtual Machine for deployments.Usage of internal APIsErrata: I fixed and simplified this section following an interesting discussion on reddit :)Java 9 introduced changes in internal classes that weren't meant for usage outside JVM, preventing/breaking the functionality of popular libraries that made use of these internals -e.g. Hibernate, ASM, Hazelcast- to gain performance.Hence to avoid it, internal APIs in JDK 9 are inaccessible at compile time (but accesible with --add-exports), remaining accessible if they were in JDK 8 but in a future release they will become inaccessible, in the long run this change will reduce the costs borne by the maintainers of the JDK itself and by the maintainers of libraries and applications that, knowingly or not, make use of these internal APIs.Finally, during the introduction of JEP-260 internal APIs were classified as critical and non-critical, consequently critical internal APIs for which replacements are introduced in JDK 9 are deprecated in JDK 9 and will be either encapsulated or removed in a future release.However, you are inside the danger zone if:Your project compiles against dependencies pre-Java 9 depending on critical internalsYou bundle dependencies pre-Java 9 depending on critical internalsYou run your applications over a runtime -e.g. Application Servers- that include pre Java 9 transitive dependenciesAny of these situations means that your application has a probability of not being compatible with JVMs above Java 8. At least not without updating your dependencies, which also could uncover breaking changes in library APIs creating mandatory refactors.Removal of CORBA and Java EE modules from OpenJDKAlso during Java 9 release, many Java EE and CORBA modules were marked as deprecated, being effectively removed at Java 11, specifically:java.xml.ws (JAX-WS, plus the related technologies SAAJ and Web Services Metadata)java.xml.bind (JAXB)java.activation (JAF)java.xml.ws.annotation (Common Annotations)java.corba (CORBA)java.transaction (JTA)java.se.ee (Aggregator module for the six modules above)jdk.xml.ws (Tools for JAX-WS)jdk.xml.bind (Tools for JAXB)As JEP-320 states, many of these modules were included in Java 6 as a convenience to generate/support SOAP Web Services. But these modules eventually took off as independent projects already available at Maven Central. Therefore it is necessary to include these as dependencies if our project implements services with JAX-WS and/or depends on any library/utility that was included previously.IDEs and application serversIn the same way as libraries, Java IDEs had to catch-up with the introduction of Java 9 at least in three levels:IDEs as Java programs should be compatible with Java ModulesIDEs should support new Java versions as programming language -i.e. Incremental compilation, linting, text analysis, modules-IDEs are also basis for an ecosystem of plugins that are developed independently. Hence if plugins have any transitive dependency with issues over JPMS, these also have to be updatedOverall, none of the Java IDEs guaranteed that plugins will work in JVMs above Java 8. Therefore you could possibly run your IDE over Java 11 but a legacy/deprecated plugin could prevent you to run your application.How do I update?You must notice that Java 9 launched three years ago, hence the situations previously described are mostly covered. However you should do the following verifications and actions to prevent failures in the process:Verify server compatibilityVerify if you need a specific JVM due support contracts and conditionsConfigure your development environment to support multiple JVMs during the migration processVerify your IDE compatibility and updateUpdate Maven and Maven projectsUpdate dependenciesInclude Java/Jakarta EE dependenciesExecute multiple JVMs in productionVerify server compatibilityMike Luikides from O'Reilly affirms that there are two types of programmers. In one hand we have the low level programmers that create tools as libraries or frameworks, and on the other hand we have developers that use these tools to create experience, products and services.Java Enterprise is mostly on the second hand, the "productive world" resting in giant's shoulders. That's why you should check first if your runtime or framework already has a version compatible with Java 11, and also if you have the time/decision power to proceed with an update. If not, any other action from this point is useless.The good news is that most of the popular servers in enterprise Java world are already compatible, like:Apache TomcatApache MavenSpringOracle WebLogicPayaraApache TomEE... among othersIf you happen to depend on non compatible runtimes, this is where the road ends unless you support the maintainer to update it.Verify if you need an specific JVMOn a non-technical side, under support contract conditions you could be obligated to use an specific JVM version.OpenJDK by itself is an open source project receiving contributions from many companies (being Oracle the most active contributor), but nothing prevents any other company to compile, pack and TCK other JVM distribution as demonstrated by Amazon Correto, Azul Zulu, Liberica JDK, etc.In short, there is software that technically could run over any JVM distribution and version, but the support contract will ask you for a particular version. For instance:WebLogic is only certified for Oracle HotSpot and GraalVMSAP Netweaver includes by itself SAP JVMConfigure your development environment to support multiple JDKsSince the jump from Java 8 to Java 11 is mostly an experimentation process, it is a good idea to install multiple JVMs on the development computer, being SDKMan and jEnv the common options:SDKManSDKMan is available for Unix-Like environments (Linux, Mac OS, Cygwin, BSD) and as the name suggests, acts as a Java tools package manager.It helps to install and manage JVM ecosystem tools -e.g. Maven, Gradle, Leiningen- and also multiple JDK installations from different providers.jEnvAlso available for Unix-Like environments (Linux, Mac OS, Cygwin, BSD), jEnv is basically a script to manage and switch multiple JVM installations per system, user and shell.If you happen to install JDKs from different sources -e.g Homebrew, Linux Repo, Oracle Technology Network- it is a good choice.Finally, if you use Windows the common alternative is to automate the switch using .bat files however I would appreciate any other suggestion since I don't use Windows so often.Verify your IDE compatibility and updatePlease remember that any IDE ecosystem is composed by three levels:The IDE acting as platformProgramming language supportPlugins to support tools and librariesAfter updating your IDE, you should also verify if all of the plugins that make part of your development cycle work fine under Java 11.Update Maven and Maven projectsProbably the most common choice in Enterprise Java is Maven, and many IDEs use it under the hood or explicitly. Hence, you should update it.Besides installation, please remember that Maven has a modular architecture and Maven modules version could be forced on any project definition. So, as rule of thumb you should also update these modules in your projects to the latest stable version.To verify this quickly, you could use versions-maven-plugin: org.codehaus.mojo versions-maven-plugin 2.8.1Which includes a specific goal to verify Maven plugins versions:mvn versions:display-plugin-updatesAfter that, you also need to configure Java source and target compatibility, generally this is achieved in two points.As properties: ... 11 11As configuration on Maven plugins, specially in maven-compiler-plugin: org.apache.maven.plugins maven-compiler-plugin 3.8.0 11 Finally, some plugins need to "break" the barriers imposed by Java Modules and Java Platform Teams knows about it. Hence JVM has an argument called illegal-access to allow this, at least during Java 11.This could be a good idea in plugins like surefire and failsafe which also invoke runtimes that depend on this flag (like Arquillian tests): org.apache.maven.plugins maven-surefire-plugin 2.22.0 --illegal-access=permit org.apache.maven.plugins maven-failsafe-plugin 2.22.0 --illegal-access=permit Update project dependenciesAs mentioned before, you need to check for compatible versions on your Java dependencies. Sometimes these libraries could introduce breaking changes on each major version -e.g. Flyway- and you should consider a time to refactor this changes.Again, if you use Maven versions-maven-plugin has a goal to verify dependencies version. The plugin will inform you about available updates.:mvn versions:display-dependency-updatesIn the particular case of Java EE, you already have an advantage. If you depend only on APIs -e.g. Java EE, MicroProfile- and not particular implementations, many of these issues are already solved for you.Include Java/Jakarta EE dependenciesProbably modern REST based services won't need this, however in projects with heavy usage of SOAP and XML marshalling is mandatory to include the Java EE modules removed on Java 11. Otherwise your project won't compile and run.You must include as dependency:API definitionReference Implementation (if needed)At this point is also a good idea to evaluate if you could move to Jakarta EE, the evolution of Java EE under Eclipse Foundation.Jakarta EE 8 is practically Java EE 8 with another name, but it retains package and features compatibility, most of application servers are in the process or already have Jakarta EE certified implementations:We could swap the Java EE API: javax javaee-api 8.0.1 providedFor Jakarta EE API: jakarta.platform jakarta.jakartaee-api 8.0.0 providedAfter that, please include any of these dependencies (if needed):Java Beans ActivationJava EE javax.activation javax.activation-api 1.2.0Jakarta EE jakarta.activation jakarta.activation-api 1.2.2JAXB (Java XML Binding)Java EE javax.xml.bind jaxb-api 2.3.1Jakarta EE jakarta.xml.bind jakarta.xml.bind-api 2.3.3Implementation org.glassfish.jaxb jaxb-runtime 2.3.3JAX-WSJava EE javax.xml.ws jaxws-api 2.3.1Jakarta EE jakarta.xml.ws jakarta.xml.ws-api 2.3.3Implementation (runtime) com.sun.xml.ws jaxws-rt 2.3.3Implementation (standalone) com.sun.xml.ws jaxws-ri 2.3.2-1 pomJava AnnotationJava EE javax.annotation javax.annotation-api 1.3.2Jakarta EE jakarta.annotation jakarta.annotation-api 1.3.5Java TransactionJava EE javax.transaction javax.transaction-api 1.3Jakarta EE jakarta.transaction jakarta.transaction-api 1.3.3CORBAIn the particular case of CORBA, I'm aware of its adoption. There is an independent project in eclipse to support CORBA, based on Glassfish CORBA, but this should be investigated further.Multiple JVMs in productionIf everything compiles, tests and executes. You did a successful migration.Some deployments/environments run multiple application servers over the same Linux installation. If this is your case it is a good idea to install multiple JVMs to allow stepped migrations instead of big bang.For instance, RHEL based distributions like CentOS, Oracle Linux or Fedora include various JVM versions:Most importantly, If you install JVMs outside directly from RPMs(like Oracle HotSpot), Java alternatives will give you support:However on modern deployments probably would be better to use Docker, specially on Windows which also needs .bat script to automate this task. Most of the JVM distributions are also available on Docker Hub: September 23, 2020 12:00 AM July 29, 2020 Gabriel Bussolo Setting Up a Jakarta EE Development Environment with SDKMAN, Eclipse IDE and TomEE MicroProfile July 29, 2020 12:00 AM What’s up, folks?!So, in this post, I want to show you how to set up a Jakarta EE development in a clean Linux (Ubuntu) installation. We will set up Java and Maven from a version manager tool called SDKMAN, the Eclipse IDE and the TomEE Application Server.SDKMAN First of all, we need to download the Java Development Kit (JDK). Because Java and the Java Virtual Machine (JVM) are specifications we have some implementations for it, like Amazon Correto, OpenJDK, OracleJDK and many others, for this tutorial, we will use the AdoptOpenJDK. July 29, 2020 12:00 AM July 13, 2020 Jean-François James Secure your JAX-RS APIs with MicroProfile JWT by Jean-François James at July 13, 2020 03:55 PM In this article, I want to illustrate in a practical way how to secure your JAX-RS APIs with MicroProfile JWT (JSON Web Token). It is illustrated by a GitHub project using Quarkus, Wildfly, Open Liberty and JWTenizr. A basic knowledge of MP JWT is needed and, if you don’t feel comfortable with that, I invite […] by Jean-François James at July 13, 2020 03:55 PM July 12, 2020 Rhuan Rocha Jakarta EE: Multitenancy with JPA on WildFly, Part 1 by Rhuan Henrique Rocha at July 12, 2020 10:49 PM In this two-part series, I demonstrate two approaches to multitenancy with the Jakarta Persistence API (JPA) running on WildFly. In the first half of this series, you will learn how to implement multitenancy using a database. In the second half, I will introduce you to multitenancy using a schema. I based both examples on JPA and Hibernate.Because I have focused on implementation examples, I won’t go deeply into the details of multitenancy, though I will start with a brief overview. Note, too, that I assume you are familiar with Java persistence using JPA and Hibernate.Multitenancy architectureMultitenancy is an architecture that permits a single application to serve multiple tenants, also known as clients. Although tenants in a multitenancy architecture access the same application, they are securely isolated from each other. Furthermore, each tenant only has access to its own resources. Multitenancy is a common architectural approach for software-as-a-service (SaaS) and cloud computing applications. In general, clients (or tenants) accessing a SaaS are accessing the same application, but each one is isolated from the others and has its own resources.A multitenant architecture must isolate the data available to each tenant. If there is a problem with one tenant’s data set, it won’t impact the other tenants. In a relational database, we use a database or a schema to isolate each tenant’s data. One way to separate data is to give each tenant access to its own database or schema. Another option, which is available if you are using a relational database with JPA and Hibernate, is to partition a single database for multiple tenants. In this article, I focus on the standalone database and schema options. I won’t demonstrate how to set up a partition.In a server-based application like WildFly, multitenancy is different from the conventional approach. In this case, the server application works directly with the data source by initiating a connection and preparing the database to be used. The client application does not spend time opening the connection, which improves performance. On the other hand, using Enterprise JavaBeans (EJBs) for container-managed transactions can lead to problems. As an example, the server-based application could do something to generate an error to commit or roll the application back.Implementation codeTwo interfaces are crucial to implementing multitenancy in JPA and Hibernate:MultiTenantConnectionProvider is responsible for connecting tenants to their respective databases and services. We will use this interface and a tenant identifier to switch between databases for different tenants.CurrentTenantIdentifierResolver is responsible for identifying the tenant. We will use this interface to define what is considered a tenant (more about this later). We will also use this interface to provide the correct tenant identifier to MultiTenantConnectionProvider.In JPA, we configure these interfaces using the persistence.xml file. In the next sections, I’ll show you how to use these two interfaces to create the first three classes we need for our multitenancy architecture: DatabaseMultiTenantProvider, MultiTenantResolver, and DatabaseTenantResolver.DatabaseMultiTenantProviderDatabaseMultiTenantProvider is an implementation of the MultiTenantConnectionProvider interface. This class contains logic to switch to the database that matches the given tenant identifier. In WildFly, this means switching to different data sources. The DatabaseMultiTenantProvider class also implements the ServiceRegistryAwareService, which allows us to inject a service during the configuration phase.Here’s the code for the DatabaseMultiTenantProvider class:public class DatabaseMultiTenantProvider implements MultiTenantConnectionProvider, ServiceRegistryAwareService{ private static final long serialVersionUID = 1L; private static final String TENANT_SUPPORTED = "DATABASE"; private DataSource dataSource; private String typeTenancy ; @Override public boolean supportsAggressiveRelease() { return false; } @Override public void injectServices(ServiceRegistryImplementor serviceRegistry) { typeTenancy = (String) ((ConfigurationService)serviceRegistry .getService(ConfigurationService.class)) .getSettings().get("hibernate.multiTenancy"); dataSource = (DataSource) ((ConfigurationService)serviceRegistry .getService(ConfigurationService.class)) .getSettings().get("hibernate.connection.datasource"); } @SuppressWarnings("rawtypes") @Override public boolean isUnwrappableAs(Class clazz) { return false; } @Override public T unwrap(Class clazz) { return null; } @Override public Connection getAnyConnection() throws SQLException { final Connection connection = dataSource.getConnection(); return connection; } @Override public Connection getConnection(String tenantIdentifier) throws SQLException { final Context init; //Just use the multi-tenancy if the hibernate.multiTenancy == DATABASE if(TENANT_SUPPORTED.equals(typeTenancy)) { try { init = new InitialContext(); dataSource = (DataSource) init.lookup("java:/jdbc/" + tenantIdentifier); } catch (NamingException e) { throw new HibernateException("Error trying to get datasource ['java:/jdbc/" + tenantIdentifier + "']", e); } } return dataSource.getConnection(); } @Override public void releaseAnyConnection(Connection connection) throws SQLException { connection.close(); } @Override public void releaseConnection(String tenantIdentifier, Connection connection) throws SQLException { releaseAnyConnection(connection); }}As you can see, we call the injectServices method to populate the datasource and typeTenancy attributes. We use the datasource attribute to get a connection from the data source, and we use the typeTenancy attribute to find out if the class supports the multiTenancy type. We call the getConnection method to get a data source connection. This method uses the tenant identifier to locate and switch to the correct data source.MultiTenantResolverMultiTenantResolver is an abstract class that implements the CurrentTenantIdentifierResolver interface. This class aims to provide a setTenantIdentifier method to all CurrentTenantIdentifierResolver implementations:public abstract class MultiTenantResolver implements CurrentTenantIdentifierResolver { protected String tenantIdentifier; public void setTenantIdentifier(String tenantIdentifier) { this.tenantIdentifier = tenantIdentifier; }}This abstract class is simple. We only use it to provide the setTenantIdentifier method.DatabaseTenantResolverDatabaseTenantResolver also implements the CurrentTenantIdentifierResolver interface. This class is the concrete class of MultiTenantResolver:public class DatabaseTenantResolver extends MuiltiTenantResolver { private Map regionDatasourceMap; public DatabaseTenantResolver(){ regionDatasourceMap = new HashMap(); regionDatasourceMap.put("default", "MyDataSource"); regionDatasourceMap.put("america", "AmericaDB"); regionDatasourceMap.put("europa", "EuropaDB"); regionDatasourceMap.put("asia", "AsiaDB"); } @Override public String resolveCurrentTenantIdentifier() { if(this.tenantIdentifier != null && regionDatasourceMap.containsKey(this.tenantIdentifier)){ return regionDatasourceMap.get(this.tenantIdentifier); } return regionDatasourceMap.get("default"); } @Override public boolean validateExistingCurrentSessions() { return false; }}Notice that DatabaseTenantResolver uses a Map to define the correct data source for a given tenant. The tenant, in this case, is a region. Note, too, that this example assumes we have the data sources java:/jdbc/MyDataSource, java:/jdbc/AmericaDB, java:/jdbc/EuropaDB, and java:/jdbc/AsiaDB configured in WildFly.Configure and define the tenantNow we need to use the persistence.xml file to configure the tenant: jdbc/MyDataSource Next, we define the tenant in the EntityManagerFactory:@PersistenceUnitprotected EntityManagerFactory emf;protected EntityManager getEntityManager(String multitenancyIdentifier){ final MuiltiTenantResolver tenantResolver = (MuiltiTenantResolver) ((SessionFactoryImplementor) emf).getCurrentTenantIdentifierResolver(); tenantResolver.setTenantIdentifier(multitenancyIdentifier); return emf.createEntityManager();}Note that we call the setTenantIdentifier before creating a new instance of EntityManager.ConclusionI have presented a simple example of multitenancy in a database using JPA with Hibernate and WildFly. There are many ways to use a database for multitenancy. My main point has been to show you how to implement the CurrentTenantIdentifierResolver and MultiTenantConnectionProvider interfaces. I’ve shown you how to use JPA’s persistence.xml file to configure the required classes based on these interfaces.Keep in mind that for this example, I have assumed that WildFly manages the data source and connection pool and that EJB handles the container-managed transactions. In the second half of this series, I will provide a similar introduction to multitenancy, but using a schema rather than a database. If you want to go deeper with this example, you can find the complete application code and further instructions on my GitHub repository. by Rhuan Henrique Rocha at July 12, 2020 10:49 PM July 06, 2020 Elder Moraes Jakarta EE Cookbook by Elder Moraes at July 06, 2020 07:19 PM About one month ago I had the pleasure to announce the release of the second edition of my book, now… by Elder Moraes at July 06, 2020 07:19 PM June 23, 2020 Oracle Aquarium Jakarta EE 9 Milestone Release, 2020 Jakarta EE Developer Survey June 23, 2020 11:10 PM Today the Eclipse Foundation and the Jakarta EE Working Group announced the initial milestone release of Jakarta EE 9, and the results of the 2020 Jakarta EE Developer Survey. Jakarta EE 9 transforms the use of the javax.* namespace in Jakarta EE 8 to use of the jakarta.* namespace. Jakarta EE 9 is ... June 23, 2020 11:10 PM June 10, 2020 Oracle Aquarium Register Now for Coherence CE and Helidon 2.0 Webinars on June 25 June 10, 2020 05:15 PM We hope you have been tracking the steady progress being made on delivery of Eclipse GlassFish 6.0 and Jakarta EE 9. One of the major consumers of GlassFish component technologies is Helidon, a set of Java libraries for developing microservices, that leverages existing Eclipse GlassFish 5.1 componen... June 10, 2020 05:15 PM May 11, 2020 Niklas Heidloff Workshops: Reactive Apps with Quarkus and OpenShift by Niklas Heidloff at May 11, 2020 01:19 PM In the context of cloud-native applications the topic ‘reactive’ becomes more and more important, since more efficient applications can be built and user experiences can be improved. If you want to learn more about reactive functionality in Java applications, read on and try out the sample application and the two new workshops.Benefits of reactive ApplicationsIn order to demonstrate benefits of reactive applications, I’ve developed a sample application with a web interface that is updated automatically when new data is received rather than pulling for updates. This is more efficient and improves the user experience.The animation shows how articles can be created via curl commands in the terminal at the bottom. The web application receives a notification and adds the new article to the page.Another benefit of reactive systems and reactive REST endpoints is efficiency. This scenario describes how to use reactive systems and reactive programming to achieve faster response times. Especially in public clouds where costs depend on CPU, RAM and compute durations this model saves money.The project contains a sample endpoint which reads data from a database in two different versions, one uses imperative code, the other one reactive code. The reactive stack of this sample provides response times that take less than half of the time compared to the imperative stack: Reactive: 793 ms – Imperative: 1956 ms.WorkshopsI’ve written two workshops which demonstrate and explain how to build reactive functionality with Quarkus and MicroProfile and how to deploy and run it on OpenShift. You can use Red Hat OpenShift on IBM Cloud or you can run OpenShift locally via Code Ready Containers.The sample used in the workshops leverages heavily Quarkus which is “a Kubernetes Native Java stack […] crafted from the best of breed Java libraries and standards”. Additionally Eclipse MicroProfile, Eclipse Vert.x, Apache Kafka, PostgreSQL, Eclipse OpenJ9 and Kubernetes are used.Workshop: Reactive Endpoints with Quarkus on OpenShiftThis workshop focusses on how to provide reactive REST APIs and how to invoke services reactively. After you have completed this workshop, you’ll understand the following reactive functionality:Reactive REST endpoints via CompletionStageException handling in chained reactive invocationsTimeouts via CompletableFutureReactive REST invocations via MicroProfile REST ClientOpen WorkshopWorkshop: Reactive Messaging with Quarkus on OpenShiftThis workshop focusses on how to do messaging with Kafka and MicroProfile. After you have completed this workshop, you’ll understand the following reactive functionality:Sending and receiving Kafka messages via MicroProfileSending events from microservices to web applications via Server Sent EventsSending in-memory messages via MicroProfile and Vert.x Event BusOpen WorkshopNext StepsTo learn more, check out the other articles of this blog series:Development of Reactive Applications with QuarkusDevelopment of Reactive Applications with QuarkusAccessing Apache Kafka from QuarkusAccessing PostgreSQL in Kubernetes from QuarkusReactive Messaging Examples for QuarkusDeveloping reactive REST APIs with QuarkusInvoking REST APIs asynchronously with QuarkusComparing synchronous and asynchronous Access to PostgresThe post Workshops: Reactive Apps with Quarkus and OpenShift appeared first on Niklas Heidloff. by Niklas Heidloff at May 11, 2020 01:19 PM January 29, 2020 Gunnar Morling Monitoring REST APIs with Custom JDK Flight Recorder Events January 29, 2020 02:30 PM The JDK Flight Recorder (JFR) is an invaluable tool for gaining deep insights into the performance characteristics of Java applications.Open-sourced in JDK 11, JFR provides a low-overhead framework for collecting events from Java applications, the JVM and the operating system.In this blog post we’re going to explore how custom, application-specific JFR events can be used to monitor a REST API, allowing to track request counts, identify long-running requests and more.We’ll also discuss how the JFR Event Streaming API new in Java 14 can be used to export live events,making them available for monitoring and alerting via tools such as Prometheus and Grafana. January 29, 2020 02:30 PM January 20, 2020 Gunnar Morling Enforcing Java Record Invariants With Bean Validation January 20, 2020 04:30 PM Record types are one of the most awaited features in Java 14; they promise to "provide a compact syntax for declaring classes which are transparent holders for shallowly immutable data". One example where records should be beneficial are data transfer objects (DTOs), as e.g. found in the remoting layer of enterprise applications. Typically, certain rules should be applied to the attributes of such DTO, e.g. in terms of allowed values. The goal of this blog post is to explore how such invariants can be enforced on record types, using annotation-based constraints as provided by the Bean Validation API. January 20, 2020 04:30 PM January 19, 2020 Philip Riecks Jakarta EE 8 CRUD API Tutorial using Java 11 by Philip Riecks at January 19, 2020 03:07 PM As part of the Jakarta EE Quickstart Tutorials on YouTube, I've now created a five-part series to create a Jakarta EE CRUD API. Within the videos, I'm demonstrating how to start using Jakarta EE for your next application. Given the Liberty Maven Plugin and MicroShed Testing, the endpoints are developed using the TDD (Test Driven Development) technique.The following technologies are used within this short series: Java 11, Jakarta EE 8, Open Liberty, Derby, Flyway, MicroShed Testing & JUnit 5Part I: Introduction to the application setupThis part covers the following topics:Introduction to the Maven project skeletonFlyway setup for Open LibertyDerby JDBC connection configurationBasic MicroShed Testing setup for TDDPart II: Developing the endpoint to create entitiesThis part covers the following topics:First JAX-RS endpoint to create Person entitiesTDD approach using MicroShed Testing and the Liberty Maven PluginStore the entities using the EntityManagerPart III: Developing the endpoints to read entitiesThis part covers the following topics:Develop two JAX-RS endpoints to read entitiesRead all entities and by its idHandle non-present entities with a different HTTP status codePart IV: Developing the endpoint to update entitiesThis part covers the following topics:Develop the JAX-RS endpoint to update entitiesUpdate existing entities using HTTP PUTValidate the client payload using Bean ValidationPart V: Developing the endpoint to delete entitiesThis part covers the following topics:Develop the JAX-RS endpoint to delete entitiesEnhance the test setup for deterministic and repeatable integration testsRemove the deleted entity from the databaseThe source code for the Maven CRUD API application is available on GitHub.For more quickstart tutorials on Jakarta EE, have a look at the overview page on my blog.Have fun developing Jakarta EE CRUD API applications,Phil The post Jakarta EE 8 CRUD API Tutorial using Java 11 appeared first on rieckpil. by Philip Riecks at January 19, 2020 03:07 PM January 07, 2020 Philip Riecks Deploy a Jakarta EE application to the root context by Philip Riecks at January 07, 2020 06:24 AM With the presence of Docker, Kubernetes and cheaper hardware, the deployment model of multiple applications inside one application server has passed. Now, you deploy one Jakarta EE application to one application server. This eliminates the need for different context paths.  You can use the root context / for your Jakarta EE application. With this blog post, you'll learn how to achieve this for each Jakarta EE application server.The default behavior for Jakarta EE application serverWithout any further configuration, most of the Jakarta EE application servers deploy the application to a context path based on the filename of your .war. If you e.g. deploy your my-banking-app.war application, the server will use the context prefix /my-banking-app for your application. All you JAX-RS endpoints, Servlets, .jsp, .xhtml content is then available below this context, e.g /my-banking-app/resources/customers.This was important in the past, where you deployed multiple applications to one application server. Without the context prefix, the application server wouldn't be able to route the traffic to the correct application.As of today, the deployment model changed with Docker, Kubernetes and cheaper infrastructure. You usually deploy one .war within one application server running as a Docker container. Given this deployment model, the context prefix is irrelevant. Mapping the application to the root context / is more convenient.If you configure a reverse proxy or an Ingress controller (in the Kubernetes world), you are happy if you can just route to / instead of remembering the actual context path (error-prone).Deploying to root context: Payara & GlassfishAs Payara is a fork of Glassfish, the configuration for both is quite similar. The most convenient way for Glassfish is to place a glassfish-web.xml file in the src/main/webapp/WEB-INF folder of your application: /For Payara the filename is payara-web.xml:/Both also support configuring the context path of the application within their admin console. IMHO this less convenient than the .xml file solution.Deploying to root context: Open LibertyOpen Liberty also parses a proprietary web.xml file within src/main/webapp/WEB-INF: ibm-web-ext.xml Furthermore, you can also configure the context of your application within your server.xml: servlet-4.0 Deploying to root context: WildFlyWildFly also has two simple ways of configuring the root context for your application. First, you can place a jboss-web.xml within src/main/webapp/WEB-INF: /Second, while copying your .war file to your Docker container, you can name it ROOT.war:FROM jboss/wildfly ADD target/app.war /opt/jboss/wildfly/standalone/deployments/ROOT.warFor more tips & tricks for each application server, have a look at my cheat sheet.Have fun deploying your Jakarta EE applications to the root context,PhilThe post Deploy a Jakarta EE application to the root context appeared first on rieckpil. by Philip Riecks at January 07, 2020 06:24 AM December 17, 2019 Rhuan Rocha Jakarta EE: Creating an Enterprise JavaBeans Timer by Rhuan Henrique Rocha at December 17, 2019 03:33 AM Enterprise JavaBeans (EJB) has many interesting and useful features, some of which I will be highlighting in this and upcoming articles. In this article, I’ll show you how to create an EJB timer programmatically and with annotation. Let’s go!The EJB timer feature allows us to schedule tasks to be executed according a calendar configuration. It is very useful because we can execute scheduled tasks using the power of Jakarta context. When we run tasks based on a timer, we need to answer some questions about concurrency, which node the task was scheduled on (in case of an application in a cluster), what is the action if the task does not execute, and others. When we use the EJB timer we can delegate many of these concerns to Jakarta context and care more about business logic. It is interesting, isn’t it?Creating an EJB timer programmaticallyWe can schedule an EJB timer to runs according to a business logic using a programmatic approach. This method can be used when we want a dynamic behavior, according to the parameter values passed to the process. Let’s look at an example of an EJB timer:import javax.annotation.Resource;import javax.ejb.SessionContext;import javax.ejb.Stateless;import javax.ejb.Timeout;import java.util.logging.Logger;@Statelesspublic class MyTimer { private Logger logger = Logger.getLogger(MyTimer.class.getName()); @Resource private SessionContext context; public void initTimer(String message){ context.getTimerService().createTimer(10000, message); } @Timeout public void execute(){ logger.info("Starting"); context.getTimerService().getAllTimers().stream().forEach(timer -> logger.info(String.valueOf(timer.getInfo()))); logger.info("Ending"); } }To schedule this EJB timer, call this method:@Injectprivate MyTimer myTimer;....myTimer.initTimer(message);After passing 10000 milliseconds, the method annotated with @Timeout will be called.Scheduling an EJB timer using annotationWe can also create an EJB timer that is automatically scheduled to run according to an annotation configuration. Look at this example:@Singletonpublic class MyTimerAutomatic { private Logger logger = Logger.getLogger(MyTimerAutomatic.class.getName()); @Schedule(hour = "*", minute = "*",second = "0,10,20,30,40,50",persistent = false) public void execute(){ logger.info("Automatic timer executing"); }}As you can see, to configure an automatic EJB timer schedule, you can annotate the method using @Schedule and configure the calendar attributes. For example:@Schedule(hour = "*", minute = "*",second = "0,10,20,30,40,50",persistent = false)As you can see, the method execute is configured to be called every 10 seconds. You can configure whether the timer is persistent as well.ConclusionEJB timer is a good EJB feature that is helpful in solving many problems. Using the EJB timer feature, we can schedule tasks to be executed, thereby delegating some responsibilities to Jakarta context to solve for us. Furthermore, we can create persistent timers, control the concurrent execution, and work with it in a clustered environment.  If you want to see the complete example, visit this repository on GitHub.This post was released at Developer Red Hat blog and you can see here.  by Rhuan Henrique Rocha at December 17, 2019 03:33 AM November 19, 2019 Christopher Guindon Modernizing our GitHub Sync Toolset November 19, 2019 08:10 PM I am happy to announce that my team is ready to deploy a new version of our GitHub Sync Toolset on November 26, 2019 from 10:00 to 11:00 am EST.We are not expecting any disruption of service but it’s possible that some committers may lose write access to their Eclipse project GitHub repositories during this 1 hour maintenance window.This toolset is responsible for syncronizing Eclipse committers accross all our GitHub repositories and on top of that, this new release will start syncronizing contributors.In this context, a contributor is a GitHub user with read access to the project GitHub repositories. This new feature will allow committers to assign issues to contributors who currently don’t have write access to the repository. This feature was requested in 2015 via Bug 483563 - Allow assignment of GitHub issues to contributors.Eclipse Committers are reponsible for maintaining a list of GitHub contributors from their project page on the Eclipse Project Management Infrastructure (PMI).To become an Eclipse contributor on a GitHub for a project, please make sure to tell us your GitHub Username in your Eclipse account. November 19, 2019 08:10 PM November 01, 2019 Edwin Derks Building Microservices with Jakarta EE and MicroProfile @ EclipseCon 2019 by Edwin Derks at November 01, 2019 09:02 AM This year’s EclipseCon was my second time visiting, and simultaneously speaking at this conference. Aside from all the amazing projects that are active within the Eclipse Foundation, this year’s edition contained a long anticipated present: the release of Jakarta EE 8. Reason enough for me and two colleagues to provide a workshop where attendees could actually get hands-on with Jakarta EE 8 and it’s microservices-enabling cousin: Eclipse MicroProfile.This workshop focusses not only on the various API’s that are provided by Jakarta EE and MicroProfile, but also on development with the Payara application server and how this all fits in a containerised environment.The slides of the workshop can be found here:https://www.slideshare.net/EdwinDerks/building-microservices-with-jakarta-ee-and-microprofile-eclipsecon-2019Of course, we hope to evolve this workshop in order to get hands on with new Jakarta EE and MicroProfile features in the near future. Stay tuned! by Edwin Derks at November 01, 2019 09:02 AM October 17, 2019 BJ Hargrave A Tool for Jakarta EE Package Renaming in Binaries by BJ Hargrave ([email protected]) at October 17, 2019 09:26 PM In a previous post, I laid out my thinking on how to approach the package renaming problem which the Jakarta EE community now faces. Regardless of whether the community chooses big bang or incremental, there are still existing artifacts in the world using the Java EE package names that the community will need to use together with the new Jakarta EE package names.Tools are always important to take the drudgery away from developers. So I have put together a tool prototype which can be used to transform binaries such as individual class files and complete JARs and WARs to rename uses of the Java EE package names to their new Jakarta EE package names.The tools is rule driven which is nice since the Jakarta EE community still needs to define the actual package renames for Jakarta EE 9. The rules also allow the users to control which class files in a JAR/WAR are transformed. Different users may want different rules depending upon their specific needs. And the tool can be used for any package renaming challenge, not just the specific Jakarta EE package renames.The tools provides an API allowing it to be embedded in a runtime to dynamically transform class files during the class loader definition process. The API also supports transforming JAR files. A CLI is also provided to allow use from the command line. Ultimately, the tool can be packaged as Gradle and Maven plugins to incorporate in a broader tool chain.Given that the tool is prototype, and there is much work to be done in the Jakarta EE community regarding the package renames, I have started a list of TODOs in the project' issues for known work items.Please try out the tool and let me know what you think. I am hoping that tooling such as this will ease the community cost of dealing with the package renames in Jakarta EE.PS. Package renaming in source code is also something the community will need to deal with. But most IDEs are pretty good at this sort of thing, so I think there is probably sufficient tooling in existence for handling the package renames in source code. by BJ Hargrave ([email protected]) at October 17, 2019 09:26 PM August 08, 2019 Niklas Heidloff Deploying MicroProfile Microservices with Tekton by Niklas Heidloff at August 08, 2019 02:48 PM This article describes Tekton, an open-source framework for creating CI/CD systems, and explains how to deploy microservices built with Eclipse MicroProfile on Kubernetes and OpenShift.What is Tekton?Kubernetes is the de-facto standard for running cloud-native applications. While Kubernetes is very flexible and powerful, deploying applications is sometimes challenging for developers. That’s why several platforms and tools have evolved that aim to make deployments of applications easier, for example Cloud Foundry’s ‘cf push’ experience, OpenShift’s source to image (S2I), various Maven plugins and different CI/CD systems.Similarly as Kubernetes has evolved to be the standard for running containers and similarly as Knative is evolving to become the standard for serverless platforms, the goal of Tekton is to become the standard for continuous integration and delivery (CI/CD) platforms.The biggest companies that are engaged in this project are at this point Google, CloudBees, IBM and Red Hat. Because of its importance the project has been split from Knative which is focussed on scale to zero capabilities.Tekton comes with a set of custom resources to define and run pipelines:Pipeline: Pipelines can contain several tasks and can be triggered by events or manuallyTask: Tasks can contain multiple steps. Typical tasks are 1. source to image and 2. deploy via kubectlPipelineRun: This resource is used to trigger pipelines and to pass parameters like location of Dockerfiles to pipelinesPipelineResource: This resource is used, for example, to pass links to GitHub reposMicroProfile Microservice ImplementationI’ve created a simple microservice which is available as open source as part of the cloud-native-starter repo.The microservice contains the following functionality:Image with OpenJ9, OpenJDK, Open Liberty and MicroProfile: DockerfileMaven project: pom.xmlOpen Liberty server configuration: server.xmlHealth endpoint: HealthEndpoint.javaKubernetes yaml files: deployment.yaml and service.yamlSample REST GET endpoint: AuthorsApplication.java, GetAuthor.java and Author.javaIf you want to use this code for your own microservice, remove the three Java files for the REST GET endpoint and rename the service in the pom.xml file and the yaml files.Setup of the Tekton PipelineI’ve created five yaml files that define the pipeline to deploy the sample authors microservice.1) The file task-source-to-image.yaml defines how to 1. build the image within the Kubernetes cluster and 2. how to push it to a registry. For building the image kaniko is used, rather than Docker. For application developers this is almost transparent though. As usual images are defined via Dockerfiles. The only difference I ran into is how access rights are handled. For some reason I couldn’t write the ‘server.xml’ file into the ‘/config’ directory. To fix this, I had to manually assign access rights in the Dockerfile first: ‘RUN chmod 777 /config/’.The source to image task is the first task in the pipeline and has only one step. The screenshot shows a representation of the task in the Tekton dashboard. 2) The file task-deploy-via-kubectl.yaml contains the second task of the pipeline which essentially only runs kubectl commands to deploy the service. Before this can be done, the template yaml file is changed to contain the full image name for the current user and environment.apiVersion: tekton.dev/v1alpha1kind: Taskmetadata: name: deploy-via-kubectlspec: inputs: resources: - name: git-source type: git params: - name: pathToDeploymentYamlFile description: The path to the yaml file with Deployment resource to deploy within the git source ... steps: - name: update-yaml image: alpine command: ["sed"] args: - "-i" - "-e" - "s;authors:1;${inputs.params.imageUrl}:${inputs.params.imageTag};g" - "/workspace/git-source/${inputs.params.pathToContext}/${inputs.params.pathToDeploymentYamlFile}" - name: run-kubectl-deployment image: lachlanevenson/k8s-kubectl command: ["kubectl"] args: - "apply" - "-f" - "/workspace/git-source/${inputs.params.pathToContext}/${inputs.params.pathToDeploymentYamlFile}"3) The file pipeline.yaml basically only defines the order of the two tasks as well as how to pass parameters between the different tasks.The screenshot shows the pipeline after it has been run. The output of the third and last steps of the second task ‘deploy to cluster’ is displayed.4) The file resource-git-cloud-native-starter.yaml only contains the address of the GitHub repo.apiVersion: tekton.dev/v1alpha1kind: PipelineResourcemetadata: name: resource-git-cloud-native-starterspec: type: git params: - name: revision value: master - name: url value: https://github.com/IBM/cloud-native-starter5) The file pipeline-account.yaml is necessary to define access rights from Tekton to the container registry.Here are the complete steps to set up the pipeline on the IBM Cloud Kubernetes service. Except of the login capabilities the same instructions should work as well for Kubernetes services on other clouds and the Kubernetes distribution OpenShift.First get an IBM lite account. It’s free and there is no time restriction. In order to use the Kubernetes service you need to enter your credit card information, but there is a free Kubernetes cluster. After this create a new Kubernetes cluster.To create the pipeline, invoke these commands:$ git clone https://github.com/ibm/cloud-native-starter.git$ cd cloud-native-starter$ ROOT_FOLDER=$(pwd)$ REGISTRY_NAMESPACE=$ CLUSTER_NAME=$ cd ${ROOT_FOLDER}/authors-java-jee$ ibmcloud login -a cloud.ibm.com -r us-south -g default$ ibmcloud ks cluster-config --cluster $CLUSTER_NAME$ export $ REGISTRY=$(ibmcloud cr info | awk '/Container Registry / {print $3}')$ ibmcloud cr namespace-add $REGISTRY_NAMESPACE$ kubectl apply -f deployment/tekton/resource-git-cloud-native-starter.yaml $ kubectl apply -f deployment/tekton/task-source-to-image.yaml $ kubectl apply -f deployment/tekton/task-deploy-via-kubectl.yaml $ kubectl apply -f deployment/tekton/pipeline.yaml$ ibmcloud iam api-key-create tekton -d "tekton" --file tekton.json$ cat tekton.json | grep apikey $ kubectl create secret generic ibm-cr-push-secret --type="kubernetes.io/basic-auth" --from-literal=username=iamapikey --from-literal=password=$ kubectl annotate secret ibm-cr-push-secret tekton.dev/docker-0=us.icr.io$ kubectl apply -f deployment/tekton/pipeline-account.yamlExecute the Tekton PipelineIn order to invoke the pipeline, a sixth yaml file pipeline-run-template.yaml is used. As stated above, this file needs to be modified first to contain the exact image name.The pipeline-run resource is used to define input parameters like the Git repository, location of the Dockerfile, name of the image, etc.apiVersion: tekton.dev/v1alpha1kind: PipelineRunmetadata: generateName: pipeline-run-cns-authors-spec: pipelineRef: name: pipeline resources: - name: git-source resourceRef: name: resource-git-cloud-native-starter params: - name: pathToContext value: "authors-java-jee" - name: pathToDeploymentYamlFile value: "deployment/deployment.yaml" - name: pathToServiceYamlFile value: "deployment/service.yaml" - name: imageUrl value: //authors - name: imageTag value: "1" - name: pathToDockerFile value: "DockerfileTekton" trigger: type: manual serviceAccount: pipeline-accountInvoke the following commands to trigger the pipeline and to test the authors service:$ cd ${ROOT_FOLDER}/authors-java-jee/deployment/tekton$ REGISTRY=$(ibmcloud cr info | awk '/Container Registry / {print $3}')$ sed "s++$REGISTRY_NAMESPACE+g" pipeline-run-template.yaml > pipeline-run-template.yaml.1$ sed "s++$REGISTRY+g" pipeline-run-template.yaml.1 > pipeline-run-template.yaml.2$ sed "s++1+g" pipeline-run-template.yaml.2 > pipeline-run.yaml$ cd ${ROOT_FOLDER}/authors-java-jee$ kubectl create -f deployment/tekton/pipeline-run.yaml$ kubectl describe pipelinerun pipeline-run-cns-authors-$ clusterip=$(ibmcloud ks workers --cluster $CLUSTER_NAME | awk '/Ready/ {print $2;exit;}')$ nodeport=$(kubectl get svc authors --output 'jsonpath={.spec.ports[*].nodePort}')$ open http://${clusterip}:${nodeport}/openapi/ui/$ curl -X GET "http://${clusterip}:${nodeport}/api/v1/getauthor?name=Niklas%20Heidloff" -H "accept: application/json"After running the pipeline you’ll see two Tekton pods and one authors pod in the Kubernetes dashboard.Try out this sample yourself!The post Deploying MicroProfile Microservices with Tekton appeared first on Niklas Heidloff. by Niklas Heidloff at August 08, 2019 02:48 PM Blogs Active Blogs Adam Bien BJ Hargrave Christopher Guindon David R. Heffelfinger Dmitry Kornilov Edwin Derks Elder Moraes Francesco Marchioni Gunnar Morling Ivar Grimstad Ivo Woltring Jakarta EE Ambassadors Jan Supol Jean-François James Markus Karg Mike Milinkovich Niklas Heidloff Open Liberty Oracle Aquarium Otavio Santana Philip Riecks Rafael Guimares & Cesar Hernandez Reza Rahman Rhuan Rocha Sergii Kostenko Tanja Obradovic Tetiana Fydorenchyk The Payara Team Thorben Janssen Tomitribe Vladimir V. Bychkov Víctor Orozco Wayne Beaton Webtide Blog Inactive Blogs Gabriel Bussolo Sebastian Daschner Theodor Augustin Dumitrescu ×Close About JakartaBlogs.ee Welcome to the blog home of open source, cloud native Java innovation! Read posts from our global community on Jakarta EE news, technologies, best practices, and compatible products. Close ×Close Add your blog Want to become a Jakarta Blogs author? To add your blog to the feed, please have a look at our guidelines and then open a GitHub issue or create a pull request with your feed-specific information. Close Sign up to our Newsletter Back to the top Eclipse Foundation About Us Contact Us Donate Members Governance Code of Conduct Logo and Artwork Board of Directors Legal Privacy Policy Terms of Use Copyright Agent Eclipse Public License Legal Resources Useful Links Report a Bug Documentation How to Contribute Mailing Lists Forums Marketplace Other IDE and Tools Projects Working Groups Research@Eclipse Report a Vulnerability Service Status Copyright © Eclipse Foundation, Inc. All Rights Reserved. Twitter account Facebook account Youtube account Linkedin account Back to the top