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