Posts Mentioning RSS Toggle Comment Threads | Keyboard Shortcuts

  • Mike 9:58 pm on June 30, 2008 Permalink | Reply
    Tags:   

    Fairy Tale of the Fruit Tree 

    This is a reprint of a fantasy authored by Yutaka Kachi and translated by Mikiko Kachi. Originally from http://www.catch.jp/openoffice/whats_oss/index_en.html.

    I am reprinting it because it is only available through PDF. I want to share it and make it easier to read and comment on. I found it in 2005 and saved the PDF. I found the the file this morning and thought it would be good to share and discuss.

    Long long time ago, there was a tree in a field of grass near a village. One day, this tree bore a lot of delicious fruit.

    The fruit were very delicious. So villagers soon harvested all of the fruits.

    There was no end to the number of people who cut branch of this tree and take them home.

    Because of this, the tree died in a few years.

    In the village, there was a clever merchant. He grafted the tree before the tree died.

    And he fertilized the tree, cut off branch when it’s too much. He took care of the tree for a long time.

    Then the tree bore fruit. He sold it and made big money.

    He was a real worrier. He fenced around the tree and was always watching the tree.

    This merchant was not just an worrier, but also a hard worker.
    His effort made the fruit more delicious and a lot of people bought it.

    Some people delivered it to busy villagers, and some people made jam from the fruits and sold it.

    The merchant monopolized the fruit tree.

    When someone said to him “ there are many worm holes ” , he heard nothing of it and said “ It’s cheap so you can’t complain that.”

    When someone asked him “ do you use any harmful fertilizer?”
    he said “ it’s company secret” and wouldn’t answer that question.

    When someone offered him “ I’d like to buy branch”, he said “ I don’t want to have competitors” and rejected the offer.

    More and more people started to sell the fruit and more and more people bought it.

    Then the merchant increased the price and made a big profit.

    In this village, there was a young man who really loved this fruit. When the merchant increased price of the fruit, he couldn’t afford it any more because he was very poor.

    So, he got interested in another tree near the village. This tree also bore a lot of fruit, but its taste was not so good and no one had cared for it. The young man started taking care of it with his friends.

    Therefore, the tree bore more fruit than they could eat. So they put up a sign board that said “ Free”. There were some people who take the fruit away although they didn’t take care of the tree, but the young man didn’t mind at all.

    The young men kept making effort for years to improve taste of the fruit as much as possible. Some people who took the fruit said “ I will help you”, “I will help you too because we don’t want to kill this tree like the first one” and helped doing time-consuming works.

    The more people helped, the more people took the fruit. When the fruit run short, the people grafted the tree to grow more. They put up “ Free” sign boards on new trees also.

    Some people delivered the fruit, and some people made jam from the fruit. They were very cooperative and sometimes they pay for agricultural equipment, fertilizer and inviting specialists to get advise.

    So they reduced warm holes, improved the taste of the fruit, and their fruit became much more popular.

    Years later, many fruit trees were planted around the village and bore a lot of delicious fruit.


    The villagers started delivering the young men’s fruit together to far-off town. In that town, many people said “I’ve never had such a delicious fruit !” and the fruit became popular. It sold like hot cakes.

    And not only the young man but also his friends and villagers all became happy.

    By the way, what happened to the merchant who monopolized the fruit tree?

    His business was also going well. For only a short while he had a fewer customers, but he expanded his business by hiring many people, shipping the fruits to far-off town, buying up fruit trees which had grown in other villages, etc.

    There was no difference between the young man and the merchant in terms of making delicious fruit.

    This is a great, simple explanation of how open source works and why the model it is successful. Growing a fruit tree is relatively easy compared to writing software, but as software development tools get easier to use, and more people learn to write code, it was and is inevitable that the number of open source tools and the quality of those tools will increase.

    There are two more PDFs that talk around open source licensing at http://www.catch.jp/openoffice/whats_oss/index_en.html.

     

  • Mike 2:48 pm on May 24, 2008 Permalink | Reply  

    Spring: OpenSessionInViewInterceptor & OpenSessionInViewFilter Examples 

    This post on OpenSessionInViewInterceptor vs. OpenSessionInViewFilter gets a lot of views from developers who are searching “OpenSessionInViewFilter” and “OpenSessionInViewFilter”. I’d guess, a lot of them are looking for examples. I don’t want to disappoint anyone so here are example setups of both the filter and the interceptor.

    OpenSessionInViewInterceptor

    This goes into your action-servlet.xml.

    <beans>

<bean id="urlMapping"
class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">

<property name="interceptors">
<list>
<ref bean="openSessionInViewInterceptor"/>
</list>
</property>

