Control not being initialized when Inheriting from a parent page flow with a package protected control

• Key: BEEHIVE-1060
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Julie Zhuo
• Reporter: Carlin Rogers
• Component/s: NetUI
• Affects Version/s: 1.0.1
• Fix Version/s: 1.0.2

Description

When a page flow in another package inherits from a parent page flow that contains a package protected @Control member variable, the control is not initialized correctly. When the page flow call a method inherited from the parent and the method uses the package protected control, an NPE will be thrown as the control will not be initialized.

The work around is to make the control field protected rather than package protected.

To reproduce create a page flow with a package protected control. Include a method in the parent page flow that uses the control. Then, create a second page flow controller class in another package that extends the parent and calls the inherited method that hits the control. I will attach a zip file that will contain page flows to repro this issue. It can also be used to test the fix.

The problem seems to occur when JavaControlUtils.initJavaControls() is called and checks for the set of annotated control fields for the inherited page flow controller class. The routine, JavaControlUtils.getAccessibleControlFieldAnnotations() checks the fields of the page flow controller and its ancestors to see if they match any of the fields found in our generated annotation XML file. However, there will not be an <annotated-element> in the processed annotations file of the derived page flow for the package protected control in the parent page flow.

I'm not sure yet whether the NetUI annotation processor should generate this <annotated-element> or if the getAccessibleControlFieldAnnotations() method should be looking at the annotated fields of parent classes. We can look at this for v.next.

Comments

[Carlin Rogers]

Files for repro and test...

[Carlin Rogers]

updating the repro so that it includes the control (the control from netui tests that the original repro referenced).

[Giovanni Motta]

I had the same problem developing with BEA workshop 9.2 tools (Build id: 740482) a beehive sample web application.
In my case, it was not enough to put the protected modifier to field level.
I got
org.apache.beehive.netui.pageflow.ControlFieldInitializationException

Caused by:

java.lang.ClassNotFoundException: operazione1.Operazione1ControllerClientInitializer

That means, in my sample, the ClientInitializer class for the subclass is not created.

The workaround i adopted was to put a 'fake' java control in the subclass, so the ClientInitializer class was generated, and then everything worked fine (also the control inherited from base class was initialized successfully, no more NPE).

[Carlin Rogers]

This is fixed with svn revision 422549
http://svn.apache.org/viewvc?rev=422549&view=rev

The change includes generating the appropriate ClientInitializer as well making sure the NetUI JavaControlUtils.getAccessibleControlFieldAnnotations() method also checks for private control field(s) of a super class.

With the revision, I added a new test to the NetUI BVT to cover this scenario.

[Russ Baker]

I verified that that no exceptions are thrown when the page flow is sub-classed. I verified using Carlin's repro ( j1060-repro-updated.zip ) against SVN 549584. I recommend that this bug be closed.

[Julie Zhuo]

Based on Russ' verification, close this out.