For my Oracle Puppet provisioning development I can't do without these create image tools: Packer and Vagrant in combination with Oracle VirtualBox or VMware. In this blogpost I will explain what these tools can do for you and how you can make your own images and use puppet as provisioning tool.
With Vagrant you can create your own virtual images and it can start puppet or chef to do all the server provisioning. Besides this, Vagrant can also manage all the network configuration or make a multi machine configuration. One of the great things of Vagrant is when you make a mistake you can start over by destroying the image ( vagrant destroy ) or start the provisioning again ( vagrant provision).
For Vagrant you need to download and import a small image box ( here is an overview of the all public boxes which you can use right away ) like CentOS or Ubuntu. This image already contains the Virtualbox guest additions, which Vagrant will use to setup the shared folder etc.
Packer is a tool which can create this vagrant box for you. With this you can create a virtual image which also can be used for Amazon EC2, VirtualBox or VMware. In my case I need to have a particular image with the latest VBox guest additions and the latest Puppet RPM's. With packer I am now be able to create the same images as which my customer uses and test it on my own laptop.
How does this work?. ( you can download a full working example at my Github page which will create a CentOS 6.4, 5.8 or Ubuntu images and this will also add Puppet )
First we need to define a json file and a Red Hat kickstart file.
here is an example of a CentOS 6.4 example. This file contains the url of CentOS minimal or network iso, the Vagrant setup steps and post installation scripts, like the puppet install.
and the CentOS kickstart file
Next add the packer directory to your path variable , go to the packer github folder and use this command
packer build centos-6.4-x86_64.json
Wait some minutes and you will have a new box. Packer also shrinks this image to 600mb and is now ready to use it for Vagrant.
Next step is to download my vagrant github folder
When you go to this directory and use the vagrant up command, this will download the CentOS box, create a Virtualbox image and start the Puppet provisioning.
here is my example of a vagrant single node configuration, this will forward some ports and starts the Puppet site.pp class.
Here is an overview of my puppet folder
This is a shared folder ( virtual image and your machine ) and you can edit these Hiera and Puppet files in your fav editor, Add the needed puppet modules and start the provisioning again by using this command: vagrant provision or do it all over again by destroying it first: vagrant destroy -> vagrant up
Also vagrant supports multi machine configuration, just look at Vagrantfile_multinode.
Here is an working 3 node example, 3 VirtualBox Servers with a working WebLogic 10.3.6.0.6 Cluster which uses a private network.
https://github.com/biemond/biemond-orawls-vagrant
Hope these will also help you.
Saturday, November 16, 2013
Saturday, October 19, 2013
The road ahead for WebLogic 12c
Before we can describe all the new features of WebLogic 12.1.3 & 12.1.4 and compare this to the 12.1.2 version we should first take a look at the 10.3.6 version. WebLogic 10.3.6 is still the latest 11g version but Oracle will support 10.3.6 till 2018 and extended support till 2021. So Oracle’s Fusion Apps and we have enough time to migrate to WebLogic 12.1.X. Oracle also promised that the upgrade should be easy. That being said we can take look at the WebLogic 12.1.X features.
Last summer Oracle already released WebLogic 12.1.2 which has since WebLogic 12.1.1 been certified for Java EE 6 and it looks like the Java EE 7 certification is still far away, so Oracle updated the 12.1.2 version with some badly needed frameworks like WebSockets. To make the developer experience more complete Oracle added more support for Maven and it comes with a utility to synchronize a Maven repository with all the needed WebLogic libraries.
12.1.2 is also the first release, which comes with Fusion Middleware infrastructure components. For now FMW 12.1.2 contains ADF & OWSM and comes with Enterprise Manager & MDS.
WebLogic 12.1.2 replaced the BEA installer and the BSU patching utilities with the Oracle Universal Installer and the OPatch utilities for applying patches. To make it even more easier it just comes in one taste ( no Java included or a specific Operating System installer ). Just one big jar file for WebLogic with Coherence or one for WebLogic, Coherence and FMW.
WebLogic 12.1.2 introduced Dynamic Clusters, Elastic JMS and integrated Coherence configuration and management. Dynamic Clusters is a great feature to extend the WebLogic Cluster with Managed Servers based on a Server Template. For this we only need to change a parameter on the cluster and the new Managed Servers are distributed over the NodeManagers. To use this feature your blades need to have enough free resources to handle the extra Managed Servers.
Elastic JMS can be combined with Dynamic Clusters, this way we only need to create 1 JMS server, target this to the cluster and every Cluster node will have its own JMS server.
When we look at the announced features of WebLogic 12.1.3 and 12.1.4 we can see that Oracle continues on this road.
WebLogic 12.1.3 will be the first version for many FMW 12c products like Oracle SOA Suite 12c and probably come in one big jar. 12.1.3 & 12.1.4 will add extra features and improvements to Elastic JMS & Dynamic Clusters. Elastic JMS in 12.1.3 will support Server Migration so you can’t lose any JMS messages.
In 12.1.4, Dynamic Clusters will have support for auto-scaling based on thresholds based on user-defined metrics. WebLogic 12.1.4 will also have an API to control the Dynamic Clusters, this way we can easily program when to stop, start or remove nodes from a dynamic cluster.
WebLogic 12.1.3 will come with the JDBC 12c driver, this driver will gives us better integration and reliability between WebLogic 12c and Oracle Database 12c (Application Continuity).
When we take a look at the administration side of WebLogic we can see that the Enterprise Manager will be more important, in WebLogic 12.1.3 we can also do Application and JMS administration from the EM application. Also 12.1.3 will contain a Restful management APIs for additional monitoring, operations, Datasource and deployment support. Plus a global OWSM policy to protect all your Web and Rest services with one server policy.
WebLogic 12.1.4 will have a new feature called Multi-Tenant Applications, this way you can define an WebLogic template for an application, so one or more customers of this application which will have its own Cluster, Managed Servers, Application and (not shared) resources plus it will support Oracle Database 12c pluggable databases.
The last part of this article will talk about the development side of WebLogic 12.1.3 and 12.1.4. First WebLogic 12.1.3 has to be the Modern Development Platform and will focus on HTML5 development.
12.1.3 has some great new features like
• Updated version of JAX-RS and WebSockets.
• Server-Sent Events, this allows you to continuously sending updates to the browsers.
• JSON-P or JSON with Padding will solve your cross domain security problems.
• Maven improvements.
• Avatar allows you to develop and deploy server side Javascript Services without knowing Java.
WebLogic 12.1.4 will be certified for Java EE 7 and this means the WebLogic platform will get some framework updates and some new frameworks like
• Java API for JSON 1.0
• Java API for WebSocket 1.0
• Batch Applications 1.0
• Concurrency Utilities 1.0
The last question is off course when can we expect WebLogic 12.1.3 & 12.1.4. The 12.1.3 version will probably be released in March or April and 12.1.4 will be much later.
Last summer Oracle already released WebLogic 12.1.2 which has since WebLogic 12.1.1 been certified for Java EE 6 and it looks like the Java EE 7 certification is still far away, so Oracle updated the 12.1.2 version with some badly needed frameworks like WebSockets. To make the developer experience more complete Oracle added more support for Maven and it comes with a utility to synchronize a Maven repository with all the needed WebLogic libraries.
12.1.2 is also the first release, which comes with Fusion Middleware infrastructure components. For now FMW 12.1.2 contains ADF & OWSM and comes with Enterprise Manager & MDS.
WebLogic 12.1.2 replaced the BEA installer and the BSU patching utilities with the Oracle Universal Installer and the OPatch utilities for applying patches. To make it even more easier it just comes in one taste ( no Java included or a specific Operating System installer ). Just one big jar file for WebLogic with Coherence or one for WebLogic, Coherence and FMW.
WebLogic 12.1.2 introduced Dynamic Clusters, Elastic JMS and integrated Coherence configuration and management. Dynamic Clusters is a great feature to extend the WebLogic Cluster with Managed Servers based on a Server Template. For this we only need to change a parameter on the cluster and the new Managed Servers are distributed over the NodeManagers. To use this feature your blades need to have enough free resources to handle the extra Managed Servers.
Elastic JMS can be combined with Dynamic Clusters, this way we only need to create 1 JMS server, target this to the cluster and every Cluster node will have its own JMS server.
When we look at the announced features of WebLogic 12.1.3 and 12.1.4 we can see that Oracle continues on this road.
WebLogic 12.1.3 will be the first version for many FMW 12c products like Oracle SOA Suite 12c and probably come in one big jar. 12.1.3 & 12.1.4 will add extra features and improvements to Elastic JMS & Dynamic Clusters. Elastic JMS in 12.1.3 will support Server Migration so you can’t lose any JMS messages.
In 12.1.4, Dynamic Clusters will have support for auto-scaling based on thresholds based on user-defined metrics. WebLogic 12.1.4 will also have an API to control the Dynamic Clusters, this way we can easily program when to stop, start or remove nodes from a dynamic cluster.
WebLogic 12.1.3 will come with the JDBC 12c driver, this driver will gives us better integration and reliability between WebLogic 12c and Oracle Database 12c (Application Continuity).
When we take a look at the administration side of WebLogic we can see that the Enterprise Manager will be more important, in WebLogic 12.1.3 we can also do Application and JMS administration from the EM application. Also 12.1.3 will contain a Restful management APIs for additional monitoring, operations, Datasource and deployment support. Plus a global OWSM policy to protect all your Web and Rest services with one server policy.
WebLogic 12.1.4 will have a new feature called Multi-Tenant Applications, this way you can define an WebLogic template for an application, so one or more customers of this application which will have its own Cluster, Managed Servers, Application and (not shared) resources plus it will support Oracle Database 12c pluggable databases.
The last part of this article will talk about the development side of WebLogic 12.1.3 and 12.1.4. First WebLogic 12.1.3 has to be the Modern Development Platform and will focus on HTML5 development.
12.1.3 has some great new features like
• Updated version of JAX-RS and WebSockets.
• Server-Sent Events, this allows you to continuously sending updates to the browsers.
• JSON-P or JSON with Padding will solve your cross domain security problems.
• Maven improvements.
• Avatar allows you to develop and deploy server side Javascript Services without knowing Java.
WebLogic 12.1.4 will be certified for Java EE 7 and this means the WebLogic platform will get some framework updates and some new frameworks like
• Java API for JSON 1.0
• Java API for WebSocket 1.0
• Batch Applications 1.0
• Concurrency Utilities 1.0
The last question is off course when can we expect WebLogic 12.1.3 & 12.1.4. The 12.1.3 version will probably be released in March or April and 12.1.4 will be much later.
Thursday, August 22, 2013
Custom Jersey WADL generation
I had a situation where the auto generated WADL did not match with my Rest services.
The first difference was that the response is presented as an object instead of a collection of objects and the second one is that it could not handle JSONWithPadding as response. Because I use this WADL in my Rest client generation, I need to fix these issues.
Lucky for me, Jersey JAX-RS allows us to provide the necessary WADL input files so the generated WADL matches with the Rest services.
To make this happen I did the following steps.
First I extended the WadlGeneratorConfig class in which I defined the following properties applicationDocsStream, grammarsStream, resourceDocStream. These vars point to the xml files which will be used in the WADL generation.
We need to add the following init param com.sun.jersey.config.property.WadlGeneratorConfig to the Jersey servlet. This init param points to your WadlGeneratorConfig class
The first file is the application-doc.xml ( located in my src folder ), this will be used for the Title and high level description of your Rest service.
<applicationdocs targetnamespace="http://research.sun.com/wadl/2006/10">
<doc title="Oracle HR Demo API" xml:lang="en"> This is a paragraph that is added to the start of the generated application.wadl </doc>
</applicationdocs>
Next is the application-grammars.xml ( located in my src folder ) this file contains the location of your own XML schema which contains all our XML Elements and Complextypes.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<grammars xmlns="http://wadl.dev.java.net/2009/02" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xi="http://www.w3.org/1999/XML/xinclude">
<include href="../xsd/schema.xsd" />
</grammars>
Add the schema.xsd with the right definitions to the xsd folder located in the web folder of the web application.
The last file is the resourcedoc.xml, this file will be generated by the Maven javadoc plugin.
To generate the content of this file we need to add some javadoc annotations to our Rest Operation methods
For example the response.representation.200.qname annotation points to the employees element (schema.xsd).
Also the response.representation.200.example annotation points to an example object.
Add the Maven JavaDoc plugin with com.sun.jersey.wadl.resourcedoc.ResourceDoclet to your project pom and generate the resourcedoc.xml
Example of a resourcedoc.xml
Startup your Webapp and now the WADL looks like this
Here is my github demo project.
The first difference was that the response is presented as an object instead of a collection of objects and the second one is that it could not handle JSONWithPadding as response. Because I use this WADL in my Rest client generation, I need to fix these issues.
Lucky for me, Jersey JAX-RS allows us to provide the necessary WADL input files so the generated WADL matches with the Rest services.
To make this happen I did the following steps.
First I extended the WadlGeneratorConfig class in which I defined the following properties applicationDocsStream, grammarsStream, resourceDocStream. These vars point to the xml files which will be used in the WADL generation.
We need to add the following init param com.sun.jersey.config.property.WadlGeneratorConfig to the Jersey servlet. This init param points to your WadlGeneratorConfig class
The first file is the application-doc.xml ( located in my src folder ), this will be used for the Title and high level description of your Rest service.
<applicationdocs targetnamespace="http://research.sun.com/wadl/2006/10">
<doc title="Oracle HR Demo API" xml:lang="en"> This is a paragraph that is added to the start of the generated application.wadl </doc>
</applicationdocs>
Next is the application-grammars.xml ( located in my src folder ) this file contains the location of your own XML schema which contains all our XML Elements and Complextypes.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<grammars xmlns="http://wadl.dev.java.net/2009/02" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xi="http://www.w3.org/1999/XML/xinclude">
<include href="../xsd/schema.xsd" />
</grammars>
Add the schema.xsd with the right definitions to the xsd folder located in the web folder of the web application.
The last file is the resourcedoc.xml, this file will be generated by the Maven javadoc plugin.
To generate the content of this file we need to add some javadoc annotations to our Rest Operation methods
For example the response.representation.200.qname annotation points to the employees element (schema.xsd).
Also the response.representation.200.example annotation points to an example object.
Add the Maven JavaDoc plugin with com.sun.jersey.wadl.resourcedoc.ResourceDoclet to your project pom and generate the resourcedoc.xml
Example of a resourcedoc.xml
Startup your Webapp and now the WADL looks like this
Here is my github demo project.
Subscribe to:
Posts (Atom)











