Meta-Information on CMP virtual fields

[Philippe Maquet]

Hi everybody,
I wonder how/if a client view and/or an entity bean can get more meta-information on the virtual fields than just their type.
Type alone is not enough to validate data ! For instance, how to get :

field lengths

precision of a numeric field

the nullable flag of a field

...

I guess I missed something in the specs...
Thank you for your help.
Best,
Phil.
[ November 30, 2003: Message edited by: Philippe Maquet ]

[Philippe Maquet]

Any idea ?

[Sathya Sankar]

Hi Philippe,

Nice to see you in the BCD forum too. As far as my reading of the spec goes, nope, we cannot get any more information on the database fields. If this information is required, we got to use helper classes / BMP entity beans / Session facade patter where a stateful session bean has that information.
Ciao,
GSS

[Philippe Maquet]

Hi Sathya,
Thanks for your reply.
I would have think of some standard way to get metadata information on an entity bean, some getMetaData() home method for instance. I guess that such an extension may exist but is vendor-specific ?
The problem is that I have no real-world J2EE experience, in such a way that anything which is not covered by the specs are for me unknown, or at best just guesses.
I suppose that it would be possible for the bean provider to write such a getMetaData() home method by himself, with the help of the JDBC java.sql.DatabaseMetaData interface, and ideally in a superclass of his CMP entity beans to make that code reusable for all of them.
Would it make sense ?
Cheers,
Phil.

[Sathya Sankar]

Hi Philippe,

I would have think of some standard way to get metadata information on an entity bean, some getMetaData() home method for instance. I guess that such an extension may exist but is vendor-specific ?

Yes, any such method would be vendor-specific and the EJB code written to use that method would consequently not be portable to other EJB containers/servers.
Reason: The home interface is bound to the CMP bean only by the deployment descriptor and a class that implements the home interface is provided by the container. Since the developer can only specify the home interface and not its implementation, this method cannot be in the home interface. As you have pointed out container specific extensions might exist to specify the implementation of the home interface, but I haven't come across such a feature in Weblogic.

The problem is that I have no real-world J2EE experience, in such a way that anything which is not covered by the specs are for me unknown, or at best just guesses.

I've read your discussions on many threads and have great respect for your views. Though you might not have hands-on J2EE experience as yet, it's just a matter of time before you start rolling on this one too .

suppose that it would be possible for the bean provider to write such a getMetaData() home method by himself, with the help of the JDBC java.sql.DatabaseMetaData interface, and ideally in a superclass of his CMP entity beans to make that code reusable for all of them.

Yes, without overruling the specification, the method could be in a superclass of the CMP bean, but as stated previously no, not in the home interface.
Thanks,
GSS

[Philippe Maquet]

Hi Sathya,

I've read your discussions on many threads and have great respect for your views. Though you might not have hands-on J2EE experience as yet, it's just a matter of time before you start rolling on this one too.

Thank you for the compliment. But I feel far less comfortable on this forum than on the SCJD one !
In fact, I don't feel comfortable with the SCBCD exam in itself. I had read somewhere that SCWCD and SCBCD were easier than SCJP which I found easy. So I hoped to study SCBCD in about 2 weeks. Unfortunately, I'll need at least one more week. In comparison with SCJP, there is so many things to remember by heart ! (and I hate that ). Things are easy to remember when you can get an obvious logical answer to a "Why ?" question about them. Unfortunately, for SCBCD and SCWCD the answer to most such "Why ?" questions doesn't help much : "Because that's written in the specs.".

Phil:
suppose that it would be possible for the bean provider to write such a getMetaData() home method by himself, with the help of the JDBC java.sql.DatabaseMetaData interface, and ideally in a superclass of his CMP entity beans to make that code reusable for all of them.
Sathya:
Yes, without overruling the specification, the method could be in a superclass of the CMP bean, but as stated previously no, not in the home interface.

Why not through the home interface ? It would not be a method linked to a particular bean instance, right ? I thought of some ejbHomeGetMetaData() method, with its result possibly cached in some metaData private class variable. Did I miss something ?
Best,
Phil.

[Sathya Sankar]

Hi Philippe,

Unfortunately, for SCBCD and SCWCD the answer to most such "Why ?" questions doesn't help much : "Because that's written in the specs.".

Yes, that's right. Both SCWCD and SCBCD emphasise memorization. But it's not that bad. I completed the SCWCD recently and believe me, I have never read the JSP, Servlet specification so thoroughly earlier. In a way, these exams make our fundamentals very strong and position us better for the real-life implementations.

Why not through the home interface ? It would not be a method linked to a particular bean instance, right ? I thought of some ejbHomeGetMetaData() method, with its result possibly cached in some metaData private class variable. Did I miss something ?

Sorry if I wasn't clear. What I meant was that we could define the custom method in the home interface but then the bean will cease being portable.
Example: Here are our classes -
1. test.MyBean implements EntityBean
2. Remote interface: test.MyRemoteIntf implements EjbObject
3. Home interface: test.MyEjbHome implements EJBHome
We can specify the custom method ejbHomeGetMetaData() in MyEjbHome.
But it is the container that will provide the implementation of the home interface. And the container cannot provide the implementations of methods beyond those dictated by the spec (create, remove etc...). This means that the developer will have to provide a custom implementation of the home interface...something like test.MyEjbHomeImpl implements MyEjbHome and instruct the container to use this home interface implementation.
Now this'll be a container specific provision and if MyBean relies on this implementaion, it is not portable to a generic EJB server.
Hope it helps....
Ciao,
GSS

[Philippe Maquet]

Hi Sathya,

Example: Here are our classes -
1. test.MyBean implements EntityBean
2. Remote interface: test.MyRemoteIntf implements EjbObject
3. Home interface: test.MyEjbHome implements EJBHome
We can specify the custom method ejbHomeGetMetaData() in MyEjbHome.
But it is the container that will provide the implementation of the home interface. And the container cannot provide the implementations of methods beyond those dictated by the spec (create, remove etc...). This means that the developer will have to provide a custom implementation of the home interface...something like test.MyEjbHomeImpl implements MyEjbHome and instruct the container to use this home interface implementation.
Now this'll be a container specific provision and if MyBean relies on this implementaion, it is not portable to a generic EJB server.

Sorry but I disagree.
In test.MyEjbHome you'll have a public MyMetaData getMetaData() home business method implemented in test.MyBean in a public MyMetaData ejbHomeGetMetaData() method.
I don't see why it wouldn't be portable from one EJB server to another.
Best,
Phil.

[Sathya Sankar]

Philippe,

In test.MyEjbHome you'll have a public MyMetaData getMetaData() home business method implemented in test.MyBean in a public MyMetaData ejbHomeGetMetaData() method.

Ofcourse yes. That was silly of me . Thanks for bringing me on the right track. So this means we can define the custom getMetaData method in the home interface and implement it in the bean without breaking portability!!
Thanks again,
GSS