>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > On 7/26/06, Matthias Wessendorf wrote: > > > > That all looks promissing. > > > Yep ... it's pretty cool. > > One of the things I debated with myself when setting this up is, where > should the "business logic" bean go? As checked in today, it's in the > webapp ... but it doesn't really have any dependencies on the JSF > environment (as it should not). However, I did leverage the annotation > based injection to insert a EntityManagerFactory into this bean ... and > that will only work if it is a container managed object (in the case at > hand, it's an application scoped managed bean so the reference to the > correct factory gets injected automaticaly). So, having the business logic > bean in the same package as the entity classes would need to be either > documented with a caveat (you have to make it a managed bean), or an > alternative mechanism to inject the factory would need to be provided. > > Similarly, to create a unit test for the busines logic class, the test case > needs to be able to fake the injection. I allowed for that by making the > corresponding instance variable have package scope instead of private (one > could also provide a package-scoped setter that the test case can use) ... > but doing stuff like this strictly for unit tests doesn't really feel right. > > Any ideas on a better approach?
I suppose that the business logic could be place in POJO's that are used by an annotated session beans. The session bean could pass the entity manager to the POJO bean. I hate the idea of creating more layers. The extra setter methods for the entity manager on the session bean sounds much simpler. I'm not sure how the transaction would be handled transparently for in container versus out of container? The examples that I have seen, uses the JNDI UserTransaction in container and the EntityTransaction out of container. > > thanks! > > > Craig > Gary > > On 7/25/06, Craig McClanahan wrote: > > > On 7/25/06, Gary VanMatre wrote: > > > > > > > > >I was looking at adding some junit test cases for a maven build > > mocking > > > > the > > > > >shale mail reader JPA library in the sandbox. > > > > > > > > > >I'm using the a transaction type of "RESOURCE_LOCAL" so the test can > > be > > > > >ran under JavaSE. The problem I'm seeing is that the test needs to > > load > > > > the > > > > >persistence.xml from the META-INF of the target jar. It can't seem > > to > > > > find it > > > > >under the project's target. I'm seeing a error message that the > > > > "default" > > > > >provider can't be found. > > > > > > > > > >What am I missing here? Any ideas? > > > > > > > > It seems to work with the latest toplink archive. > > > > http://www.oracle.com/technology/products/ias/toplink/JPA/index.html > > > > > > > > > > > > > That's good. Just as a quick reminder, the persistence.xml file is > > actually > > > in the META-INF directory of the mailreader-jpa.jar file (i.e. the one > > that > > > contains the entity classes), not in the webapp, so be sure this JAR is > > on > > > the classpath for your tests. AFAIK that's a best practice, so you can > > > reuse the entity classes and persistence unit combination in multiple > > > environments. > > > > > > Craig > > > > > > > > > > > > -- > > Matthias Wessendorf > > > > further stuff: > > blog: http://jroller.com/page/mwessendorf > > mail: mwessendorf-at-gmail-dot-com > >
