I just found out what the problem was: I had a value="pictureDao" instead of a ref="pictureDao"... I could kick myself for that. Sorry for all the fuss.
Regards, Chris Anil Gangolli wrote: > > > Christian: > > You need to check which spring bean definition file you are using to > define your daos and which one you are using to define your managers and > what's getting included in the webapp application context spring bean > definitions. You are probably exposing the manager bean definitions up > to the webapp spring bean context but not the daos. > > But that's not really all. There is a key difference in their > treatment. In the default AppFuse setup, the transaction boundaries > surround all manager methods and this is done using Spring aspects using > a line like: > > <aop:advisor id="managerTx" advice-ref="txAdvice" > pointcut="execution(* *..service.*Manager.*(..))" order="2"/> > > On the other hand, the DAOs just expect the transaction to be there and > there is generally no corresponding aspect. This seems to be the main > difference in how they are treated. If you directly access the Dao, > you'll also need to redefine where you have these transaction > boundaries. Conversely, if your controller calls need to call multiple > managers it is likely that you will also want/need to initiate > transactions at the level of the Controller or higher. > > One thing ill I've found about the tutorial setup is the unusual 1-1-1-1 > pairing of controller, manager, dao, model object. It's fine for a > simple tutorial, but rarely appropriate for a real app. If you > continue to develop that way, you will likely hit problems with the > default transaction boundaries as well as with the pain of dealing with > all of the classes. I think Matt comments on this somewhere, but I > can't find a reference right now. > > Generally I use something like: > Controller per action/view/form. Many more of these than managers. > Manager for an entire service interface. Each method may interact > with multiple DAOs. Each method is an entire service-level operation. > Quite a few more of these than DAOs. > Each DAO manages a single primary model object, but may in some > cases also manage its child entities for hierarchical types (e.g. > master-detail-subdetail with cascading). > > If you develop along these lines, you probably will feel less need to > expose DAOs directly to controllers. > > --a. > ----- Christian Decker http://blog.snyke.net -- View this message in context: http://www.nabble.com/Accessing-DAOs-in-the-controllers-tp20217953s2369p20238717.html Sent from the AppFuse - User mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
