Production Redeployment with ADF Shared WebLogic Libraries

Based on my previous post I wanted to know if we can achieve to redeploy parts of an ADF application by using shared WebLogic Libraries. In conjuction with the production redeployment WLS feature the overall goal is to prove that we can update modular ADF applications without downtime.

Introduction

The sample application consists of an employees taskflow that is bundled as ADF Library and deployed as shared library on WebLogic server. The sample is based on ADF 11.1.1.7 / WLS 10.3.5 / HR Schema.

First step: Create ADF Library as Shared WAR deployment

Goto JDev application with the containing Taskflow:

Create a MANIFEST.MF file under ViewController/src/META-INF/ with the following contents

The important parts are

Extension-Name: enpit.sample.empFlow

Specification-Version: 1.0

Implementation-Version: 1.0

Create ADF Library Deployment Profile for the empFlow on ViewController project with dependency on your Model project.

Make sure only connection name is Included in the Library

Having an ADF Library Deployment Profile in the employee taskflow application we create an additional Deployment profile (of type WAR) in the ViewController project. 

Under  WAR Options include the MANIFEST.MF file

Make sure to remove everything from Web Files contributors since we only want to wrap the ADF Library inside this WAR file.

Same to WEB-INF/classes. Exclude everything.

Under Profile Dependencies add the dependency to the ADF Library Profile

Goto WEB-INF/lib Filters and uncheck everything except the desired ADF Library JAR file.

With that WAR deployment configuration we are able to deploy -  the ADF Taskflow -  as shared library to the WebLogic server. (Select ViewController, right click, Choose Deploy > SharedADFLib ...to Application Server)

As a result the library shows up under Deployments in the WebLogic Admin Console

Deploy master application

In the master application that consumes the taskflow from the ADF Library we need to make sure

• versioning is configured for application deployment
• ADF Library is not bundled with the EAR
• Library reference is added to the ADF Shared Library in weblogic.xml (not weblogic-application.xml)

To enable the versioning for the app deployment we add /src/META-INF/MANIFEST.MF file with the contents

Manifest-Version: 1.0

Weblogic-Application-Version: 1.0

Now goto the EAR deployment profile and add the MANIFEST.MF file under the EAR Options

