Bobby Bissett wrote:
>>
>> I wonder if the harness can scan all the server source files, look for
>> handlers (they extend from a known classes, right?), then generate
>> necessary pieces.
>
> But there's nothing in the handler code that says how/where it's used.
> The same handler could be used multiple times in more than one handler
> list for the same service (e.g., in different ports, or in a list
> depending on what binding is being used, etc.). It's really the xml
> descriptor that we need to do this. In the fromjava case, it could be
> simple at least since the service impl class will have an annotation
> pointing to the file.
OK. I'm hoping that not many tests will use it, so I think we should
just let test data include this file.
The trade-off is if the benefit of short-hand outweighs the cost of
inventing a new syntax (more importantly, the cost of learning this new
syntax), and it looks like the short-hand wouldn't save too much.
If so, I think it's OK to just include this handler file verbatim in
test data.
I suspect such a handler file, if present, needs to be discoverable from
the descriptor (especially if it needs to be given as an input to
wscompile.)
Is this one per endpoint? Or is this one per service? Is this something
the harness can find by using a convention, or does it something the
user need to write to test descriptor?
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com