Spring 3.0 (REST) and Struts2

[Frans Thamura <fr...@meruvian.org>]

hi all

i just put Spring 3.0 to S2 REST environment, and still trying to work with,

i still testing several small code of old S2 inside, but the spring
has work unconnected with Spring.

S2-Spring work well also with Spring 3M3.

i read several url like this

http://blog.springsource.com/2009/03/08/rest-in-spring-3-mvc/

and got that Spring 3 also move to REST

any comment it?


and also

there is declarative transaction inside spring that may be can benefit
S2 apps, can share this experience?

thx
Frans

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: Spring 3.0 (REST) and Struts2

[Wes Wannemacher <we...@wantii.com>]

On Thu, Sep 24, 2009 at 6:01 AM, Frans Thamura <fr...@meruvian.org> wrote:
[snip]
>
> there is declarative transaction inside spring that may be can benefit
> S2 apps, can share this experience?
>

Frans, I use Spring's declarative transaction management, but there
are some caveats. The biggest being that it depends on AOP. This is
subtle, but I have been bitten by a few of the side-effects. First of
all, behind the scenes, Spring tries to use Dynamic JDK proxies which
imposes the requirement that the "intercepted" methods must be
implementations from an interface. This means that if you try to use
@Transactional on an action method like the following -

public class SomeAction extends ActionSupport {
  ...

  @Transactional
  public String someInterestingMethod() {
    doSomethingInteresting(BusinessClass bizInstance);
    return SUCCESS;
  }
}

This does not work, since you can see from the class declaration,
SomeAction is not implementing an interface that exposes 'public
String someInterestingMethod();' This is easily mitigated by
configuring Spring to use CGLIB rather than JDK proxies. This imposes
a rule though that any classes using @Transactional must have a
default, no-arg constructor.

The next issue that bit me was that 'self-invocation' does not work
(which makes sense and I should have known it wouldn't work).
Self-invocation is a situation like this -

public class SomeServiceImpl implements SomeService {
  ...
  @Transactional
  public BusinessClass save(BusinessClass bizClass) {
    ...
  }

  public BusinessClass create(String id, String value) {
    BusinessClass newInstance = new BusinessClass();
    newInstance.setId(id);
    newInstance.setValue(value);
    return save(newInstance);
  }
}

Notice that 'create' doesn't have @Transactional? It shouldn't need
it, right, 'save' has it... Well, this doesn't work. The call to
'save' isn't intercepted (IIRC, it doesn't matter if the proxies are
JDK or CGLIB).

That being said, declarative transaction management is great! I still
prefer it, and just work around these issues. I have found that if I
separate things appropriately (service = interfaces, implementations =
spring beans) then I don't have to worry too much. I don't mess with
transactions in Struts actions and if I feel like I need a transaction
in an action, I just refactor the service.

-Wes

PS. As to Spring 3, as soon as it's released, we will work toward
getting it working.

-- 
Wes Wannemacher

Head Engineer, WanTii, Inc.
Need Training? Struts, Spring, Maven, Tomcat...
Ask me for a quote!

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org