A wise old hermit known only as Jesse Wilson <[EMAIL PROTECTED]> once said:
> I'm using XDoclet to generate a remote interface for > an entity EJB. One of my methods throws an EJBException > in the bean class: > > /** > * @ejb.interface-method > * view-type="both" > */ > public void setStatusValue(String status) throws EJBException > > > The XDoclet generated code shows the method as throwing > a RemoteException, but not the EJBException: > > public void setStatusValue( java.lang.String status ) > throws java.rmi.RemoteException; > > > The generated code is fine in WebLogic but JBoss complains > that the remote method's signature does not match the > corresponding method in the bean. > > Can I get XDoclet to include the EJBException (and any other > exceptions that I add) in the remote interface? Any other exceptions already should be being included in the remote interface. EJBException is a special case, as the client should never receive it - the container intercepts it, and depending on the transaction context throws a TransactionRolledBackException or RemoteException to the client instead, so the remote intf doesn't need to include the EJBException. See the chapter on Exceptions in the EJB spec (section 12.3 in the EJB 1.1 spec, haven't got the 2.0 spec to hand to check the section number). In fact, the bean class doesn't /need/ to include it either; it's a subclass of RuntimeException and therefore unchecked. In fact, section 12.2.2 in the EJB 1.1 spec even includes a note to this effect. However, some people still like to include it (I do, for one) so we strip it out again in the remote's template. If you look in the template, you'll see <XDtMethod:exceptionList append="java.rmi.RemoteException" skip="javax.ejb.EJBException"/>; If you try removing it from your bean class' methods, does JBoss stop complaining? If the difference in EJBException/RemoteException is truly what JBoss is complaining about, then I'd suggest this is a JBoss problem not XDoclet. As you've observed yourself, other app servers have no problem with it. If you really wanted it not to be stripped out, you could just create a custom template without the skip parameter and tell the subtask to use that instead. It'd be easier to just not include it in the bean class, though, IMO. Andrew. ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
