Tuesday Feb 25, 2014

Stretching an inputText inside of a Table Column

A quick trick to note if you have a table that includes a column containing an <af:inputText>. If the user is able to re-size the columns within the table, then it's not unreasonable to have the inputText stretch along with the column to take advantage of the full width available. 

The first thing to do is to set the simple property of the inputText to "true".  This almost does the trick, but you'll find that as you stretch the column there is a small trailing gap between the end of the input field and the column which grows as the column is stretched. So although the input is stretched as well it does not fill the cell which looks a little messy.

The second trick then is to set the contentStyle property on the inputText to "min-width:100%;" Do this and you will eliminate that gap and the input will now fill the column cell completely as you resize. 

Monday Feb 24, 2014

Programmatic UI Scrolling in ADF Faces

I've been dealing with a use case recently where we needed to synchronize two panels in a user interface, where (in the simple version) selecting an object on one side of the screen would also select a corresponding object in a scrolling area on the other side of the screen and scroll in into view.  the scrolling panel in this case being a panelGroupLayout / scroll, not a table.

Declarative  scrolling is really simple, you can drop a UI element such as commandButton onto the page and then nest, within that, the behavior tag <af:scrollComponentIntoViewBehavior>. This tag is great if you have a long page and want to provide the users with a way to navigate to different sections, however, it needs to be wired to a command component and the user needs to physically invoke the operation.

In this case, everything needed to happen in reaction to a series of complex programmatic events and so, the use of the behavior tag did not cut it.  So I did a small amount of testing to see if it was possible to achieve the same result in a hands off fashion from within java code.

It turns out to be pretty simple to do, but there are different approaches depending on your version:

Programatic Scrolling in 11.1.2.n and 12c

In the newer versions of ADF this issue is addressed head on with a new API on the AdfFacesContext -> scrollComponentIntoView(component, focus);  This API takes a UIComponent reference for the component to scroll to, and the second argument is a boolean flag to indicate if the component should take focus as well (for example if it was an input field).  

Programatic Scrolling in 11.1.1.n

 Prior to ADF Faces 11.1.2 the handy  scrollComponentIntoView() api does not exist, however, we can acheive the same effect using some JavaScript. (Note if you are on a version of ADF that does support the scrollComponentIntoView() Java API then use that, not this.)

As with the behavior tag, you need to do two things.

  1. The target component has to have clientComponent="true" as this scrolling operation all takes place on the client
  2. You need the full id of the target component.  This should include any naming containers such as templates and regions.  The safest way to do this is to call getClientId() on the java component itself. 

 Then you can just invoke this little function.  Note that the code does not have any error handling if you get the component ID wrong so feel free to improve it to make it more robust:

import org.apache.myfaces.trinidad.render.ExtendedRenderKitService;
import org.apache.myfaces.trinidad.util.Service; 

private void scrollIntoView(String componentId){
  StringBuilder builder = new StringBuilder();
  builder.append("var c = AdfPage.PAGE.findComponent('");
  builder.append("'); c.scrollIntoView(true,null);");
  FacesContext fctx = FacesContext.getCurrentInstance();
  ExtendedRenderKitService erks =
    Service.getRenderKitService(fctx, ExtendedRenderKitService.class);
  erks.addScript(fctx, builder.toString());        

If you use this function an it appears not to work you may be hitting a timing issue where the framework is, in turn, resetting the focus after you have set it.  If that seems to be happening in your case, then the solution is to re-write the above JavaScript slightly to execute the scrollIntoView() after a short delay.  You can use a JavaScript  setTimeout() function on the window object to do this.  Delaying the scroll call for about 10ms should be sufficient.

Thursday Feb 20, 2014

JAX-RS 2.0 MessageBodyReader not found error

From time to time we all make silly mistakes which lead to much head scratching and time being wasted. This is a short missive about just such a mistake that I made yesterday which then had me totally stumped (for a a few minutes at least!) this morning.

So, here's the story.  I was taking a long flight back to the UK from California yesterday and had wanted to keep working on a client UI for a RESTful service provided by our build infrastructure.  As you can imagine, it's not going to work very well to access those services in flight, so I spent the wait time in the lounge building out a quick mock implementation of the data structure using the same POJOs so I could switch to that and continue with the UI development offline. As part of this I thoughtlessly added a new constructor into my main POJO that the REST service JSON structure mapped in to.  All was well.

This morning I'm back online, so I switch the implementation of my UI data provider back to the real service to see what the UI now looks like with more data - it fails? Huh? OK back to the test client - it also fails:

Exception in thread "main" 
  MessageBodyReader not found for media type=application/json, 
  type=class com.groundside.model.Orchestration, 
  genericType=class com.groundside.model.Orchestration.
 at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor$TerminalReaderInterceptor.aroundReadFrom(ReaderInterceptorExecutor.java:207)
 at org.glassfish.jersey.message.internal.ReaderInterceptorExecutor.proceed(ReaderInterceptorExecutor.java:139)
 at org.glassfish.jersey.message.internal.MessageBodyFactory.readFrom(MessageBodyFactory.java:1109)
 at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:853)
 at org.glassfish.jersey.message.internal.InboundMessageContext.readEntity(InboundMessageContext.java:785)
 at org.glassfish.jersey.client.ClientResponse.readEntity(ClientResponse.java:267)
 at org.glassfish.jersey.client.InboundJaxrsResponse$1.call(InboundJaxrsResponse.java:111)
 at org.glassfish.jersey.internal.Errors.process(Errors.java:315)
 at org.glassfish.jersey.internal.Errors.process(Errors.java:297)
 at org.glassfish.jersey.internal.Errors.process(Errors.java:228)
 at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:397)
 at org.glassfish.jersey.client.InboundJaxrsResponse.readEntity(InboundJaxrsResponse.java:108) 

