Wednesday, May 4, 2011

JDeveloper performance tuning

Reference:
http://java2go.blogspot.com/2007/06/jdeveloper-tips-2-fine-tuning.html

Using Editor
tools->preferences->code editor->code insight and set it to something smaller (default 1 sec)
tools->preferences->extensions and disable extensions that you don't need
Tools->Preferences->Environment->Look and Feel and change it to Windows

Using JDeveloper Configuration File (%JDEV_HOME%\jdev\bin\jdev.conf)
AddVMOption -XX:Xms256M
AddVMOption -XX:Xmx1024M
AddVMOption -XX:PermSize=128M
AddVMOption -XX:MaxPermSize=512M
AddVMOption -DVFS_ENABLE=true
AddVMOption -Dsun.java2d.ddoffscreen=false
AddVMOption -Dsun.java2d.noddraw=true
AddVMOption -XX:+UseConcMarkSweepGC
AddVMOption -XX:+UseParNewGC
AddVMOption -XX:+CMSIncrementalMode
AddVMOption -XX:+CMSIncrementalPacing
AddVMOption -XX:CMSIncrementalDutyCycleMin=0
AddVMOption -XX:CMSIncrementalDutyCycle=10
Uncomment AddVMOption -Xsinglecpu on Multicore Machine
AddVMOption -Dsun.awt.keepWorkingSetOnMinimize=true

Using trinidad-config.xml
animation-enabled = false

More information can be found from
  • http://andrejusb.blogspot.com/2009/06/quick-hint-for-adf-faces-rich-client.html
  • http://andrejusb.blogspot.com/2009/06/jdeveloper-11g-ide-performance-problem.html

Sunday, March 6, 2011

JSF life cycle « John Deringer

JSF provides a well defined processing life-cycle for handling page request and form post. It really isn’t necessary to understand the JSF life-cycle to use JSF but it helps when attempting to understand the process of applying values, conversion, validation, event handling, exceptions and rendering. The six phases show the order in which JSF typically processes a form post. The list shows the phases in their likely order of execution but the life-cycle can be short-circuited, which is what happens during form validation errors, pressing a cancel button or by setting a components immediate attribute to ‘true’.

The six phases of a request process

JSF Life Cycle

  1. Restore view

    • JSF keeps a copy of the client view and component state on the server. During the restore view phase the JSF implementation will either create a new view for an initial page request, or render the server-side copy during a post-back request.

  2. Apply request values

    • Updates the server-side view with the new component values.

  3. Process validations

    • Performs conversion and/or validation of new component values.

  4. Update model values

    • Updates the server-side component’s with their new values.

  5. Invoke application

    • Invokes any server-side application logic contained within your managed bean.

  6. Render response

    • Renders the new view as directed by your backing bean and/or navigation mapping.

The six phases discussion

Restore View

The Faces View is the server-side representation of the JSF UI component tree. The restore view phase will either create a fresh view or restore an existing view, if one exists. JSF stores all views and their component states within an object called the FacesContext. When the FacesServlet controller receives a request it examines the view id to determine if there is an existing copy of the view in storage. The FacesContext object contains all the state information JSF needs to manage the GUI component’s state for the current request in the current session. The FacesContext stores the view in its viewRoot property; viewRoot contains all the JSF components for the current view ID and the components state. Once the view has been created, or retrieved, JSF advances directly to the render response phase.

Apply Request Values

The purpose of the apply request values phase is for each component to retrieve its current state. During this phase the JSF runtime performs the job of processing name-value pairs from the incoming request. JSF assigns the request values to the components by calling the decode() method on each component in the view hierarchy. The decode() method process’ the request value and assigns it to the local value attribute of the component. If there are any errors during the value assignment an error message is generated and queued in the FacesContext object, where it will be displayed during the render response phase. If a component’s immediate attribute is set to true, then conversion, validation and events associated with the component are processed in this time.

Process Validation

Conversion and validation occurs when the JSF runtime calls the processValidators() method on each component in the view hierarchy. The processValidators() method will first initiate any data conversion that is required before validating the components value against the application’s validation rules. If there are any errors during the conversion or validation process the component is marked invalid and an error message is generated and queued in the FacesContext object. If a component is marked invalid, JSF advances directly to the render response phase, which will display the current view with the queued validation error messages. If there are no validation errors, JSF advances to the update model values phase.

