Created attachment 51584 [details]
dataprovider.jar

Did this used to work before beta1?

This scenario used to work for JSF Table, Drop Down List,...
But I can't tell exactly about Text Field, Static Text,...

only 1 text field and 1 database table is needed to reproduce

5. DnD DB table "HOTEL" (window "Services") on the tree node "SessionBean1" (window "Navigator").
6. DnD JSF component Text Field on Designer.
   Right click on it and use the popup menu item "Bind to Data".
7. In the dialog "Bind to Data" 
   - choose Data Provider: hotelDataProvider (SessionBean1)
   - select Data field: HOTEL.HOTELNAME (String)
   Click OK.
8. Run project.

this worked in 5.5

Need to confirm that this is a crs data provider, not just a data provider issue

About "only 1 text field and 1 database table is needed to reproduce".
Yes, you're right.
I just wanted to emphasize difference between using of DataProvider, created by DnD, and 
DataProvider from SessionBean.

This might be a problem with dataprovider EL resolver.

This was interesting.

I created the project as mentioned in desc5 I exited IDE and restarted.
Since database connection had not been established, the Component error page opened.
Once the database started, I tried restoring the page, but this failed. 

Exceptions from the DP expression language evaluator occurred

This may be a property resolver problem

Here is another scenario

5. DnD DB table "HOTEL" (window "Services") on the tree node "SessionBean1" (window "Navigator").
6. DnD JSF component Text Field on Designer.
   Right click on it and use the popup menu item "Bind to Data".
7. In the dialog "Bind to Data" 
   - choose Data Provider: hotelDataProvider (SessionBean1)
   - select Data field: HOTEL.HOTELNAME (String)
   Click OK.
8. Exit and restart IDE  

Connection is re-established to the database
but still need to click refresh the Component Error page

After refreshing still binding fails

See attached exception

Created attachment 51618 [details]
PropertyNotFound exception that occurs at design-time when trying to restore binding

Winston,please evaluate.  I don't think it's a CachedRowSet DP bug, but if it is database related, please assign back to me

John, if the component is bound to a column and while
refreshing or restoring, if the cachedrowset does not
gives back the column as field key then EL resolver will
throw a property not found exception. 

This is certainly occurring because after the refresh, the metadata for the cachedrowset has not been fetched correctly. 

This how Dataprovider EL resolver works. 
- First it resolves the Dataprovider of the binding (in this case it is hotelDataProvider), which is resolved correctly.
- Then it asks the hotelDataProvider if it recognizes the property (in this case it is the database column HOTELNAME)
bound to the component.
- hotelDataProvider fetches the metadata and gets all the database columns and checks if HOTELNAME exists in it.
  If not found it throws the exception "Field 'HOTEL.HOTELNAME' not found in DataProvider".
- Then Dataprovider EL resolver wraps that exception and throws PropertyNotFoundException, since it can not resolve the
property part of the binding, even though it could resolve the bean part of the binding.  

John, take a look at why the meadata is not correctly fetched.
  
   
 

There might be 2 bugs here, one runtime, the other design-time, if at all related

At design-time...

in CachedRowSetDataProvider, a cachedRowSet is always null.

Earlier on, ProjectDataSourceTracker listens for ModelSet to be informed that the project has been modeled.
Once the project has been modeled PDST tries to get the data source names.

In getDSNames() once names are found they are added to a StringBuffer.
However, there is some problem with beanClass.

javax.sql.RowSet.class.isAssignableFrom(beanClass) is false when it should be true and as a result, no data sources are
found because beanClass is just an Object instead of a com.sun.sql.rowset.CachedRowSetXImpl

Here is snippet of getDSNames():

