Problem with interfaces
-----------------------
Key: JBAS-1605
URL: http://jira.jboss.com/jira/browse/JBAS-1605
Project: JBoss Application Server
Type: Bug
Components: EJBs
Versions: JBossAS-3.2.5 Final
Environment: Linux Mandrake 10.1. Server: Compaq Proliant LM570 (If I'm not
wrong)
Reporter: Edmundo Antoranz
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 :D. 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!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.jboss.com/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
JBoss-Development mailing list
JBoss-Development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jboss-development
