Product Version: NetBeans IDE Dev (Build 200710231200)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b05
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Userdir: C:\Documents and Settings\Owner\.netbeans\dev

Created attachment 51829 [details]
log file

An instance of CachedRowSetDataProvider is created with a null CachedRowSet
Need to find out how/why this happening

Correction, a CachedRowSetXImpl does not get loaded when the project opens

David, any ideas?

When the DataProviderELResolver tries to retrieve the field keys from the CachedRowSetDataProvider, there are no fieldkeys
found because this instance of CachedRowSetDataProvider was instantiated with a null CachedRowSetXImpl

It appears that the reason why the CachedRowSetXImpl is null is that there are no data sources found in the project.

Setting a breakpoint on line 352 of ProjectDataSourceTracker and watching the local variable, newValue (the data source
value), each time ModelSet fires an event, newValue always evaluates to an empty string.  

For projects where the data provider is in the Page Bean newValue gets set to the data source

I think this is a bug in insync in that a project with a data provider in the Session Bean, not the Page bean, the
SessionBean doesn't get modeled properly.

the comment desc7 was incorrect.

instead, in insync, LiveUnit instantiates the CachedRowSetDataProvider  using
sourceUnit.instantiateBean(beanClass);

After instantiating, the SLR instance of slparent is null.

Compared to the CRSDP is created in the Page bean, SLR instance is instead an instance of UIViewRoot

This still looks like an insync issue, but I won't reassign until I'm sure

Just a info. The backing bean (Page) is associated with JSF component hierarchy.
So the Source Live Root(SLR) is an instance of UIViewRoot. However, Session Bean is
not a backing bean. So it may not have UIViewRoot as SLR.  

I really don't know what is happening here. But, keep in mind there are two EL resolving
happening here

1. Resolving dataprovider itself from the component binding
   (This seems to work fine)
2. Resolving the CachedRowset binding set to the dataprovider in the SessionBean _init() method.
   (not sure if this resolving happens correctly)

Did you check if the second binding got resolved correctly?

some findings:

Scenario 1
  DnD a database table onto the page
Result: CachedRowSetXImpl5 is instantiated

Scenario 2 
  DnD a database table onto SessionBean1 in the Navigator
Result: CachedRowSetXImpl5 is not instantiated

For the scenario where the CRSDP is created in the SessionBean,  DataProviderELResolver getValue method receives a base
instance with a property, cachedRowSet that is null

Compared to CRSDP in the Page Bean, the cachedRowSet property is an instance of CachedRowSet

...

This issue is happening exactly the same reason why  http://www.netbeans.org/issues/show_bug.cgi?id=119919 is happening
which I explained in that issue.

Follow Johns steps and reproduce the issue.  After refreshing the page, CachedrowsetDataprovider fails to get the filed
keys.
- Now open the session bean and modify anything (just add some space somewhere) and save it. 
- Refresh Page1 and now the page will render correctly.
 
What happens is, insync remodels the page (as it was changed) and resets the CahedRowset to the CachedrowsetDataprovider. 

Since similar to issue #119919, the cachedrowset properties already set (during previous modeling of SessionBean), now
CahcedRowsetDataprovider behaves correctly and fieldkeys are obtained. 

Note that you can expect that similar to #119919 you could set cachedrowset to the CahcedRowsetDataprovider after
setting the properties to cachedrowset and then close and open the project (after disconnecting) would work. But it will
not. You have to modify the SessionBean for insync to remodel and reset the CahcedRowsetDataprovider. The reason is
Cachedrowset does not reset itself after the connection is modified.

This exactly the scenario what I put when John and David fixed the bug #119529. This is the comment I put

I believe John's concern is - will the "executed" flag will be correctly reset to false, 
if some programmatic change happens to the underlying cachedRowset or some user action 
happens in the designer.

For example, if in the Session Bean user re-sets the cahcedRowset "command" property,
now the fetched infomation in the CachedRowset is invalid. Dataprovider might receive 
an event that the underlying CachedRowset has changed. In that case the "executed" flag 
should be reset to false, so that next request for info will fetch the info corresponding
to the new "command".

Another scenario is, user might refresh the designer which in turn calls the CachedRowsetDataprovider.refresh().
In this case also, I think, "executed" must be reset to false, so that fresh information will be fetched from 
database in the next request.

 

 I think it's a class loading issue.  In the original order, CachedRowSet is null.
So, if there's no CachedRowSet available then it can't be executed 

It seems to me an issue in JSF or insync

As a test, I added a refresh() to the CRSDP in setCachedRowSet(...) but still get the PropertyNotFoundException

It turns out that setCachedRowSet isn't invoked at design-time

Also, when the CRSDP is used at design-time, as in getFieldKeys(...), getCachedRowSet() returns null as I explained earlier

