title: What Spring has to do with static context
body: <p>I removed <code>static</code> from DAO methods and sessionFactory. Now IDE makes me switch back to use static DAO methods because it says <code>Non-static method updatePrice(long) cannot be referenced form a static context</code>. Neither of classes includes static keyword. What's wrong? How to fix it?</p>
  
  <p><strong>ServiceActionDAO</strong></p>
  
  <pre><code>@Transactional
  public class ServiceActionDAO{
   @Autowired
      SessionFactory sessionFactory;
  
  public void insert(ServiceActionEntity paramServiceAction){
          Transaction localTransaction = null;
          try{
              Session localSession = sessionFactory.getCurrentSession();
              localSession.save(paramServiceAction);
              localSession.getTransaction().commit();
  ServiceOrderDAO.updatePrice(paramServiceAction.getServiceOrderFk().longValue());// error
          }
          catch (Exception localException){
              if (localTransaction != null) {
                  localTransaction.rollback();
              }
          }
      }
  </code></pre>
  
  <hr>
  
  <p>UPDATE</p>
  
  <p>I find a quick way to solve this problem by replacing error line with:</p>
  
  <pre><code>new ServiceOrderDAO().updatePrice(paramServiceAction.getServiceOrderFk().longValue());
  </code></pre>
  
  <p>Now it's not a static call.</p>
  
  <hr>
  
  <p>UPDATE 2</p>
  
  <p>I have a lot of DAO classes and a number of controllers. I have to find quick fix with minimum code changes taking into account Spring architecture. I have one DAO calls one or more DAOs to perform some complex queries. </p>
  
  <p>As was denoted before: creating new instance of DAO would lead to unpredictable Spring  session behavior. </p>
  
  <p>It appears that my controllers also have calls for DAO classes.</p>
  
  <p>What is the easiest way (with minimum code changes) to fix this problem?</p>
  
  <hr>
  
  <p>UPDATE 3</p>
  
  <p>Ended up injecting DAO into DAOs and Controllers. It seems like quick fix but from the conceptual point of view I doubt that this is the best solution...</p>