So now I spin round and make all the checks I can think of.  The libraries are all unchanged, perhaps the shape of the service has been changed overnight? - nope, every thing is the same.  The mime type coming from the service is still application/json as well. 

So I'm pretty confused. Back to first principles though. Has really nothing changed? Well in fact yes there was a change - just one little, tiny thing, that new constructor.  Of course that was it.  One of the requirements for the JAX-RS unmarshalling is that the entity class should have an empty constructor.  Before it was implicit, but now I'd added that new constructor for the mocking which included arguments and that replaced the implicit empty constructor and broke the above requirement to boot.  So it was simple to fix in the end just annoying. Hey ho...

Thursday Dec 05, 2013

Current Date / Time on your JSF pages

OK, it's a trivial problem but I'll answer to anyway. Is there a simple way to get the date and time in expression language inside your pages, without writing Java code?

The answer is of course yes, it's simple to do in a declarative manner.  You will need to create a basic managed bean definition in your JSF configuration.  So for example I might add the following definition for a bean called "now" to my adfc-config.xml file:


That's enough to ensure that a Date object called "now" is available on the request map and is re-created (i.e. refreshed) on every roundtrip.  This can then be referenced inside of your page:

  <af:outputText value="#{now}">
    <af:convertDateTime type="both" timeZone="CET"/>

Notice how I've specified the timezone I want to see here as the result of the new Date() creation will be the date in UTC / GMT.

There you are, short and sweet. 

Tuesday Dec 03, 2013

Click History in ADF 12c

In previous posts (see here) I've covered various aspects of logging in ADF and in conjunction with a presentation delivered at the UK Oracle Users Group, I'm continuing the trend with an article on the new Click History functionality within 12c. 

So What is Click History? 

Basically the feature relates to instrumentation that is built into the ADF framework which, when switched on, continuously reports the actions that users have taken within the UI.  This mostly relates to physical clicks on UI elements such as buttons and tabs, but it also reports scrolling events, graph draws and more.  Why is it useful?  Well the point is that it can help answer that particular question - "What did you do before you got the error?" You can see how you could leverage this in a feedback or error reporting function in a UI where the information is extracted and automatically bundled with other useful information for the Support staff to have a look at. 

Each Click History record provides information about the  component, region and view that reported the event, along with key information about the application,  the user and the DSID (Diagnostic Session ID).

Here's a screen shot from some in-application diagnostics that I've developed as an small example.  In this case the history is being dumped and read into the actual application UI.  This is something I'll cover doing in a follow up article. 

Click History Data

Enabling Click History 

As I mentioned Click History is part of the framework in 12c, however, it's not switched on for every application by default.  There will be a performance overhead for any kind of tracing like this so we want to be explicit about choosing to use it. 

