Re: OK, more JPA questions
On Mon, May 19, 2008 at 12:04 PM, David Nedrow <[EMAIL PROTECTED]> wrote: > First, thanks for the help. Item 1 implemented via @SpringBean(name = > "blah"). ;) > > On May 16, 2008, at 3:31 PM, Igor Vaynberg wrote: > >> there are basically two things that you need no matter what web >> framework you are integrating with: >> >> 1) a way to lookup your dao singleton >> >> wicket-ioc allows you to quickly build an annotation based injection > > >> 2) a way to scope the entity manager to request >> >> you need this so that lazy loading works. you are already doing this >> with a threadlocal already, the only thing you need to do is to wire >> in that closeEntityManager() call. >> >> you can either do this with a servlet filter that sits around the >> wicket filter, or you can hook into wicket's requestcycle and do it >> from there. there are really no advantages either way. > > I'll ask for help with this bit on the Spring list to help avoid clutter > here. > > The filter route sounds like want I want, as I would prefer to keep as much > of the "bookkeeping" as possible out of the application logic. see org.springframework.orm.jpa.support.OpenEntityManagerInViewFilter -igor > > -David > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OK, more JPA questions
First, thanks for the help. Item 1 implemented via @SpringBean(name = "blah"). ;) On May 16, 2008, at 3:31 PM, Igor Vaynberg wrote: there are basically two things that you need no matter what web framework you are integrating with: 1) a way to lookup your dao singleton wicket-ioc allows you to quickly build an annotation based injection 2) a way to scope the entity manager to request you need this so that lazy loading works. you are already doing this with a threadlocal already, the only thing you need to do is to wire in that closeEntityManager() call. you can either do this with a servlet filter that sits around the wicket filter, or you can hook into wicket's requestcycle and do it from there. there are really no advantages either way. I'll ask for help with this bit on the Spring list to help avoid clutter here. The filter route sounds like want I want, as I would prefer to keep as much of the "bookkeeping" as possible out of the application logic. -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: OK, more JPA questions
there are basically two things that you need no matter what web framework you are integrating with: 1) a way to lookup your dao singleton you can do this with servletcontextlistener, a lazy init static lookup on the dao itself, keep it in some other singleton like the wicket application subclass, or make it a spring/guice/whatever bean. depends on what you want to use, wicket doesnt really care. the only concern is that you must than be careful not to let any component keep a reference to the dao because it is not serializable. wicket-ioc allows you to quickly build an annotation based injection solution that wraps these kinds of dependencies in serializable light-weight proxies, which allows you to keep references or pass these dependencies around in wicket components. see wicket-spring or wicket-guice for example implementations. 2) a way to scope the entity manager to request you need this so that lazy loading works. you are already doing this with a threadlocal already, the only thing you need to do is to wire in that closeEntityManager() call. you can either do this with a servlet filter that sits around the wicket filter, or you can hook into wicket's requestcycle and do it from there. there are really no advantages either way. hope this helps some. you have to keep in mind that wicket is purely a UI framework, that is why we do not have a single story on how to tie in a perstistance service or any other kind of lower tier to the framework - that is simply outside what we consider our scope. -igor On Fri, May 16, 2008 at 12:14 PM, David Nedrow <[EMAIL PROTECTED]> wrote: > There doesn't seem to be one recommended way to inject/use JPA-based utility > archives in Wicket. It looks as though most of it is based around Spring, > which is fine, yet adds another app layer. > > I've generated a tiny Derby db using the JPA facilities provided by > MyEclipse. > > The sources can be found at: > > http://nedron.net/JpaTest.jar > > A binary "library" was created, including the default generated > persistence.xml file and can be downloaded at: > > http://nedron.net/JpaTest-bin.jar > > I think more people than just me would find it useful if someone could use > this extremely simple database in a simple, single page Wicket app. > > Note that I have zero problem using this type of library in a standalone > Java app, and given that I'm relatively new to Wicket, I don't want to go to > a bunch of effort only to find that I've gone about it the wrong way. > > Basic questions... > > Do I need to get hold of the com.foo.jpa.JpaNet.EntityManagerHelper in the > main WicketApplication class and then serve that out to pages and panels as > needed? The question here is, do I need EntityManagerHelper transaction > wrappers around my DAO operations? Or is that handled auto-magically by some > other mechanism (JTA)? > > I guess what I'm really getting at is, what is the recommended way to use > the library directly without extracting it? > > All of the examples I've found so far include the dao/etc. along with the > app code, so there is no clear indication as to how a "third-party" java > library is used in Wicket(/Spring). And many examples and much of the > documentation is remarkably framdibulous, along the lines of "What is > session managed? Session managed is not container managed. What is container > managed? Container managed is not session managed." > > I've gotten myself pretty confused on this, as you can tell. ;) > > -David > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
OK, more JPA questions
There doesn't seem to be one recommended way to inject/use JPA-based utility archives in Wicket. It looks as though most of it is based around Spring, which is fine, yet adds another app layer. I've generated a tiny Derby db using the JPA facilities provided by MyEclipse. The sources can be found at: http://nedron.net/JpaTest.jar A binary "library" was created, including the default generated persistence.xml file and can be downloaded at: http://nedron.net/JpaTest-bin.jar I think more people than just me would find it useful if someone could use this extremely simple database in a simple, single page Wicket app. Note that I have zero problem using this type of library in a standalone Java app, and given that I'm relatively new to Wicket, I don't want to go to a bunch of effort only to find that I've gone about it the wrong way. Basic questions... Do I need to get hold of the com.foo.jpa.JpaNet.EntityManagerHelper in the main WicketApplication class and then serve that out to pages and panels as needed? The question here is, do I need EntityManagerHelper transaction wrappers around my DAO operations? Or is that handled auto- magically by some other mechanism (JTA)? I guess what I'm really getting at is, what is the recommended way to use the library directly without extracting it? All of the examples I've found so far include the dao/etc. along with the app code, so there is no clear indication as to how a "third- party" java library is used in Wicket(/Spring). And many examples and much of the documentation is remarkably framdibulous, along the lines of "What is session managed? Session managed is not container managed. What is container managed? Container managed is not session managed." I've gotten myself pretty confused on this, as you can tell. ;) -David - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