or some reason the CRSDP is instantiated when the order of operations in SessionBean1._init() are such that the
CachedRowSet gets initialized after the rowset instead of before

        hotelRowSet.setDataSourceName("java:comp/env/jdbc/TRAVEL_ApacheDerby");
        hotelRowSet.setCommand("SELECT * FROM TRAVEL.HOTEL");
        hotelRowSet.setTableName("HOTEL");
        hotelDataProvider.setCachedRowSet((javax.sql.rowset.CachedRowSet) getValue("#{SessionBean1.hotelRowSet}"));

In this order the property binding works. 

This is the same order as when the CRSDP is created in the Page bean since the SessionBean is modeled first the order
these statements are executed in the same order.

There could still be a problem with the way the rowset is created in CachedRowSetXImpl5 ...

Another thing I noticed in the following order

hotelDataProvider.setCachedRowSet((javax.sql.rowset.CachedRowSet) getValue("#{SessionBean1.hotelRowSet}"));
hotelRowSet.setCommand("SELECT * FROM TRAVEL.HOTEL");

In the above order, setCommand() seems to call release() which in turn calls initContainer()
This resets the rowsetMetadata.
    
I'm not sure if this resets any initialization set by  setCachedRowSet() by the dataprovider.

*** Issue 119098 has been marked as a duplicate of this issue. ***

from desc 18 : "setCommand() seems to call release() which in turn calls initContainer()
This resets the rowsetMetadata."

No, doesn't seem to reset initialization.

At least at design-time, there seems to be a problem with instantiating CachedRowSetXImpl5 through
resurrectDesignBean(...) in LiveUnit, but I can't be sure - there's lots of class loading going on here.
The reason being that just prior to setCachedRowSet the bean classes get loaded.  Once inside setCachedRowSet, the
cachedRowSet passed in is null.

I'll need to ask the insync team about this

Turns out order of statements generated in SessionBean1.

In NetBeans 5.5 the order in SessionBean1._init() is

 personRowSet.setDataSourceName("java:comp/env/jdbc/TravelPack");
        personRowSet.setCommand("SELECT * FROM TRAVEL.PERSON");
        personRowSet.setTableName("PERSON");
        personDataProvider.setCachedRowSet((javax.sql.rowset.CachedRowSet)getValue("#{SessionBean1.personRowSet}"));


In 6.0 the order is
        personDataProvider.setCachedRowSet((javax.sql.rowset.CachedRowSet)getValue("#{SessionBean1.personRowSet}"));
        personRowSet.setDataSourceName("java:comp/env/jdbc/TravelPack");
        personRowSet.setCommand("SELECT * FROM TRAVEL.PERSON");
        personRowSet.setTableName("PERSON");

*** Issue 119919 has been marked as a duplicate of this issue. ***

I see two issues
1) During design time initialization of dataprovider after initializing rowset is not making any difference, the value 
binding expression resolver returns null when the project is opened. However if we force the re-modeling of sessionbean
and go back to designer, the page looks fine.
2) Runtime seems to require rowset to be initialized before initializing dataprovider

Winston and David think the ordering of property set statement should not matter. So requires more debugging and 
analysis

The run time issue has been addressed by #119919

The design time issue is due to EL expression resolution failing when it is trigerred by an evaluation of another EL 
expression where-in the first part of the expressions are same for both. 

For example: If a text field in Page1.jsp is bound to
a dataprovider in sessionbean via a VB expression like #{SessionBean1.dataprovider.VALUE['PERSON.NAME']}, while 
evaluating this expression, SessionBean1 needs to be modeled, which requires evaluation of another VB expression #
{SessionBean1.rowset}. The later evaluation returns null and therefore we get property not found exception.

Invoking the evaluation immediately after failure does give correct results. For now we are using this
workaround.

Verified the pre-integration jar on 
 NetBeans IDE Dev (Build 200710311411)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b02
System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)

Build: NetBeans IDE 6.0 RC1 (Build 200711131200)
VM: Java HotSpot(TM) Client VM, 1.6.0_03-b05
OS: Windows 2000, 5.0, x86

User Comments: 

Created attachment 53298 [details]
stacktrace

javydreamercsw, the exception you have just  reported and have appended is not the same 
as this original bug. can you open a new issue including some comments. thanks. 

Guys, please, don't hurry!
I'm testing this issue and I can't reproduce this bug on RC2 200711201000...
Give me more time...

I tried to reproduce the original scenario several times on:

Product Version: NetBeans IDE 6.0 RC2 (Build 200711201000)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b02
System: Windows XP version 5.1 running on x86

It works for me. 

Though sometimes (twice) the exception 
"java.lang.RuntimeException: CommonDDAccess.addBean unexpected exception"
appeared in the "messages.log" (see the last attached file "messages.log").
Then in the dialog "Bind to Data" the item "personDataProvider" was red 
in the DropDownList "Choose a Data Provider", but in several seconds it became black.

Created attachment 53317 [details]
messages.log