Kohsuke,
Many thanks for the effort. I just rebuilt with the latest snapshot. First,
I ran into the dreaded "spring namespace" issue, which boils down to the
spring.schema and spring.handlers files not being current. I patched the pom
file
and added the following to the "build/plugins" element for now:
<plugin>
<artifactId>maven-antrun-plugin</artifactId>
<executions>
<execution>
<phase>process-classes</phase>
<configuration>
<tasks>
<copy file="target/xbean/META-INF/spring.handlers"
todir="target/classes/META-INF" />
<copy file="target/xbean/META-INF/spring.schemas"
todir="target/classes/META-INF" />
</tasks>
</configuration>
<goals>
<goal>run</goal>
</goals>
</execution>
</executions>
</plugin>
Now spring does not complain about not finding "wss:bindings" etc.
2) I still not clear as to how to inject spring configured beans into the
SEI. Maybe, I am going about it
wrong. One way I could think of was, is it possible to configure the
<ws:service> impl attribute as a
spring bean? Then I would be able to inject it.
I tried the ServletContextAware, but @PostConstruct executes before spring
can inject the ServletContext.
If the above works, then I could get rid of the @PostConstruct altogether at
least to retreive spring beans.
Cheers
Mohan
On 1/3/07, Kohsuke Kawaguchi <Kohsuke.Kawaguchi_at_sun.com> wrote:
>
> Kohsuke Kawaguchi wrote:
> > Mohan K R wrote:
> >> Kohsuke,
> >>
> >> Thanks for the reply.
> >>
> >> I was trying to draw the analogy from Spring MVC, in that scenario a
> IoC
> >> Container heirarchy is created with the root
> >> being the bean factory (ApplicationContext) initialized by the Spring
> >> Context Loader Listener. Then, the dispatcher
> >> servlet (in this case WSSpringServlet) would create its own
> >> ApplicationContext and tag itself as child of the "root"
> >> context created by the ContextLoaderListener. Now, it is debatable the
> >> benefits of creating an IoC Hierarchy!
> >
> > OK. I see. So the idea is that by creating a hierarchy, you can avoid
> > name collisions among beans. Is that right? I guess that makes sense.
> >
> > Now, my question is how do I/users create a child IoC context?
> >
> >
> >> About the other question, yes wac is the WebApplicationContext, which
> is the
> >> IoC container, so it is like a Chicken
> >> and egg thing, I cannot inject it into the SEI. I need to access the
> IoC so
> >> that I can retrieve the beans needed to initialize
> >> the SEI properly. Currently the way to get the "wac" (that I know of)
> is
> >> using the ServletContext. But, in JAX-WS 2.0
> >> I cannot seem to figure out how to get the ServletContext in a
> @PostContruct
> >> annotated Method.
> >
> > I see.
> >
> > Since your SEI is now a Spring-configured bean, you can get all kinds of
> > dependencies injected into your SEI bean by Spring, without writing any
> > explicit code to access WebApplicationContext. Is that not enough? Do
> > you still need to get access to WebApplicationContext?
> >
> > And more importantly, when Spring injects dependencies into your SEI, I
> > thought it should be able to inject the WebApplicationContext itself to
> > your SEI, maybe by using a reserved bean name or something --- I'm just
> > talking what I would have done if I were implementing Spring, so I don't
> > know if it's actually capable of doing that, but don't you think it
> should?
> >
> > If we can programmatically export a bean to the namespace of Spring, I
> > can have WSSpringServlet inject ServletContext as a bean, but it doesn't
> > look like there's a way to do that.
> >
> > In a sense this seems to be a generic problem in Spring, not a JAX-WS
> > problem. Essentially the problem seems to me that you want Spring to
> > inject ServletContext into places where you need it, yet it doesn't seem
> > to be able to do. Shouldn't this be fixed in Spring? Or am I making a
> > wrong assumption somewhere?
>
> Yep. And Spring already handles that. All you need to do is to have your
> SEI implement org.springframework.web.context.ServletContextAware, and
> you'll have ServletContext injected by Spring.
>
> --
> Kohsuke Kawaguchi
> Sun Microsystems kohsuke.kawaguchi_at_sun.com
>
>
>