[jbossws-dev] JSR181 Changes added in async changes

Jason T. Greene jason.greene at jboss.com
Fri Nov 17 08:33:09 EST 2006


This relates one of the big complaints (which was ignored) I had with
the JAX-WS spec before it was released. (Bill raised it as part of the
Java EE spec and EJB3 specs). The behavior Heiko implemented is actually
inline with the rest of EJB3 (@Remote, @Local). 

The current spec behavior for @WebService is clumsy, and error prone.

The spec requires you to specify endpointInterface using a string! So a
simple refactor moving the interface would break the WS deployment.
Also, it's normal java practice to actually implement the interface. So
the information for which interface to use is right there, in the
implements line. Further, if someone doesn't specify endpointInterface
by accident, and yet they do implement the endpointInterface, then it
will be ignored but the deployment will still work (since the bean class
is used). However, this will be confusing to the user, because they will
potentially get different output since all of the specialized
annotations are on the interface.

So even though I agree that this is how it SHOULD have been implemented,
it's just not that way in the spec, so if we add the interface search,
we still have to keep the spec behavior. The combination of the two
creates situations (although odd ones) that would fail on our stack but
work on others.

For example:

@WebService
@HandlerChain(file = "server-handlers.xml")
public class FooImpl implements Foo {}

@WebService
@HandlerChain(file = "client-handlers.xml")
public class Foo
{}

In this peculiar case, we have 2 definitions, the server side, and the
client side. They must be different because they specify different
handlers, thus endpointInterface is not specified. However, to ensure
consistency the server side implements the client side. It can however
be fixed on our stack by removing the implements line.

So the question is it worth it to add this behavior, which would only
work on our stack? Perhaps the better solution is to push it on a
maintenance release of the spec.

-Jason

> -----Original Message-----
> From: Thomas Diesler [mailto:thomas.diesler at redhat.com]
> Sent: Friday, November 17, 2006 2:17 AM
> To: Jason T. Greene
> Cc: Heiko Braun; jbossws-dev at lists.jboss.org
> Subject: Re: [jbossws-dev] JSR181 Changes added in async changes
> 
> 
> IMO this is fuzzy logic and should be avoided.
> There should at least be a comment that states the compelling reason
to
> do this guess-work.
> 
> Jason T. Greene wrote:
> > Heiko,
> >
> > I noticed the following change, which adds some non spec compliant
> > behavior. I am not against it, but we probably should all discuss
this
> > further before we decide to do it. Do you have anything right now
that
> > depends on it?
> >
> > Also, it breaks the JSR181HandlerTestCase (although I will change
the
> > test in the mean time)
> >
> >           if (anWebService.endpointInterface().length() > 0)
> >           {
> >              seiName = anWebService.endpointInterface();
> >              seiClass = udi.classLoader.loadClass(seiName);
> >              anWebService =
> > (WebService)seiClass.getAnnotation(WebService.class);
> > +
> >              if (anWebService == null)
> >                 throw new WSException("Interface does not have a
> > @WebService annotation: " + seiName);
> >           }
> > +         else
> > +         {
> >
> > +            WebService seiAnnotation = null;
> > +
> > +            for(Class potentialSEI : sepClass.getInterfaces())
> > +            {
> > +
if(potentialSEI.isAnnotationPresent(WebService.class))
> > +               {
> > +                  seiClass = potentialSEI;
> > +                  seiName = seiClass.getName();
> > +                  seiAnnotation =
> > sepClass.getAnnotation(WebService.class);
> > +                  break;
> > +               }
> > +            }
> > +
> > +            if(seiAnnotation!=null)
> > +               anWebService = seiAnnotation;
> > +         }
> > +
> >
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> > Jason T. Greene
> > Senior Software Engineer
> > JBoss, a division of Red Hat
> > xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> >
> >
> > _______________________________________________
> > jbossws-dev mailing list
> > jbossws-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/jbossws-dev
> >
> 
> --
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> Thomas Diesler
> Web Service Lead
> JBoss, a division of Red Hat
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx





More information about the jbossws-dev mailing list