Problem with interfaces

Maybe this is not exactly one JBoss AS bug per se. Let's see what you think.

I'm a newcomer to EJBs. I've been working them for little time so far. But I crashed into a Java Language veeeeeeeeery interesting problem related to EJBs interfaces. I have been doing a little experimentation working around the problem and wanted to provide you with my results. This is the situation:

I personally like to define EJBs business logic method definitions in a separate interface from Remote and Local interfaces. Say something like this:

[code]
public interface BeanInterface {
public void aMethod() throws RemoteException;
}
[/code]

I then create the Remote and Local interfaces:
[code]
public interface Bean extends BeanInterface, EJBObject {}

public interface BeanLocal extends BeanInterface, EJBLocalObject {
puiblic void aMethod();
[/code]

I override the method so it doesn't throw Remote Exception (to comply with EJB specificacion. Otherwise JBoss would complain ).

No problem so far. Now.... I want to extend this interface to make a new bean:
[code]
public interface NewBeanInterface extends BeanInterface {
public void anotherMethod() throws RemoteException;
}
[/code]

Piece of cake.

Let's make the remote interface:
[code]
public void NewBean extends NewBeaninterface, EJBObject {}
[/code]

That's ok.... however, this is when it get's tricky. Let's make the local interface:
[code]
public interface NewBeanLocal extends extends EJBLocalObject, NewBeanInterface {
public void anotherMethod();
}
[/code]

Before you start yelling at me: I know that this is simply not enough, because I know that there is a method that hasn't been overriden (BeanInterface.aMethod()) and therefore is still throwing RemopteException. IO got that. That leads me into having to override EVERY METHOD defined in my common interface's superinterfaces. That's definitely not an option, right?

So I noticed that i could use the "superbean" locel interface to "override" the exceptions... just like with classes: you can't throw one exception in an overriding method if the overriden method can't throw it... Am I clever?. Say:

[code]
public interface NewBeanLocal extends extends EJBLocalObject, NewBeanInterface, BeanLocal {
public void anotherMethod();
}
[/code]

Let's compare the signatures of aMethod() involved:

BeanLocal.aMethod()
NewBeanInterface.aMethod() throws RemoteException (as a matter of fact, it should be BeanInterface.aMethod() throws RemoteException)

My "logic" is fairly simple, If I'm putting them together, the only way to merge them is that the result signature doesn't throw RemoteException. I deployed... and guess what? JBoss complained because my Local Interface is throwing RemoteException in its method definitions. But as I have explained, I DON'T.... well I thought I didn't . So I started to dig around this problem a little further and after checking the resulting interface with Reflection, I noticed that Java is actually NOT merging the method signatures in a single signature (that wouldn't throw RemoteException) but keeping both signatures in the interface.

I mean, If I checked it with reflection, I would find two methods with the same signature... only that one of them throws RemoteException. See what I mean? I'm a master at making simple things look complicated. I expect not to be doing so this time.

This has led me to think of JBoss.

I know that JBoss analizes the Local interface with reflection... and that's where the problem comes from. JBoss takes a look at the interface, checks all the method definitions and finds RemoteException on some of them... therefore, it start winining . I think JBoss could "meditate" about both method definitions and realize that the class that implements the Local Interface won't be able to throw RemoteException after all. So... is it a bug?

I guess that's all I wanted to say. Perhaps you will say: Well.... sure.... we noticed that when we wrote the first line of code of JBoss AS ... and it's meant to be that way. Maybe I'm right and it's a bug. Not sure yet. Would appreciate your feed back on this subject (be it a bug or my mistake).

Thanks for taking the time to read this. Greetings!