I’ve been around Red Hat JBoss BPM Suite (jBPM) and Red Hat Process Automation Manager (RHPAM) for many years. Over that time, I’ve learned a lot about the lesser-known aspects of this business process management engine.
If you are like most people, you might believe that user tasks are trivial, and learning about their details is unnecessary. Then, one day, you will find yourself troubleshooting an error like this one:
User '[User:'admin']' was unable to execution operation 'Start' on task id 287271 due to a no 'current status' match.
Receiving one too many similar error messages led me to learn everything that I know about user tasks, and I have decided to share my experience.
User tasks are a vital part of any business process management engine, jBPM included. Their behavior is defined by the OASIS Web Services—Human Task Specification, which has been fully adopted by Business Process Model and Notation (BPMN) 2.0—the standard for business processes diagrams. The spec defines two exceptionally important things that I will discuss in this article: The user task lifecycle and task access control. Without further ado, let’s jump right in.
Note: These troubleshooting tips are applicable to Red Hat JBoss BPM Suite 6.2 and above and Red Hat Process Automation Manager 7.
Continue reading “Troubleshooting user task errors in Red Hat Process Automation Manager and Red Hat JBoss BPM Suite”
The recent release of Eclipse JKube 1.0.0 means that the Fabric8 Maven Plugin is no longer supported. If you are currently using the Fabric8 Maven Plugin, this article provides instructions for migrating to JKube instead. I will also explain the relationship between Eclipse JKube and the Fabric8 Maven Plugin (they’re the same thing) and introduce the highlights of the new Eclipse JKube 1.0.0 release. These migration instructions are for developers working on the Kubernetes and Red Hat OpenShift platforms.
Eclipse JKube is the Fabric8 Maven Plugin
Eclipse JKube and the Fabric8 Maven Plugin are one and the same. Eclipse JKube was first released in 2014 under the name of Fabric8 Maven Plugin. The development team changed the name when we pre-released Eclipse JKube 0.1.0 in December 2019. For more about the name change, see my recent introduction to Eclipse JKube. This article focuses on the migration path to JKube 1.0.0.
Continue reading “Migrating from Fabric8 Maven Plugin to Eclipse JKube 1.0.0”
In this article, I share several new language support features in the recently released Language Support for Apache Camel VS Code extension 0.0.27. Before I discuss these improvements, please note that updates to the VS Code extension are available in other IDEs that support the Camel Language Server, including Eclipse IDE, Eclipse Che, and more. It is simply easier to focus on one IDE for my demonstrations, so I’ve chosen VS Code.
Note: Apache Camel is a versatile open source integration framework based on known enterprise integration patterns.
Continue reading “New language support features in Apache Camel VS Code extension 0.0.27”
In this article, I answer a question that I have seen asked on various forums: Will Quarkus be compatible with Jakarta EE? To understand our answer to that question, it is helpful to know the history of Quarkus and what we’re trying to achieve with it. So, please indulge me while I lay that groundwork.
A short history of Quarkus and Java EE
When Emmanuel Bernard, Jason Greene, Bob McWhirter, and I first discussed kicking off the ThornFly.x proof of concept, which would later become Quarkus, we had conversations about where Java EE (now Jakarta EE) would eventually fit. I think we all agreed that we already had the best open source implementation of Java EE in the form of WildFly and Red Hat JBoss Enterprise Application Platform (JBoss EAP). Creating yet another addition to this space seemed confusing at best. At worst, we feared that it would split our engineering and open source community efforts.
Continue reading “Quarkus and Jakarta EE: Together, or not?”
After nine months of incubation with the Eclipse Foundation, Eclipse JKube 1.0.0 is finally here. This release marks the final deprecation of the great Fabric8 Maven Plugin (FMP) project. JKube is a complete replacement of FMP and includes all of the major features. Projects relying on FMP to create Apache Maven Java containers should migrate to Eclipse JKube to take full advantage of the new features, bug fixes, and upstream project maintenance described in this article.
JKube is a collection of plugins plus a standalone Java library that fit into your Maven project. If you have a Java project that needs to get deployed into Kubernetes or Red Hat OpenShift, this is the right tool for you. JKube takes care of everything related to the cluster deployment while you, as a developer, get to concentrate on implementing your application without worrying about where it needs to be deployed.
Continue reading “Cloud-native Java applications made easy: Eclipse JKube 1.0.0 now available”
As a developer, you have probably experimented with Kubernetes. It’s also possible that you are already running several Java applications on a Kubernetes platform, maybe Red Hat OpenShift. These initial containerized applications were greenfield projects, where you enjoyed the benefits of a platform providing templated deployments, easy rollbacks, resource availability, security by default, and a manageable way to publish your services.
Now, you might be thinking, “How can I enjoy all of these benefits in my existing Java applications?” Most Java applications in production today are running on virtual machines (VMs), likely on an application platform that is not container friendly. So, how can you migrate them from the current platform to containers on Kubernetes?
It isn’t an easy task, but this is a problem that we have been working hard on for years. Red Hat’s Migration Toolkit for Applications (MTA) 5.0 is the latest resulting iteration: An assembly of tools that you can use to analyze existing applications and discover what is required to modernize them. Read on to learn MTA 5.0’s features and migration paths.
Continue reading “Migrate your Java apps to containers with Migration Toolkit for Applications 5.0”
Apache Camel K should be as lightweight as possible. Therefore, the Camel K project provides standalone Java files that describe a Camel integration. The downside to this practice is that existing IDEs cannot provide complete support out of the box. A few months ago, I mentioned the Java language support for Apache Camel K that was discussed in Red Hat Visual Studio Code (VS Code) extension, and how it provides Java language support for Apache Camel K. In this article and demo, I show you how to do the same with Eclipse Che and che.openshift.io.
Continue reading “Add Java language support for Apache Camel K inside Eclipse Che”
Spring Cloud Functions are yet another interesting option for Java developers when building serverless applications. You have already seen how to build and run applications for Red Hat OpenShift Serverless using Quarkus, but in this article, we talk about how to use Spring Cloud Functions and walk you through those steps. These steps are similar to running any other Spring Boot application with OpenShift Serverless. One of the benefits of building an open hybrid serverless platform is giving developers a choice of programming languages, tools, frameworks, and portability across any environment to run serverless applications. Beyond that, you want to ensure that the developer experience and overall workflow is intuitive and practical, which is what you will learn here.
Continue reading Using Spring Cloud Functions with OpenShift Serverless
Apache Camel K is a lightweight integration framework built on Apache Camel that runs natively on Kubernetes. Camel K is designed explicitly for serverless and microservices architectures and allows you to run an integration written in Camel DSL on your cloud.
Continue reading Introducing IDE support for Apache Camel K Modeline
Red Hat CodeReady Dependency Analytics is a hosted service on OpenShift that provides vulnerability and compliance analysis for your applications, directly from your IDE. It automatically analyzes your software composition and provides recommendations to address security holes and licensing issues. The 0.1 release of CodeReady Dependency Analytics includes access to the Snyk Intel Vulnerability Database, which is a curated database of both unique and known open source software security advisories.
Continue reading Vulnerability analysis with Red Hat CodeReady Dependency Analytics and Snyk Intel