There have been bubbles of interest about OSGi in the Java community over recent years. I for one was very excited about the advent of a modular Java platform that freed us from the classloader issues in the JDK manifested best by Jakarta commons-logging (clogging our app servers).
What do developers prefer – reading documentation or donating bone marrow?
No matter what you answered, I have good news for you.
It is now easier than ever to join the National Marrow Registry.
Also, we’ve made a number of changes to the documentation for our latest release of Mule ESB. We hope these improvements will make it easier than ever to get started quickly using our best-of-breed integration platform.
On top of all the features we plan for next releases we are starting to think about Mule instance remote bootstrapping. The idea would be to facilitate installation/upgrade of whole mule instances on remote machines, including new ones.
In my previous post, I talked about what devops is and the need for devops tools around Tomcat. In this post, I want to go in depth around collaboration between devs and ops and how it applies to Tcat Server.
A key concept of the devops movement is that not only are there developers and operations, but there are also lots of people in between.
REST – the REpresentational State Transfer as defined in Roy Fielding’s thesis – is not a protocol, a standard, an API, a technology or a product. You cannot buy it, you can’t download and install it and you don’t need to poke another hole in your firewall for it. Instead, REST lives at a level completely decoupled form any specific technology, protocol or product, because REST is merely an architectural style: A set of constraints and principles,
If you follow this blog or what’s happening in Mule 3, you’ve heard about the newly introduced configuration mechanism based on patterns. In the coming releases of Mule, we will keep adding new patterns based on users feedback and requests.
But this doesn’t mean your experience with configuration patterns will be limited to the ones that come with Mule distributions: we have made it easy for you to create your own patterns and,
You wouldn’t necessarily be very excited about reliable, graceful app server restarts — unless you go to restart your server and it doesn’t restart, or unless the restart script corrupted your webapp data. There are times when a reasonably fast, fully reliable restart is a very important feature. Some examples:
I’m pretty sure that if Dante was in IT, there would be at least one stage of hell devoted to getting developers and operations to work together well. Horror stories abound. One of my favorite recent ones was about a company where the operations team wouldn’t let the developers surface any UI that they could access to manage their applications. The developers decided that they could get around this by building an API and then having a UI locally that they could use which was not in the realm of the operations team.
The Mule IDE 2.2.1 release that went out today contains a big productivity improvement: a hot deployment builder. It allows you to deploy your project to a running Mule 3 instance automatically. Read all about hot deployment in Mule 3 in the user guide.
The easiest way to get started with the hot deployment builder is to create a new Mule project. It will have the builder attached automatically.