<property name="mappings">

</bean>

<bean name="openSessionInViewInterceptor"
class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">

<property name="sessionFactory">
<ref bean="sessionFactory"/>
</property>
</bean>

</beans>

    OpenSessionInViewFilter

    This goes into your web.xml.

    <web-app>

<filter>
<filter-name>openSessionInViewFilter</filter-name>
<filter-class>org.springframework.orm.hibernate3.support.OpenSessionInViewFilter</filter-class>
</filter>

<filter-mapping>
<filter-name>openSessionInViewFilter</filter-name>
<url-pattern>*.html</url-pattern>
</filter-mapping>

</web-app>

    If you are not sure if you need to use the filter or the interceptor, check our post that explains the “>difference between the OpenSessionInViewFilter and the OpenSessionInViewInteceptor. The comments on that page offer some good insight too.

     

    • Anonymous 2:49 pm on May 24, 2008 Permalink

      Thanks.

    • Anonymous 2:49 pm on May 24, 2008 Permalink

      thanks a lot! code is better than 1000 blog post! :D

    • Mike 2:50 pm on May 24, 2008 Permalink

      Too true. I hate going to software blogs and seeing nothing but paragraph after paragraph. I want to see code that I can copy and paste, that has comments in it so that I can follow it.

      Glad I could help. Cheers.

    • cookie 2:51 pm on May 24, 2008 Permalink

      Hi Mike,
      Kudos on the great explanations and examples.

      I am a newbie to Spring (as well as Java :P ). I have a question regarding OpenSessionInViewInterceptor/ Filter.

      I have a Spring app that only selective controllers requires open sessions. Can I selectively “hook-up” the interceptor to those controllers?

      Thanks a lot.

      YS

    • Anonymous 2:51 pm on May 24, 2008 Permalink

      For those of you using the Persistence API, there is also an EntityManager version:

      org.springframework.orm.jpa.support.OpenEntityManagerInViewInterceptor

      Thanks for your example, Chris

      PS I would put an example – but seems the comments box does not allow it :(

    • weggyboy 2:52 pm on May 24, 2008 Permalink

      Nice Post, but it only works for views, doesn´t it?

      I was trying to change some entries after the proposed changes and found out, that the write operations are not allowed with the default session setting for the openViewInSession filter.
      After searching for a solution I´ve found that:

      import org.springframework.orm.hibernate3.support.OpenSessionInViewFilter;
      import org.hibernate.*;
      import org.springframework.dao.*;

      public class SessionFilter extends OpenSessionInViewFilter {
      /*
      * The default mode is FlushMode.NEVER
      *
      * @see org.springframework.orm.hibernate.support.OpenSessionInViewFilter#getSession(net.sf.hibernate.SessionFactory)
      */
      protected Session getSession(SessionFactory sessionFactory)
      throws DataAccessResourceFailureException {
      Session session = super.getSession(sessionFactory);
      session.setFlushMode(FlushMode.COMMIT);
      return session;
      }

      /**
      * we do an explicit flush here just in case we do not have an automated flush
      */
      protected void closeSession(Session session, SessionFactory factory) {
      session.flush();
      super.closeSession(session, factory);
      }
      }

      Now it works as wished!

    • delta one 2:53 pm on May 24, 2008 Permalink

      Excellent example!

    • Dan Allen 3:21 pm on May 24, 2008 Permalink

      You should read Spring in Seam, Part 3 (http://www.javaworld.com/javaworld/jw-05-2008/jw-05-spring-seam3.html) and chapters 8 and 9 of Seam in Action to discover why this Spring filter/interceptor is essential a huge *hack*. The persistence manager (Hibernate Session/JPA EntityManager) was designed to be extended across a series of requests, not be relegated to a single request or worse service layer call. LazyInitializationExceptions happen because the persistence manager is scoped incorrectly.

    • David Newcomb 12:28 pm on October 12, 2009 Permalink

      Your xml for urlMapping is incomplete! No value is set for:

      and the property is closed. What is it supposed to be?

    • David Newcomb 12:29 pm on October 12, 2009 Permalink

      Your xml for urlMapping is incomplete! No value is set for:
      property name=”mappings”
      and the “property” is not closed. What is it supposed to be?

    • David Newcomb 1:51 pm on October 12, 2009 Permalink

      Also urlMapping doesn’t work if you are using annotations.
      If you are using annotations you should probably go for the OpenSessionInViewFilter otherwise there is a rats nest of other support classes you need. Just spent the day reading all about it and I have lost the will to live :(

    • Mike 9:25 am on October 13, 2009 Permalink

      @David Newcomb – The post isn’t really about how to set mappings. But you’ll want something like

      installController

      which maps a request URI to a controller. Here are some examples…

      http://www.google.com/search?q=SimpleUrlHandlerMapping+example

    • Pieno 7:52 am on July 11, 2010 Permalink

      In Spring 3 you can use the tag to use the OpenSessionInViewInterceptor. There is an example on my blog: http://www.pieno.be/content/2010/opensessioninviewinterceptor-example-spring-3-web-mvc

  • Mike 2:38 pm on May 24, 2008 Permalink | Reply  

    Spring: OpenSessionInViewInterceptor vs. OpenSessionInViewFilter 

    Problem: Assuming you’re using an ORM, such as Hibernate, rendering the view with business objects that have many-to-one or one-to-one relationships might try to access a detached object with a lazy property and throw a LazyInitializationException. For this reason, we’re provided with the Open Session In View pattern.


    Solution: The Open Session In View pattern binds a Hibernate session to the thread to be used throughout the life of the request and closes any transactions when the response is sent. This is what allows your view to access model objects with lazily loaded properties after a transaction has been closed. This is nothing new and this is not what this post is about.

    To setup the Open Session In View in your Spring application, you have two options. The OpenSessionInViewInterceptor and the OpenSessionInViewFilter. You can use either solution because the two classes serve the very same function and implement the same pattern. Well if this is the case, then why do they both exist? Why is there a filter option and an interceptor option? This is what I set to find out.

    I’ve been searching Google all night. I’ve read through forums, I’ve read docs, and I’ve read blogs. Why? Because I want to use the better of the two options on my application. I want to ensure I am getting the best performance and the most reliability for my clients as I can. Anyway, the only thing that I could dig up was that they are equal in almost every way. The only consideration that you really need to make is what servlet spec you are using. If your servlet container support version 2.3 or later, you can use either one. If it’s 2.2 or earlier, you’ll need to go with the OpenSessionInViewInterceptor.

    Surely there are other considerations. Maybe you want to keep your filters down to a bare minimum, or you think interceptors are confusing or messy. Or perhaps you like to keep your configuration files as small as possible. If you use annotations, you might want to go with the OpenSessionInViewInterceptor.

    I hope I answered any questions you had about why there were two classes for implementing this pattern.

     

    • jazzy 2:40 pm on May 24, 2008 Permalink

      Hi, thanks for your post, it’s good to see that at least someone is writing about this stuff because I always feel a little worried if I’m using functionality that it appears no one else is using.

      There is an argument for OpenSessionInViewInterceptor that you have left out. If you want to keep a hard line separation between your model and your view, ie, data objects should never be passed to JSPs, and web forms should never be passed to the model, so you’re doing conversions in the controller, then you don’t want the session to be open to the JSPs, you want to intercept calls to the Actions, so that when the JSP is being rendered, the session is closed, and any LazyInitializationException is an indication that you are breaking your design pattern.

      Another reason for the existence of an OpenSessionInViewInterceptor is that web containers are not the only views to business objects, for example, you might have an MDP that receives a message, makes a call on your business object, gets some hibernate data objects back as results, and encodes them and sends a reply message. In this case the only option is OpenSessionInViewInterceptor.

    • Robert Reiz 4:26 am on August 20, 2008 Permalink

      Another example: If you are using a quartz-job in your service-layer with hibernateDAO access you got an Exception

      “No Hibernate Session bound to thread, and configuration does not allow creation of non-transactional one here”

      with the openSessionInViewFilter. Because the openSessionInViewFilter is not active for actions startet on your service-layer. Here you need the openSessionInViewInterceptor.

    • Ryan Stewart 8:50 am on August 25, 2008 Permalink

      Actually, neither the Open Session In View Filter nor interceptor is the correct solution to your quartz problem. That exception is telling you that that your configuration won’t let you arbitrarily create a session. This is good, and is likely the result of configuring your HibernateTemplate with allowCreate=false. Using the Open Session In View pattern here would be a Bad Idea, as it simply ensures that a *non-transactional* session is available, which might allow your quartz job to complete successfully, but outside of a transaction, which could mean that nothing gets committed to the database, or it might just fail with a different exception. Worst case, it might mean that things are written to the database in auto-commit mode, meaning that other threads reading from the database could get corrupt data back. Operations performed by the service layer should be done within a transaction. This probably means that your services should be proxied with a TransactionInterceptor to handle your transactions. The TransactionInterceptor does *not* need an Open Session In View Filter or Interceptor, as it opens its own session if one is not available.

      A good example of when to use the Open Session In View Interceptor is one that jazzy gave: when processing messages or requests from something other than a person using a web page. You can actually consider the Open Session In View Filter as a specialized application of the Open Session In View Interceptor. It is useful only when a request comes to your application via a servlet container. If the request/message comes via other channels–say a message from a JMS queue–then the Open Session In View Filter is useless because it isn’t going through the Filter mechanism. That’s where you need the Open Session In View Interceptor (assuming that some response message is needed). Both filter and interceptor allow you to render a response outside of a transaction–that’s what the Open Session In View pattern is really about. The only distinction is that one is specific to a servlet environment, and one isn’t.

    • Robert Reiz 3:54 am on September 4, 2008 Permalink

      Hallo Ryan Stewart,

      sorry for my late response. I don’t use the HibernateTemplates, I am working with the genericDaos from Christian Bauer and annotation driven transaction management. The openSessionInViewInterceptor you can use with the property “singleSession=false”. It will not use a single session per request then, but rather let each data access operation or transaction use its own session (like without Open Session in View).
      But you are right and I was wrong. The TransactionInterceptor does not need an OpenSessionInViewFilter or Interceptor, as it opens its own session if one is not available. If I comment out the OpenSessionInViewInterceptor the quartz job works still fine, because I am using the @Transactional annotation in the service layer.

    • Ryan Stewart 8:36 am on September 4, 2008 Permalink

      If you’re using Spring and Hibernate, then you’re most likely using the org.springframework.orm.hibernate3.support.HibernateDaoSupport. If this is true and you don’t know that you’re using a HibernateTemplate, then you’re likely injecting this with a SessionFactory. The HibernateDaoSupport always uses a HibernateTemplate internally, though, whether you configure it explicitly or not. However, if this is how it’s being used, then it will default to allowCreate=true, so your “No Hibernate Session” exception is coming from something else that is not allowed to create a session. Normally using the Open Session In View pattern, in whatever incarnation, would prevent this, but, as you mentioned, setting singleSession=false removes this benefit, and it will go back to breaking because a session is not eagerly created when singleSession=false. Instead, everything is allowed/required to create its own session as needed, as if the pattern weren’t in use at all.

    • Robert Reiz 2:52 pm on September 4, 2008 Permalink

      I am not using the HibernateDaoSupport. I am using the org.springframework.orm.hibernate3.LocalSessionFactoryBean and inject it via “autowire=byName” in the my DAOs. My DAOs all extend the GenericDaoHibernate class from Christian Bauer. For the transactions I am using the org.springframework.orm.hibernate3.HibernateTransactionManager. My “No Hibernate Session” exception occurred because the @Transactional method was not listed in the Interface to my Service class. Since I added the method signature to the interface it works fine with and without OpenSessionInViewInterceptor/Filter.

    • Ryan Stewart 3:35 pm on September 5, 2008 Permalink

      The most prominent GenericDaoHibernate class I see is org.appfuse.dao.hibernate.GenericDaoHibernate. Is that what you’re using? It’s a direct subclass of HibernateDaoSupport. If not, then you’re probably doing stuff manually that this class automates for you.

    • Robert Reiz 8:52 am on September 6, 2008 Permalink

      Actually I’m using my own GenericDao class. I have take a look to org.appfuse.dao.hibernate.GenericDaoHibernate. It’s similar to my class. Perhaps in the next project I will use it. Thank you for the hint.

    • Charles Gutjahr 1:26 am on November 11, 2008 Permalink

      I have found it necessary to choose OpenSessionInViewInterceptor over OpenSessionInViewFilter when using Spring Web Flow (SWF).

      If you use the filter (OpenSessionInViewFilter) then all requests will have the Hibernate session applied to them, regardless of whether Spring MVC, Spring Web Flow or something else handles the request. This is a problem if you use Spring Web Flow’s flow managed persistance (ie the tag) because it creates its own Hibernate session… this results in two sessions being created and a pile of IllegalStateExceptions because only one session is allowed.

      OpenSessionInViewInterceptor solves this problem because you can choose to apply it only to some handlers – ie apply it to Spring MVC but don’t apply it to Spring Web Flow. That way you can use OpenSessionInViewInterceptor for Spring MVC where it is very useful — and let Spring Web Flow use its (probably superior) flow managed persistance for Spring Web Flow handlers.

    • Mike 9:20 pm on November 11, 2008 Permalink

      @Charles Gutjahr – Charles, thanks for sharing that use case. I use and love Spring MVC, but have not had the opportunity to get into web flow yet. Thanks for describing the situation that you encountered and why the interceptor was the solution. I’m sure that comment will be very helpful to someone soon.

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
esc
cancel