In your application itself you need to make 2 small changes:

  1. Create a new web.xml context parameter with the name oracle.adf.view.faces.context.ENABLE_ADF_EXECUTION_CONTEXT_PROVIDER and set the value to true.
  2. Add an extra library reference to your /WEB-INF/ weblogic.xml file (create this if you don't have one already).  Here's the reference you need:


Assuming that you have a correctly configured Weblogic domain that has been extended with JRF this library will already be defined for you.  

So in your application, that's basically it. However, we then need to do a little work on the server to configure the server side parameters for this, specifically how much space should be devoted to the Click History buffer.  To explain, Click History has a logical circular buffer of a specified size. As the buffer fills up then new records will be written from the start again and the older records discarded. When you want to look at the history, then you have to dump this buffer, but we'll come to that later. 

Server Side Configuration of Click History 

Switching Click History On or Off

 Although individual applications enable Click History, the server also has to be told to pay attention.  This is very simple to do as it is controlled by switching a particular logger (oracle.clickhistory.EUM) to the NOTIFICATION level. This can be done from Enterprise Manager, or from the Weblogic scripting tool, WLST. Here, I'll show you how to do it from the command line using WLST, I think you can probably work out how to do it though EM yourself. 

So, with WLST running:

wlst> connect()
wlst> getLogLevel(logger='oracle.clickhistory.EUM')

The value of INCIDENT_ERROR indicates that the facility is OFF, so we can set it on with the following command:

wlst> setLogLevel(logger="oracle.clickhistory.EUM",

If you've not encountered the setLogLevel command in WLST before, just issue help('setLogLevel') from the WLST command line to view the options and what they mean. 

Viewing the Click History Buffer

Unlike a normal logging message we can't view the Click History output directly in EM, instead we need to explicitly dump the buffer to the console, or more usually a file.  As I mentioned we can also do this in code which is something I'll cover in another article. So for now, let's look at how to do that from WLST:


Again you can issue the help() command in WLST for more information about the options on executeDump(), but in this case I'm just taking the simple option of dumping the data to a file.. Inside the file you'll see the output containing all of the lines of  Click History information like this:

[2013-11-20T09:08:53.332+00:00] [AdminServer] [NOTIFICATION] [] [oracle.clickhistory.EUM] 
[tid: 120][userId: alice] [ecid: 67ea61aa-dde8-4e35-afa2-a75a24c8a820-00001769,0] 
[CLICK_COMPTYPE: oracle.adf.RichShowDetailItem] [APP: SummitProductionDeploy] 
[DSID: 0000K9ohwuNFw000jzwkno1IYTfR00000X] [CLICK_VIEWID: /index] 
[CLICK_REGIONVIEWID: /customer-task-flow-definition/Customers] [CLICK_STARTTIME: 1384938532808] 
[CLICK_RENDERTYPE: oracle.adf.rich.Item] [CLICK_TYPE: disclosure] 

 It's pretty easy to parse this by eye...

Configuring the Click History Buffer Size

 You can view the initial size of the circular buffer by issuing the following WLST command:

wlst> listLogHandlers(name="apps-clickhistory-handler")

This will return a chunk of information, including the all important buffer size. (some information omitted here for space reasons):

Handler Name: apps-clickhistory-handler
type:         oracle.core.ojdl.logging.QuickTraceHandlerFactory
useLoggingContext: true
encoding:	    UTF-8
bufferSize:	    880640
flushOnDump:	    false

To change the buffer size from the value of 880640bytes it's another WLST command:

wlst> configureLogHandler(name="apps-clickhistory-handler",

So that's the basics of Click History - enjoy. 

Wednesday Oct 09, 2013

Quick Reference for Popup Alignment

I don't know about you, but I always forget what what the various popup hints used by <af:showPopupBehavior> actually relate to in terms of look.  So to save myself time more than anything I've put together a simple visual reference to show how each hint positions the popup.

Wednesday Sep 04, 2013

Basic WebLogic Deployment Plans for your ADF Application

In my recent article Dealing with ADF_FACES-30214 I alluded to the fact that you could automate the (re)setting of web.xml parameters using a deployment plan.  This is particularly useful to ensure that all of those development-time switches are toggled off when deploying the application into a UAT or production environment.  At this stage you could head off and just research deployment plans for WebLogic in the main WebLogic server documentation.. However, I wanted to show you how easy it is to create and use a deployment plan from within JDeveloper and to embed it into a deployment profile that can be used either from the IDE or via OJDeploy  in your build system.

To help illustrate this I\ve created a simple application which echos the values of the oracle.adf.view.rich.versionString.HIDDEN and javax.faces.PROJECT_STAGE context params onto the screen using EL. This is a 12c application, however, the same approach can be taken with JDeveloper 11g as well :

So the aim here is to update those values to their production-ready settings ("true" and "Production" respectively) using a deployment plan.  For convenience, I'm going to define it as part of the project contents, although strictly speaking where you put it is up to you, you'll just need to make sure that it's not packaged up inside of your deployment  artifacts (e.g. the WAR file) as it's only needed at deploy time.

Create the file from the New Gallery: Deployment Descriptors > WebLogic Deployment Descriptor and choose plan.xml in the Create WebLogic  Deployment Descriptor wizard - Step 1, as shown here:

On the next step of the wizard you can name the new file, I've called mine dpdProductionModePlan.xml. Step through the rest of the wizard accepting the defaults. Once the wizard has run you'll find the new file in your META-INF directory.  It's not too exciting:

<?xml version = '1.0' encoding = 'US-ASCII'?>
<deployment-plan xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
                 xsi:schemaLocation="http://xmlns.oracle.com/weblogic/deployment-plan http://xmlns.oracle.com/weblogic/deployment-plan/1.0/deployment-plan.xsd"

The key task that we accomplish in a deployment plan, and the thing we actually need to do in this case, is value substitution and we can do that in a variety of deployment descriptors, including web.xml, the target here. 

Logically here's what happens.  The deployment plan defines one or more overrides for a particular descriptor (e.g. web.xml). It locates an element in the XML file using an XPath expression and replaces the target with the value of a named variable that is defined in the plan.

So let's start off with a variable definition, here's the variable that will be used to define the new value for PROJECT_STAGE


So that's easy enough. Now we need to locate what descriptor file to override and the XPath expression that will identify the XML change to make.  Before starting this you will need to look at the deployment profile for your Web project (Project Properties > Deployment > Edit the profile you are using).  Grab the name of the WAR file as defined in the profile. Here's mine for my little demo app - the WAR file is called DeploymentPlanWebapp.war:

Once we have that information we can create the override section in the plan file where we locate the correct parameter in the web.xml, and substitute in the new value:

  <module-descriptor external="false">

You can see  the <variable-assignment> section and the XPath expression within that which is locating the correct context-param element from the collection of parameters based on the param-name value. The param-value is then replaced with the contents of the variable we defined before.

Once the  plan is complete we need to tell JDeveloper (or OJDeploy) to use it (Note that we can also use the same deployment plan when uploading an EAR file from the WebLogic console or using the web logic.Deployer task) .  

To set JDeveloper up, you just need to edit your Application (EAR) deployment profile (Application > Application Properties > Deployment > Edit Your Deployment Profile), then in the general section of the deployment profile property tree you can browse for and select the plan file you've just created:

Now it's simply a matter of deploying that application using the updated profile. Here I've deployed onto my standalone 12c WebLogic installation's managed server.  For completeness I've updated the plan to also replace the value for the oracle.adf.view.rich.versionString.HIDDEN value as well as the PROJECT_STAGE:

And here's the full plan file for reference:

<?xml version = '1.0' encoding = 'US-ASCII'?>
    <module-descriptor external="false">

Of course there is more that you can do with deployment plans, now you have the basics have a read of the WebLogic documentation on the subject (12c link)

You can download the sample application that I used to illustrate this entry along with the deployment plan from the ADF EMG Samples Repository - download workspace.

Monday Sep 02, 2013

Using Teams with Hudson 3.1

I'm in the process of writing some articles on the new Team Concept feature in Hudson 3.1.0. The first of these is now available over on the HudsonCentral Blog:

This article steps you through setting up and using the new team feature from scratch.  If you are a Hudson user check it out it's a great new capability for you to exploit.

Friday Aug 30, 2013

Dealing with ADF_FACES-30214

Whilst doing some work on a separate blog entry using the demo Summit application in 12c I noticed a message repeated again and again in the WebLogic log in the console. Nothing annoys me more that constantly repeating messages that obscure the stuff I really want to see (I've wrapped the message to fit here) :

 <Warning> <oracle.adfinternal.view.faces.renderkit.rich.DocumentRenderer> 
   <ADF_FACES-30214> <The setting to enable version display will be ignored 
   because the application is running in production mode.>

Switching this message off is super easy, as we'll see, but what does it relate to?

Well, this is all to do with the following context parameter defined in your web.xml file

    <description>Whether the 'Generated by...' comment at the bottom of ADF Faces HTML pages should contain version number information.</description>

This parameter defines if the generated page output contains detailed information about the ADF version. This information is useful in development and QA evironments but is not something that you want in a production environment as it is of potential use to a Hacker. So, to see the version information we need to explicitly include this context paramter and set the value to false so as not to hide the version info.

Now in JSF 2 we have an additional factor come into play to complicate matters, which is the Project Stage (there are several articles on Project Stage that you can find with your favorite search engine, but this one covers the basics). Basically Project Stage is a way that you can define an application as being in Development, Test or Production mode and effect changes accordingly (both in the declarative sense as we have an example of here, but also in terms of code and behaviors). 

Now the problem that all this relates to, the unwanted log message, is a reflection of the fact that if the Project Stage is not explicitly defined then it's going to default to Production mode (hopefully the message begins to make sense now?) . So we kind of have two mutually exclusive settings in this app.  On one hand I'm asking for Development time version information, and on the other hand the app thinks it's in production mode. The result is this message, and, if you look at the actual source of the page in the browser you'll see this:

<!--Created by Oracle ADF (Version information hidden), 
    accessibility (mode:null, contrast:standard, size:medium), 
    skin:skyros-v1.desktop (skyros)-->

The fix?  Well I do want to see the version information so I need to tell the application that it's in Development mode, not Production mode. To do this I just have to add a Project Stage entry into web.xml:


(Note the value is capitalized "Development")  

Now when the application is re-deployed, the pesky message has gone and the page source contains oodles of version information:

<!--Created by Oracle ADF (ADF RichClient API - ABRAMS (custom: 
  / ADF RichClient Impl - ABRAMS (custom: 
  / ADF-Controller{Oracle-BuildSystem=Linux - java - 1.7.0_10-b18, 
  Oracle-Version=, Created-By=23.6-b04 (Oracle Corporation), 
  Oracle-Builder=Official Builder, Oracle-Label=JDEVADF_12., 
  Oracle-BuildTimestamp=2013-06-09 02:39:02 -0700} 
  ADF-Model{Oracle-BuildSystem=Linux - java - 1.7.0_10-b18, 
  Oracle-Version=, Created-By=23.6-b04 (Oracle Corporation), 
  Oracle-Builder=Official Builder, Oracle-Label=JDEVADF_12., 
  Oracle-BuildTimestamp=2013-06-09 01:58:04 -0700} 
  ADF-Share{Oracle-BuildSystem=Linux - java - 1.7.0_10-b18, 
  Oracle-Version=, Created-By=23.6-b04 (Oracle Corporation), 
  Oracle-Builder=Official Builder, Oracle-Label=JDEVADF_12., 
  Oracle-BuildTimestamp=2013-06-09 12:47:43 -0700}  / powered by JavaServer Faces -, 
  accessibility (mode:null, contrast:standard, size:medium), skin:skyros-v1.desktop (skyros)--> 

Next time I show how you can use a WebLogic Deployment Plan to update the Project Stage as you deploy your application 

Tuesday Jul 30, 2013

(Adventures in) ADF Logging in 12c

An offline conversation with Andrejus Baranovskis the other day alerted me to a difference in behavior with the ADF Logger in 12.1.2. It seems that the logging output is not being output to the console as it was in 11g, although it's certainly being written to the log file OK.

I did a little testing and digging on this, and the issue it turns out is pretty simple.

The root cause is in the default definition of the console hander in the logging.xml file. In 11g, this handler is configured to let everything through level="ALL".  In 12c the default configuration is only to pass more significant issues through to the console level="WARNING:32".  The reason for this change is, I'm guessing to reduce the amount of general noise that you see when WebLogic is started. 

So it's trivial to switch back to the verboseness of 11g if you'd like to:

  1. From the console choose Actions --> Configure Oracle Diagnostic Logging to open the logging.xml view
  2. Switch to source view and locate the <log_handler name='console-handler' ... entry
  3. Change the WARNING:32 value to ALL

If you are feeling more creative, and want the best of both worlds, you can of course define a second handler for the console with this more permissive value and assign that explicitly to just your loggers - then you can get the verbose output for your logging without everything else.  

For example;

1. Define a custom handler 

<log_handler name='demo-console-handler' 

2. Use the custom handler for your root logger:

<logger name="oracle.demo" level="FINEST" useParentHandlers='false'>
  <handler name='odl-handler'/>
  <handler name='wls-domain'/>
  <handler name='demo-console-handler'/>  


Hawaii, Yes! Duncan has been around Oracle technology way too long but occasionally has interesting things to say. He works in the Development Tools Division at Oracle, but you guessed that right? In his spare time he contributes to the Hudson CI Server Project at Eclipse
Follow DuncanMills on Twitter

Note that comments on this blog are moderated so (1) There may be a delay before it gets published (2) I reserve the right to ignore silly questions and comment spam is not tolerated - it gets deleted so don't even bother, we all have better things to do with our lives.
However, don't be put off, I want to hear what you have to say!


« June 2016