JHeadstart Blog

If you change the Group Layout properties in your Application Definition, JHeadstart might not generate certain JSF files anymore. It is good practice to clean up files that are not used anymore.

For example, if you change the Layout Style from "table-form" to "form", the table page is not generated anymore. If you had already generated that table page in an earlier run, that JSPX file is still in your project, but not part of your application page flow anymore.

If you want to get rid of these superfluous JSF pages, you can do the following:

• Run the JHeadstart 10.1.3 Application Generator
• Don't save all files yet
• Go to the Navigator of JDeveloper 10.1.3, to the folder where the pages are generated
• Check which page names are not italic
  

Alberto wrote in to tell us that he downloaded the JHeadstart 10.1.2 evaluation copy from the JHeadstart Product Center, and asked where to download JDeveloper 10.1.2 for which JHeadstart 10.1.2 is certified. The answer is: from the JDeveloper Archives.

A working set allows you to define a set of files (a subset of project source path contents) that you want to work with. For large projects, you may want to work with a small subset of the source files (for example, all the files in a given package, plus a few others). Typically, you would perform the following actions scoped to the working set:

• Make
• Build/rebuild
• Search
• Find usages
  

1. Open [JDevHome]/jdev/system/oracle.ide.10.1.3.36.73/projects/index.xml and finding the entry for the JDeveloper project on which you defined the working sets.
2. The entry in index.xml references a working set definition file in the [JDevHome]/jdev/system/oracle.ide.10.1.3.36.73/projects folder.
3. Possibly rename this (project-specific) working set definition file to a more meaningful name.
4. Share this working set definition file with your team, and tell everyone to change the project entry in their own [JDevHome]/jdev/system/oracle.ide.10.1.3.36.73/projects/index.xml to let it point to the new file. (And don't forget to do that yourself as well, if you changed the name ;-)
   

I found out that the Manila Blog Search we had did not work, so thanks to my colleague Steven Chan I implemented Google Search for the JHeadstart blog. See the right-hand navigation bar, just below the Categories. Try it out!

Oscar writes in to ask if he can deploy JHeadstart on a BEA WebLogic application server instead of an Oracle Application Server. The answer is yes:  a JHeadstart application is "just" an ADF application, and therefore is compatible with all application servers mentioned in the JDeveloper Application Server Support Matrix.

You can deploy a JHeadstart / ADF application to:

• Oracle Application Server
• Standalone OC4J
• Tomcat
• JBoss
• WebLogic
• WebSphere

In an application with role-based access it is common practice to hide
menu options which navigate to pages you are not allowed to see.



When using a JSF, a good solution to implement this is to use the open source security project
created by Duncan Mills. Aternatively, you can take a look at the
custom solution implemented in the Oracle SR Demo (install through
JDeveloper -> Check for Updates).



Both techniques can only be used to hide or disable menu options,
buttons and/or other user interface components. It does not prevent
illegal access to unauthorized pages through URL hacking. For example,
if you run the SR Demo, and log in as dfaviet, a user with customer
role, you do not see the Management tab. However, if you then change
the browser URL to .../SRDemoADFBC/faces/app/management/SRManage.jspx you will go to the management page, no problem!



JHeadstart uses a simple technique to prevent illegal access to JSF
pages. This technique can also be used in non-JHeadstart applications,
provided that you use the ADF DataBinding layer. We will demonstrate
the technique by protecting the SRManage.jspx page of the SRDemo.



The trick is to use the parameter element of the page definition. Open the app_management_SRManagePageDef page definition. You can
specify a parameter by going to the structure pane of the page
definition, right mouse click on parameters and choose Insert inside parameters => parameter.  A dialog  pops up where  you can enter  an  id and value.

Enter roles as the value for id property, and #{userInfo.manager}  as the value for the value property. Your page definition XML should look like this:



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


<pageDefinition xmlns="http://xmlns.oracle.com/adfm/uimodel"


               
version="10.1.3.35.83" id="app_management_SRManagePageDef"


               
Package="oracle.srdemo.view.pageDefs">


  <parameters>


    <parameter id="roles" value="#{userInfo.manager}"/>


  </parameters>


  .....



Now, the last step is to add code to the page lifecycle class that
evaluates the above roles expression and returns an access denied
message when the expression evaluates to false. This is surprisingly
simple. Add the following method to the SRDemoPageLifecycle class:



  protected void checkRoles(LifecycleContext ctx)

  {

    DCBindingContainer container =  (DCBindingContainer) ctx.getBindingContainer();

    DCParameter rolesParam = container.findParameter("roles");

    if (rolesParam != null)

    {

      if (!(Boolean)rolesParam.getValue())

      {

        HttpServletResponse response =

         
(HttpServletResponse)
JSFUtils.getFacesContext().getExternalContext().getResponse();

        try

        {

          response.sendError(HttpServletResponse.SC_FORBIDDEN,

                            
"You have insufficient privileges for the requested page");

        }

        catch (IOException e){}

        JSFUtils.getFacesContext().renderResponse();

      }

    }

  }



And call this method as the first statement in the prepareModel() method.
That's all. Instead of sending the SC_FORBIDDEN message to the browser,
you can also add a global "AccessDenied" navigation case to your
faces-config, which navigates to a custom error page. To do this, use
the following code instead of the response.sendError call:



  NavigationHandler navHandler = JSFUtils.getFacesContext().getApplication().getNavigationHandler();

  navHandler.handleNavigation(JSFUtils.getFacesContext(),null,"AccessDenied");       



As you see, the page definition parameter element is quite handy for
configuring generic code in the page lifecycle class. We will shortly
post other techniques that also rely on the parameter element. Stay
tuned!

In our project we found out that a certain error only occurred in the
deployment environment, and then only sometimes. Those are the worst
problems to solve! The error message was:

JBO-30003: The application pool (...name...) failed to checkout an application module due to the following exception:

oracle.jbo.JboException: JBO-29000: JBO-25000: Unknown SQL type: null.



After debugging, googling, and metalinking, we found that the error was
related to the State Management mechanism of ADF Business
Components. The error only occurred when on certain pages an Application Module instance's state
had to be passivated to the database, and later activated again.



Steve Muench gave us a great tip: you can enforce this Application
Module (AM) passivation and activation in your development environment
by temporarily setting a configuration parameter. See section 28.8, "Testing to Ensure Your Application Module is Activation-Safe" of the ADF Developer's Guide.



This enabled us to reproduce the error in JDeveloper, and to verify that the patch for bug 5191597 you can download from MetaLink did indeed solve the problem!

When you use the JDeveloper 10.1.3 Debugger you get a Data tab where
you can see the values of local variables at the breakpoint. If one of
the local variables is a View Row (a ViewRowImpl class), this blog
describes how to inspect the underlying data of the row without having
to code getters for each attribute. Assuming that the attributes are
mapped to Entity attributes, you can open the ViewRowImpl instance, and
drill down using the following steps:

• mInner


• mRows


• [0] (assuming you want to see the data of the first mapped Entity, otherwise you can choose [1], [2], etc)


• mData


• mStorage

Licensed JHeadstart users can now download JHeadstart 10.1.3 Service Update 1 (build 10.1.3.0.97) from the Consulting Supplement Option.
Apart from a number of bug fixes (see the release notes for a list),
this service update contains some functional enhancements:

• File Upload in Table Layout. It is now possible to generate file upload items in a table layout.


• File
  Download/Images in Table Layout. It is now possible to generate file
  download links or images in a table layout. 


• Checkboxes based on String attributes in Table Layout. It is now
  possible to generate checkboxes that are directly based on String
  attributes with a two-value domain (matching the true/false state of
  the checkbox). It is no longer necessary to create transient attributes
  of type Boolean in your ViewObject to be able to generate checkboxes in table layout.


• When
  Access Denied Go To Next Group. When the user navigates to a
  group he is not allowed to access, JHeadstart can automatically
  redirect the user to the start page of the next group for which the
  user is authorized.
• Show Template Names in Source.
  There is a new service-level checkbox property "Show Template Names in
  Source". When checked (the default) the generated sources contain
  comments indicating which Velocity template was used to generate each
  page snippet.
  
  

• Multi-Select List of Values


• Client-side checking of required items in Table Layout
  
  


• Tree-style List of Values


• Search through Tree nodes
• Generating of graphs