On Apr 10, 2009, at 2:45 PM, Laird Nelson wrote:
package net.foobar;
public interface SayHello {
public String sayHello();
}
// snip
package net.foobar;
import javax.ejb.Remote;
import javax.ejb.Stateless;
import javax.jws.WebService;
@Stateless(name="SayHello")
@WebService
@Remote
public class SayHelloImpl implements SayHello {
@Override
public String sayHello() {
return "Hello!";
}
}
[...]
// This test FAILS
@Test
public void testWebService() throws Exception {
final Service sayHelloService = Service.create(new URL("
http://127.0.0.1:4204/SayHelloImpl?wsdl"), null);
assertNotNull(sayHelloService);
final SayHello sayHello = sayHelloService.getPort(SayHello.class);
assertNotNull(sayHello);
assertEquals("Hello!", sayHello.sayHello());
}
This test code still attempts to use the same interface (SayHello) as
both a business remote and web service endpoint interface. The
failure looks different, but it's still the same issue at heart.
If you want to present both a web service and business remote view
(and we'll throw in business local for good measure), here is what
will work and guaranteed to be portable to any Java EE 5 compliant
implementation.
public interface SayHello {
public String sayHello();
}
@WebService
public interface SayHelloService extends SayHello {
}
@Remote
public interface SayHelloRemote extends SayHello {
}
@Local
public interface SayHelloLocal extends SayHello {
}
@Stateless(name = "SayHello")
public class SayHelloImpl implements SayHelloService,
SayHelloLocal, SayHelloRemote {
public String sayHello() {
return "Hello!";
}
}
All vendors will definitely support the above.
I personally don't see any issues with allowing users to do this:
@WebService
@Remote
@Local
public interface SayHello {
public String sayHello();
}
But as mentioned, the spec explicitly disallows combing @Local and
@Remote, and does not explicitly allow or disallow combining
@WebService with either @Remote or @Local. Our assumption was that
combining @WebService with @Remote or @Local would be disallowed for
the same reasons combining @Local and @Remote was disallowed.
Hopefully we can get this cleared up in the EJB 3.1 spec so this will
not cause portability issues as it does currently.
-David