Luminis at JavaOne Moscow
Paul Bakker and Bert Ertman gave a talk at JavaOne Russia about Migrating from Spring to Java EE, which was received very well. Here are some pictures from the conference.
The Apache Software Foundation Announces Apache ACE as a Top-Level Project
Open Source OSGi software distribution framework especially suited for the Cloud and embedded computing markets
Forest Hill, MD – 27 February 2012 – The Apache Software Foundation (ASF), the all-volunteer developers, stewards, and incubators of nearly 150 Open Source projects and initiatives, today announced that Apache ACE has graduated from the Apache Incubator to become a Top-Level Project (TLP), signifying that the Project’s community and products have been well-governed under the ASF’s meritocratic process and principles.
Apache ACE is a software distribution framework for managing and distributing modular software components, configuration data, and other artifacts to OSGi-based and related target systems.
Comprising a set of OSGi bundles, Apache ACE allows developers to easily manage the dependencies, deployment, and feedback of installed software components. This proves particularly useful when scaling across embedded and Cloud computing applications by covering the area of deploying and dynamically scaling applications in the cloud, as well as mobile platforms that would utilize ACE to create their own market or application store.
Using Apache ACE, updates and new components can be easily distributed while keeping a full history of what was installed where and during what period. In addition, ACE helps developers set up an automated development, QA/testing, staging, and production environment.
Initially donated to the Apache Incubator in 2009 by software solutions provider Luminis, a diverse and international group of developers joined the initial developers of the ACE code base to successfully form the Apache ACE community.
“We are excited that ACE has successfully graduated as a Top-Level Project,” said Marcel Offermans, Vice President of Apache ACE and Fellow at Luminis. “Developing projects ‘The Apache Way’ stimulates widespread cooperation with individuals that each bring their specific knowledge to the project. Diversity is key — the community is evolving the project in new and interesting ways, leveraging the collective expertise.”
Availability and Oversight
Apache ACE software is released under the Apache License v2.0, and is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project’s day-to-day operations, including community development and product releases. Apache ACE source code, documentation, mailing lists, and related resources are available at http://ace.apache.org/
About The Apache Software Foundation (ASF)
Established in 1999, the all-volunteer Foundation oversees nearly one hundred fifty leading Open Source projects, including Apache HTTP Server — the world’s most popular Web server software. Through the ASF’s meritocratic process known as “The Apache Way,” more than 350 individual Members and 3,000 Committers successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation’s official user conference, trainings, and expo. The ASF is a US 501(3)(c) not-for-profit charity, funded by individual donations and corporate sponsors including AMD, Basis Technology, Cloudera, Facebook, Google, IBM, HP, Hortonworks, Matt Mullenweg, Microsoft, PSW Group, SpringSource/VMware, and Yahoo!. For more information, visit http://www.apache.org/.
“Apache”, “Apache ACE”, and “ApacheCon” are trademarks of The Apache Software Foundation. All other brands and trademarks are the property of their respective owners.
Sources: Apache Software Foundation, MarketWatch
Forge Arquillian plugin 2.0 BETA 1
I’m happy to release the first beta of the 2.0 version of the Arquillian Forge plugin on the last day of the year.
What’s new?
Forge Beta5 compatibility
Forge is getting close to final and we are making the latest API changes, which unfortunately broke some plugins. The 2.0 version of the Arquillian plugin works with the latest and greatest release again.
More containers and easier maintenance
The amount of containers supported by Arquillian starts to be a little overwhelming. It’s absolutely great to see the community building support for more and more containers. This started to be a problem for maintaining the Forge plugin however. It’s hard to track compatibility issues with containers if I’m not actively using them myself. In the previous version of the plugin the support for each container was hard coded. There is nothing really wrong with that, but it’s hard for other developers to help out by fixing or creating support for a new container; first of all you would need to know something about writing Forge plugins.
In the 2.0 version of the plugin all containers are described in a JSON format. Adding a new container is as simple as adding the container description to this JSON file, making it trivial for anyone to contribute on this. It gets even better; when the new Arquillian website goes live at some point in the future, the containers will be parsed from the documentation directly. Simply documenting a container would be enough to add support to the plugin.
For the release of this beta I added support for all containers listed in the documentation. Note however that some of the documentation is outdated and not working. It would be great if people contribute patches to the container configuration JSON file.
Container configuration
In Arquillian containers can be configured in arquillian.xml. Here you can set hostnames, ports, usernames etc. depending on the container’s capabilities. Forge now helps setting those properties.
Simply type:
arquillian configure-container --profile [maven-profile-id]
Of course you can use the TAB key to choose from the Maven profiles in your POM. Forge will now prompt which configuration option you want to set and lists all possible options for that specific container including it’s type and description. Choose an option and type a value. Forge adds this to the arquillian.xml file.
Try it!
Make sure you have the latest Forge release installed. In Forge simply type:
forge install-plugin arquillian
Devoxx Java EE 6 live coding talk on Parleys
The three hour live coding talk about Java EE 6 by Bert Ertman and Paul Bakker is now available on Parleys. In this Devoxx talk a web application is created from scratch using Java EE 6 while explaining all different technologies such as CDI, JSF, EJB, JPA and JAX-RS. The idea of the talk is that the application should be realistic; using a real database, using Maven so that we can build on a CI server and the code should be tested well. Although most of the code is plain Java EE 6 we use JBoss Forge and Arquillian for setting up the project and integration testing.
Judging from the many reactions at the conference and blog posts this is a great talk to get familiar with all the basics of Java EE 6 while still working in a realistic environment.
Migrating Spring to Java EE talk on Parleys
The popular JavaOne talk by Bert Ertman and Paul Bakker about migrating Spring to Java EE was given again at JFall and recorded on Parleys. The recording is in English.
Apache ACE with Amazon EC2
Introduction
This article is a guide on how to install and use Apache ACE to provision Amazon EC2 instances.
Installing an ACE server
There are two kind of instances that you need when working with ACE:
- One ACE server
- One or more targets
You will upload your bundles to the ACE server and use it’s UI to provision distributions to targets. A target is a node where your application runs. Deployment scenarios can be more complex as described here, but for this article we will use a single ACE server.
We will start by setting up the ACE server. You can run this server anywhere (even a machine on your local network) but since this article is about provisioning Amazon EC2 instances we will install ACE itself on EC2 too. You can either download the latest binary ACE release or build one yourself from the sources. In this article we will build ACE ourselves.
Step 1 – Build ACE
Use the following commands to checkout the sources and build them using Maven.
svn checkout http://svn.apache.org/repos/asf/incubator/ace/trunk ace cd ace mvn install -Dmaven.test.skip=true
Step 2 – Install the ACE server
Because we will run on an Amazon EC2 instance you will need to start one first using the AWS management console. This is the only time you actually need to start an instance yourself, when we have ACE installed we can do this directly from ACE. It is a good idea to assign a static IP to the node, because you need to reconfigure ACE when the IP changes.
Start at least a “Small” instance. The standard Amazon Linux image (either 32 or 64 bit) is sufficient.
Next you have to transfer the ACE installation to the server. This can easily being done by using an SFTP client using the certificate that you generated in AWS, or you can use the SCP command:
scp -i mycertificate.pem org.apache.ace.target.devserver-0.8.1-incubator-SNAPSHOT-distribution.zip ec2-user@[server-ip]:ace.zip
Transfer the zip file in ace-target-devserver/target to the Amazon instance. Now SSH to the Amazon Instance (you can use the “connect” button in the AWS console).
Unzip Ace:
unzip ace.zip
Step 3 – Configure the ACE server
ACE needs to be configured to work with EC2. Open conf/org.apache.ace.nodelauncher.amazon.cfg and use the following configuration:
# Configure your server here server=http://[your-ace-server-ip]:8080 # Note that AMIs are specific to an Amazon availability zone amiId=ami-6a31041e location=eu-west-1 # Your access key ID and secret access key (AWS console, top right menu "Security Credentials") accessKeyid=[your access key] secretAccessKey=[your secret key] # Tag prefix for instance names tagPrefix=default # Use this bootstrap to use a Sun VM instead of the OpenJDK one provided by Amazon nodeBootstrap=cd ~; wget -Ojava.bin http://javadl.sun.com/webapps/download/AutoDL?BundleId=43871 ;chmod +x java.bin;./java.bin /y; export PATH=`pwd`/jre1.6.0_23/bin:$PATH # Open up any extra ports (comma separated list) extraPorts=9090 additionalObrDownloads= externalDownloadUrls=
Optional – Use Glassfish on target nodes
By default ACE will start a plain Felix instance on provisioned nodes. You can use Glassfish instead however as shown in this video. The only thing you have to add to the configuration is the following:
aceLauncher=ace-glassfish-launcher.jar additionalObrDownloads=ace-managementagent.jar externalDownloadUrls=[glassfish zip download location]
Step 4 – Start the ACE server
./run.sh
The ACE UI should now be available on: http://[your-server-ip]:8080/ace
Running a local test server
Normally you should not need to access a provisioned server directly. In case of problems (e.g. bundles are not starting) it is very convenient to have an OSGi shell available however. Of course you could provision a remote shell to your target instance, but there is an even easier approach. You can run an ACE target on your local machine where you can easily connect to the OSGi shell. Remember that the shell is also just a bundle, so you do need to make it part of your distribution in the ACE UI. Go to the ace directory that you checked-out earlier and open the ace-launcher/target directory. Now start ACE (you might have a different name for the jar file):
java -jar ace-launcher.jar identification=LocalTest discovery=http://[your-ace-server-ip]:8080 fwOption=org.osgi.framework.system.packages.extra=sun.misc,com.sun.management
After a few seconds the LocalTest instance should be visible in the targets column in the ACE UI.
Upload Bundles
All the configuration is completed now. Use the ACE UI to upload some bundles and configure some features and distributions. It is recommended to provision small feature sets at a time to make debugging easier.
Provision EC2 target nodes
Now that you have tested your distribution on a local test server you can spawn real targets. Click the “add target” button, enter a name and click “start”. It will ~1 minute to start the instance. You can see the node starting in your AWS console too. When the node is started ACE will tell you the target’s IP.
When it all goes wrong…
In some rare occasions an ACE target can get into a state where you can no longer deploy or undeploy bundles, or where ACE gets into an endless loop of trying to deploy. Luckily this is not a really big issue because the target nodes are provisioned anyway. Just stop the target and create a new one. This does mean it’s probably not a good idea to store any persistent data on the nodes itself, but use external storage instead (e.g. S3). This is not an ACE issue, but a best practice in general when working with provisioned servers.
Limitations
- An ACE server can only be configured to use a single AWS account. Install a second ACE server if you need to provision servers using another AWS account.
- An ACE server can either provision Felix or Glassfish to target nodes. If you need some targets with Felix and some others with Glassfish, you need to install a second ACE server.
Provisioning Glassfish on Amazon EC2 using ACE
In this video you will see how to start an Amazon EC2 server and provision Glassfish to it with just a few clicks and provision both plain OSGI bundles and WAB files to it within seconds.
OSGi (lite) on Google App Engine using PojoSR
The idea of OSGi Lite, as outlined by Peter Kriens is OSGi without the module layer. PojoSR is based on Apache Felix and runs in any standard Java environment: from the class path, inside a WAR, wherever your current Java runs because it never touches a class loader. Running an OSGi application is as easy as running the main method in PojoSR with the “bundles” on the class path. PojoSR finds the JARs on the class path, if the JAR is a bundle and contains a Bundle Activator, it is activated. You can also use the META-INF/service model to embed to OSGi Lite subsystem. It is surprising how many bundles work out of the box: Declarative Services, the Apache Felix Shell, etc. all work well, although some need a bit of twiddling.
Google App Engine (GAE) allows fast development and deployment, and essentially ‘free’ scalability. To reach this, your application runs in a secure environment, isolated from the underlying operating system. This imposes some limitations: the main ones that hamper OSGi are a ban on spawning threads, and applications are not allowed to write to the file system. OSGi applications are typically long-running systems, which use a set of worker threads (in fact, the specification mandates the use of a separate thread for certain operations), and frameworks usually rely on the filesystem for framework storage.
PojoSR on GAE
Luckily, PojoSR provides us with a simpler framework that doesn’t need its own threads nor filesystem cache. Furthermore, its lack of classloader magic makes it easy to integrate into the GAE environment. This is not to say that one couldn’t get a more sophisticated OSGi module layer to run on GAE but using PojoSR was very easy. We’ll will explain what we did in another post but today, lets first introduce you to the example application we did build and got to work on GAE.
First example: running standard services
For our first demo we took a set of plain bundles, and deployed them in PojoSR running on Google App Engine. We use the Apache Felix Web Console, and the bundles that support it.
Most of these run out of the box, except for the Configuration Admin service.
The Apache Felix implementation uses a separate configuration delivery thread, which is not possible on GAE, and it persists its data in the framework storage directory. We updated the implementation to make delivery synchronous on a single thread. The Apache Felix implementation allows us to plug in PersistenceManager providers, which we use to store its data in the user’s session.
You can play with this for yourself at http://pojosr-demo.appspot.com/system/console. Keep in mind that PojoSR stores all state in your browser session, so you can always go back the factory settings by closing your browser. Also, you cannot install your own bundles in this framework.
Second example: service dynamics
In this demo, we show the dynamic nature of a framework that lives only in your session. We have a simple bundle, the WebsiteWatcher, which registers a service for each website you want to monitor. You instruct this bundle to register services using Configuration Admin (to be precise, use a ManagedServiceFactory). We then have a service which allows you to overlay status notifications about the websites you’re monitoring over another page. We use Daniel Bremer-Tonn‘s excellent JQuery plugin for showing Toast Messages.
You can play with this for yourself at http://pojosr-demo.appspot.com/websitewatcher?over=http://pojosr-demo.appspot.com/system/console. The username/password for the demo is admin/admin.
Thats it for today. We’ll put up the source code of GAE demo and explain it in more detail soon at the PojoSR page.
regards,
OSGi in Action Released!
In April 2011, the print version of OSGi in Action was released by Manning Publications. Written by four of the Apache Felix committers, Richard S. Hall, David Savage, Stuart McCullough and our own Karl Pauls, the book offers an overview of the OSGi framework and how to use it to develop modular, dynamic applications.
The book is available both in print and as an on-line PDF version and it’s a valuable resource for both software developers and architects that want to learn the details of the OSGi core and compendium specification. It’s split in three main parts. It starts out with the theory behind OSGi, explaining conceps like modularity, the life cycle layer and the service registries. It then moves on with OSGi in practice, where you learn how to setup, build, debug and deploy applications. It ends with advanced topics like embedding OSGi, using security and creating web applications.
At Luminis Technologies, we use it as part of our OSGi training and of course OSGi is the basis for our LMS provisioning server, the perfect way to automatically deploy software components to target systems.
