JDeveloper 11gR1 Bug in Tuning Node of ViewObject

Today I came across a bug in the tuning node of ViewObjects in JDeveloper 11gR1 (meaning all 11.1.1.x versions). For a prove of concept I played with the tuning options available for ViewObjectes in JDeveloper. The following image shows the the default tuning node of a ViewObject (it doesn’t matter if it’s based on an EntiyObject or not):

Default Tuning Node

Default Tuning Node

As I tested some options I eventually switched to the ‘Only up to row number’ radio button which enables the input field for the number of rows:

Tuning for '...up to row number'

Tuning for ‘…up to row number’

Nothing special there. Now if you delete the number (default is 10)

Delete Number from Field

Delete Number from Field

and ‘tab’ out of the input field, or click on any other field, you get an error dialog telling you that ‘(null) is not a valid fetch size value’.

Error Dialog

Error Dialog

OK, this is correct, but if you hit the OK button or the ‘x’ to close the dialog to put the number back in the dialog stays open, you can’t close it. You don’t get a chance to put the number back into the field. A first I had to kill JDeveloper through the task manager (I did that a couple of times ;)) until I found the following workaround:
            hit the Esc key
you may need to do this multiple times, but the dialog closes eventually and the last number is back in the input field.

This bug is fixed in the current JDeveloper 11gR2 (11.1.2.3.0) version!

Advertisements

JDeveloper & ADF: Carefully Select the Data Control Scope of Bounded Task Flows

A customer asked me to look into an error which showed up in one of their applications. Without going into the details of real use case I like to bring this issue to your attention as it might happen to you too.

Use Case
I set up a mock use case to show the problem as this: A page (.jspx or .jsf) includes one (or more) other task flows as a region. The base page retrieves some data using a method call exposed in the data control, which should be displayed in the region for information purpose.

Implementation
If the task flows share their data controls this is not a big deal to implement this. You can download the sample using the link provided at the end of this blog. The sample uses the HR schema and was build using JDev 11.1.1.5.0 and was additional tested with JDev 11.1.1.1.6.0 and JDev 11.1.2.2.0, which show the same behavior.

On the base page I set up an inputText which I use to pass a parameter to the method (callMeTest) which retrieves some info from the application module. The callMeTest method simply returns the passed parameter together with a ‘nice’ message:

    public String callMeTest(String name) {
        _logger.info("Called with: "+name);
        return "Call me Test "+name;
    }

The return value is then displayed on the base page at the bottom under the button and should be displayed in the region, under the table, too. The sample just uses one region. When no value is present ‘****’ is used as parameter. The image below shows the application after starting it.

Start Screen

Start Screen

After entering a value into the inputText field below the table and hitting the ‘callMeTest’ button underneath it, you see that the return value is displayed below the button on the base page and under the table inside the region. If the button is hit with another value, both values are updated.

After entering a value and hitting the button

After entering a value and hitting the button

Nothing unusual so far. Now, for some unknown reason, after a change to another part the application, that functionality did not work any longer. The value in the base page still updates after the call to the method, but the value in the region stopped updating.

Screen after next deployment

Screen after next deployment

The reason for this behavior is a simple one. A look into the task flow properties of the region, revealed that the checkmark for the ‘Share data controls with calling task flow’ was not set, meaning that the task flow get its own data control frame. The result is that the method outcome from the base page is not visible in the region.

TaskFlow properties (1)

TaskFlow properties (1)

The question was how did this happen, when the change which results in the new deployment had nothing to do with this part of the application?

Analysis
It turned out, that when you create a new bounded task flow this property value is set to ‘default’. This is shown in the ‘Overview’ of the task flow as bluish shade in the check box. No checkmark is set and a look into the source reveals that the whole section

    <data-control-scope>
      <....../>
    </data-control-scope>

is just missing from the XML file.

TaskFlow after creation

TaskFlow after creation

Once you click on this property in the property editor you can just switch between ‘isolated’ or ‘shared’.

TaskFlow properties (2)

TaskFlow properties (2)

The only possible way to get the bluish shade back is to delete the section in the source view of the task flow.

TaskFlow properties in 'Source Mode'

TaskFlow properties in ‘Source Mode’

So this checkbox has three states ‘bluish’, ‘isolated’, and ‘shared’. Well, there is a forth state which you get if you open the property editor in source mode and select ‘default’. The following table shown all states together with their meaning:

State  Meaning
Bluish  Shared
Check marked  Shared
Unchecked not bluish  Isolated
Data-control-scope empty  Isolated

While the application works according to the meaning of the flag, I find it not intuitive how JDev handles this setting. The programmer who made the change to the application clicked this property, but meant to do so on a different task flow. So he unchecked the ‘Share data controls with calling task flow’ property as he remembered that it was not set before.

Recommendation
My advise is to set the flag whenever you create a task flow so you know which share mode the task flow uses. This avoids errors like the one described in this blog.

UPDATE
In the meantime Chris Muir raised the issue with the UX specialists (Oracle intern) and Bug 14390576 has been raised for this issue.
Thank you Chris!

The sample uses the HR schema and was build with JDeveloper 11.1.1.5.0, tested with 11.1.1.6.0 and 11.1.2.2.0 . You can download the sample work space form ADF Samples: Source Code

JDev 11.1.2.1.0: Dealing with ADF_FACES-60003 Error: Component with ID: r1:1:cb1 not registered for Active Data.

