Results 1 to 5 of 5

Thread: Abstract Bean definition causing View Resolving Error

  1. #1
    Join Date
    Aug 2004
    Location
    New York, NY
    Posts
    46

    Default Abstract Bean definition causing View Resolving Error

    I am using some of the example config from the petclinic sample app. In particular I am having problems with my views resolving when I have the following bean definition:

    Code:
    <bean id="baseTransactionProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
    			abstract="true">
    		<property name="transactionManager"><ref bean="transactionManager"/></property>
    		<property name="transactionAttributes">
    			<props>
    				<prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
    				<prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
    				<prop key="load*">PROPAGATION_REQUIRED,readOnly</prop>
    				<prop key="store*">PROPAGATION_REQUIRED</prop>
    			</props>
    		</property>
    	</bean>
    As the example shows, I am using this as the parent bean for my Transaction definitions for target business objects.

    My problem is I get the following error when VelocityView tries to resolve my view:

    Code:
    org.springframework.beans.factory.BeanIsAbstractException&#58; Tried to instantiate abstract bean definition '&baseTransactionProxy'
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean&#40;AbstractBeanFactory.java&#58;177&#41;
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean&#40;AbstractBeanFactory.java&#58;136&#41;
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType&#40;DefaultListableBeanFactory.java&#58;177&#41;
    	at org.springframework.context.support.AbstractApplicationContext.getBeansOfType&#40;AbstractApplicationContext.java&#58;473&#41;
    	at org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors&#40;BeanFactoryUtils.java&#58;108&#41;
    	at org.springframework.beans.factory.BeanFactoryUtils.beansOfTypeIncludingAncestors&#40;BeanFactoryUtils.java&#58;112&#41;
    	at org.springframework.beans.factory.BeanFactoryUtils.beanOfTypeIncludingAncestors&#40;BeanFactoryUtils.java&#58;141&#41;
    	at org.springframework.web.servlet.view.velocity.VelocityView.initApplicationContext&#40;VelocityView.java&#58;182&#41;
    	at org.springframework.context.support.ApplicationObjectSupport.setApplicationContext&#40;ApplicationObjectSupport.java&#58;79&#41;
    	at org.springframework.web.servlet.view.AbstractCachingViewResolver.loadAndConfigureView&#40;AbstractCachingViewResolver.java&#58;123&#41;
    	at org.springframework.web.servlet.view.AbstractCachingViewResolver.resolveViewName&#40;AbstractCachingViewResolver.java&#58;78&#41;
    	at org.springframework.web.servlet.DispatcherServlet.render&#40;DispatcherServlet.java&#58;629&#41;
    	at org.springframework.web.servlet.DispatcherServlet.doService&#40;DispatcherServlet.java&#58;535&#41;
    	at org.springframework.web.servlet.FrameworkServlet.service&#40;FrameworkServlet.java&#58;321&#41;
    	at javax.servlet.http.HttpServlet.service&#40;HttpServlet.java&#58;802&#41;
    	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter&#40;ApplicationFilterChain.java&#58;237&#41;
    	at org.apache.catalina.core.ApplicationFilterChain.doFilter&#40;ApplicationFilterChain.java&#58;157&#41;
    	at org.apache.catalina.core.StandardWrapperValve.invoke&#40;StandardWrapperValve.java&#58;214&#41;
    	at org.apache.catalina.core.StandardValveContext.invokeNext&#40;StandardValveContext.java&#58;104&#41;
    	at org.apache.catalina.core.StandardPipeline.invoke&#40;StandardPipeline.java&#58;520&#41;
    	at org.apache.catalina.core.StandardContextValve.invokeInternal&#40;StandardContextValve.java&#58;198&#41;
    	at org.apache.catalina.core.StandardContextValve.invoke&#40;StandardContextValve.java&#58;152&#41;
    	at org.apache.catalina.core.StandardValveContext.invokeNext&#40;StandardValveContext.java&#58;104&#41;
    	at org.apache.catalina.core.StandardPipeline.invoke&#40;StandardPipeline.java&#58;520&#41;
    	at org.apache.catalina.core.StandardHostValve.invoke&#40;StandardHostValve.java&#58;137&#41;
    	at org.apache.catalina.core.StandardValveContext.invokeNext&#40;StandardValveContext.java&#58;104&#41;
    	at org.apache.catalina.valves.ErrorReportValve.invoke&#40;ErrorReportValve.java&#58;117&#41;
    	at org.apache.catalina.core.StandardValveContext.invokeNext&#40;StandardValveContext.java&#58;102&#41;
    	at org.apache.catalina.core.StandardPipeline.invoke&#40;StandardPipeline.java&#58;520&#41;
    	at org.apache.catalina.core.StandardEngineValve.invoke&#40;StandardEngineValve.java&#58;109&#41;
    	at org.apache.catalina.core.StandardValveContext.invokeNext&#40;StandardValveContext.java&#58;104&#41;
    	at org.apache.catalina.core.StandardPipeline.invoke&#40;StandardPipeline.java&#58;520&#41;
    	at org.apache.catalina.core.ContainerBase.invoke&#40;ContainerBase.java&#58;929&#41;
    	at org.apache.coyote.tomcat5.CoyoteAdapter.service&#40;CoyoteAdapter.java&#58;160&#41;
    	at org.apache.coyote.http11.Http11Processor.process&#40;Http11Processor.java&#58;799&#41;
    	at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.processConnection&#40;Http11Protocol.java&#58;705&#41;
    	at org.apache.tomcat.util.net.TcpWorkerThread.runIt&#40;PoolTcpEndpoint.java&#58;577&#41;
    	at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run&#40;ThreadPool.java&#58;683&#41;
    	at java.lang.Thread.run&#40;Thread.java&#58;595&#41;
    I think this has to do with org.springframework.transaction.interceptor.Transa ctionProxyFactoryBean being a FactoryBean and getBeansOfType tries to actually get the Factory. I thought that getBeansOfType would always skip Abstract beans reguardless?

    Why this doesn't fail for the sample app, I have no idea unless the view resolver it's using is implemented differently. I haven't had a lot of time to look at the implementation there.

    This is with Spring 1.1 Final running on Tomcat. Any ideas?

    Thanks,
    Patrick

  2. #2
    Join Date
    Aug 2004
    Location
    Montréal, Canada
    Posts
    845

    Default

    :idea:
    This issue has been fixed. For more information take a look at Abstract Beans Causes Error With Velocity View SPR-316


    :!:
    There is another bug related to this one. You can reproduce it easily:
    Code:
      <bean id="myBean" class="MyBean" abstract="true">
        ....
      </bean>
    
      factory.getBeansOfType&#40;MyBean.class, bool1, bool2&#41;;
    call to factory.getBeansOfType will fail.
    I reported this new bug on JIRA: getBeansOfType fails when abstract bean exists in the context SPR-326
    Omar Irbouh

    Spring Modules Team
    http://irbouh.blogspot.com/

  3. #3
    Join Date
    Aug 2004
    Location
    New York, NY
    Posts
    46

    Default

    Quote Originally Posted by irbouho
    :idea:
    This issue has been fixed. For more information take a look at Abstract Beans Causes Error With Velocity View SPR-316
    Yeah, I know, I reported it. :wink:

    Quote Originally Posted by irbouho
    :!:
    There is another bug related to this one. You can reproduce it easily:
    Code:
      <bean id="myBean" class="MyBean" abstract="true">
        ....
      </bean>
    
      factory.getBeansOfType&#40;MyBean.class, bool1, bool2&#41;;
    call to factory.getBeansOfType will fail.
    I reported this new bug on JIRA: getBeansOfType fails when abstract bean exists in the context SPR-326
    Have you tried your code with what's in CVS? I think the fix for my Velocity problem was a fix for the more general problem you are having. VelocityView was just one of the places that exposed it.

    Or maybe there are more places where the Factory is supposed to ignore Abstract Beans but doesn't.

  4. #4
    Join Date
    Aug 2004
    Location
    Montréal, Canada
    Posts
    845

    Default

    I tried this sample with yesterday snapshot from CVS. Could you try on your side?
    Omar Irbouh

    Spring Modules Team
    http://irbouh.blogspot.com/

  5. #5

    Default

    I also confront with this problem when using Acegi-Security-0.6.
    Why don't you replace the fixed class with the bugged one in release 1.1.

    Here is the exception:
    Code:
    &#91;23.09.2004 18&#58;07&#58;52&#58;812 EEST&#93; 3b39758c WebGroup      E SRVE0026E&#58; &#91;Servlet Error&#93;-&#91;Filter &#91;Acegi Authentication Processing Filter&#93;&#58; could not be initialized&#93;&#58; org.springframework.beans.factory.BeanIsAbstractException&#58; Tried to instantiate abstract bean definition '&baseTransactionProxy'
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean&#40;AbstractBeanFactory.java&#58;177&#41;
    	at org.springframework.beans.factory.support.AbstractBeanFactory.getBean&#40;AbstractBeanFactory.java&#58;136&#41;
    	at org.springframework.beans.factory.support.DefaultListableBeanFactory.getBeansOfType&#40;DefaultListableBeanFactory.java&#58;177&#41;
    	at org.springframework.context.support.AbstractApplicationContext.getBeansOfType&#40;AbstractApplicationContext.java&#58;473&#41;
    	at net.sf.acegisecurity.util.FilterToBeanProxy.init&#40;FilterToBeanProxy.java&#58;126&#41;
    	at com.ibm.ws.webcontainer.filter.FilterInstanceWrapper.init&#40;FilterInstanceWrapper.java&#58;105&#41;
    	at com.ibm.ws.webcontainer.filter.WebAppFilterManager.loadFilter&#40;WebAppFilterManager.java&#58;365&#41;
    	at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterInstanceWrapper&#40;WebAppFilterManager.java&#58;159&#41;
    	at com.ibm.ws.webcontainer.filter.WebAppFilterManager.getFilterChain&#40;WebAppFilterManager.java&#58;206&#41;
    	at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.handleWebAppDispatch&#40;WebAppRequestDispatcher.java&#58;968&#41;
    	at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.dispatch&#40;WebAppRequestDispatcher.java&#58;564&#41;
    	at com.ibm.ws.webcontainer.webapp.WebAppRequestDispatcher.forward&#40;WebAppRequestDispatcher.java&#58;200&#41;
    	at com.ibm.ws.webcontainer.srt.WebAppInvoker.doForward&#40;WebAppInvoker.java&#58;119&#41;
    	at com.ibm.ws.webcontainer.srt.WebAppInvoker.handleInvocationHook&#40;WebAppInvoker.java&#58;276&#41;
    	at com.ibm.ws.webcontainer.cache.invocation.CachedInvocation.handleInvocation&#40;CachedInvocation.java&#58;71&#41;
    	at com.ibm.ws.webcontainer.cache.invocation.CacheableInvocationContext.invoke&#40;CacheableInvocationContext.java&#58;116&#41;
    	at com.ibm.ws.webcontainer.srp.ServletRequestProcessor.dispatchByURI&#40;ServletRequestProcessor.java&#58;186&#41;
    	at com.ibm.ws.webcontainer.oselistener.OSEListenerDispatcher.service&#40;OSEListener.java&#58;334&#41;
    	at com.ibm.ws.webcontainer.http.HttpConnection.handleRequest&#40;HttpConnection.java&#58;56&#41;
    	at com.ibm.ws.http.HttpConnection.readAndHandleRequest&#40;HttpConnection.java&#58;618&#41;
    	at com.ibm.ws.http.HttpConnection.run&#40;HttpConnection.java&#58;443&#41;
    	at com.ibm.ws.util.ThreadPool$Worker.run&#40;ThreadPool.java&#58;672&#41;

Similar Threads

  1. Order of Bean definitions matters?
    By cfuser in forum Container
    Replies: 2
    Last Post: Oct 21st, 2005, 10:29 AM
  2. Spring container fails with no exception
    By naor in forum Container
    Replies: 9
    Last Post: Oct 1st, 2005, 03:39 PM
  3. EHCaching Hibernate
    By dencamel in forum Data
    Replies: 3
    Last Post: Sep 6th, 2005, 09:03 PM
  4. could not satisfy dependencies
    By springuser in forum Container
    Replies: 4
    Last Post: Apr 26th, 2005, 01:15 PM
  5. Replies: 1
    Last Post: Apr 25th, 2005, 07:37 PM

Posting Permissions

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