tag:blogger.com,1999:blog-6400109873187811774.post1218675160431654020..comments2023-02-19T13:31:53.769+01:00Comments on terraza de aravaca: Lessons learned using GWT, Axis and JPA simultaneouslyAnonymoushttp://www.blogger.com/profile/16230758554312791063noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-6400109873187811774.post-2402306152344514412009-01-23T09:20:00.000+01:002009-01-23T09:20:00.000+01:00We're using Gwt-Ext, OpenJPA, and Spring as fo...We're using Gwt-Ext, OpenJPA, and Spring as follows:<BR/><BR/>public interface BaseDAO<T extends Serializable, PK extends Serializable> {<BR/>//various CRUD methods and generic finders<BR/>}<BR/><BR/>//JPA implementation of BaseDAO with Spring JpaDaoSupport<BR/>public class BaseJPADAO<T extends BaseEntity, PK extends Serializable> extends JpaDaoSupport implements BaseDAO<T, PK> {<BR/><BR/>}<BR/><BR/>public interface TblFndDAO extends BaseDAO<TblFnd,String> {<BR/>//various finders<BR/>}<BR/><BR/>/**<BR/> * @spring.bean id="tblFndDAO"<BR/> * @spring.property name="entityManagerFactory" ref="entityManagerFactory" //inject entityManagerFactory for Spring JpaDaoSupport<BR/> * @author Enrico Goosen<BR/> */<BR/>public class TblFndJPADAO extends BaseJPADAO<TblFnd,String> implements TblFndDAO {<BR/><BR/>}<BR/><BR/>@Entity<BR/>@Table(name="TBL_FND",schema="EBSTATUS")<BR/>public class TblFnd extends BaseEntity {<BR/><BR/>}<BR/><BR/>/**<BR/> * Manage all the Fund Detail Business service requirements<BR/> * @spring.bean id="fundDetailsManager"<BR/> * @spring.property name="tblFndDAO" ref="tblFndDAO"<BR/> */<BR/>@Transactional<BR/>public class FundDetailsManagerBean implements FundDetailsManager {<BR/><BR/>}<BR/><BR/>Regards,<BR/>Enrico GoosenAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-54905871884047603312009-01-08T09:23:00.000+01:002009-01-08T09:23:00.000+01:00Muy interesante para los que trabajen con Java... ...Muy interesante para los que trabajen con Java... para cuando una entrada sobre Oracle????<BR/><BR/>cesartiz<BR/>www.socioestusegovia.tkCésarhttps://www.blogger.com/profile/16457478226084753037noreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-61426081846125476622008-12-30T21:40:00.000+01:002008-12-30T21:40:00.000+01:00The ServletContextListener exists while the web ap...The ServletContextListener exists while the web application exists.<BR/><BR/>The phrase "until the last request is<BR/>serviced for the Web application" means that the ServletContextListener must not be unloaded (when the aplication is going to be stopped) until the last (pending) request is serviced.<BR/><BR/>The phrase DOES NOT mean that the listener can be unloaded in an active web application when the "last request" is serviced. When the web application is active you do not know which is the "last request"! ;-)Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-39819251930226590262008-12-30T20:32:00.000+01:002008-12-30T20:32:00.000+01:00until the last request isserviced for the Web appl...<I>until the last request is<BR/>serviced for the Web application</I>??<BR/>Then once there are no requests being serviced the ServletContextListener object will stop being maintained (= subject to GC)Anonymoushttps://www.blogger.com/profile/16230758554312791063noreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-30439088155502533652008-12-30T19:10:00.000+01:002008-12-30T19:10:00.000+01:00You can use a ServletContextListener:SRV.10.5 List...You can use a ServletContextListener:<BR/><BR/>SRV.10.5 Listener Instances and Threading<BR/>The container is required to complete instantiation of the listener classes in a Web<BR/>application prior to the start of execution of the first request into the application. <B>The<BR/>container must maintain a reference to each listener instance until the last request is<BR/>serviced for the Web application.</B>Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-13950711224498128242008-12-30T16:32:00.000+01:002008-12-30T16:32:00.000+01:00Zvika, I do not think that a static var might caus...Zvika, I do not think that a static var might cause problems. There will be one static var in each web applicaction. That is OK.<BR/><BR/>In my opinion, the problem is how to assure that the class with the static var is not unloaded from memory.<BR/><BR/>By the way, I do not like singletons at all. They are very dangerous.<BR/><BR/>JuanAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-73664929897795480882008-12-30T15:56:00.000+01:002008-12-30T15:56:00.000+01:00Yes, you could use a Singleton, a Threadlocal or e...Yes, you could use a Singleton, a Threadlocal or even a JNDI resource, but the simple static attribute did the trick. It didn't fail during the tests and it did not produce any memory leaks.<BR/>Tomcat created just one EntityMemoryFactory, which was shared by the threads. It gave no problem at all. That's why I did not use anything more sophisticated.Anonymoushttps://www.blogger.com/profile/16230758554312791063noreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-45713336493006422532008-12-30T13:50:00.000+01:002008-12-30T13:50:00.000+01:00thanks for the tips,some questions:using static me...thanks for the tips,<BR/><BR/>some questions:<BR/>using static members in jee apps isn't a trivial nor usually recommended practice, also due to classloader behavior that might cause visibility problems or multiple instances (see http://www.javaspecialists.eu/archive/Issue052.html or http://www.objectsource.com/j2eechapters/Ch21-ClassLoaders_and_J2EE.htm, for example)<BR/>so,<BR/>why did you choose rhis solution instead of using a ThreadLocal object or, better off, a jndi accessible EntityManager, the recommended jee way (see: http://docs.jboss.org/ejb3/app-server/reference/build/reference/en/html/entityconfig.html, for jboss details, I'm sure other servers have it too)<BR/><BR/>Thanks,<BR/>Zvikaצְבִיקַ'הhttps://www.blogger.com/profile/06574092551885873890noreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-81727010553418514512008-12-30T13:06:00.000+01:002008-12-30T13:06:00.000+01:00In case the GC removes it if nobody has a referenc...<I>In case the GC removes it if nobody has a reference to it (the fact that you are pointing out), the next time that is used it will be created again... but only once.<BR/>There's nothing wrong with that.</I><BR/><BR/>Efficiency?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-25598677219172593702008-12-30T09:43:00.000+01:002008-12-30T09:43:00.000+01:00Juan, what I said is that the EntityManagerFactory...Juan, what I said is that the EntityManagerFactory should be static, so that there is only one for the whole application and it is shared by all the threads. In case the GC removes it if nobody has a reference to it (the fact that you are pointing out), the next time that is used it will be created again... but only once.<BR/>There's nothing wrong with that.Anonymoushttps://www.blogger.com/profile/16230758554312791063noreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-73259568149110489612008-12-30T08:40:00.000+01:002008-12-30T08:40:00.000+01:00En Java, nada te garantiza que una clase con una v...En Java, nada te garantiza que una clase con una variable static permanezca en memoria cuando no hay objetos instanciados. Por lo tanto, el JPAManager que propones está mal. Ten en cuenta que la máquina virtual puede cepillarse la clase (y, como consecuencta, el EntityManagerFactory) cada vez que no quede ningún objeto instanciado de JPAManager. Es un error muy grave el pensar que una variable static no puede desaparecer.<BR/><BR/>El EntityManagerFactory debería permanecer en memoria gracias a algún objeto cuya existencia estuviese garantizada durante la vida de la aplicación, por ejemplo, un filtro.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-13411664281340049462008-12-29T22:12:00.000+01:002008-12-29T22:12:00.000+01:00So you discovered the documentation was right ?Sur...So you discovered the documentation was right ?<BR/>Sure this needs to be claimed !<BR/><BR/>Just a bit disappointed..<BR/><BR/>ScCédric Pineauhttps://www.blogger.com/profile/05541759530343617305noreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-58607198188756846832008-12-29T16:36:00.000+01:002008-12-29T16:36:00.000+01:00Sure, Hasan. Sorry if it wasn't all that clear.The...Sure, Hasan. Sorry if it wasn't all that clear.<BR/>The idea is that every method executed when a GWT remote service or an Axis web service is called should create a JPAManager.<BR/>You are right, the EntityManager is a class level attribute, but it's not static, it's private. So every method would use a different EntityManager, given that each would create a new JPAManager.<BR/><BR/>The case of the EntityManagerFactory is different, because this one can and should be shared. That's why it's static.<BR/><BR/>Hope to have clarified a little bit.Anonymoushttps://www.blogger.com/profile/16230758554312791063noreply@blogger.comtag:blogger.com,1999:blog-6400109873187811774.post-25932316592179796982008-12-29T15:46:00.000+01:002008-12-29T15:46:00.000+01:00Hi,First of all, thanks for the tips..one thing; y...Hi,<BR/><BR/>First of all, thanks for the tips..<BR/><BR/>one thing; you have created the EntityManager at class level.<BR/><BR/>But, you said; "Each method of the GWT remote service must create a new EntityManager" above..<BR/><BR/>i got confused a bit.. could you please clear it?<BR/><BR/>regards,Hasan Turksoyhttps://www.blogger.com/profile/06596667760778488320noreply@blogger.com