private String getDSNames( LiveUnit daUnit) {
        DesignBean[] beans = daUnit.getBeans();
        StringBuffer names = new StringBuffer();
        boolean doneFirst = false;
        for (int i = 0; i < beans.length; i++) {
            Class beanClass = beans[i].getBeanInfo().getBeanDescriptor().getBeanClass();
            //TODO: "dataSourceName" within Rowset class will always be a valid datasource.
            //TODO:  However, a "dataSourceName" could be in *any* class, we just
            // don't have a guarentee it represents a jdbc datasource from our server nav.
            // HACK - check for RowSet of if system prop rave.cached is set.
            if (javax.sql.RowSet.class.isAssignableFrom(beanClass) {
            ...
               // where the StringBuffer is populated with data source names
            }

It seems this error only occurs using Java 6

nevermind, I'm also seeing a problem on Java 5 with my local build.

However, using the latest nightly build 10231200  I cannot reproduce and it's running Java 5

I installed 10231200 nightly build, removed the databases from .netbeans-derby, started with a clean userdir
and created the project as mentioned and deployed.

Result was successful - the dropdown was bound to the rowset.

I can reproduce this issue only using the development build where I register a different Glassfish installation.

It could be that if the project is deployed to a Glassfish running on JDK 1.5 while NetBeans is running on Java 6.
This is documented in the release notes.

So, I am closing as INVALID

I forgot to mention that I did a clean install using Java 5 (so both NetBeans and Glassfish are running on Java 5)
and repeated the installation using Java 6 and in  both cases the project created and result were successful

I tested it on my windows Vista

I removed .netbeans-derby, I removed my netbeans installation, I removed the userdir, I removed the glassfish, I removed
all my JDKs

- installed JDK 1.6_03
- installed glassfisg-v2-58g
- installed latest netbeans 6 (20071028)

It *did* not work for me. The page displayed with out any data.

I was thinking, that in case of  dataprovider in the Page bean, the properties to the CachedRowset is set first.
(becuase SessionBean1 is instantiated first, so SessionBean1.init() is called first). Then the CahcedRowset is set to
the dataprovider.

In case of dataprovider  in the session bean, first the cachedrowset is set to dataprovider and then it properties are set.

If you look at the SessionBean init() method you see

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

So I wanted to arrage the code and make it look similar to dataprovider is Page Bean. So I did the following

       personRowSet.setDataSourceName("java:comp/env/jdbc/TRAVEL_ApacheDerby");
       personRowSet.setCommand("SELECT * FROM TRAVEL.PERSON");
       personRowSet.setTableName("PERSON");
       personDataProvider.setCachedRowSet((javax.sql.rowset.CachedRowSet) getValue("#{SessionBean1.personRowSet}"));
        
Guess what the data showed up at runtime!

I'm certain the problem is in CachedRowsetDataProvider. 

Note that issue http://www.netbeans.org/issues/show_bug.cgi?id=120251 is happening exactly because of the above reason,
which I have explained in that issue.

reopening based on winston's comments.

Winston is absolutely right.

I tried to reproduce the initial bug scenario (with 2 text fields) on:
Product Version: NetBeans IDE Dev (Build 200710281200)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b02
System: Windows XP version 5.1 running on x86
&
Sun Java System Application Server 9.1 (build b58g-fcs)
Java: 1.6.0_03; Java HotSpot(TM) Client VM 1.6.0_03-b02

When new data provider was created in SessionBean1, the java code in SessionBean1.java was:
        personDataProvider1.setCachedRowSet((javax.sql.rowset.CachedRowSet) getValue("#{SessionBean1.personRowSet1}"));
        personRowSet1.setDataSourceName("java:comp/env/jdbc/TRAVEL_ApacheDerby");
        personRowSet1.setCommand("SELECT * FROM TRAVEL.PERSON");
        personRowSet1.setTableName("PERSON");
and the 2nd text field didn't contain data in a web-browser - this bug is reproduced on the latest build.

When java code was changed as Winston recommended:
        personRowSet1.setDataSourceName("java:comp/env/jdbc/TRAVEL_ApacheDerby");
        personRowSet1.setCommand("SELECT * FROM TRAVEL.PERSON");
        personRowSet1.setTableName("PERSON");
        personDataProvider1.setCachedRowSet((javax.sql.rowset.CachedRowSet) getValue("#{SessionBean1.personRowSet1}"));
the 2nd text field contains data in a web-browser - in this case the bug is NOT reproduced.

tested Milestone 9 build and the fieldkeys are available at runtime so the component is displayed with the correct binding.

Seems to be a rowset problem.  Reassiging to David

steps to reproduce:

 Connect to DB Derby Travel.
 DnD DB table "HOTEL" (window "Services") on the tree node "SessionBean1" (window "Navigator").
 DnD JSF component Text Field on Designer.
   Right click on it and use the popup menu item "Bind to Data".
 In the dialog "Bind to Data" 
   - choose Data Provider: hotelDataProvider (SessionBean1)
   - select Data field: HOTEL.HOTELNAME (String)
   Click OK.
 Run project.

reassiging to myself

David offered to help create unit tests 

looks like same issue as 120251
since the order of initializing data sources in SessionBean1._init() has changed since 5.5

*** This issue has been marked as a duplicate of 120251 ***

Closed as duplicate of the bug http://www.netbeans.org/issues/show_bug.cgi?id=120251.

For this runtime issue, the CachedRowSetDataProvider is swallowing an exception.
Enabling the exception at runtime - here it is

Initializing Sun's JavaServer Faces implementation (1.2_04-b20-p03) for context '/WebApplication624'
java.sql.SQLException: execute() never called
        at com.sun.sql.rowset.CachedRowSetXImpl5.checkExecuted(CachedRowSetXImpl5.java:151)
        at com.sun.sql.rowset.CachedRowSetXImpl5.absolute(CachedRowSetXImpl5.java:2688)
        at com.sun.data.provider.impl.CachedRowSetDataProvider.absolute(CachedRowSetDataProvider.java:348)
        at com.sun.data.provider.impl.CachedRowSetDataProvider.setCursorRow(CachedRowSetDataProvider.java:393)
        at com.sun.data.provider.impl.CachedRowSetDataProvider.setCursorIndex(CachedRowSetDataProvider.java:363)
        at
com.sun.data.provider.impl.CachedRowSetDataProvider$RowSetPropertyChangeListener.propertyChange(CachedRowSetDataProvider.java:1128)
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:333)
        at java.beans.PropertyChangeSupport.firePropertyChange(PropertyChangeSupport.java:270)
        at com.sun.sql.rowset.CachedRowSetXImpl.setCommand(CachedRowSetXImpl.java:240)
        at webapplication624.SessionBean1._init(SessionBean1.java:37)
        at webapplication624.SessionBean1.init(SessionBean1.java:89)
        at com.sun.rave.web.ui.appbase.servlet.LifecycleListener.attributeAdded(LifecycleListener.java:327)
        at org.apache.catalina.session.StandardSession.setAttribute(StandardSession.java:1706)
        at org.apache.catalina.session.StandardSessionFacade.setAttribute(StandardSessionFacade.java:163)
        at com.sun.faces.context.SessionMap.put(ExternalContextImpl.java:972)
        at com.sun.faces.application.ApplicationAssociate.createAndMaybeStoreManagedBeans(ApplicationAssociate.java:540)
        at com.sun.faces.el.ManagedBeanELResolver.getValue(ManagedBeanELResolver.java:82)
        at javax.el.CompositeELResolver.getValue(CompositeELResolver.java:143)
        at com.sun.faces.el.FacesCompositeELResolver.getValue(FacesCompositeELResolver.java:64)
        at com.sun.el.parser.AstIdentifier.getValue(AstIdentifier.java:86)
        at com.sun.el.parser.AstValue.getValue(AstValue.java:127)
        at com.sun.el.ValueExpressionImpl.getValue(ValueExpressionImpl.java:206)
        at javax.faces.component.UIOutput.getValue(UIOutput.java:173)
        at com.sun.webui.jsf.component.StaticText.getValue(StaticText.java:138)
        at com.sun.webui.jsf.component.StaticText.getText(StaticText.java:490)
        at com.sun.webui.jsf.renderkit.widget.StaticTextRenderer.getProperties(StaticTextRenderer.java:88)
        at com.sun.webui.jsf.renderkit.widget.RendererBase.encodeChildren(RendererBase.java:135)
        at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
        at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
        at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
        at com.sun.webui.jsf.util.RenderingUtilities.renderComponent(RenderingUtilities.java:74)
        at com.sun.webui.jsf.renderkit.html.BodyRenderer.encodeChildren(BodyRenderer.java:226)
        at javax.faces.component.UIComponentBase.encodeChildren(UIComponentBase.java:812)
        at javax.faces.component.UIComponent.encodeAll(UIComponent.java:886)
        at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)
        at javax.faces.component.UIComponent.encodeAll(UIComponent.java:892)

There is a problem in CachedRowSetDataProvider

A fix is on the way

Checked in potential fix:

Checking in test/com/sun/data/provider/impl/CachedRowSetDataProviderTest.java;
/cvs/visualweb/dataprovider/runtime/library/test/com/sun/data/provider/impl/CachedRowSetDataProviderTest.java,v  <-- 
CachedRowSetDataProviderTest.java
new revision: 1.3; previous revision: 1.2
done
Checking in src/com/sun/data/provider/impl/CachedRowSetDataProvider.java;
/cvs/visualweb/dataprovider/runtime/library/src/com/sun/data/provider/impl/CachedRowSetDataProvider.java,v  <-- 
CachedRowSetDataProvider.java
new revision: 1.9; previous revision: 1.8
done

-Verified pre-integration jar fixes runtime in NB10291200.
-Also verified runtime after rearranging entries in the SessionBean _init: 


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

and also tested moving the personRowSet.setDataSourceName entry:

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

David checked in a fix that has been verified by Krys.
Thanks David, John and Krys

Thanks, Krys.  Can you mark the issue as verified?

Verified jar fix. See previous note.