Page 2 of 2 FirstFirst 12
Results 11 to 17 of 17

Thread: Help with putting transactions around webwork actions

  1. #11
    Join Date
    Aug 2004
    Location
    Toronto, Canada
    Posts
    736

    Default

    Futang/Mike,

    See Juergen's comment on the bug entry. He does have a point. getObjectType should never through a NPE even with a prototype coming in as the last name on the interceptors list, as the targetsource will default to the specail empty target source instance, which will just return null for the type. Now this means you should get a null result from the getObjectType, but that's legal.

    Can you try to confirm where and how you're getting the NPE? Perhaps the easiest thing to do is to do is put a breakpoint on the code, and attach to the servlet engine. I think things are not what they seem.

    Now, there's the question of whether the code should still try to do more to return a valid object type in this case (instead of null), which it could, and I think it should...
    Colin Sampaleanu
    SpringSource - http://www.springsource.com

  2. #12
    Join Date
    Aug 2004
    Posts
    16

    Default

    I think Juergen is misunderstanding where the NPE is occurring. The NPE is not occurring on the getTargetSource().getTargetClass() call, but within getTargetClass for SingletonTargetSource. When createAdvisorChain is a called in setBeanFactory the SingletonTargetSource that is created has an underlying null target. So when SingletonTargetSource.getTargetClass is called it executes target.getClass() and NPE. At least I'm pretty sure all of that is true.

  3. #13
    Join Date
    Aug 2004
    Location
    Toronto, Canada
    Posts
    736

    Default

    No, that's impossible. If you look at createAdvisorChain as called form setBeanFactory, all it does when the last name is a prototype name is set the targetName. That it's. Then next in setBeanFactory, only if the proxy is a singleton does freshTargetSource() (which is the only place that creates the SingletonTargetSource) get called at that point.

    I sitll think have a bad config of some sort, and all is not quite as you are describing it. I was trying to figure out if perhaps you forgetting to set the proxy itself to singleton (the property, not the attribute), but all that would do would create a SingletonTargetSource from the get-go. Not what you want, but it would be a completely valid targetsource, and would not produce the NPE you describe, so that's no it...

    What version of Spring are you using btw?
    Colin Sampaleanu
    SpringSource - http://www.springsource.com

  4. #14
    Join Date
    Aug 2004
    Posts
    16

    Default

    Colin, thank you for all your help with this. It is far more likely you are correct, but here is the process as I understand it (with Spring 1.1). Within createAdvisorChain the following code is executed (pasted verbatim)

    Code:
    // add a named interceptor
    Object advice = null;
    // avoid unnecessary creation of prototype bean just for advisor chain initialization
    if (isSingleton() || this.beanFactory.isSingleton(this.interceptorNames[i])) {
        advice = this.beanFactory.getBean(this.interceptorNames[i]);
    }
    addAdvisorOnChainCreation(advice, this.interceptorNames[i]);
    Then within addAdvisorOnChainCreation namedBeanToAdvisorOrTargetSource(next) is called. The next variable is the advice parameter which is null since the ProxyFactoryBean property "singleton" is set to false and the interceptor is the xwork action with the singleton attribute set to false. Within namedBeanToAdvisorOrTargetSource null is again passed in. The following code is executed

    Code:
    try {
    	Advisor adv = this.advisorAdapterRegistry.wrap(next);
    	return adv;
    }
    catch (UnknownAdviceTypeException ex) {
    	// Treat it as a TargetSource
    	if (next instanceof TargetSource) {
    		return (TargetSource) next;
    	}
    	else {
    		// It's not a pointcut or interceptor.
    		// It's a bean that needs a TargetSource around it.
    		return new SingletonTargetSource(next);
    	}
    }
    Since null cannot be wrapped and is not an instance of TargetSource a SingletonTargetSource is created with null as the target. Also, I have confirmed within the debugger that this is what is happening. I am going to create a standalone configuration file that I can post in it's entirety. Thanks again. Mike.

  5. #15
    Join Date
    Aug 2004
    Posts
    16

    Default

    I just took a look at the CVS HEAD code and this is handled very differently. It also looks like it solves this problem. Instead of creating a SingletonTargetSource as a result of setBeanFactory it creates a PrototypePlaceholderAdvisor and places that on the advice chain. This way the targetSource is still EMPTY_TARGET_SOURCE and getTargetSource will return null. Since this code has changed so much let me try upgrading before we waste anymore time thinking about this. Mike.

  6. #16
    Join Date
    Aug 2004
    Location
    Toronto, Canada
    Posts
    736

    Default

    Well, this is why I asked what version you were using, as some of the stuff changed from 1.1 to 1.1.1. Now, while there have been changes since 1.1.1, they shouldn't really affect any of this. The code you show seems to be from 1.1.1, and even in that version (never mind CVS head) there should be no issue.

    Quote Originally Posted by futang
    Colin, thank you for all your help with this. It is far more likely you are correct, but here is the process as I understand it (with Spring 1.1). Within createAdvisorChain the following code is executed (pasted verbatim)

    Code:
    // add a named interceptor
    Object advice = null;
    // avoid unnecessary creation of prototype bean just for advisor chain initialization
    if (isSingleton() || this.beanFactory.isSingleton(this.interceptorNames[i])) {
        advice = this.beanFactory.getBean(this.interceptorNames[i]);
    }
    addAdvisorOnChainCreation(advice, this.interceptorNames[i]);
    Even in 1.1.1, you should never get here for the last name in the interceptor names list. There is a continue up above it that will cause the loop to continue and never get down here...

  7. #17
    Join Date
    Aug 2004
    Posts
    16

    Default

    Not sure what was going on, but it works fine in 1.1.1. Thank you for your help.

Similar Threads

  1. JDO Transactions and JUnit testing
    By markds75 in forum Data
    Replies: 2
    Last Post: Sep 17th, 2005, 01:46 AM
  2. Multiple actions
    By bytecount in forum Web Flow
    Replies: 1
    Last Post: Jul 27th, 2005, 10:34 AM
  3. Auto-injecting Struts Actions
    By steve_molitor in forum Web
    Replies: 0
    Last Post: Apr 21st, 2005, 04:03 PM
  4. Replies: 4
    Last Post: Mar 15th, 2005, 05:50 AM
  5. Replies: 10
    Last Post: Nov 2nd, 2004, 09:38 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •