COPPER Engine News

COPPER 8.0.0 released

contact@copper-engine.org — Sun, 08 Mar 2026 00:00:00 +0000

COPPER 8.0.0 has been released. It is available on GitHub and in Maven Central.

Virtual threads in Processor Delegates now will run on Java 25. COPPER 8 itself will be using Java 25.

COPPER 7.0.0 released

contact@copper-engine.org — Sun, 08 Mar 2026 00:00:00 +0000

COPPER 7.0.0 has been released. It is available on GitHub and in Maven Central.

Added the optional usage of virtual threads as Processor Delegates. Inspite of the fact that virtual thread’s full power is available in Java 25, this release can help projects on their migration route to Java 25. COPPER 7 itself will be using Java 21.

COPPER 6.2.0 released

contact@copper-engine.org — Sun, 08 Mar 2026 00:00:00 +0000

COPPER 6.2.0 has been released. It is available on GitHub and in Maven Central.

Added experimental features to improve audit support.

COPPER 6.1.0 released

contact@copper-engine.org — Thu, 08 Jan 2026 00:00:00 +0000

COPPER 6.1.0 has been released. It is available on GitHub and in Maven Central.

Added documentation of the implementation concept for continuations in COPPER.

COPPER 6.0.0 released

contact@copper-engine.org — Mon, 03 Nov 2025 00:00:00 +0000

COPPER 6.0.0 has been released. It is available on GitHub and in Maven Central.

COPPER has been upgraded to work with Java 17-25. Older versions of Java are supported in previous COPPER versions. COPPER 5.4 runs with Java 8 to 18. Java 7 is supported by COPPER 4.x.

COPPER 5.5.2 released

contact@copper-engine.org — Wed, 05 Jun 2024 00:00:00 +0000

COPPER 5.5.2 has been released. It is available on GitHub and in Maven Central.

COPPER has been upgraded to Spring 5.3.36.

COPPER 5.5.1 released

contact@copper-engine.org — Tue, 04 Jun 2024 00:00:00 +0000

COPPER 5.5.1 has been released. It is available on GitHub and in Maven Central.

The dependency on javax.xml.bind has been removed.

COPPER 5.5.0 released

contact@copper-engine.org — Sat, 20 Apr 2024 00:00:00 +0000

COPPER 5.5.0 has been released and is ready for Java 22 and Java 23. It is available on GitHub and in Maven Central.

COPPER has been upgraded to ASM 9.7.

COPPER 5.4.2 released

contact@copper-engine.org — Sat, 01 Apr 2023 00:00:00 +0000

COPPER 5.4.2 has been released and is ready for Java 19, 20 and Java 21. It is available on GitHub and in Maven Central.

COPPER has been upgraded to ASM 9.5.

COPPER 5.4 released

contact@copper-engine.org — Fri, 10 Sep 2021 00:00:00 +0000

COPPER 5.4 has been released and is ready for Java 17 and Java 18. It is available on GitHub and in Maven Central.

COPPER has been upgraded to ASM 9.2.

COPPER 5.3 released

contact@copper-engine.org — Fri, 23 Oct 2020 00:00:00 +0000

COPPER 5.3 has been released and is ready for Java 15 and Java 16. It is available on GitHub and in Maven Central.

COPPER has been upgraded to ASM 9.

COPPER 5.2 released

contact@copper-engine.org — Mon, 06 Apr 2020 00:00:00 +0000

COPPER 5.2 has been released and is ready for Java 14. It is available on GitHub and in Maven Central.

COPPER has been upgraded to ASM 8.

COPPER 5.1 released

contact@copper-engine.org — Mon, 09 Dec 2019 00:00:00 +0000

COPPER 5.1 has just been released and is ready for Java 13. It is available on GitHub and in Maven Central.

COPPER has been upgraded to ASM 7.2, so Java 12 and 13 are now supported.

COPPER 5.1 adds support for git as workflow repository in order to enable a lightweight CI/CD pipeline using git repositories for changes in workflows. (Changes outside the workflows are not in scope of this pipeline.)

However, if you don’t need this feature, you can use COPPER the same way as before.

Checkout the new monitoring UI for COPPER 5.0

contact@copper-engine.org — Tue, 04 Sep 2018 00:00:00 +0000

With the recent release of COPPER 5.0 , we not only upgraded COPPER to run with Java 9+ and make proper use of the new module system, but we also developed a totally new monitoring UI based on modern web techniques (SPA with Vue.js). In this blog post, we would like to demonstrate the new UI, give you simple hands-on setup and useage instructions, and highlight the key features. We’ll further want to give you some background decisions on why the things are developed the way they are.

There is a dedicated reason for us to not just use a standard (metrics) monitoring tool for monitoring a COPPER engine: We not only want to visualize metrics, but also provide the user some highly COPPER specific data (i.e. workflow related state data) and give the user the possibility to directly act on monitored events, i.e. let him perform some control-operations. In our day-to-day useage of COPPER in many projects, we often have workflows like this: “Get some information synchronously and quickly from microservice A, with that response, get some additional information from system B”. Now service A goes down or slightly changes its response/API unexpectedly which causes some of our workflows to fail and go into an error state internally. What we want to do in operations now: We see that a lot of workflow are broken due to the outage from service A and once service A is up again, we want to restart all affected workflows to redo their requests.

With the new monitoring UI, we can do just that. We are able to see a list of all broken workflows and are able to inspect each of those. We can see the Java stacktrace of the broken expression, we can check out the serialized workflow data object and - if the file based workflow repository was used - get the source code of the workflow visualized in the monitoring UI all along with highlighting the relevant lines of code for the current situation. We can further just issue a broken workflow (or a set of workflows defined by a matching filter) to be reenqued and thus rerun from the last wait position.

The monitoring UI of course also offers some visualization of important metrics, just to make operations a bit easier.

From an architecture perspective, we

want the COPPER engine to keep a minimal library footprint and especially don’t want the engine to remember metrics by itself.
want to be open to any other monitoring / operations solution and not specifially bound the user to our new monitoring UI.
want the monitoring UI to be strictly separated from the engine.

The last point needs some special attention here. In business environments, we usually have a highly secured setup where the application running COPPER engine is not accessible from outside. The monitoring UI, on the other hand, should be open to any operator to be able to get monitoring information at any time from anywhere. Of course, the monitoring UI needs to meet standard security pattern so that not anyone else can control the workflows, but that was self-evident in the UI development. To come back to the point, usually monitoring UI and copper engine need to run on different hosts. With our distributed engine setup, this point becomes even more apparent. We want to have one monitoring UI running, showing the state of all involved engines within the application.

In order to support a wide variety of monitoring and operation tools, COPPER engine always exposed its metrics and some operations via JMX. In our monitoring UI setup, we plugin to the existing JMX, put Jolokia as a connector in between and are thus able to access the JMX operations securely via REST method invocation, only requiring the JMX port to be available from outside the engine host. The monitoring UI can run on a less restrictive network which has JMX access to the copper host and which is avaiable e.g. from a corporate reverse nginx proxy or similar.

If the user visits the monitoring UI, the application will start to gather monitoring data (remember: historical data is not stored in COPPER!) and keep it for the user in order to visualize statistics in graphs over time. But as the user usually wants to visualize not the current state of the system but want to inspect historical patterns (Like: Why did the system crash last night?), there is a small tutorial included in the UI on how to setup a metrics database so that the COPPER JMX metrics are continuously gathered and put into a metric store. In our example setup, we make use of the InfluxDB TICK stack (namingly telegraf to export JMX metrics and InfluxDB as storage engine). Our monitoring UI can be adjusted to visualize the metrics not from the browser local store but to query InfluxDB and thus show historic values as well, where the user didn’t have the browser opened.

We definitely don’t want to replace existing monitoring environments with the new UI. Each customer has different setups and tools in use and we don’t want to build up a fully suitalbe monitoring solution here. We encourage you to use tools like InfluxDB for storing metrics, Graphana for proper visualization in all granularities and setup alarm rules and events in there. But if you for instance received an alarm or an unexpected behaviour or if you are in development, the UI is the place where you quickly get a more detailed overview with workflow states, do a better problem analysis and be able to perform certain actions like workflow deletion or reenqueing.

But enough for the reasoning and architecture, let’s just get our hands on. Assuming you already have a copper engine running, starting the monitoring UI is as simple as

docker run -p 8080:8080 copperengine/copper-monitoring

The copper engines to connect to can be setup from within the UI and by each user on its own. You can, however, as well set up some default connections via environment variables so that a new user already has some engines pre setup, specific for the project to be monitored. Same goes for standard UI user/password and a possible InfluxDB connection. If you run the UI, keep in mind that you engine must be in a 5.0+ version as for the UI to work, some minor but important changes to the engine had to be made.

Et voila, you can now checkout the features of the new UI yourself. For a fully detailed setup and technical description, just visit the source repository and checkout the README.md file. After all, copper-monitoring is Open Source and licensed via Apache 2.0, same as the copper engine.

If you don’t have docker installed or you currently don’t have time to check out the UI yourself, we’d like to close the article with a feature list.

Get the overhead view of your application:
- Real-time statistics visualized
- Number of active/broken workflows per engine
- Workflow details and interaction
- Audit Trail display
- Workflow Repository display
- Processor Pool display
Broken Workflows ( with state of ERROR or INVALID )
- Display details ( with stacktrace ) of broken workflows
- Display error and last wait Strack Traces
- Display source code of the workflow ( with highlights on the last waiting line and error line )
- Display the workflow’s deserialized state
- Open workflow in pop-up window
- Filter workflows by class name, state or created and modification date
- Restart broken workflows ( one, filtered or all )
- Delete broken workflows ( one, filtered or all )
Waiting Workflows ( with state of WAITING )
- Display details ( with stacktrace ) of waiting workflows
- Display source code of workflow ( with highlights on the last waiting line and error line )
- Display last wait Strack Traces
- Display the workflow’s deserialized state
- Open workflow in pop-up window
- Filter workflows by class name or created and modification date
- Delete waiting workflows (one, filtered, or all )
Workflow Repository info
- Display type, source, and last build results of the repository
- Display list of classes within the repository and their details
- Display source code of the repository classes
Processor Pools info
- Display processor pool statistics
- Processor pool actions: Resume, Suspend, Resume Deque and Suspend Deque
Audit Trail
- Filter audit trail based on time, log level, class, id, etc.
Collect and show Statistics for all engines
- The GUI can collect statistics and store them in Local Storage, but only while the page is running in a browser
- The GUI can alternatively give a user custom generated settings to use with Telegraf and Influx DB so that statistics can be collected continuously.
- Statistics will be visualized in real-time from either data source

COPPER 5.0 released

contact@copper-engine.org — Tue, 28 Aug 2018 00:00:00 +0000

COPPER 5.0 has just been released and is ready for Java 11. It is available on GitHub and in Maven Central.

COPPER has been upgraded to ASM 6.1, so Java 9, 10 and 11 are now supported in addition to Java 8. This release no longer supports Java 7 or older versions.

COPPER 5.0 adds support for the Java Platform Module System in order to let you build modular applications. However, if you don’t need this feature, you can use COPPER the same way as before.

We are also proud to announce the first release of our new Monitoring UI for COPPER, which is written as a modern single page application with Vue.js as JavaScript framework and communicating with the COPPER engine(s) via a JMX-REST Bridge (Jolokia). Note that for the UI to work, your engine needs to be on that 5 release.

Another addition to this release is a demo project showing how to build a modular application with Java 11 and COPPER 5. It provides a Gradle script for creating a custom runtime image of this application.

COPPER 5.0.0-alpha1 released

contact@copper-engine.org — Tue, 08 May 2018 00:00:00 +0000

We are proud to announce that COPPER 5.0.0-alpha1 has just been released. It is available on GitHub and in Maven Central.

COPPER has been upgraded to ASM 6.1, so Java 9 and 10 are now supported in addition to Java 8. This release no longer supports Java 7 or older versions.

We also added support for the Java Platform Module System in order to let you build modular applications. However, if you don’t need this feature, you can use COPPER the same way as before.

In addition to the Java version upgrade, we are happy to share the alpha state of our new monitoring UI for COPPER, which is written as a modern single page application with Vue.js as JavaScript framework and communicating with the COPPER engine(s) via a JMX-REST Bridge (Jolokia). You can find the sources aon GitHub. Note that for the UI to work, your engine needs to be on that 5 release.

