Results 1 to 7 of 7

Thread: Help: ProxyFactoryBean + non-singletons

  1. #1
    Join Date
    Aug 2004
    Posts
    7

    Default Help: ProxyFactoryBean + non-singletons

    Hi,

    Using Spring 1.1.

    I'm using a ProxyFactoryBean to add advices to my target, which is required to not be a singleton.

    After reading the docs I tried:

    Code:
    <bean id="UploadNewFileAction" class="org.springframework.aop.framework.ProxyFactoryBean">
        <property name="singleton"><value>false</value></property>
        <property name="proxyTargetClass"><value>true</value></property>
        <property name="interceptorNames">
            <list>
                <value>FileUploadAdvice</value>
                <value>FileExtractContentAdvice</value>
                <value>FileSubjectTopicNatureAdvice</value>
            </list>
        </property>
        <property name="target"><ref local="_uploadFileAction" /></property>
    </bean>
    
    <bean name="_uploadFileAction" class="my.UploadFileAction"/>
    But when I run it, I got an exception saying
    Code:
    FactoryBean threw exception on object creation; nested exception is org.springframework.aop.framework.AopConfigException&#58; Target name cannot be null when refreshing!
    But after I took a look at the test suites that came along with Spring and tried:
    Code:
    <bean id="UploadNewFileAction" class="org.springframework.aop.framework.ProxyFactoryBean">
        <property name="singleton"><value>false</value></property>
        <property name="proxyTargetClass"><value>true</value></property>
        <property name="interceptorNames">
            <list>
                <value>FileUploadAdvice</value>
                <value>FileExtractContentAdvice</value>
                <value>FileSubjectTopicNatureAdvice</value>
                <value>_uploadFileAction</value>
            </list>
        </property>
    </bean>
    it's running back properly again.

    I wonder why? :?: Because _uploadFileAction should be defined as the target of the ProxyFactoryBean instead of one of the members of the interceptor stack.

    TIA,
    Raymond

  2. #2
    Join Date
    Aug 2004
    Location
    San Mateo, CA
    Posts
    1,265

    Default

    You cannot use the target property for a non-singleton target. Instead you need to specify the target bean name, which in this case will terminate the list of interceptor names. This is necessary because Spring must obtain a new instance of the target via a getBean() call every time a new proxy instance is created. If the ProxyFactoryBean held a reference to the target, all proxy instances it created would hit the same target.
    Rod Johnson - GM, SpringSource Division, VMware
    http://www.springsource.com
    Spring From the Source

  3. #3

    Default

    Wouldn't it make more sense to have a targetName property instead of setting the bean name in the interceptor list?

  4. #4
    Join Date
    Aug 2004
    Location
    San Mateo, CA
    Posts
    1,265

    Default

    Wouldn't it make more sense to have a targetName property instead of setting the bean name in the interceptor list?
    Yes. I'm just worried about backward compatibility. Maybe we should consider changing this in Spring 1.2, but it would break some code. I didn't feel it was an option with 1.1.1, for example. I guess a clear error message explaining the migration path would be acceptable.

    Anyone else have a view on this?
    Rod Johnson - GM, SpringSource Division, VMware
    http://www.springsource.com
    Spring From the Source

  5. #5

    Default

    While ease-of-use is the ultimate goal, I do not like to see compatibility broken inbetween major version numbers.

    I consider "major version numbers" to be the first digit. So stuff written in 1.0 would work all the way up to 1.9. Other wise all of your 1.x documentation is going to have stuff like, "in 1.2.3.2 of Spring, it works this way, but in 1.2.3.3 it's this way."

  6. #6

    Default

    Well, it could be done while preserving backward compatibility. You add a targetName property, and if it's null you use the current way of doing things. If targetName is defined, then you use it as the target and the last interceptorName is used as an interceptor instead of the target.

    Optionnally, a warning could also be done if targetName is null. I don't see any backward compatibility problem with this approach.

    Guillaume

  7. #7
    Join Date
    Aug 2004
    Location
    Columbus, OH
    Posts
    65

    Default Please document this

    Wow! :shock:

    I can't believe I tripped over this thread. I was trying to understand why my proxied non-singleton was maintaining its state between fetches from the context. Like everyone else, I read the documentation differently.

    I suppose a check in ProxyFactoryBean should be made to throw some kind of config error if:
    Code:
    !getSingleton&#40;&#41; && getTarget != null
    I thought the interceptor/advisor names were included by name because sometimes *they* need to maintain state. Not the target bean.

    Does this same "problem" exist if I am using TransactionProxyFactoryBean? Can you apply that to non-singletons?

Similar Threads

  1. Replies: 6
    Last Post: Sep 28th, 2005, 04:14 PM
  2. not so Singletons, and Cyclic references
    By Ian Johnson in forum Container
    Replies: 0
    Last Post: May 23rd, 2005, 04:18 PM
  3. Replies: 1
    Last Post: Jan 11th, 2005, 12:21 PM
  4. Replies: 1
    Last Post: Dec 14th, 2004, 11:53 PM
  5. ProxyFactoryBean proxying singleton
    By bst@jcs.be in forum AOP
    Replies: 2
    Last Post: Nov 22nd, 2004, 09:21 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
  •