________________________________________ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Friday, February 11, 2005 3:08 AM To: [email protected] Subject: [Andromda-user] Spring without EJB
Hi all, I have a question about the applicationContext.xml generated by the Spring cartridge. We're using the Spring-cartridge with Hibernate, but without EJBs. The generated applicationContext.xml file contains the following relevant beans: - 'transactionManager' (org.springframework.orm.hibernate.HibernateTransactionManager). - 'hibernateInterceptor' (org.springframework.orm.hibernate.HibernateInterceptor) - 'entityTransactionInterceptor' (org.springframework.transaction.interceptor.TransactionInterceptor) - 'serviceTransactionInterceptor' (org.springframework.transaction.interceptor.TransactionInterceptor) But I'm wondering why the DAOs are proxied with the 'entityTransactionInterceptor'. Is the 'entityTransactionInterceptor' actually needed, since transaction boundaries should be demarcated on business fa�ades only (service beans). I think DAOs should never be exposed to clients (e.g. the web tier); they should always be invoked through the business layer. -- Yeah they should never be exposed, however why not have them transaction enabled, what if people want to test their DAOs alone? Don't see the harm in having it there. On the other hand, service beans are correctly proxied with the 'serviceTransactionInterceptor', but also with a 'hibernateInterceptor'. I thought a 'hibernateInterceptor' only made sense on a DAO implemented with Hibernate, am I right? (See Spring reference section Data Access Using Relational Mappers > Hibernate > Applying an AOP Interceptor instead of a Template). -- Having the hibernateInterceptor across the services allows us to have lazy retrieval of associations within the services (keeps the session open and closes it for us at the end of the service operation execution). I had one more little problem: I would like to create a child ApplicationContext in another package, using the instance of generated applicationContext.xml as a parent. But I couldn't get a reference to the ApplicationContext instance of the ServiceLocator singleton because the ServiceLocator.instance().getContext() method has protected accessibility. Since the ServiceLocator default constructor is private, I'm not sure the protected modifier makes sense anyway. Couldn't this method be declared public instead? -- Well actually it's protected for a reason: I wanted to keep it so that you could use the ServiceLocator with EJBs interchangeably with the regular Spring one (meaning you add ejb support with a namespace property and remove it with a namespace property without code changes), so therefore I decided to not have any Spring (or EJB) specific stuff exposed. You can always override the template in the cartridge locally if you want different behavior. Thanks for your help, Johnny. ------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_ide95&alloc_id396&op=click _______________________________________________ Andromda-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/andromda-user
