Posted by Andrew Phillips mid-morning: March 9th, 2010
From Java EE to Google App Engine to GigaSpaces, the idea of developing against a middleware or “infrastructure” API is well established in the Java world.
But these are fixed environments. With the (re-)advent of virtualization, it is now becoming feasible to package and rapidly provision your own environment, custom-designed to meet your application’s needs.
As the big middleware vendors are realizing, it is not just possible to create such Virtual Appliances, but necessary: a production app’s setup inevitably includes more than just a couple of EARs.
Here, we’ll look at the current state of cloud and middleware deployment tooling, examine possible future developments and draw parallels between deployment and related processes.
(more…)
Posted by Vincent Partington mid-morning: February 10th, 2010
We’ve already been talking about Deployit, XebiaLabs’ deployment automation product, for some time. Now we are proud to announce that you can try Deployit for yourself by downloading the Personal Edition of Deployit!
If you don’t know what Deployit is yet, have a look at the movie below!
To summarize; Deployit will automate your Java EE application deployments and, because of the overview it offers and the history it keeps, it also allows you to manage and optimize your deployments.
(more…)
Posted by Vincent Partington at around evening time: December 7th, 2009
For Deployit, XebiaLabs’ automated deployment product for Java EE applications, we are always building and modifying integrations with middleware systems such as IBM WebSphere, Oracle WebLogic and the JBoss application server. These integrations are small enough so that they can be rearranged to get many different deployment scenarios. A typical step, as we call these integrations, would be “Create WebSphere datasource” or “Restart WebLogic Server”. So how do the test that code?
We’ve had some success using FitNesse and VMware to do integration tests on our deployment scenarios. But there were a few problems with this apporach:
- We could only test complete deployment scenarios in this way. If we wanted to test just a single step, we had to make a deployment scenario that used that step just to be able to test it.
- Because FitNesse does not provide any feedback while a test is running and the steps, let alone the deployment scenarios, can sometimes take a while to execute, there was little feedback on the progress.
- While it is possible to debug a FitNesse Fixture using Eclipse the process is not very convenient when debugging a technical component such as this step.
- To verify that a deployment scenario has executed succesfully we had to extend our FitNesse Fixture often. And while debugging code under test in FitNesse is complicated enough, debugging a Fixture is even harder!
Clearly we needed a different approach if we wanted to develop new steps easily.
(more…)
Posted by Vincent Partington in the early evening: November 23rd, 2009
In my previous blog on the deployment capabilities of the major application servers, I asked, as a joke, whether anybody knew the difference between containment paths, configuration IDs and object names in WebSphere’s scripting interface wsadmin. I didn’t get (nor expect 
) an answer. But instead of keeping you in the dark, this blog will explain the difference between these three and how you can translate between them.
Configuration ID
Configuration IDs are the most common id you will encounter when working with wsadmin. They uniquely specify an element in the configuration of WebSphere Application Server and are needed to modify the configuration with one of the commands in the AdminConfig object.
Posted by Kris Geusebroek in the early morning: September 28th, 2009
Using Spring JMS in our application which needs to be running on WebSphere proved to be somewhat of a challenge. And since googling provided a lot of information but just a small ‘easy to miss’ piece of text to put the pieces together, i decided to write up this blog.
Posted by Sander Hautvast at around evening time: June 30th, 2009
In this series I want to address some topics that are old and well known, but still seem to puzzle developers and administrators in a j2ee environment. Think of anything in or around an application server. When talking of application servers I mostly refer to websphere. Sadly I have no real experience using any other. Yet I aim to keep a broad perspective, not to narrow the audience. The level should be beginner to intermediate.
Part1 Starting your own threads.
As long as I worked with application servers, people have always told me not to start my own threads, because the j2ee specification states that this is forbidden. These threads are also referred to as ‘naked’ and ‘unmanaged’. The danger they pose is doing things that the application server knows nothing about. It could cause resource leaks, no debugging, failing to stop a server or security problems.
Yet there is a number of open source frameworks that do just this, and no one seems to object. Think of quartz, or Log4j (the watchdog that monitors changes in log4j settings). And even the jdk itself is guilty: use of java.util.Timer also causes so called unmanaged threads.
Posted by Vikas Gupta terribly early in the morning: June 24th, 2009
Introduction
Visual aspects of a portal have a significant impact on the quality of user experience and, thus, indirectly on the success of the portal. The look and feel of the portal should be appealing and unique. Most of the times look and feel provided by the portal server does not serve the purpose. Hence, most of the portal servers provide mechanism to customize the look and feel of the portal. In Websphere portal, themes and skins provide the mechanism to customize the look and feel of the portal for an enhanced user experience. (more…)
Posted by Vikas Gupta mid-afternoon: April 19th, 2009
Coordination between portlets is a very common requirement. An example of information sharing between portlets can be a weather portlet displaying the weather information of a city and a map portlet displaying the location of the city. Since, both the portlets would be using the same zip code for a user, there should be mechanism provided by the portlal containers to allow portlets to share the zip code.
Prior to JSR 286, the support for inter portlet communication was rather minimal and information sharing between different portlets was accompalished primarily using application scoped session objects or vendor specific APIs. Both of above methods were rather problematic as in the former maintaining the uniqueness of the session attribute over a complex aaplication was a concern and in the later portability of the portlet was hampered. In order to provide coordination between portlets the Java Portlet Specification v2.0 (JSR 286) introduces the following mechanisms:
- public render parameters in order to share render state between portlets.
- portlet events that a portlet can receive and send.
Let’s have a look how to use the above features.
(more…)
Posted by Sander Hautvast in the early evening: April 10th, 2009
Logging should be simple and straightforward. It is an essential part of everyday administrative operations and it provides vital information for debugging production incidents. Adequate logging saves time and money. When hosting a number of applications, say 10+, you will want to separate application logs from each other and from platform logs and traces. Logging frameworks like the jdk logger and log4j, cooperating with the j2ee container provide the means to do this, using configuration files. So far, so good.
(more…)