Goto application descriptors Filters and exclude MANIFEST.MF. (Otherwise the EAR won't be created as JDeveloper will try to include 2 MANIFEST.MF files in the EAR. You will see this exception in the deployment log window).

Now exclude the ADF Library from the application deployment. Goto ViewController project properties of the master application and make sure the library is not deployed by default.

In the WAR deployment profile check that the ADF Library JAR is not included

Next create WEB-INF/weblogic.xml and add library reference to the ADF Shared Library.

Important note: In my first try I added that library reference in the weblogic-application.xml. That won't work. At deployment time there will be the following exception

[08:23:54 AM] [Deployer:149034]An exception occurred for task [Deployer:149026]deploy application enpit_application1 [Version=1.0] on DefaultServer.: javax.faces.context.ExternalContext.

[08:23:54 AM] Weblogic Server Exception: weblogic.application.WrappedDeploymentException: javax.faces.context.ExternalContext

[08:23:54 AM]   See server logs or server console for more details.

[08:23:54 AM] weblogic.application.WrappedDeploymentException: javax.faces.context.ExternalContext

[08:23:54 AM] ####  Deployment incomplete.  ####

[08:23:54 AM] Remote deployment failed (oracle.jdevimpl.deploy.common.Jsr88RemoteDeployer)

So don't try this.

Doing it right you should see the following in Admin Console:

Test the application. It loads the taskflow and displays version 1

Next Step: Test production redeployment based on new version of ADF Shared Library

We are going to 

• Make changes in employees taskflow
• Change Library Implementation-Version to 1.1
• Deploy ADF Library as Shared WLS Library
• Increase application version to 1.1
• Redeploy master application

So first we increase the library version

and make some simple changes to the JSFF

Next: Deploy ADF Library to JAR

Next: Deploy sharedADFLib Deployment to IntegratedWebLogic

Check deployment in the Admin Console

Goto the master application and change Weblogic-Application-Version to 1.1

and deploy the master application to Verify deployment in the Admin Console once again. You should notice that previous application (1.0) is in stop running state. Actually it is meant to be RETIRED Mode. Existing web sessions will be served by that version 1.0.

Open a NEW BROWSER WINDOW (a different browser window to be dead sure) and point to the master application URL. You should see new version of the integrated Taskflow.

Conclusion

This mechanism is really powerful. It lets you redeploy application parts - maybe of a huge application - without downtime.

Download Sample Application

• enpit.sample.testsharedlibs-jdev11117.zip

Related Posts

• WebLogic Application redeployment using shared libraries - without downtime 
• http://andrejusb.blogspot.de/2010/07/deploying-adf-applications-as-shared.html
• http://andrejusb.blogspot.de/2010/07/redeploy-and-version-adf-shared.html

WebLogic Application redeployment using shared libraries - without downtime

Environment

Oracle WebLogic 10.3.6

Use Case

An application that depends on custom shared libraries needs to be redeployed without downtime. That means without interrupting the availability of the application to existing and new clients. Since production redeployment is not available for libraries we need to think about a different approach.

Precondition

A shared library (as war) is deployed (state: active) and targeted to - for simplicity say - AdminServer with the following version settings:

Extension-Name: enpit-common-war-lib

Specification-Version: 1.0

Implementation-Version: 1.0.4

An application references that library in its weblogic.xml in the following way:

<?xml version='1.0' encoding='UTF-8'?>

<weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.bea.com/ns/weblogic/weblogic-web-app.xsd" xmlns="http://www.bea.com/ns/weblogic/weblogic-web-app">

  <library-ref>

       <library-name>enpit-common-war-lib</library-name>

  </library-ref>

</weblogic-web-app>

The library is referenced without any version information. That means it will reference the highest available deployed library version. That application is successfully deployed and also targeted to AdminServer. Its state is active. It is working correctly, accesses Java classes in the shared library.

Problem

Trying to deploy the existing library (not changing the version information) once again 

java weblogic.Deployer -adminurl t3://eden.local:7001 -username weblogic -password welcome1 -upload -library -targets AdminServer -deploy -source enpit-shared-lib-war.war

results in the following error:

Cannot undeploy library Extension-Name: enpit-common-war-lib, Specification-Version: 1, Implementation-Version: 1.0.4 from server AdminServer, because the following deployed applications reference it: enpittestcommons-reflib.war

=> Makes sense!

Solution Trial 1

We change the MANIFEST.MF of the Shared Library that has to be redeployed to

Implementation-Version: 1.0.5   (the deployed one has 1.0.4)

Lets see what happens

Task 17 completed: [Deployer:149117]deploy library enpit-common-war-lib [LibSpecVersion=1.0,LibImplVersion=1.0.5] on AdminServer.

Target state: deploy completed on Server AdminServer

=> We succeeded. Have a new version deployed!

Question 1

Which version is our running application now using?

Well, the application still uses version 1.0,1.0.4 although it is specified that the highest version should be used. To conclude: The application does not dynamically adopt to the new library version. I think that is good. Otherwise it would be much magic happening in the background.

Question 2

We stop the running application. Now the application shows up in the admin console in state "prepared".

Lets start it again. ... It moves again to state "active".

Which version is our running application now using?

Well, In my simple use case I changed the returned string in the library class to "1.0,1.0.5" according to the new library version. And indeed, my sample app shows the right information.

Library-Version: 1.0,1.0.5

Conclusion: That's a powerful way to update dependencies for an application. All you have to do is just restarting the application. At the time of restart the new version of the library is picked up! Further: we are able to undeploy the unreferenced "old" library (in my case 1.0,1.0.4). Everything works as expected except the use feedback at the admin console looks inconsistent. Selecting the Library no referenced applications are shown in the corresponding section

Question 1

How about production redeployment for the application in that scenario? It would mean that the application would have NO DOWNTIME. So lets give it a try. I have undeployed the sample app and deployed it as follows:

java weblogic.Deployer -adminurl t3://eden.local:7001 -username weblogic -password welcome1 -upload -targets AdminServer -deploy -source enpittestcommons-reflib.war -appversion 1.0

Note: That the web application shows up with a version information.

Next: We are going to update the library to impl. version 1.0.6

Task 24 completed: [Deployer:149117]deploy library enpit-common-war-lib [LibSpecVersion=1.0,LibImplVersion=1.0.6] on AdminServer.

Deployment succeeded!

Next: Instead of restarting the web application we Redeployit with "-appversion 1.1"

Log: weblogic.Deployer invoked with options:  -adminurl t3://eden.local:7001 -username weblogic -upload -targets AdminServer -deploy -source enpittestcommons-reflib.war -appversion 1.1

<05.06.2013 19:14 Uhr MESZ> <Info> <J2EE Deployment SPI> <BEA-260121> <Initiating deploy operation for application, enpittestcommons-reflib.war#1.1 [archive: /Users/ak/Dropbox/community/doag/doag-2013-imc/use-shared-lib-app/enpittestcommons-reflib.war], to AdminServer .>

Task 25 initiated: [Deployer:149026]deploy application enpittestcommons-reflib.war [Version=1.1] on AdminServer.

Task 25 completed: [Deployer:149026]deploy application enpittestcommons-reflib.war [Version=1.1] on AdminServer.

Target state: deploy completed on Server AdminServer

Now we test the existing connection. It still shows

Library-Version: 1.0,1.0.5

Further open a new Browser and target to the same web app URL gives me :

Library-Version: 1.0,1.0.6

After sessions timed out, we get the following picture

Conclusion

Shared Libraries on WebLogic Server in conjunction with "production redeployment" is a really powerful feature. Applications can upgrade to a library version without downtime!

Next I would like to check if same is possible with shared ADF Libraries. That way it would be possible to update separate application parts (deployed as ADF Libraries) without downtime. Would be really cool!

ADF: Static Values View Object does not show any values (solved)

Environment

ADF/JDEV 11.1.2.4

Problem description

After creating a ViewObject of Type "static values" and running an instance inside the Business Components tester I noticed that no values are displayed at runtime! From the navigation action it looks like there are exactly as many rows that has been created, but whatever row is displayed, all values are empty!

Analysis

Looking in depth I noticed that the reference to the resource bundle where the static values are coming from, is invalid. The path does not match the actual source for the properties file although the static values ViewObject has been created by the JDeveloper Wizard

Solution

Short term solution is to manually adjust the value of the attribute PropertiesFile of the corresponding ResourceBundle.

So if the Property file is under src/enpit/sample/adf/transientvoascriteria/modelBundle.properties set the value to PropertiesFile="enpit.sample.adf.transientvoascriteria.modelBundle"

Rebuild and restart the BC Tester to verify that everything is working as expected:

Remark

The reason for the mismatch I guess is because JDeveloper does not handle everything correctly if having dots in project names. So take care if you use JDeveloper project names like 'MyApp.Model'. Double check references to the property bundle!

ADF 11.1.1.7 New Feature: HTML5 Placeholder

Many of us have waited for it some time now. With the arrival of ADF 11.1.1.7 the Input components have got a new attribute: placeholder.

Use Case

Provide a prompt text inside an input component.

Usage

In order to use this feature just fill in the newly added attribute from the property inspector or directly in the source code.

On runtime it is properly rendered as placeholder-HTML5 Attribute.

Works on all modern browsers ;)