COPPER 4.2.0 released

contact@copper-engine.org — Tue, 29 Nov 2016 00:00:00 +0000

We are proud to anounce, that COPPER 4.2.0 has just been released. See https://github.com/copper-engine/copper-engine/blob/4.2.0/WHATSNEW.txt for changes.

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/4.2.0

COPPER Performance Test now available

contact@copper-engine.org — Wed, 15 Jun 2016 00:00:00 +0000

Our new COPPER ‘Performance Test’ is now available. Check our performance test.

COPPER 4.1.1 released

contact@copper-engine.org — Tue, 07 Jun 2016 00:00:00 +0000

We are proud to anounce, that COPPER 4.1.1 has just been released. Besides a bugfix, this release contains a nice little performance enhancement which speeds up resubmit/savepoint and wait/notify in an idle system. In an idle copper engine, the database queue creator and readers sleep for a while before trying again. When a response arrives in copper (using ProcessingEngine.notify) the engine wakes up the queue creator to check for workflow instances that are ready to be resumed. If the creator has found at least one workflow instance to resume, it will wake up the database readers. Doing so, the latency times are as small as possible, unless the “notify” arrives AFTER the corresponding “wait” in the workflow is invoked.

If the “notify” occurs BEFORE the “wait”, the mechanism described above did not work, leading to long latency times because the queue processes are sleeping until their sleep interval is finished. In this release, we optimized this issuse. So even if the “notify” occurs before the “wait” there will be no unnecessary long latency times. On my local notebook with an Oracle 11g database the execution time of a resubmit/savepoint in an otherwise idle system melt down from 800ms to round about 10 to 20 ms.

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/4.1.1

COPPER 4.1.0 released

contact@copper-engine.org — Tue, 31 May 2016 00:00:00 +0000

We are proud to anounce, that COPPER 4.1.0 has just been released. In this release we mainly fixed issue #61 “Speed up PersistentLockManager” Attention! The interface and usage of PersistentLockManager has changed in this release! See javadoc of PersistentLockManager for details. Also Oracle package “copper-body.sql” has changed.

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/4.1.0

COPPER 4.0.3 released

contact@copper-engine.org — Tue, 24 May 2016 00:00:00 +0000

We are proud to anounce, that COPPER 4.0.3 has just been released. This release contains mainly some bugfixes.

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/4.0.3

COPPER 4.0.2 released

contact@copper-engine.org — Tue, 17 May 2016 00:00:00 +0000

We are proud to anounce, that COPPER 4.0.2 has just been released. This release contains only some bugfixes.

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/4.0.2

COPPER 4.0.1 released

contact@copper-engine.org — Thu, 14 Apr 2016 00:00:00 +0000

We are proud to anounce, that COPPER 4.0.1 has just been released. This release mainly contains some minor enhancements:

New feature: Some extensions in the JMX interface
New feature: In persistent engines using an RDBMS, responses provided to getAndRemoveRespone(s) are ordered by response TS

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/4.0.1

COPPER Website broken links fixed

contact@copper-engine.org — Wed, 13 Apr 2016 00:00:00 +0000

Since our 4.0.0 release some pages on our COPPER website had some broken links. This has been fixed now. We apologize for the inconvenience.

COPPER meets Cassandra - COPPER 4.0.0 released

contact@copper-engine.org — Wed, 13 Apr 2016 00:00:00 +0000

We are proud to anounce, that COPPER 4.0.0 final has just been released.

The most important new feature of this release is the Apache Cassandra support. Copper now comes with an adapter that connects to a Apache Cassandra NoSQL database. We love Cassandra because it offers high availability and really scales linear. Besides it is for free and open source. With Copper 4 you can run your persistent workflows on a Cassandra Cluster instead of a classic relational DBMS, e.g. MySQL or Postgres. See the cassandra getting started at cassandra-getting-started.txt on how to setup Copper using cassandra.

Besides the Cassandra support, we worked on some things to make usage of Copper easier, especially for new users. The new ClasspathWorkflowRepository is quite easy to use. No need for extra folders for the workflow java files, and no need for a JDK installation at runtime. Just pass the package names of those packages containing your Copper workflows - that’s all.

