RE: JPA best-practices?
And you need a framework for this? Come on! An extremely lightweight framework that gives me dependency injection and helps manage the myriad of repository and service classes I end up with in large enterprise systems? All without the need for heavyweight Swing and the XML hell and runtime error opportunities that delivers... Need a lightweight framework that gives me all that and lets me port my apps between JDO - Hibernate with miniscule effort? Hell yeah! We're also about to open source some key infrastructure libraries that are deployed to exPOJO which means that JDO (JPOX, Kodo etc.,) users can use them as well as Hibernate users. A big issue with the adoption of many Java libraries is that they hard code dependence on a particular persistence solution: JDBC, EJBs, Hibernate, JDO etc., which limits their appeal if you happen to have a favorite that isn't their favorite ;) Deploying to exPOJO means a library developer can expose their wares to the maximum audience possible by providing repository components for the major transparent persistence engines (Hibernate, JDO etc.,). It's also useful if you want to go with an ORM but your company or client hasn't decided on one yet - just pick your favorite ORM and then start development while you're waiting on their decision. When they finally make up their mind you'll have an easy time porting your app. Chris Colman wrote: exPOJO is a lightweight, dependency injection framework with support for the exposed POJO domain model pattern for highly productive app development. It provides a very concise and simple interface declaring the essential generic services of a transparent persistence engine. 'Transparent' is the key word here so the interface needs only be extremely minimal but this generic interface is massively powerful. Out of the box it has JDO and Hibernate implementations of this interface and others (including JPA) can be supported in under 60 minutes if required. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
That could be great, that way we could support each other.. Do you have an idea on how to get started? regards Nino Uwe Schäfer wrote: Nino Saturnino Martinez Vazquez Wael schrieb: Im actually about to write a tutorial thing about howto JPA-HIBERNATE-SPRING in wicket... It could be something worth looking at, Im trying to have a clean seperation of domain / database and frontend (wicket). interesting. i could write a WICKET-JPA-GUICE thingy. Maybe we could join efforts? cu uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
Uwe Schäfer schrieb: Maris Orbidans schrieb: Let's remember good old EJB's. Inject an EntityManager in a session bean facade and EJB container will handle all concurrency issues. No need to write any boilerplate code. that´s where i come from. problem is, that you domain object aren´t able to lazily fetch attached data from database, unless you manage the EM yourself (maybe via Stateful SB, like seam does you encourage to). if you use EJB3 you really want to use the wicket-contrib-javaee project (wicketstuff) all you need to do is call you @EJB and rest is handled automatically ! see yourself: http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee i love this thing! Best, Korbinian there are situations in which SBs are the best way to implement DAOs. I doubt, these are the majority. BTW I have seen that some people use OpenEntityManagerInViewFilter and map it to url pattern /*. It seems that an EntityManager would be created every time a static web resource is accessed. Isn't that terrible ? i don´t know if OpenEntityManagerInViewFilter actually opens an EM. my solution wont, but instead provide a Context for EMs, so that they can be created and managed (and yes, more than one ;) automatically on demand. cu uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
Nino Saturnino Martinez Vazquez Wael schrieb: Im actually about to write a tutorial thing about howto JPA-HIBERNATE-SPRING in wicket... It could be something worth looking at, Im trying to have a clean seperation of domain / database and frontend (wicket). interesting. i could write a WICKET-JPA-GUICE thingy. Maybe we could join efforts? cu uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
if you use EJB3 you really want to use the wicket-contrib-javaee project (wicketstuff) all you need to do is call you @EJB and rest is handled automatically ! That project needs an update for 1.3 Add wicket-ioc dep / remove spring dep + some other unneeded deps / fix package names, I contacted the author but got no response. Plus you have to define all beans in the web.xml which is not needed when you work with jsf for example (tested on glassfish). Does anybody know why that is? but since this thread is about jpa+guice+wicket on lightweight container and not j2ee + wicket I suppose that wicket-contrib-javaee is not what they are looking for. On Nov 16, 2007 4:45 PM, Korbinian Bachl [EMAIL PROTECTED] wrote: Uwe Schäfer schrieb: Maris Orbidans schrieb: Let's remember good old EJB's. Inject an EntityManager in a session bean facade and EJB container will handle all concurrency issues. No need to write any boilerplate code. that´s where i come from. problem is, that you domain object aren´t able to lazily fetch attached data from database, unless you manage the EM yourself (maybe via Stateful SB, like seam does you encourage to). see yourself: http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee i love this thing! Best, Korbinian there are situations in which SBs are the best way to implement DAOs. I doubt, these are the majority. BTW I have seen that some people use OpenEntityManagerInViewFilter and map it to url pattern /*. It seems that an EntityManager would be created every time a static web resource is accessed. Isn't that terrible ? i don´t know if OpenEntityManagerInViewFilter actually opens an EM. my solution wont, but instead provide a Context for EMs, so that they can be created and managed (and yes, more than one ;) automatically on demand. cu uwe - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
Maris Orbidans schrieb: Let's remember good old EJB's. Inject an EntityManager in a session bean facade and EJB container will handle all concurrency issues. No need to write any boilerplate code. that´s where i come from. problem is, that you domain object aren´t able to lazily fetch attached data from database, unless you manage the EM yourself (maybe via Stateful SB, like seam does you encourage to). there are situations in which SBs are the best way to implement DAOs. I doubt, these are the majority. BTW I have seen that some people use OpenEntityManagerInViewFilter and map it to url pattern /*. It seems that an EntityManager would be created every time a static web resource is accessed. Isn't that terrible ? i don´t know if OpenEntityManagerInViewFilter actually opens an EM. my solution wont, but instead provide a Context for EMs, so that they can be created and managed (and yes, more than one ;) automatically on demand. cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
Let's remember good old EJB's. Inject an EntityManager in a session bean facade and EJB container will handle all concurrency issues. No need to write any boilerplate code. BTW I have seen that some people use OpenEntityManagerInViewFilter and map it to url pattern /*. It seems that an EntityManager would be created every time a static web resource is accessed. Isn't that terrible ? Maris Uwe Schäfer wrote: i plan to use JPA together with Wicket. Are there any battle-proven best-practices out there of how to handle EnityManagers and Transactions? What do other people use (no, not the spring crowd ;) ? One EntityManager per Request seems to be the obvious idea and a guice Provider may help with that. Does anyone have serious experiences with that or other suggestions? Subclass WebRequestCycle, and construct it with an EntityManager. In onBeginRequest(), create a transaction, storing it in a private variable. In onEndRequest(), commit the transaction if it hasn't already been rolled back and clean up the EntityManager. In onRuntimeException(...), rollback the transaction and then return super.onRuntimeException(...). You'll need to inject a ProviderEntityManager into your WebApplication subclass such that you can call .get() on it when you make your custom WebRequestCycle. You'll need to configure that provider in a Guice module somewhere, obviously. You should be able to figure that out. ;-) How do you inject things into your WebApplication? Well, you can use the new GuiceWebApplicationFactory, which unfortunately didn't quite make it into 1.3.0-rc1 but is in trunk. However, you can copy that class from trunk and use it in your own project quite happily - it has no extra dependencies. If you need to integrate with your container-managed JTA transactions you'll need something a little different (the container may well start and commit the tx for you), but the principle is roughly the same. Alternatively, you can take Wicket out of the picture and do stuff using a ServletFilter (like Spring's OpenEntityManagerInView). Regards, Al - 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: JPA best-practices?
Francis De Brabandere schrieb: if you use EJB3 you really want to use the wicket-contrib-javaee project (wicketstuff) all you need to do is call you @EJB and rest is handled automatically ! That project needs an update for 1.3 Add wicket-ioc dep / remove spring dep + some other unneeded deps / fix package names, I contacted the author but got no response. Plus you have to define all beans in the web.xml which is not needed when you work with jsf for example (tested on glassfish). Does anybody know why that is? err, you need to checkout the trunk version for 1.3, built is for 1.2 ! the trunk works perfect with 1.3, but its noted on the page AFAIK but since this thread is about jpa+guice+wicket on lightweight container and not j2ee + wicket I suppose that wicket-contrib-javaee is not what they are looking for. well, for me ejb3 is as lightweight as spring is sorry to say that, but spring is IMHO XML nightmare while ejb3 seems very easy for me.. On Nov 16, 2007 4:45 PM, Korbinian Bachl [EMAIL PROTECTED] wrote: Uwe Schäfer schrieb: Maris Orbidans schrieb: Let's remember good old EJB's. Inject an EntityManager in a session bean facade and EJB container will handle all concurrency issues. No need to write any boilerplate code. that´s where i come from. problem is, that you domain object aren´t able to lazily fetch attached data from database, unless you manage the EM yourself (maybe via Stateful SB, like seam does you encourage to). see yourself: http://wicketstuff.org/confluence/display/STUFFWIKI/wicket-contrib-javaee i love this thing! Best, Korbinian there are situations in which SBs are the best way to implement DAOs. I doubt, these are the majority. BTW I have seen that some people use OpenEntityManagerInViewFilter and map it to url pattern /*. It seems that an EntityManager would be created every time a static web resource is accessed. Isn't that terrible ? i don´t know if OpenEntityManagerInViewFilter actually opens an EM. my solution wont, but instead provide a Context for EMs, so that they can be created and managed (and yes, more than one ;) automatically on demand. cu uwe - 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: JPA best-practices?
On Nov 16, 2007 8:02 PM, Korbinian Bachl [EMAIL PROTECTED] wrote: That project needs an update for 1.3 Add wicket-ioc dep / remove spring dep + some other unneeded deps / fix package names, I contacted the author but got no response. Plus you have to define all beans in the web.xml which is not needed when you work with jsf for example (tested on glassfish). Does anybody know why that is? err, you need to checkout the trunk version for 1.3, built is for 1.2 ! the trunk works perfect with 1.3, but its noted on the page AFAIK hmm, the pom still needs an update to use ioc instead of swing + what are those servlet/portlet api dependencies doing there? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
Chris Colman wrote: The obvious benefit in such an approach is that your POJO model and the services that you provide to implement business rules etc., remain completely portable to different persistence engines - ie., no vendor lock in. well, i thought that was JPA was all about !? No, definitely not! JPA was all about creating a standard that Hibernate could conform to. Remember there *already* was a standard for Java persistence: JDO. JDO implementations such as JPOX and others implement both JDO (obviously) and JPA but it is not possible for Hibernate to provide all the features of JDO and so it could never implement the JDO standard - hence a less powerful standard had to be created so that Hibernate could play the standards game. It seems it's also possible for a few other ORM tools to conform to that standard. Apart from Hibernate and JPOX you've got TopLink, Cayenne and others. Which would you rather depend on; exPOJO or JPA? /Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JPA best-practices?
Chris Colman wrote: It seems it's also possible for a few other ORM tools to conform to that standard. Apart from Hibernate and JPOX you've got TopLink, Cayenne and others. That's my point. Which would you rather depend on; exPOJO or JPA? Two different things: exPOJO is a lightweight, dependency injection framework with support for the exposed POJO domain model pattern for highly productive app development. It provides a very concise and simple interface declaring the essential generic services of a transparent persistence engine. 'Transparent' is the key word here so the interface needs only be extremely minimal but this generic interface is massively powerful. Out of the box it has JDO and Hibernate implementations of this interface and others (including JPA) can be supported in under 60 minutes if required. JPA is a different thing altogether - it's an ORM standard. The trouble is that it had to make compromises to allow certain popular ORMs to implement it. exPOJO does not try to be another ORM standard. It just takes the best the exposed domain model pattern has to offer and uses that such that the only components with engine specific references are the repository components that you build that have engine specific queries in them. All the rest can be handled generically. /Anders - 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: JPA best-practices?
Al Maw schrieb: Hi Al Subclass WebRequestCycle, and construct it with an EntityManager. thanks! That may well be an alternative to the common ServletFilter-pattern. One question: isn´t it a little better to have the ThreadLocal Holder for the EntityManager separate from the RequestCycle, but notified of its events? Somewhat a 'listener' that registers itself ? This would decouple things as well as make configuration at runtime easier. (The 'Favor decoration over inheritance' thing.) What am i missing? -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
Uwe Schäfer wrote: Subclass WebRequestCycle, and construct it with an EntityManager. thanks! That may well be an alternative to the common ServletFilter-pattern. Well, err, yes. ;-) One question: isn´t it a little better to have the ThreadLocal Holder for the EntityManager separate from the RequestCycle, but notified of its events? Somewhat a 'listener' that registers itself ? If you have one, then sure. Whatever feels cleanest to you. There is no single best way with all this stuff. My DAOs actually use Spring's HibernateTemplate, so getting hold of a session in there is done using sessionFactory.getCurrentSession(). It's a bit different in your case with JPA stuff. This would decouple things as well as make configuration at runtime easier. (The 'Favor decoration over inheritance' thing.) What am i missing? Nothing, it sounds like. ;-) Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
Do you know if theres any plans on making a maven2 archetype for qwicket? Evan Chooly wrote: There's also qwicket.sf.net that specifically uses JPA+spring. I'm finishing up updates now for 1.3 support and improved project setup. SVN is your best bet there but I'm hoping to put up the new version this weekend. On Nov 9, 2007 10:04 AM, Francis De Brabandere [EMAIL PROTECTED] wrote: You might want to have a look at http://databinder.net, that project is using hibernate but the setup should be similar? The big problem is that a EntityManager is not thread-safe and should indeed be created per request. Let me know if you get there! On Nov 9, 2007 1:52 PM, Uwe Schäfer [EMAIL PROTECTED] wrote: hi i plan to use JPA together with Wicket. Are there any battle-proven best-practices out there of how to handle EnityManagers and Transactions? What do other people use (no, not the spring crowd ;) ? One EntityManager per Request seems to be the obvious idea and a guice Provider may help with that. Does anyone have serious experiences with that or other suggestions? cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - 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] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
Chris Colman schrieb: The obvious benefit in such an approach is that your POJO model and the services that you provide to implement business rules etc., remain completely portable to different persistence engines - ie., no vendor lock in. well, i thought that was JPA was all about !? As well as wrapping the various persistence engines it also provides dependency injection without resorting to separate XML/bean mania - it's all done very quickly and concisely and automatically in Java - Thanks, that´s what guice is great for, and it is really neatly integrated with wicket. http://expojo.com I´ll take a look anyway, thanks. cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
That's a definite feature i plan on adding as soon as I can. As a noted maven hater, though, it'll take some time and libations to help me swallow my pride. :) On Nov 12, 2007 3:47 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Do you know if theres any plans on making a maven2 archetype for qwicket? Evan Chooly wrote: There's also qwicket.sf.net that specifically uses JPA+spring. I'm finishing up updates now for 1.3 support and improved project setup. SVN is your best bet there but I'm hoping to put up the new version this weekend. On Nov 9, 2007 10:04 AM, Francis De Brabandere [EMAIL PROTECTED] wrote: You might want to have a look at http://databinder.net, that project is using hibernate but the setup should be similar? The big problem is that a EntityManager is not thread-safe and should indeed be created per request. Let me know if you get there! On Nov 9, 2007 1:52 PM, Uwe Schäfer [EMAIL PROTECTED] wrote: hi i plan to use JPA together with Wicket. Are there any battle-proven best-practices out there of how to handle EnityManagers and Transactions? What do other people use (no, not the spring crowd ;) ? One EntityManager per Request seems to be the obvious idea and a guice Provider may help with that. Does anyone have serious experiences with that or other suggestions? cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - 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] -- Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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: JPA best-practices?
Evan Chooly wrote: Do you know if theres any plans on making a maven2 archetype for qwicket? That's a definite feature i plan on adding as soon as I can. As a noted maven hater, though, it'll take some time and libations to help me swallow my pride. :) Good luck! Archetypes are really a pain, because of the template text strings in the source that keep them from compiling in place, so they're hard to code, test, and maintain. I just abandoned mine. People can almost as easily rename classes and packages after the fact, I've rationalized. Nathan -- View this message in context: http://www.nabble.com/JPA-best-practices--tf4777536.html#a13708172 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
Uwe Schäfer wrote: i plan to use JPA together with Wicket. Are there any battle-proven best-practices out there of how to handle EnityManagers and Transactions? What do other people use (no, not the spring crowd ;) ? One EntityManager per Request seems to be the obvious idea and a guice Provider may help with that. Does anyone have serious experiences with that or other suggestions? Subclass WebRequestCycle, and construct it with an EntityManager. In onBeginRequest(), create a transaction, storing it in a private variable. In onEndRequest(), commit the transaction if it hasn't already been rolled back and clean up the EntityManager. In onRuntimeException(...), rollback the transaction and then return super.onRuntimeException(...). You'll need to inject a ProviderEntityManager into your WebApplication subclass such that you can call .get() on it when you make your custom WebRequestCycle. You'll need to configure that provider in a Guice module somewhere, obviously. You should be able to figure that out. ;-) How do you inject things into your WebApplication? Well, you can use the new GuiceWebApplicationFactory, which unfortunately didn't quite make it into 1.3.0-rc1 but is in trunk. However, you can copy that class from trunk and use it in your own project quite happily - it has no extra dependencies. If you need to integrate with your container-managed JTA transactions you'll need something a little different (the container may well start and commit the tx for you), but the principle is roughly the same. Alternatively, you can take Wicket out of the picture and do stuff using a ServletFilter (like Spring's OpenEntityManagerInView). Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: JPA best-practices?
Chris Colman schrieb: The obvious benefit in such an approach is that your POJO model and the services that you provide to implement business rules etc., remain completely portable to different persistence engines - ie., no vendor lock in. well, i thought that was JPA was all about !? No, definitely not! JPA was all about creating a standard that Hibernate could conform to. Remember there *already* was a standard for Java persistence: JDO. JDO implementations such as JPOX and others implement both JDO (obviously) and JPA but it is not possible for Hibernate to provide all the features of JDO and so it could never implement the JDO standard - hence a less powerful standard had to be created so that Hibernate could play the standards game. Enough of the history lesson already ;) As well as wrapping the various persistence engines it also provides dependency injection without resorting to separate XML/bean mania - it's all done very quickly and concisely and automatically in Java - Thanks, that´s what guice is great for, and it is really neatly integrated with wicket. Yes, exPOJO and guice are great alternatives to a heavyweight and XML based approach like Spring. exPOJO, being a lightweight implementation of the exposed POJO domain model pattern has the benefit of making it easy to port apps between Hibernate, JDO and JPA without changing any of your model code or 'Service' classes. You only need to implement an engine specific Repository class as repositories are the only classes that contain engine specific API calls - ie., mainly the queries. If the slow performance of Hibernate's reflection based dirty state checking on large object graphs has you worried then you can quickly change your underlying persistence engine over to a byte code enhanced solution, like for example JPOX, with the lightning fast dirty state checking and other performance gains that brings. http://expojo.com I´ll take a look anyway, thanks. cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 - 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: JPA best-practices?
Evan Chooly wrote: Do you know if theres any plans on making a maven2 archetype for qwicket? That's a definite feature i plan on adding as soon as I can. As a noted maven hater, though, it'll take some time and libations to help me swallow my pride. :) Good luck! Archetypes are really a pain, because of the template text strings in the source that keep them from compiling in place, so they're hard to code, test, and maintain. I just abandoned mine. People can almost as easily rename classes and packages after the fact, I've rationalized. Alleluia brother - I hear what you're saying! Whoever decided declaring stuff in type safe, compile time checked Java was hard? I've certainly never found writing or updating Java classes hard - probably because that's what I do every day! Give me Java config over XML config any day. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
There's also qwicket.sf.net that specifically uses JPA+spring. I'm finishing up updates now for 1.3 support and improved project setup. SVN is your best bet there but I'm hoping to put up the new version this weekend. On Nov 9, 2007 10:04 AM, Francis De Brabandere [EMAIL PROTECTED] wrote: You might want to have a look at http://databinder.net, that project is using hibernate but the setup should be similar? The big problem is that a EntityManager is not thread-safe and should indeed be created per request. Let me know if you get there! On Nov 9, 2007 1:52 PM, Uwe Schäfer [EMAIL PROTECTED] wrote: hi i plan to use JPA together with Wicket. Are there any battle-proven best-practices out there of how to handle EnityManagers and Transactions? What do other people use (no, not the spring crowd ;) ? One EntityManager per Request seems to be the obvious idea and a guice Provider may help with that. Does anyone have serious experiences with that or other suggestions? cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - 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: JPA best-practices?
i plan to use JPA together with Wicket. Are there any battle-proven best-practices out there of how to handle EnityManagers and Transactions? What do other people use (no, not the spring crowd ;) ? One EntityManager per Request seems to be the obvious idea and a guice Provider may help with that. Does anyone have serious experiences with that or other suggestions? Have you seen exPOJO (http://expojo.com) yet? It an open source, very lightweight framework, free for use in commercial and open source apps, which sounds like what you're looking for. It allows you to build a completely POJO object model and persist it via a generic transparent persistence interface that has plugins for the various popular transparent persistence engines: Hibernate (implemented), JDO/JPOX (implemented) and JPA (will be implemented if sufficient demand) The obvious benefit in such an approach is that your POJO model and the services that you provide to implement business rules etc., remain completely portable to different persistence engines - ie., no vendor lock in. As well as wrapping the various persistence engines it also provides dependency injection without resorting to separate XML/bean mania - it's all done very quickly and concisely and automatically in Java - which means you have the benefit of compile time error checking instead of finding out about configuration errors at run time as you do in Spring. The only XML config is the usual configuration of an exPOJO filter and start up/shut down (ServletContextListener) listener in your web.xml. These are just a few lines that only need to be set up once and never need adjusting no matter how big your project grows. You can read more about it and download (~200kb!) from: http://expojo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
JPA best-practices?
hi i plan to use JPA together with Wicket. Are there any battle-proven best-practices out there of how to handle EnityManagers and Transactions? What do other people use (no, not the spring crowd ;) ? One EntityManager per Request seems to be the obvious idea and a guice Provider may help with that. Does anyone have serious experiences with that or other suggestions? cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: JPA best-practices?
You might want to have a look at http://databinder.net, that project is using hibernate but the setup should be similar? The big problem is that a EntityManager is not thread-safe and should indeed be created per request. Let me know if you get there! On Nov 9, 2007 1:52 PM, Uwe Schäfer [EMAIL PROTECTED] wrote: hi i plan to use JPA together with Wicket. Are there any battle-proven best-practices out there of how to handle EnityManagers and Transactions? What do other people use (no, not the spring crowd ;) ? One EntityManager per Request seems to be the obvious idea and a guice Provider may help with that. Does anyone have serious experiences with that or other suggestions? cu uwe -- THOMAS DAILY GmbH Adlerstraße 19 79098 Freiburg Deutschland T + 49 761 3 85 59 0 F + 49 761 3 85 59 550 E [EMAIL PROTECTED] www.thomas-daily.de Geschäftsführer/Managing Directors: Wendy Thomas, Susanne Larbig Handelsregister Freiburg i.Br., HRB 3947 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