Update model values

It is in the update model values phase that the properties of the managed bean are updated with the new values from the pages UI component’s to which they are bound. The JSF runtime initiates the update by calling the updateModel() method on each UIInput component in the view hierarchy.

Invoke application

During this phase any action handlers and event listeners that are bound to UI components are called. This is where any custom business logic may be invoked such as persisting or retrieving data. This is also the phase where page navigation may occur. You initiate page navigation by defining a specific outcome for a form submission and returning that outcome that is defined within a faces-config navigation mapping. Once the navigation occurs, you move to the final phase of the life-cycle.

Render response

It is in the final phase of the JSF life-cycle that displays the view with all of its components in their current, updated, state. The JSF runtime accomplishes this by calling the encode() method on each component within the component tree hierarchy. The render response phase also saves the current state of the view in the FacesContext object for subsequent view request or sever-side operations.

A note on immediate event handling

The immediate event handling attribute of a JSF component is used to handle events that normally don’t necessitate validating an entire form. A common example is found when updating a list of cities when a state is selected from a drop-down list. When the state is selected you don’t not want the entire form validated when all you want is the list of cities to be updated. This would be a good place to use immediate event handling.

Conclusion

A JSF page is represented as a tree of UI components, called a view. Upon a page request or form submission the JSF life-cycle begins. During the life-cycle, the JSF runtime must build the view while considering state information entered by a user or previously stored on the server. When the client submits a form, the JSF runtime must perform several tasks such as converting and validating the data and processing any registered events. The JSF runtime performs all of these tasks as a series of well defined steps as part of the JSF life-cycle.JSF life cycle « John Deringer: "Renders the new view as directed by your backing bean and/or navigation mapping"

Friday, October 1, 2010

Migrating Security Policies from Development to Standalone WLS 11g

By Andrejus Baranovskis
Problems with security policies migration during deployment were solved using policies migration scripts from Steve Muench article - Simplified ADF 11g Application Credential and Policy Migration to Standalone WebLogic Servers. Its worth to mention, with latest JDeveloper 11g PS2 and WebLogic release, security policies are migrated during deployment process automatically - WLS system-jazn-data.xml is updated without running additional scripts. However, it happens we need to update system-jazn-data.xml with new policies, without whole application redeployment. For this purpose, similarly as in Steve article, we can use WLST command - migrateSecurityStore.

If you will run Steve scripts on latest Oracle Fusion release - you will see that some parts need to be updated (build.xml should contain updated references to JPS libraries, jps-config.xml should be updated with new system-jazn-data.xml location in fmwconfig folder). Main goal of my today post is to describe how you can apply migrateSecurityStorecommand and migrate security policies from development environment (or any other) into test/production WLS environment.

I'm using sample jazn-data.xml from this application - JaznMigration.zip. There is one simple security policy defined for index page:


Application role is mapped to specific Enterprise role:


In order to use migrateSecurityStore command, you will need to define jps-config.xml file, where you will point to source jazn-data.xml and to destination system-jazn-data.xml:


More about this file structure, please read in Oracle FMW Security Guide - Section 7.5.2.1. In my case, I have created jps-config.xml file inside WLS domain folder structure, I have copied source jazn-data.xml manually.

In order to execute WLST command, we will need to run WLST.cmd script. Make sure, you are using WLST.cmd script from oracle_common folder, otherwise it will not recognize ADF related WLST commands:


When WLST is running, you can execute migrateSecurityStore command. This WLST command can be run offline, this means no need to have running WLS server. Make sure you specify jps-config.xml file, source and destination contexts correctly, as it is defined in jps-config.xml:


And here we go, security policies are magically migrated to WLS system-jazn-data.xml and ready to be used:


Next step, make sure WLS server is connected to Active Directory service, where WLS can find users with correct Enterprise roles. Or for test purpose, define these users and roles in WLS embedded security realm.

Ah, almost forgot - make sure you have restarted WebLogic, before trying to test if it works.

Users and Groups migration: a handy JDeveloper feature

By Andre Correa