Furthermore we introduced some new EngineFactories which make it easier to create and start a Copper engine, see CassandraEngineFactory or RdbmsEngineFactory.

And last but no least, this release no more supports Java 6.

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/4.0.0

COPPER meets Cassandra - COPPER 4.0.0-alpha1 released

contact@copper-engine.org — Fri, 27 Nov 2015 00:00:00 +0000

We are proud to anounce, that COPPER 4.0.0-alpha1 has just been released.

Furthermore we introduced some new EngineFactories which make it easier to create and start a Copper engine, see CassandraEngineFactory or RdbmsEngineFactory.

And last but no least, this release no more supports Java 6.

COPPER 'Getting started' now available

contact@copper-engine.org — Tue, 02 Dec 2014 00:00:00 +0000

Our new COPPER ‘Getting started’ is now available. Check our docs.

COPPER 3.2.1 released

contact@copper-engine.org — Mon, 25 Aug 2014 00:00:00 +0000

We are proud to announce COPPER 3.2.1

This release mainly contains some fixes and enhancements in the monitoring:

Refactoring: Fixed many typos in copper-monitoring. Refactoring: Renamed Dashboard as Configuration in copper-monitoring-client. New feature: Preliminary version of the new Dashboard view. Bugfix: Issue #43: Copper Monitoring Workflows View - Total Count always 0. Bugfix: Issue #44: Copper Monitoring View - Workflow Repository multiple entry for workflow names. Bugfix: Issue #45: Copper Monitoring: High loading times for Dashboard and Resources views.

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/3.2.1

COPPER 3.2 released

contact@copper-engine.org — Mon, 11 Aug 2014 00:00:00 +0000

We are proud to announce COPPER 3.2.0

COPPER has been upgraded to ASM 5.0, so Java 8 is now supported!

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/3.2.0

COPPER 3.1 released

contact@copper-engine.org — Fri, 04 Apr 2014 00:00:00 +0000

We are proud to announce COPPER 3.1.0

New feature: PersistentLockManager - a service to obtain/manager persistent locks, e.g. to functionally synchronize workflow instances.
New feature: PersistentProcessorPool.suspendDequeue/resumeDequeue Suspends/resumes dequeuing of workflow instances from the storage.
New feature: New utility org.copperengine.core.util.Backchannel, that offers functionality to signal a response from within a persistent workflow to its originator
New feature: support for the H2 database
New feature: added SimpleJmxExporter in copper-coreengine to ease the registering of JMX beans when COPPER runs without Spring
Maven: copper-coreengine: moved dependency on C3P0 to copper-regtest. Removed *ConnectionCustomizer classes, because they broke the JDBC spec regarding autoCommit; also removed OracleConnectionTester as it can be substituted by setting ‘preferredTestQuery=”SELECT 1 FROM DUAL”’ in C3P0 datasource.
Maven: copper-coreengine: removed unnecessary dependencies on aopalliance, findbugs-annotations and commons-codec, so the only remaining dependencies are on ASM and slf4j-api

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/3.1.0

New mailing list

contact@copper-engine.org — Thu, 16 Jan 2014 00:00:00 +0000

The COPPER project now has a mailing list, hosted by Google Groups:

https://groups.google.com/forum/#!forum/copper-engine

The mailing list is intended as a forum for both users and developers. All current COPPER developers are signed up.

The list members discuss general and technical issues around current and future COPPER releases. New users are always welcome! Don’t hesitate to ask the developers any questions!

You can subscribe to this list either by using the Google Groups website or, if you don’t want to create a Google account, by sending an e-mail to copper-engine+subscribe@googlegroups.com with topic “subscribe”. Or, if that doesn’t work, simply e-mail us at contact@copper-engine.org and we’ll sign you up.

Using COPPER with Maven or Gradle

contact@copper-engine.org — Tue, 14 Jan 2014 00:00:00 +0000

Since release 3.0 COPPER is available on the Maven Central Repository.

This means that now you can pull in the COPPER core engine and all its assorted libraries as a Maven dependency. Simply add the following dependency to your project’s POM:

<dependency>
    <groupId>org.copper-engine</groupId>
    <artifactId>copper-coreengine</artifactId>
    <version>3.0</version>
 </dependency>

