Reflection for setting CMP Bean Attributes

[Ajay Hatkar]

In large applications/projects it is always an issue about how to pass the Values. Although is it feasible to set the attributes using reflaction and avoid normal setter getter methods, it is not recomended by EJB spec.
can anybody please suggest fesible solutions

[Pradeep bhatt]

In large applications/projects it is always an issue about how to pass the Values

Why is there a problem, I dont understand?

[Lasse Koskela]

In fact, the use of reflection is partly prohibited by the EJB specification ("The enterprise bean must not attempt to query a class to obtain information about the declared members that are not otherwise accessible to the enterprise bean because of the security rules of the Java language"). I would also like to hear what's the issue with setters and getters?
[ August 28, 2003: Message edited by: Lasse Koskela ]

[Ajay Hatkar]

An application refers a CMP bean having around 70-75 attributes. and the entity represented by the bean one of the primary entity. so the CMP is referred multiple times in application.
The nature of application is such that, may need to update the all attributes of the particular CMP. so we may need to call 70-75 setter/getter methods for each access.
If there is a change in any of attribute name or type then we may need to update the changes at multiple places where ever ther is refernce for CMP bean. ( around 70-75 get/set methods so as to access or update CMP attributes and at multiple places )
Maintenance of application becomes a tough job.

[Pradeep bhatt]

If there is a change in any of attribute name or type then we may need to update the changes at multiple places where ever ther is refernce for CMP bean.

Yes you have to do that. How will reflection solve the problem? Are you planning to read the method name from some properties file?
Lasse has already mentioned about the EJB spec restrictions. Even if allowed, Introspection does have a performance impact.
[ August 28, 2003: Message edited by: Pradeep Bhat ]

[Lasse Koskela]

This is where the Transfer Object pattern comes into play.

[Pradeep bhatt]

I am curious to know why would attribute type and name change?

[Lasse Koskela]

...and how would reflection help in the case they would change?

[Ajay Hatkar]

Scenario
There are around 50...60 CMP beans.
15..20 session beans ( Session Facades ) which are referring those CMPS.
Now even a small change at the implementation time ( data type or name of attribute ).
We need to change at multiple places. but using reflection we can write a common method which will set/get all attributes.
Even with Transfer object pattern, we need to develop as many objects as no of CMPS.

[Pradeep bhatt]

I am still not convinced.. what are going to pass to the method..list of get/set methods. Where does this list come from?

[Ajay Hatkar]

How EJB container does us for us ?
We have just tag declartions for container right ?
Container provides the implementation for us... so it uses reflection for classes we have written for bean
can we do the same with CMP Bean classes

[Pradeep bhatt]

can we do the same with CMP Bean classes

No you cannot. Why will the names /types of variable change?

[Ajay Hatkar]

In any projects which goes on for years, we may need to make some design changes. I think changing names of Columns/type/name or addition of columns in table while in development/implementation is not very unusal case.
So now in cases where CMP's are based on such tables, what other alternative is available

[Lasse Koskela]

How often do you change a field's type during the whole lifecycle? Really. You've only got a couple of types you can store into a database (mainly numbers, text and binary) anyway... I don't consider renaming to be an issue these days when IDEs support trivial refactorings such as Rename Field and Rename Method.

[Pradeep bhatt]

Yes, I completely agree with Lasse. Types and name changes are very rare.
Using intropsection will impact the performance. Why should performance pay the price?

[Ajay Hatkar]

Pradeep quote
Using intropsection will impact the performance. Why should performance pay the price?
Certainally true
EJB 2.0 Specification
The enterprise bean must not attempt to query a class to obtain information about the declared
members that are not otherwise accessible to the enterprise bean because of the security rules
of the Java language. The enterprise bean must not attempt to use the Reflection API to access
information that the security rules of the Java programming language make unavailable.
but if we have a separate utility class which obtains information about CMP attributes and sets CMP attributes, does it anyway defers away from EJB Specification

[Pradeep bhatt]

If the utility class is called from an EJB the restriction still apply.