Have you ever tried to expose a JAX-WS web service via https in JBoss FUSE? Well I tried to do that recently and ran into issues. I hope this post may help you on that task.
In recent times, Maven Sites came close to becoming extinct. Maven Plugins were still using them for the wonderful automatic documentation page (named goals), but regular projects were not using them anymore.
However, Maven Sites have some huge benefits such as keeping the documentation close to the code, and automatically providing reports, information and API docs (Javadoc). Being able to release the documentation at the same time as the code was also a great advantage.
So why was this feature not used? Several reasons:
- The look and feel was terrible.
- The apt syntax was terrible.
- The customization was terrible.
Now, though, it’s possible to create much better Maven Sites using Twitter Bootstrap for the skinning and Markdown for the editing. Even better, if you use GitHub, your site can be automatically updated on your project’s GitHub page.
This blog post explains how to use all these new features.
We are migrating an existing Java EE Application from JBoss AS 6 to JBoss AS 7. This blog post introduces our experience we have gained during the migration of the application to the new JBoss AS 7.
Overview of the application
The application is a Java EE application based on EJB, JPA and it contains a web application built with JSF. Furthermore, the application contains a web service to interact with a third-party system and some MBean’s for administration and configuration.
CDI introduced a convenient implementation of the observer pattern into the JavaEE world. Using the CDI API, components can emit events, or receive events created by other components (using the @Observes annotation). This allows developers to reduce the coupling between the emitters and the receivers of events.
However, the current API does not allow to handle what we call “global” events. Global events are propagated among all active sessions, i.e., current users and are not restricted to the current session.
This blog post briefly explores the CDI observer pattern and explains how it can be extended to support global events.
The last blog post (Jumping into continuous delivery with Jenkins and SSH) demonstrated how to build and deploy an application continuously using Jenkins, SSH and Nexus. In that scenario, the application was packaged and deployed on Nexus by Jenkins, and then retrieved from Nexus by the host. However, what about doing it without Nexus? You might have no other need for Nexus or even Maven. Or perhaps you prefer to deploy your application only after you have tested it in several environments. So, how to deploy your application without Nexus?
This post explains how to use the Jenkins SCP plugin to copy the freshly built application to another machine using SCP. This is useful when you need to copy an application to a specific machine or another environment without exposing it publicly.
Although this post is focused on Jenkins, other continuous integration servers have equivalent capabilities.
Let’s imagine the following situation. You’re working on an application for a customer. Despite a firm deadline and a roadmap given to your customer, he’d like to check the progress regularly, let’s say weekly or even daily, and actually give you feedback.
So to make everybody happy, you start releasing the application weekly. However, releasing is generally a hard-core process, even for the most automated processes, and requires human actions. As the release date approaches, stress increases. The tension reaches its climax one hour before the deadline when the release process fails, or worse, when the deployment fails. We’ve all been in situations like that, right?
This all-too-common nightmare can be largely avoided. This blog post presents a way to deal with the above situation using Jenkins, Nexus and SSH. The application is deployed continuously and without human intervention on a test environment, which can be checked and tested by the customer. Jenkins, a continuous integration server, is used as the orchestrator of the whole continuous delivery process.
akquinet tech@spree has published a technology radar analyzing the trends of 2011–2012. It provides an overview of the evolution of practice in the Information Technology sector in 2011 as well as a forecast for 2012. It is the result of one year of analysis and synthesis performed by the Innovation department of akquinet tech@spree.
The technology radar captures the output from discussions, experiments, projects, and feedback from customers and developers. It synthesizes the results to inform global technology strategy decisions. It focuses on new technologies and methodologies with a high level of attraction. This document does not aim to provide an in-depth presentation of each technology, focusing instead on conciseness and highlighting the trends and state of the practice.
More information on http://radar.spree.de
The PicketLink framework provides identity management (IDM) to applications based on different identity providers. PicketLink offers support for a number of different identity store back-ends like LDAP or RDBMSes.
We are successfully using PicketLink in several internal and external applications and it is also a foundation for many other frameworks like seam-security or the GateIn portal server.
Puppet is a configuration manager embracing the infrastructure-as-code movement. It allows you to describe the desired configuration of your system. One of the most common tasks for Puppet is to configure an Apache frontend.
This blog post explains how you can use Puppet to configure an Apache server as frontend using the mod_proxy, without having to write a single Apache directive.