This automatically pulls in the dependent libraries copper-jmx-interface and the third-party libraries asm, slf4j-api, log4j, commons-codec, c3p0 and aopalliance. (Note: we are currently working on a refactoring to make the list of third-party dependencies even smaller – in the end only asm and slf4j-api will be needed!)

If you are using Gradle, then add the following line to your dependencies:

compile 'org.copper-engine:copper-coreengine:3.0'

If you’re using the Spring Framework then you will also need copper-spring, because since 3.0 the Spring support classes have been moved from the core to its own project:

<dependency>
    <groupId>org.copper-engine</groupId>
    <artifactId>copper-spring</artifactId>
    <version>3.0</version>
</dependency>

Likewise for Gradle:

compile 'org.copper-engine:copper-spring:3.0'

There are other COPPER artifacts on Maven Central, namely copper-monitoring.* which contains our upcoming monitoring server and UI and orch-engine/orch-interfaces/orch-simulators which contains an exhaustive real-world COPPER example application. Both will be explained in future posts, so stay tuned!

COPPER 3.0 released

contact@copper-engine.org — Tue, 14 Jan 2014 00:00:00 +0000

The top item of this 3.0 release is that we changed COPPER’s toplevel package from de.scoopgmbh.copper to org.copperengine.

Other than that the public API is unchanged (almost, see below). If you are using COPPER then you can easily migrate your project by changing all import statements from de.scoopgmbh.copper to either org.copperengine.core (if the class resides in copperengine-core.jar) or org.copperengine (otherwise).

If you have persistent workflows, don’t worry that the persisted stackframes might contain references to old classes in the de.scoopgmbh.* package: we got you covered. Whenever COPPER loads a persistent workflow instance (or response) it transforms the package name automatically during load time – no further intervention neccessary.

Other changes, compared to the last stable release 2.4.3

Refactoring: Renamed COPPER major Throwable from “de.scoopgmbh.copper.InterruptException” to “org.copperengine.core.Interrupt”. Persistent workflow instances and responses in existing databases keep compatible due to a loadtime adaptation feature - see StandardJavaSerializer.classnameReplacement
Refactoring: All Spring supporting classes have been moved to an own subproject: copper-spring. Attention! SpringTransactionController and SpringTxnAuditTrail have been moved to another package
Refactoring: de.scoopgmbh.copper.audit.BatchingAuditTrail does no longer implement spring’s InitializingBean. This makes copper less dependent on spring stuff.
Refactoring: de.scoopgmbh.copper.Response.internalProcessingTimeout changed from Integer to Long to enable really LONG timeouts
Refactoring: Renamed table ADAPTERCALL to COP_ADAPTERCALL, renamed index IX_ADAPTERCALL to COP_IDX_ADAPTERCALL
New feature: Added new wait methods, e.g. de.scoopgmbh.copper.Workflow.wait(WaitMode, long, TimeUnit, String…)
New feature: COPPER now uses the Eclipse compiler ecj (or any other JSR-199 compatible java compiler) when found on the CLASSPATH and the default Java compiler is not available. Thus you can run COPPER on a normal JRE instead of a full JDK, ie. you no longer need to provide tools.jar as long as you add ecj.jar to your runtime dependencies.
Bugfix: Issue #26: Removed commons-logging from dependencies
Bugfix: Issue #25: Removed log4j dependency from copper-coreengine
COPPER is now available as a Maven dependency on Maven Central

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/3.0

COPPER 3.0 RC 1 released

contact@copper-engine.org — Tue, 07 Jan 2014 00:00:00 +0000

Besides some new functional features, one main issue of the 3.0 release is the renaming of COPPER’s toplevel package to org.copperengine.

To make migration of existing applications easy, persistent workflow instances and responses in existing databases keep compatible due to a loadtime adaptation feature - see StandardJavaSerializer.classnameReplacement

A complete overview of what’s new in release 3.0 is available in our git repo at WHATSNEW.txt

COPPER and Java 8

contact@copper-engine.org — Wed, 11 Dec 2013 00:00:00 +0000

Java 8 is just around the corner and you might wonder if COPPER is ready for Java 8, especially the new language features.

