Why doesn't the name() attribute of the @Stateless annotatio

[asack]

If I have an EAR named foobar.ear and I have stateless session bean marked:

@Stateless ( name = "/somwhereelse/foobar" )
public class foobar...etc.

The JNDI binding becomes foobar/somwherelese/foobar/local which IMO seems wrong. The name() attribute should provide a mechnism to specify the global JNDI since its EJB3 primitive unlike @LocalBinding which is JBoss specific. I realize that by default the EJB3 JNDI namespace by default is "name of ear file"/* but shouldn't the name() attribute be able to override that?

Thanks!

PS Where are the specs for the annotations? I don't see any real doc in JSR-220.

[bdecoste]

If you want to explicitly specify the jndi binding, use the RemoteBinding and the LocalBinding annotations. The name attribute of Stateless sets the EJB name for the bean. Without A RemoteBinding or LocalBinding annotation, the default binding is earName/ejbName.

The EJB annotations are in the spec. The JBoss specific annotations like RemoteBinding are not.

[asack]

"bdecoste" wrote:
If you want to explicitly specify the jndi binding, use the RemoteBinding and the LocalBinding annotations. The name attribute of Stateless sets the EJB name for the bean. Without A RemoteBinding or LocalBinding annotation, the default binding is earName/ejbName.

The EJB annotations are in the spec. The JBoss specific annotations like RemoteBinding are not.

I think there should be a JNDI attribute for the EJB3 beans that is generic. Glassfish apparently (after looking at their JavaDoc) uses a mappedName attribute in their Stateless annotation. Already we have a discreptancy across J2EE EJB3 implementations. I think JNDI binding is so fundamental to a J2EE bean writer it should be standardized across app server implementations.

[bdecoste]

jndi bindings are not standardized in the spec, so each vendor will likely have their own policy.

[asack]

"bdecoste" wrote:
jndi bindings are not standardized in the spec, so each vendor will likely have their own policy.

With all due respect to the EJB3 group which I think have done a fantastic job of making EJBs more accessible, little things like this should not go unnoticed.

Why is it architecturally wrong to standardize jndi bindings? Btw, from the spec I first got the impression that everything was going to be under java:comp/ejb3 or something like that to begin with. The reason why I believe an EJB3 developer should have control over this is to make one's code portable across app server environments. Having to deal with the fact that JBoss puts them here and Glassfish puts them there and BEA puts them somewhere else sucks! :-)!

The EJB3 annotations are in spec but they seem to not be organized other than in the Persistence document unless my copy is out of date. What I have just discovered (big doi) is using the source/javadoc to lookup annotation definitions which seems to give me a one stop shop for all annotations (whether they be EJB3 spec or JBoss specific).

One last vent, the lifecycle callback @PreDestory should be honored by @Stateless beans. As Bill I think pointed out, @Stateless beans never get destroyed and on undeployment @PreDestory never gets called. Maybe my understanding of the spec is wrong, but the above behavior doesn't seem to be correct and/or compliant with the spec.

[gavin.king]

I totally agree that this ENC/global JNDI stuff needs to be standardized in the next rev of the spec. In fact, there are MANY non-persistence-related items that we had on our wishlist that we simply ran out of time to do in this release.

[asack]

I totally agree that this ENC/global JNDI stuff needs to be standardized in the next rev of the spec. In fact, there are MANY non-persistence-related items that we had on our wishlist that we simply ran out of time to do in this release.

Yea!

I have another question since I have some people reading this thread. This may not be EJB3 specific but J2EE 5.

What I would also really like to see is a @Main annotation over a class that defines some known function (like public void main()) under an EAR deployment. What this would do is after the EAR is deployed and all EJB3's and WAR's are deployed, this function would be called. I don't understand why under an EAR that all flow control seems to be initiated from the web tier. This seems very limited. Maybe there is a way to do this that is NOT app server specific but I haven't come across it (please let me know if there is a way to do this!!!).

Even though the app server provides IoC, I should still be able to kick start my stuff from within the deployment and not rely on an external entity.

Maybe I'm way off or no one would find this useful other than me!! :-)!

[elkner]

How about @Service + @Management and putting the "init my app" stuff into the start() method (having that in the spec would be really cool)?

OK, there is still the permission issue wrt. @RunAs, but AFAIK it is already fixed in CVS (but not in CR2 :-(()...

[asack]

"elkner" wrote:
How about @Service + @Management and putting the "init my app" stuff into the start() method (having that in the spec would be really cool)?

OK, there is still the permission issue wrt. @RunAs, but AFAIK it is already fixed in CVS (but not in CR2 :-(()...

Sure but its JBoss specific. EAR lifecycle management and a @Main notion should be a fundamental aspect of the J2EE standard IMO.

Oh, the notion of @Depends too should also be part of the base spec and not a value add-on. There should be annotation or deployment descriptor based ways to standardize dependencies across deployments and beans.

[starksm64]

Send comments to: [e-mail], [e-mail]

[asack]

[e-mail]

Scott, is that a serious suggestion or a "stop whining, call the phone company" type answer? :-)!

Well at least EAR/lib is going to exist in J2EE 5 (that's a no brainer).

[starksm64]

"asack" wrote:


Scott, is that a serious suggestion or a "stop whining, call the phone company" type answer? :-)!

Well at least EAR/lib is going to exist in J2EE 5 (that's a no brainer).

Serious if you care about getting non-portable behavior standardized.