Class pollution and the EJB spec

Jay Shaughnessy jshaughn at redhat.com
Fri May 7 16:24:53 UTC 2010


We actually used to do it the way you're suggesting until someone, can't 
remember who, suggested that we pull the remote decls out of the local 
in favor of the "implements remote" approach.  No one could remember why 
we had done it the original way but perhaps it was for JDK5 compatibility.

Of course the new approach looks much cleaner and is easier to deal 
with.  If there is any we can keep it this way it would be nice.

On 5/7/2010 7:22 AM, Heiko W.Rupp wrote:
> Hi,
>
> I see the following the following pattern being used more and more in our code
>
> @Stateless
> public class MyBean implements MyBeanLocal {
> ...
> }
>
>
> @Local
> public interface MyBeanLocal implements MyBeanRemote
> {
>     public void foo();
> ...
> }
>
> @Remote
> @Webservice
> @SomethingElse
> public interface MyBeanRemote
> {
>      @WebMethod public void foo();
> ...
> }
>
> I am currently seeing the following  issues with that: on jdk15, @Webservice, @SomethingElse need to be on the classpath of clients using MyBeanLocal for compilation.
> Actually (but I have not found an example forbidding it), I am not sure if the pattern above is portable, as the spec does not talk about
> the semantics of such inheritance of @WebService and @WebMethod (as opoosed to the inheritance of @TransactionAttribute)
>
> So I think it would be better in the future not to use this above pattern - the IDE actually allows to easily pull up a method form
> a session bean class into both interfaces if needed.
>    Heiko
>
>
>    


More information about the rhq-devel mailing list