Can someone confirm/explain the following for me.
In pre EJB 2.0 days. it was required that the member fields of a CMP should be declared individually and with public access, e.g.
The deployment descriptor would list the names of these fields one by one. The container would set/get the data in them during persistence using reflection on the fields directly. The getXXX() and setXXX() methods are not only not required, they may or may not appear in the remote interface of the bean. Or I should say if a public method appeared in the bean then perhaps it HAS to be in the remote interface of the bean (I'm not sure of this but would sure like to know)
In EJB 2.0, the above requirement is not required. i.e. the container uses the getXXX(), setXXX() methods instead to access data. And so, the requirement that the individual fields be declared public is absent. The deployment descriptor / EJBQL still needs the name of the CMP fields, but those are obtained through javabean naming schemes, i.e. the bean class has getMichael()/setMichael() and field in the DD / EJBQL would be 'michael'.
Am I correct? If not, how wrong am I?
Thanks in advance
CMP entity bean fields must have accessors for their properties that are mapped to some table fields. Yes, when the container persists or loads or creates a entity bean, it uses these accessors to load/save the bean properties from/to the database. If you have getAbc and setAbc methods, the bean has the property named Abc, and these accessors must be abstract in EJB2. You then define how properties are mapped to columns in deployment descriptors.
Surely not all public methods in the EJB must be published via the remote interface. For example, if you would not like people to change the countryName of the coutry which has the ID 'A', your remote(or local) interfaces would not have the setCountryName(String) method. However you'd allow the clients to access the countryName property, so the remote/local interfaces would have a getCountryName() method. You may say that the methods in the bean class are meant to be invoked by the container, and the remote/local interfaces are meant to be invoked by the clients. Of course the container will have to generate some classes to "build a bridge" between the container and the bean instance.
Hope this helps.
You are right of course.
Just an FYI, in WAS 3.5, if I have a public method in my bean implementation class and do not have it in the remote interface for an Entity Bean, it throws up.