Alas, no! The reason is that we are using the awesome ASM bytecode engineering library to load, modify and store workflow classes from and into the database. The current stable release is 4.2, which is not ready for Java 8 yet.

However, the ASM developers are already working on Java8 compatibility and promise that it’s ready with the next major release 5.0. A beta version is already available, which we are testing right now.

Thus, in short: you cannot use Java8 with COPPER right now. If you really want to use COPPER with Java 8, you can do so, but be very careful to compile all your persistent workflow classes with --source 1.7 --target 1.7. (All your other classes can be compiled without these options.) But that’s probably not what you want, because you cannot use the new language features in your workflows, especially closures.

We will release a new COPPER version with Java 8 support as soon as ASM 5.0-stable hits the scene, so stay tuned!

COPPER now on GitHub!

contact@copper-engine.org — Mon, 09 Dec 2013 00:00:00 +0000

We moved the source code from Google Code to GitHub: Now it’s here: https://github.com/copper-engine/copper-engine

Google Code served us well one year now, but we found that GitHub has some very attractive features: better issue and release management, free webspace (GitHub pages), a nicer wiki. Plus, of course, the first-class support for Git, the new version control behemoth we all love.

So, we removed all content from the old Google code site and moved it to GitHub. The new issue tracker is here, and all documentation went to our new website.

Please let us know if anything is missing! E-mail to contact@copper-engine.org.

COPPER website revamped

contact@copper-engine.org — Sun, 08 Dec 2013 00:00:00 +0000

As you can see, we completely revamped our copper-engine.org website. :) Take a look around!

The site is now made with pure Bootstrap 3.0 and is served by the Jekyll templating engine on GitHub pages (more on GitHub in our next post).

Not everything is quite there yet, documentation is still lacking, but we’re working on it! We’ll post it here whenever we make some new content available.

Stay tuned!

COPPER 2.4.3 released

contact@copper-engine.org — Tue, 26 Nov 2013 00:00:00 +0000

COPPER 2.4.3 is the latest stable release. Here’ what’s new:

New feature: engine.run throws DuplicateIdException if an existing workflow instance id is used - this is also implemented for the transient engine which substitutes throwing an IllegalStateException
New feature: Default value for property “loadNonWorkflowClasses” in “FileBasedWorkflowRepository” changed from false to true, due to various problems, e.g. Switch-case not working out-of-the-box
Bugfix: ArrayIndexOutOfBoundsException and other exceptions during workflow instrumentation when extensively using nested blocks and local variables

You can get it here: https://github.com/copper-engine/copper-engine/releases/tag/2.4.3

COPPER - Forget BPEL!

contact@copper-engine.org — Mon, 10 Jun 2013 00:00:00 +0000

Some myths never die. Although BPEL clearly is an XML dialect and does not define nor is it meant to be a graphical representaion of processes some people insist of using graphical tools to model the most complex workflows, just because they can. This can lead to absurd monster diagrams like this one (be aware: 710kb, 1866x10826px; use your browser to zoom). No, I’m not making this up. This is a real world workflow from one of our customers which is actually in use. (Ok, I admit it has been anonymized.)

I guess the poor developer who has the questionable honor to maintain this mess might have come to the conclusion, just after adding the 500th arrow somewhere in the lower 30 feet (when printed on fanfold paper), that there’s something gone horribly wrong here. But, of course, it’s not his decision to get rid of it; it had most likely been a management decision to introduce all that fancy UI stuff that looked great on glossy paper. It’s the “if-you-got-one-hammer-everything-looks-like-a-nail” philosophy that went berserk here. We claim that it is system immanent for BPEL tools.

How much better would it have been if this workflow has been described and implemented in Java. Every developer could easily read and understand it. There’s no impedance mismatch.

One often heard argument for graphical notations is that they bridge the gap between development team and business side. That’s true. But it only works on a very basic and abstract architectural level. It’s a misconception that you should use graphical notations for actual implementation, too. The problem is: once you got these fancy UI tools, no one tells you where to stop!

Implementing a workflow is a complicated technical task where the best help is a complex framework that takes the burden from you of caring about all the nasty technical details of persistence, repeatability, reliability etc. and lets you concentrate on the actual business rules. That’s what COPPER is for.