No, it's not a mistake. For example, with @WebService, if you don't set the serviceName, it will default to an empty String. This is how the annotation was designed. If it was not designed that way, you would have to set the serviceName explicitly yourself. From there, the container looks at the serviceName and will set its own default value if the serviceName is an empty String.
does this mean, that EJB's that use defaults of such annotations have restricted portability ?
For, if the @WebService example is deployed on another app server, possibly a new serviceName is defined by the new app server. So one has to adjust the client that accesses the service to the new name. Alternatively one has to change the EJB through setting the serviceName element on the old name given by the former app server.
Particulary interesting is @Table(name): Here the API says
Defaults to the entity name. Default: ""
That's quite confusing. [ November 14, 2008: Message edited by: Ralph Jaus ]
I think you are confusing what the Java API does, and what the container does. For annotations, you can set a default value for each variable. If you don't, the variable becomes mandatory, so the user of the annotation must set its value. Not very user friendly, isn't it ? So many annotations' variables use a default value. Like @Table's name. You don't need to set its value, because it defaults to an empty String (in the Java API world). That's convenient. Now, what about the container ? He sees an @Table annotation with a name whose value is an empty String ? What does it do ? It defaults the name to the entity name. So ? The user is happy, because he doesn't have to set the table name for every entity around.
To summarize, @Table(name) default to "" in the Java API world (J2EE). But it then defaults to the entity name in the Java Peristence API world (a layer above).
Joined: Apr 27, 2008
now it's clear. Thank you very much for the explanation.