Luciano Resende wrote:
On Thu, Jun 24, 2010 at 3:18 PM, Mike Edwards
<[email protected]> wrote:
Luciano Resende wrote:
I had originally started that on JAXWSAsyncInterfaceProcessor
following the same pattern that you are describing and I think it
would be a better location for these code to reside.
Luciano,
Could you tell us more about the work that is in
JAXWSAsyncInterfaceProcessor and why it would be a better place for the code
to be placed?
Yours, Â Mike.
I started with all the introspection to filter the Async operations
from the service interfaces based on all the rules specified on the
SCA spec, and as it was based on JAX WS Client Async API, and we
already had a JAX WS module handling JAX WS specific stuff, seemed to
me as the best place to be.
Having said that, my code wasn't in use, and we were doing a simple
filter by name in various places.
Luciano,
OK, now I understand better - this is code for handling the JAX-WS Client side
asynchronous interfaces.
So far, we've worked mainly on the SCA defined server-side asynchronous interfaces, which are not
the same thing. We may well want to use what you have done for the client side work.
One question that I have for you - the JAXWSAsyncInterfaceProcessor is placed in its own separate
module. Is there a need for this? Would it not be straightforward to include it as a separate
package within the interface-java module? I say this since there is no distinction in the SCDL for
these interfaces - they all are specified in <interface.java/> elements.
Since ANY client side interface could have these async methods, we have to check ALL Java interfaces
for their presence (tedious, but unlike the server side stuff, there is no simple "trigger" like the
presence of the @asyncInvocation annotation), so I don't see the JAXWS Async methods processing as
being anything other than "mainstream".
Yours, Mike.