JDeveloper Code-Template for ADFLogger

 Environment: JDeveloper 11.1.1.6

To make the Logger-Declaration a not so tedious work you can make use of JDeveloper Code Template features which is available in the preferences.

In JDeveloper:

1. Open from the menu: Tools > Preferences

2. Open: Code Editor > Code Templates

3. Click "+" to add a new code template

4. Goto the Code-Tab and add the following:

private static final ADFLogger LOGGER = ADFLogger.createADFLogger($clazz$.class);

5. Goto Imports-Tab and add needed classes:

oracle.adf.share.logging.ADFLogger

6. Confirm Changes by clicking 'OK'.

=>> The Code-Template 'logger' is now available inside the Java-Editor.

Using the Code-Template in JDevelopers Editor

1. Open a Java class

2. Place cursor right inside class definition, type 'logger' and press 'Ctrl+Enter'.

Afterwards the ADFLogger is available inside the Java class.

On the following Blog posts you can find more information around ADFLogger + a CodeTemplates XML which you can import in your JDeveloper.

More information

• ADF Logging https://blogs.oracle.com/groundside/entry/adventures_in_adf_logging_part
• ADF Logger Templates https://blogs.oracle.com/groundside/entry/adventures_in_adf_logging_part1

Managing ADF Applications with Oracle Java Cloud Service Control

In this post I am going to show how to manage and monitor Oracle ADF Applications in the Oracle Cloud using Oracle Java Cloud Service Control.

Prerequisites

You should have the following done before trying the described steps in this post yourself.