When you run an ADF web application directly from JDeveloper, it starts its embedded WLS and deploys the application. In such context, JDeveloper has a very convenient feature when dealing with users and groups defined in the application's jazn-data.xml file. They get deployed along with the application into WLS embedded LDAP server, provided the Users and Groups check box is selected in the Application Properties Deployment window, as shown right below:


applicationMenu

UsersAndGroupsMigration 

Then by simply asking JDeveloper to run your application you get everything you need.

As said, that's a JDeveloper convenience that only works when deploying the application through JDeveloper. Do notice this apply whether you click & run a page or taskflow or explicitly ask JDeveloper to deploy your application into WLS, as shown:

DeployingViaJDev

But if you’re not using JDeveloper, you’re on your own. You should not expect it to happen when generating an ear file and deploying via any other means, although jazn-data.xml is packed within the ear file. `I've gotten this question from a few of customers. And some believe that's a bug. It's not.

You need to manually populate WLS embedded LDAP. There are two ways to accomplish it:

1) Using wlst.sh:

> connect ('weblogic','','t3://:') > cd('')>  > cmo.importData('DefaultAtn', '', None)  


2) Using WLS Console:

Notice the path at the top to understand how to get to this screen.

Enter the ldif file absolute path name in “Import File” on Server field. Notice the file has to be accessible on the server file system.

DefaultAuthenticatoSetupWLS

Here's a small sample of the ldif file you can use and extend:

dn: dc=@domain@
dc: @domain@
objectclass: top
objectclass: domain
dn: ou=@realm@,dc=@domain@
ou: @realm@
objectclass: top
objectclass: organizationalUnit
dn: ou=groups,ou=@realm@,dc=@domain@
ou: groups
objectclass: organizationalUnit
objectclass: top
dn: cn=group1, ou=groups, ou=@realm@, dc=@domain@
memberURL: ldap:///ou=people,ou=@realm@,dc=@domain@??sub?(&(objectClass=person)(wlsMemberOf=cn=group1,ou=groups,ou=@realm@,dc=@domain@))
objectclass: top
objectclass: groupOfUniqueNames
objectclass: groupOfURLs
cn: group1
uniquemember: cn=user1,ou=people,ou=@realm@,dc=@domain@ 
 
dn: ou=people,ou=@realm@,dc=@domain@
ou: people
objectclass: organizationalUnit
objectclass: top
dn: uid=user1,ou=people,ou=@realm@,dc=@domain@
objectclass: top
objectclass: person
objectclass: organizationalPerson
objectclass: inetOrgPerson
objectclass: wlsUser
cn: user1
sn: user1
uid: user1
userpassword: welcome1
wlsMemberOf: cn=group1,ou=groups,ou=@realm@,dc=@domain@

Thursday, August 5, 2010

Detailed Logging for ADF Security

is possible to get more information about what security checks are happening and failing when you run an application with ADF Security enabled. The answer is yes. Just go to the Run / Debug / Profile entry in the project properties and edit the run profile (or create a new one) and add the following parameter to the Java Options field:
-Djps.auth.debug.verbose=true

Then when you run you'll get a huge amount of output showing each check and the status - rather like this:
[JpsAuth] Check Permission    PolicyContext:        [unsecuredtuhra2#V2.0]    Resource/Target:      [sessiondef.fragments_searchUIPageDef_BasicEmployeeSearchCriteriaQuery_VCTree_Root_internal_vcival_def_34_DynamicRegion]    Action:               [view]    Permission Class:     [oracle.adf.share.security.authorization.RegionPermission]    Result:               [FAILED]    Evaluator:            [ACC]    Failed ProtectionDomain:ClassLoader=sun.misc.Launcher$AppClassLoader@1ea2dfe   CodeSource=file:/C:/builds/R1_Production/jdeveloper/modules/oracle.adf.share_11.1.1/adf-share-support.jar   Principals=total 2 of principals(     1. JpsPrincipal: oracle.security.jps.internal.core.principals.JpsAnonymousUserImpl "anonymous" GUID=null DN=null     2. JpsPrincipal: oracle.security.jps.internal.core.principals

Managing ADF Security Using Oracle Enterprise Manager 11g

from Andrejus Baranovskis's Blog