Thanks. I started implementing this, and I'm making a progress.
I'm using XBean (that's what you mean by "XSD-based configuration-files
in Spring 2.0", right?) for the syntax, so I don't have to use ugly
generic syntax.
This is the current example:
> <beans
> xmlns:ws= "http://jax-ws.dev.java.net/spring/core"
> xmlns:wss="http://jax-ws.dev.java.net/spring/servlet">
>
> <wss:bindings id="jax-ws.http">
> <wss:bindings>
> <wss:binding url="/add" service="#addService" />
> <wss:binding url="/sub" service="#addService" />
> </wss:bindings>
> </wss:bindings>
>
> <!-- simplest definition only needs @id and @impl -->
> <ws:service id="addService" impl="foo.MyService" handlers="#myHandler"/>
>
> <bean id="myHandler" class="foo.MyHandler" />
>
> </beans>
Am I on the right track so far?
dumpshock wrote:
> On 11/20/06, Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_sun.com> wrote:
>> dumpshock wrote:
>> > Hi Mr. Kawaguchi!
>> >
>> > Yes, you are right, I implemented the spring-integration based on
>> > InstanceResolver and InstanceResolverAnnotation. I followed the
>> > example you commited on jax-ws-commons.dev.java.net.
>> > The only thing I had to change was to remove the
>> > WebServiceFeatureAnnotation from my @SpringConfigured-Annotation since
>> > this will fail with any implementation of
>> > com.sun.xml.ws.binding.WebServiceFeatureList newer than 1.1.2.2
>> > because there was introduced some Exception for unknown
>> > WebServiceFeatureAnnotations.
>>
>> I lost some of details, but I guess the WebServiceFeature bean is not
>> too important for this because you'll be activating this via annotation.
>> Is that right?
> That's right! And I think, in the case of fetching the
> Webservice-Implementation from Spring, the WebServiceFeatureAnnotation
> should not even been used, since it is not really a feature of the
> Webservice to be configured by any specific means.
>
>>
>> > I have to admit, that my knowledge about the whole JAX-WS-Stack is not
>> > that great, I ony began last week to work with JAX-WS. There is a
>> > strong need for us to access our spring-managed beans. Even nicer,
>> > with the InstanceResolver-solution I can configure my complete
>> > Webservice in Spring.
>>
>> That's fine. I can provide the JAX-WS RI side of the knowledge. What I'm
>> looking for is someone with more spring experience than we have.
>>
>>
>> > I do not know, if I would be great help on that integration, but
>> > clearly I am interessted.
>> > Just tell me, what I can do to help.
>>
>> I'd first like to pounce a few ideas to see if it makes sense for Spring
>> users. Then if you could help us with some of the implementation or
>> usability feedback, that would be great.
> I'll try me best :-)
>
>>
>> So here is the idea...
>>
>> The initial idea for supporting Spring was that, like in your case, if
>> your application is wired by Spring, it would be very convenient if
>> JAX-WS fetches the configured service instances (class with @WebService)
>> from Spring --- for example in that way, your bean would receive other
>> configurations by Spring.
> Great idea! And it just works with the use of
> InstanceResolverAnnotation. I only found a small problem, which I will
> explain by the end of this mail.
>
>> Then we thought, if we are to do that, wouldn't it be nice if you can
>> configure other things with Spring, like handlers associated with the
>> service. because to do that today you'd need to write a separate file,
>> and that can be very easily absorbed to Spring. And again, if we fetch
>> handlers from Spring, handlers could be wired by Spring too. You can do
>> all sorts of AOP stuff, or get other beans injected to handlers.
> I wrote a (rather suboptimal) solution for accessing spring from my
> handlers too. I created a class ApplicationContextAwareHandler from
> which all my handlers must be subclassed. On first request, they cache
> the Spring-ApplicationContext and let me lookup needed beans by
> "Object getBean(String id)" or "B getBean(String id, Class<B> type)".
> But configuring the handlers themself in Spring would be somewhat
> nicer, since lots of spring-users like AOP, and using it on services
> and handlers would be a great benefit.
>
>>
>> Then we thought, well, if we are to do that, wouldn't it be even nicer
>> if you can configure JAX-WS itself with Spring. For example, today,
>> you'd have to write sun-jaxws.xml (if you run outside JavaEE) to specify
>> what are your service classes and which URL you want them to bind to,
>> etc. Today, JAX-WS reads that file and assembles a bunch of components
>> to do what you want it to do, and if you think about it, this is exactly
>> the kind of thing Spring does --- put together a bunch of components!
> Agreed! Based on the new support for XSD-based configuration-files in
> Spring 2.0 you could even define a "little language" that is not too
> much different from the current sun-jaxws.xml, but allows all kind of
> additional things, that spring can do.
> I would be glad to get rid of sun-jaxws.xml in favor of a somewhat
> more flexible solution.
>
>>
>> And then the added benefit is that this mechanism allows extension
>> authors to easily plug in their own components. For example, some people
>> are writing custom transports, so why not use Spring as the mechanism to
>> configure those, instead of have them write their own "deployment
>> descriptor".
> Here we should of course follow the JavaEE-5-Theme of "convention over
> configuration" and should provide sensible defaults for things like
> transports and this like, so you only have to do configuration, if you
> want something else.
> This is somewhat advanced stuff (in regards to webservices), and I did
> not think alot about that by now. As said, I'm not to deep in SOA and
> Webservices by now.
>
>>
>> Does that make sense?
> Yes, it does!
>
>
> ---
> So coming back to the problem I encountered when using
> InstanceResolverAnnotation to fetch my Webservice from Spring.
> Currently I am using the wsit-nightly builds, because we need some
> features of WS-Security and we need MTOM.
> When writing a service, writing the OptimizedMimeSerialization-Policy
> into the WSDL and let it be instantiated by JAX-WS itself, the service
> does MTOM as expected. When fetching the very same service from
> Spring, it does not.
> When I activate MTOM by annotation in the Webservice-class everything
> is working fine, but I like the approach to configure these kind of
> features by WSDL, because these are things that affect the service by
> itself.
>
>>
>> --
>> Kohsuke Kawaguchi
>> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>>
>
> I hope I can help!
>
--
Kohsuke Kawaguchi
Sun Microsystems kohsuke.kawaguchi_at_sun.com