• Having a (trial) Oracle Cloud Java Service (which includes the database cloud service as well)
• Having deployed an ADF Application to Oracle Cloud as described in the previous post (http://multikoop.blogspot.de/2012/12/deploying-adf-applications-into-oracle.html)

Managing tasks

The Oracle Java Cloud Service Control - that's the official name - is a subset of Enterprise Manager Cloud Control 12.1.0.2.0. It supports the Cloud Service Administrator to do the following tasks:

• View the list of services, metrics and availability of each service instance
• Deploy / Undeploy / Start / Stop Java EE (ADF) applications
• View cloud service job logs to see and verify recent activity
• View and export application log messages
• View ADF Application performance metrics <<< "does not work for me"

Getting started, Monitor Service Metrics

To get started log in at cloud.oracle.com and open "My Services" tab.

On this screen the first interesting metrics can be monitored per Java service instance.

• Java Heap usage, averaged over the last 15 minutes
• CPU usage, averaged over the last 15 minutes

From the service overview we can follow the 'Service Console' Icon that will take us to the 'Oracle Cloud Java Service Control'

The dashboard mainly shows an overview of the service availability and some common used resource usage metrics in different representations (diagram, table) like

• Active HTTP Sessions
• Request processing time (in ms)
• Request count (per minute)
• Open JDBC Connections
• Java Heap Usage
• CPU Usage

Deploy / Undeploy / Start / Stop Java EE (ADF) applications

The next important part is the possibility to Deploy, Undeploy (Delete), Redeploy, Start & Stop Applications. These are common administration tasks which are easy to use without any complications - at least start, stop worked fine so far ;). 

For this post I am going to try deployment of ADF App right from the browser. Let's see if it works (The first ADF Deployment into the Oracle Cloud I have done from JDeveloper IDE, which worked without any problems). So let's click 'Deploy New' 

Choose an EAR from you local machine, give the child a name and press 'Deploy'. 

The upload goes really quick and user is provided with a message which says that a cloud service Job has been started in order to perform the task.

Lesson learned: It is not possible to provide a deployment plan while deploying ADF Applications in the Oracle Cloud.

This brings us to the next feature. 

Cloud service job logs

On the bottom of the cloud control dashboard there is a table panel 'Java Cloud Service Jobs' to track the recent activity. After refreshing the dashboard we notice that the previously started deployment job has failed.

Select the corresponding row and open the 'View Java Cloud Service Job Logs' Menu

The strange thing here (bad UX) is that the service administrator has to guess what actually caused the deployment to fail from 3 options

• The uploaded EAR might have not passed the virus scan
• The uploaded ADF Application might have not passed the whitelist validation
• The deployment failed due to some other issue.

a) For every option you choose from the Menu a file is downloaded and can be viewed on the local machine.

Virus Scan: Passed successful.

b) Next: Application Whitelist Validation

2012-12-29 16:41:23 CST: Starting action "API Whitelist"

2012-12-29 16:41:23 CST: API Whitelist started

2012-12-29 16:41:24 CST: WARNING  - There are 2 warnings(s) found for enpit_cloudapp2.ear.

2012-12-29 16:41:24 CST: WARNING  - Path:enpit_cloudapp2.ear (2 Warnings)

2012-12-29 16:41:24 CST: WARNING   - Path:enpit_cloudapp2.ear (2 Warnings)

2012-12-29 16:41:24 CST: WARNING    - Path:enpit_cloudapp2.war (2 Warnings)

2012-12-29 16:41:24 CST: WARNING     - Path:WEB-INF**** (2 Warnings)

2012-12-29 16:41:24 CST: WARNING      - 1:Recommended child element "jsp-descriptor" missing under element /

               bea-weblogic:weblogic-web-app.

              

               If you have a JSP file that is not pre-compiled, The compilation errors

               could be shown on the browser. It is recommended to include

               <jsp-descriptor><verbose>false<****><****-descriptor> in weblogic.xml.

               Line No:2.

2012-12-29 16:41:24 CST: WARNING      - 2:Recommended child element "session-descriptor" missing under element /

               bea-weblogic:weblogic-web-app.

              

               You will be required to have distinct cookie-path, if multiple

               applications are accessed with in the same SSO session or if you have

               multiple applications with different auth-method(CLIENT-CERT, FORM, BASIC)

                in the same service instance.

               Line No:2.

2012-12-29 16:41:24 CST: WARNING  - enpit_cloudapp2.ear had  2 warning(s).

          

2012-12-29 16:41:24 CST: INFO     - Whitelist validation has completed with 0 error(s) and 2 warning(s).

2012-12-29 16:41:24 CST: Whitelist validation passed.

