Doorgaan naar hoofdcontent

Spring-ws and spring-mvc combined

Sometimes we want to use both spring-ws and spring-mvc in one application. However, these are two different stacks. To use them combined is a bit of a hassle, and... lest I forget, this post. The following needs to be set in the applicationcontext:
 
<!-- To nicely support webservices from httprequests, we use the WebServiceMessageReceiverHandlerAdapter (which needs a messagefactory) -->
<!-- Because we declare this, the dispatcherservlet automatically uses it... instead of the normal mvc adapter! -->
<!-- To ensure that the normal mvc adapter is also loaded, we need to define it (the SimpleControllerHandlerAdapter) as well. -->

<!-- Requires a message factory so we declare one -->
<bean class="org.springframework.ws.transport.http.WebServiceMessageReceiverHandlerAdapter">
  <property name="messageFactory" ref="messageFactory" />
</bean>
<bean id="messageFactory" class="org.springframework.ws.soap.saaj.SaajSoapMessageFactory" />

<bean class="org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter" />

<!--  and now we can add normal support for both mvc and sws -->
<mvc:annotation-driven />
<sws:annotation-driven />

<!-- Since we want to use our own marshallers, override the default endpoint adapter, which allows us to add our own marshallers. -->

<bean id="defaultMethodEndpointAdapter" class="org.springframework.ws.server.endpoint.adapter.DefaultMethodEndpointAdapter">
  <property name="methodArgumentResolvers">
    <list>
      <ref bean="marshallingPayloadMethodProcessor" />
    </list>
  </property>
  <property name="methodReturnValueHandlers">
    <list>
    <ref bean="marshallingPayloadMethodProcessor" />
    </list>
  </property>
</bean>

<bean id="marshallingPayloadMethodProcessor" class="org.springframework.ws.server.endpoint.adapter.method.MarshallingPayloadMethodProcessor">
  <constructor-arg ref="xmlBeansMarshaller" />
  <constructor-arg ref="xmlBeansMarshaller" />
</bean>
This combined wisdom is found at this StackOverflow Article, but mostly in this code sample

Reacties

Populaire posts van deze blog

Spring's conditional annotation with properties

Spring has a nice @Conditional annotation, to have the option to have beans be available in the context depending a specific condition (Of course, this can also be realized by using @Configuration objects, but that's a different post). Ideally, we'd have the option to have a condition evaluate to true or false depending on a property. Sadly, Spring does not support that out of the box. Googling and looking around gives a partial solution, but the complete one here, so we won't forget: /** * Components annotated with ConditionalOnProperty will be registered in the spring context depending on the value of a * property defined in the propertiesBeanName properties Bean. */ @Target({ ElementType.TYPE, ElementType.METHOD }) @Retention(RetentionPolicy.RUNTIME) @Conditional(OnPropertyCondition.class) public @interface ConditionalOnProperty { /** * The name of the property. If not found, it will evaluate to false. */ String value(); /** * if the p...

OSGI insights without sonar

So I was on a project without sonar. Oh my. Well, it was an OSGI project, so the problems couldn't be that bad, right? But how good were they (and what things were bad?) I found Stan4j , a code analysis tool for eclipse, which draws nice graphs and can handle osgi pretty well it seems. Now I can see that dependencies/bundle names aren't properly aligned (even though OSGI doesn't complain), etc.

JPA and transactions

So I was working with JPA and transactions. Consider the following: In bean 1, with implicit TX 1, managed entities are loaded/created,and returned in bean 2, with implicit TX 2, entities are modified in bean 3, with NO TX, bean 1 is called, and the results are passed to bean 2. and bean 4 is similar to bean 3, but with it's own transaction, TX3 What happens when bean 3 finishes: are the entities updated? What happens when bean 4 finishes, are the entities updated? The answer to this is simple; entities are managed through a persistance context. That context is tied to the transaction. So in bean 2, there is a difference. When called from bean 3, it runs in a different transaction then bean 1, and thus a different persistance context, and thus the entities are not managed 'by this transaction'.When called from bean 4, it all runs in the same transaction, TX3, and the results are persisted.