Guy Rouillier wrote:
> Okay, your "two reasons" make sense to me why it would not be a good idea to
> have the EJB implement its remote interface. I just tried deploy an EJB
> which had a method in the remote interface that I didn't define in the bean.
> Everything compiled and jar'd okay, but when I tried to deploy JBoss told me
> a method was missing (and it told me which one - very nice!) I think it
> would be much better to have such errors caught at build time, instead of at
> deploy time. I've only used one other EJB container (Oracle) and deploying
> with that container was a real nuisance. In general, it's always best to
> catch errors as early in the process as possible. Perhaps I should submit a
> recommendation to Sun that either javac or jar take a -EJB flag, which would
> inform it to check to make sure that all required methods are implemented.
One pattern that some people advocate is to create a separate interface
that only has the business methods in it, and does not extend EJBObject.
The true remote interface extends this 'Operations' interface and the
Bean implementation implements it. This gives you signature and method
checking at compile time. One problem is that developer tools like
JBuilder aren't savvy about this and may put new operations in the wrong
place, if you use the EJB automation tools.
danch
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