2012-12-29 16:41:24 CST: "API Whitelist" complete: status SUCCESS

c) Looks like the deployment actually went wrong - and indeed

2012-12-29 16:41:24 CST: Starting action "Deploy Application"

2012-12-29 16:41:24 CST: Deploy Application started

2012-12-29 16:41:40 CST: weblogic.application.ModuleException:

2012-12-29 16:41:40 CST: WLS action state: failed

2012-12-29 16:41:40 CST: Action FAILED with WLS state: failed

2012-12-29 16:41:40 CST: Application deployment failed.

2012-12-29 16:41:42 CST: [Deployer:149034]An exception occurred for task [Deployer:149026]remove application enpit_cloudapp2 on c1.: .

2012-12-29 16:41:42 CST: WLS action state: completed

2012-12-29 16:41:42 CST: "Deploy Application" complete: status FAILED

=> Well so it looks like an exception occurred while 'removing the application on c1". This message does not help really much, is confusing since that was the first deployment and no need for removing a previous application.

Application log messages

Maybe the log messages give some more information about the failure. The messages are accessible by following the link 'View Log Messages'

Looks like there is a configuration exception in the deployed ADF Application. After deploying the same application from JDeveloper into the Cloud I have noticed the Deployment Platform in the Log was 'Oracle Cloud'. So the problem was clear to me. Open the Deployment Profile and adjust the platform to 'Oracle Cloud' for creating the EAR.

After creating the EAR once again with that setting and performing same steps from the Cloud Control as described above the deployment worked as expected.

Important lesson learned: The Deployment Profiles and so the resulting ADF Application EAR differs.  You cannot use the same EAR for Deployment to on-premise WebLogic Server AND Oracle Cloud Java Service! 

ADF Performance metrics

Clicking on a given ADF applications name shows a dedicated performance view

IMHO the displayed metrics cannot be realtime values because most of the testing time -  there were 2 active HTTP sessions all values were displaying 0. So I guess it is an average view over the last 15 Minutes.

From the application menu the ADF Performance view can be opened.

This part is very disappointing for now since the displayed information is just not true!

The sample app is using an Application Module and so should also display application module pool stats as indicated (but empty :( )

Same to the TaskFlows view

Sample application is using two bounded task flows. So I would expect them to be shown up here.

Conclusion

In general the Java Cloud Service Control makes what it is made for. It looks like the observed shortcomings are a limitation to the trial account or the ADF Performance Summary does not work in its current state. It is interesting to see that even in the official Oracle Cloud Documentation (Sec. Monitoring Oracle Java Cloud Service) there is no word left about the ADF Performance Summary + all available screenshots show 0 sessions, 0 requests and so on.

If someone has a different experience or some guy from Oracle has an explanation for the inconsistent  behavior in the Cloud Service Control feel free to comment. I would be happy to be convinced from the opposite - a reliable cloud service control for monitoring ADF Applications.

Enhancement Requests

• Java Cloud Service Jobs
• • Emphasize failed jobs, e.g. displaying 'Failed' in Red.
  • In case of failed jobs there should be made clear on first view what caused the issue (Virus detected, Whitelist violated, other issue).
  • Error message in case of failed deployment should be more useful. An message like 'An exception occurred for task [Deployer:149026]remove application enpit_cloudapp2 on c1.: .' does not say anything about the cause.
• Resource Usage metrics (sessions, Request processing time, JDBC Connections)
• • Realtime Values. Currently it looks like the values are most of the time 0 even if there is some load.
• ADF Performance 
• • Display the actual metric values. Currently AM Pool and Taskflow metrics are not shown.
• General: Improved Reliability. Sometime there were just errors and inconsistent information displayed (see next image). E.g. error getting datasources and open JDBC Connections = 0 but the DB based application was accessible and worked fine.

Documentation

• Oracle Cloud Documentation (Monitoring Oracle Java Cloud Service) http://docs.oracle.com/cloud/CSJSU/monitor.htm#CSJSU7070

Related Posts

• Deploying ADF Applications into Oracle Cloud using JDeveloper (by enpit) (http://multikoop.blogspot.de/2012/12/deploying-adf-applications-into-oracle.html) 
• Deploying Database Objects to Oracle Cloud using JDeveloper (by enpit) (http://multikoop.blogspot.de/2012/12/deploying-database-objects-to-oracle.html)
• Oracle Cloud Java and Database Services in Action (by enpit) (http://multikoop.blogspot.de/2012/11/oracle-java-and-database-cloud-services.html)