properties of an EJB entity bean field

Thread view:

Marcus Beyer - 16 Mar 2004 16:44 GMT

Is there a standard way to determine the maximum length
(e.g. CHAR(20) or VARCHAR(50)) of a field in EJB?
Or how can I constrain user input?

thanx!
Marcus

Reply to this Message

Petros Petrou - 16 Mar 2004 21:38 GMT

Hi,

You have to edit the following file :

$JBOSS_HOME\server\default\conf\standardjbosscmp-jdbc.xml

Find the corresponding tag for the RDBMS you are using
e.g Hypersonic, mySQL etc and edit the value in the
data type mapping you want.

This is the mySQL VARCHAR type mapping. You need to change
250 to your value. Keep in mind to give an invalid value
as your deployment will propably fail. For instance mySQL
VARCHAR type cannot be more than 255.

<mapping>
<java-type>java.lang.String</java-type>
<jdbc-type>VARCHAR</jdbc-type>
<sql-type>VARCHAR(250) BINARY</sql-type>
</mapping>

Regards,

Petros
Greece

> Is there a standard way to determine the maximum length
> (e.g. CHAR(20) or VARCHAR(50)) of a field in EJB?
> Or how can I constrain user input?
>
> thanx!
> Marcus

Reply to this Message

Marcus Beyer - 17 Mar 2004 10:43 GMT

> Hi,
>
[quoted text clipped - 16 lines]
> <sql-type>VARCHAR(250) BINARY</sql-type>
> </mapping>

Thank you, but my problem is not setting these values,
but reading them -- out EJB developer sets these values
for each field individually.

Maybe I have to parse the deployment descriptor ...

Other ideas?

thanx!
Marcus

Reply to this Message

John C. Bollinger - 17 Mar 2004 17:55 GMT

> Thank you, but my problem is not setting these values,
> but reading them -- out EJB developer sets these values
> for each field individually.

The problem here is that these values are not properties of the beans,
but rather properties of the beans' mapping onto the underlying
persistent store. It is extremely difficult in the general case for the
bean to expose these, as the details and foibles of the persistent store
will vary with the store itself. EJB is supposed to _insulate_ clients
from such things.

> Maybe I have to parse the deployment descriptor ...

If you choose this route (supposing you find a way to actually get your
hands on the descriptors) it is probably not the main deployment
descriptor you want but a container-specific descriptor extension. I
would not recommend pursuing this.

My actual recommendation is that the bean provider should _document_ the
required supported ranges of property values, and the application
assembler should take responsibility for setting up the mappings
correctly. Bean clients should then behave per the documentation.

You could provide for client-side validation by putting per-property
validation methods on the beans' home interfaces (or by other similar
means) if that is necessary. If you use BMP then the bean provider
could encode server-side validation into the property setter methods.
These techniques still depend on correct instructions in the deployment
descriptor and ancillary descriptors.

John Bollinger
jobollin@indiana.edu

Reply to this Message

Marcus Beyer - 23 Mar 2004 11:30 GMT

Hello John,

thank you for your thoughts on the matter!

>> Thank you, but my problem is not setting these values,
>> but reading them -- out EJB developer sets these values
[quoted text clipped - 6 lines]
> will vary with the store itself. EJB is supposed to _insulate_ clients
> from such things.

So at the end a database needs only one datatype: blob? hmmm ...

>> Maybe I have to parse the deployment descriptor ...
>
> If you choose this route (supposing you find a way to actually get your
> hands on the descriptors) it is probably not the main deployment
> descriptor you want but a container-specific descriptor extension.

I did so and with dom4j <http://dom4j.org/> it was quite easy.
I added the code at the end of this message.

> I would not recommend pursuing this.
> My actual recommendation is that the bean provider should _document_ the
> required supported ranges of property values, and the application
> assembler should take responsibility for setting up the mappings
> correctly. Bean clients should then behave per the documentation.

I prefer that my GUI behaves correctly without all this trouble.
So *I* want to be insulated from such things.
Also I don't like the idea of having the same information set twice.

> You could provide for client-side validation by putting per-property
> validation methods on the beans' home interfaces (or by other similar
> means) if that is necessary.

IMHO validation is best when the user *can't* insert invalid imput.
The GUI won't display it when it's invalid. When the sql-type is
int4, and you type in 'p' then nothing is inserted, if you paste in
'123456789' then '1234' is inserted, etc. -- without my intervention.

thanx!
Marcus

import java.io.IOException;
import java.io.InputStream;
import java.util.Iterator;
import java.util.List;
import org.dom4j.Document;
import org.dom4j.Element;
import org.dom4j.io.SAXReader;

public class EntityInfo
{

public static void showEntityInfo(Class classInEJBJar)
{
InputStream is = null;
try
{
is = classInEJBJar.getResourceAsStream("/META-INF/jbosscmp-jdbc.xml");
SAXReader reader = new SAXReader();
Document doc = reader.read(is);
List entities = doc.selectNodes("//enterprise-beans/entity");
System.out.println("entities found: " + entities.size());
for (Iterator iter = entities.iterator(); iter.hasNext();)
{
Element entityElement = (Element) iter.next();
Element entityName = entityElement.element("ejb-name");
System.out.println(entityName.getTextTrim());
List cmpFields = entityElement.elements("cmp-field");
for (Iterator iterator = cmpFields.iterator(); iterator.hasNext();)
{
Element cmpFieldElement = (Element) iterator.next();
Element fieldNameElement = cmpFieldElement.element("field-name");
Element sqlTypeElement = cmpFieldElement.element("sql-type");
String sqlType = sqlTypeElement == null ? null :
sqlTypeElement.getTextTrim();
Field field = new Field(fieldNameElement.getTextTrim(), sqlType);
if (sqlTypeElement != null)
{
System.out.print(" " + fieldNameElement.getTextTrim());
System.out.print(": " + sqlTypeElement.getTextTrim());
System.out.println();
}
}
}
}
catch (Exception e)
{
/*
* this way other projects don't have to know about dom4j Exceptions
*/
throw new RuntimeException(e);
}
finally
{
if (is != null)
{
try
{
is.close();
}
catch (IOException e)
{
}
}
}
}

}

Reply to this Message

Petros Petrou - 18 Mar 2004 15:19 GMT

I now see what you want to do. I thought you want to set these values
sorry.

I thought that you cant specify custom size for each field individually
but the file you need is jbosscmp-jdbc.xml propably. Its the META-INF
folder of the bean jar. John seems to know more about the issue.

Keep in mind that if you accidentaly change this file JBoss will
redeploy the bean.

Do you know how can you set the values for each field individually
by the way?? I didnt know you can do this.

Petros

>> Hi,
>>
[quoted text clipped - 27 lines]
> thanx!
> Marcus

Reply to this Message

Marcus Beyer - 23 Mar 2004 11:35 GMT

> I now see what you want to do. I thought you want to set these values
> sorry.

> I thought that you cant specify custom size for each field individually
> but the file you need is jbosscmp-jdbc.xml propably. Its the META-INF
> folder of the bean jar. John seems to know more about the issue.

Yes, I posted some code ...

> Keep in mind that if you accidentaly change this file JBoss will
> redeploy the bean.

I only read the file ...

> Do you know how can you set the values for each field individually
> by the way?? I didnt know you can do this.

/**
* @ejb.interface-method
* @ejb.persistence
*     column-name="FirstName"
*      jdbc-type="CHAR"
*      sql-type = "CHAR(100)"
*/
public abstract String getFirstName();

Marcus

Reply to this Message

properties of an EJB entity bean field

Free Magazines