The last couple of weeks I saw some questions on OTN JDev forum dealing with file and image handling in ADF applications. All of the needed information to do this is already published in various blog posts and tutorials, still I did not find a post covering all aspects with a single demo application.

I’m in the progress of writing a mini series about file handling (upload and download) and image handling in ADF applications providing exactly this demo application. If you are interested in this stay tuned, as the first part is almost ready to publish.

Now, while I assembled the demo application I stumbled upon this error:

java.lang.IllegalStateException: ADF_FACES-60003:Component with ID: r1:1:cb1 not registered for Active Data.
	at oracle.adfinternal.view.faces.activedata.PageDataUpdateManager.unregisterComponent(PageDataUpdateManager.java:600)
	at oracle.adfinternal.view.faces.context.RichPhaseListener.handleStartAndStopActiveData(RichPhaseListener.java:502)
	at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl._executePhase(LifecycleImpl.java:479)
	at oracle.adfinternal.view.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:204)
	at javax.faces.webapp.FacesServlet.service(FacesServlet.java:312)
	at weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
	at weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
	at weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
	at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.adf.model.servlet.ADFBindingFilter.doFilter(ADFBindingFilter.java:173)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.adfinternal.view.faces.webapp.rich.RegistrationFilter.doFilter(RegistrationFilter.java:122)
	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:468)
	at oracle.adfinternal.view.faces.activedata.AdsFilter.doFilter(AdsFilter.java:60)
	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl$FilterListChain.doFilter(TrinidadFilterImpl.java:468)
	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:293)
	at org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl.doFilter(TrinidadFilterImpl.java:199)
	at org.apache.myfaces.trinidad.webapp.TrinidadFilter.doFilter(TrinidadFilter.java:92)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at weblogic.servlet.utils.FastSwapFilter.doFilter(FastSwapFilter.java:66)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.security.jps.ee.http.JpsAbsFilter$1.run(JpsAbsFilter.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at oracle.security.jps.util.JpsSubject.doAsPrivileged(JpsSubject.java:313)
	at oracle.security.jps.ee.util.JpsPlatformUtil.runJaasMode(JpsPlatformUtil.java:413)
	at oracle.security.jps.ee.http.JpsAbsFilter.runJaasMode(JpsAbsFilter.java:94)
	at oracle.security.jps.ee.http.JpsAbsFilter.doFilter(JpsAbsFilter.java:161)
	at oracle.security.jps.ee.http.JpsFilter.doFilter(JpsFilter.java:71)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at oracle.dms.servlet.DMSServletFilter.doFilter(DMSServletFilter.java:136)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at weblogic.servlet.internal.RequestEventsFilter.doFilter(RequestEventsFilter.java:27)
	at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.wrapRun(WebAppServletContext.java:3715)
	at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3681)
	at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321)
	at weblogic.security.service.SecurityManager.runAs(SecurityManager.java:120)
	at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2277)
	at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2183)
	at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1454)
	at weblogic.work.ExecuteThread.execute(ExecuteThread.java:209)
	at weblogic.work.ExecuteThread.run(ExecuteThread.java:178)
...

It happened when I used a af:fileDownloadActionListeneron a detail page fragment and navigated back to the master page fragment. As I never saw the error before and did not use ‘Active Data’ anywhere in my demo, I started digging.

There are some members of OTN hitting the same error (may be not under the exact same conditions) as this thread shows.
The thread points to an older post which mentions that this is caused by the bug 9218151 and is fixed in JDev 11.1.2.0.0. As I use JDev 11.1.2.1.0 this should not happen, or I see a regression of the bug in JDev 11.1.2.1.0. The bug database did not help either, as there is very little information on the bug itself.
The solution given in the thread to use a custom error handler (and ignore the error) did not seem right to me. I did not try the other solution to write a custom tag either, as it looks like overkill to me.

The normal debugging of this problem didn’t get me further to a solution. I tried a couple of things and even was able to get around the error with some hacks I will not publish here.

Luckily I met Frank Nimphius at the DOAG2011 and ask him about this bug (that’s what such events are for :)). He gave the right pointer to solve the problem.
With JDev 11.1.2.0.0 a new default ‘change event policy’ was introduced to the iterators and components. Now the policy is ‘ppr’ and not ‘none’ as before.
Jobinesh had blogged about the new ‘change event policy’ and its meaning here.

As I couldn’t reproduce this behavior in JDev 11.1.1.5.0 Franks suggestion was to set the change event policy back to none. After doing exactly this the error is gone, the application runs as expected.

The new policy can be changed (back to the old behavior) on a global level for applications you are building new under JDev 11.1.2.x. To do this open the adfc-config.xml file from the ‘Application Resources:

adfc-config.xml

adfc-config.xml

change to the ‘Overview’ tab and select the ‘Model’. Here you remove the selection from the check box:

adfc-Config.xml Change Event Policy

adfc-Config.xml Change Event Policy

If you already have done some work in your project, e.g. used some views on an UI page, you have to change the iterators one by one. For this open the bindings of the page and select an iterator:

Change Event Policy on Iterator

Change Event Policy on Iterator

You may let the default ‘change event policy’ be ‘ppr’ if you like, as there are some advantages (there must be a reason why Oracle changed it in the first place). Only if you hit the error you can change the policy for the iterators involved. Keep in mind, that changing the policy later may have some side effects to your existing pages. It’s up to you to decide and test this.

I’ll file an SR for this just to make sure that Oracle looks into this again. For me it looks like a bug as I don’t understand why I get an error at all.