Re: [JBoss-user] Testing EJB's
Thanks, Dain. At first, I was encouraged by your reply, so I checked out the source, but it doesn't address my needs. At least, the branch I checked out (3.0 and jboss-head) could not run the testsuite successfully without first firing up JBoss. I want to be able to test my CMP's in an in-memory, lightweight EJB container that I can somehow quickly bootstrap from my JUnit testrunner. The CMP's would persist for the duration of the tests in the in-memory Hypersonic database. Perhaps EJB's are so resource intensive that something like this isn't feasible? -- Jim Dain Sundstrom [EMAIL PROTECTED] writes: Jim, How do you think we test JBoss? Take a look at the CMP tests in the testsuite. We have an addon to JUnit that can deploy and undeploy applications. Also we have a tool that can run the tests on the server side like (I wrote this to test local interfaces), but does not require a servlet tier. -dain On Tuesday, December 10, 2002, at 02:23 PM, Jim Crossley wrote: These are good points, and I appreciate yours and others' prompt replies. However, the solutions presented so far seem to force me to complicate my object model to facilitate testing. I agree that an app that is difficult to test probably suffers from poor design, but web apps by their very nature are difficult to test. The app I'm currently working on is very CRUD-ish; it does simple read/write maintenance on a bunch of related objects. I don't want the web tier to access the Entity beans directly -- this would violate the transactional requirements -- so they go through a Session Facade. Creating additional POJO's through which the session beans interact with the entities only adds an unnecessary layer of complexity IMHO. The app is currently implemented using OJB, and I'm interested in refactoring it to use CMP EJB's, which IMHO are much easier to create and maintain (with Xdoclet, of course) than OJB. The big benefit of using OJB, however, is that a user can easily test the entire app from end-to-end without deploying or even interacting with an external resource. This is possible with Hypersonic's in-memory database. It got me thinking that an in-memory EJB container would be just as cool. JBoss is architected so well that I figured there must be a way to do it. I'm currently trying to add enough stuff to the minimal configuration to support the deployment of EJB's, and then I'll see if it's not possible to invoke that configuration from the setup of my JUnit test runner. Does anyone else think this is possible or even worth pursuing? -- Jim Demyanovich, Craig - Apogent wrote: Jim, I currently do not unit test either Entity or Session Beans. Entity Beans are trivial to write, and I trust that the application server will persist them as advertised. To unit test Session Beans would require that they be deployed. Since deployment complicates unit testing and complicated or difficult unit tests suggest that the design could be done differently/better, I design Session Beans to be controllers of a number of collaborating objects. These objects are simply business objects that encode the business logic of the system. Since they are plain Java classes, I can unit test them very easily. Consider a message-driven bean. As I generally design them, MDBs receive a message, hand it to a parser, hand the results of parsing to other objects that do something with the message contents, hand the results of that work to a communictator, which knows how to send the final results where they need to go. So, I don't test any part of the MDB; rather, I test the various collaborating business objects. If I'm confident that they all behave as expected, I'm confident that they will also do so when they interact via one another's interface. Hope that helps, Craig --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___
RE: [JBoss-user] Testing EJB's
There is an example in the jboss/testsuite/buid.xml of an ANT target that starts up JBoss, runs JUnit tests and then shutsdown JBoss. Note that this stuff hangs on Windows because of pause commands in the bat files launched in the background (unless fixed in the last couple weeks) and the shutdown command not only has a non-backward compatible arg format between 3.0.x and 3.2.x, but there are limitations on the JVM the server is compiled with and running with - I believe due to Java's godawful serialization ids. Not the same JVM as JUnit, but the next best thing for automated tests. I can give more info on how I used this stuff if you are interested. -Fred -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Dain Sundstrom Sent: Wednesday, December 11, 2002 12:29 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Testing EJB's If you want to test in JBoss, you will need to have JBoss running somehow. Unless you are running on a very old machine, the JBoss start up should be start fairly quickly (under 30 sec). I usually just leave a JBoss instance running, and test over and over again. -dain On Wednesday, December 11, 2002, at 11:15 AM, Jim Crossley wrote: Thanks, Dain. At first, I was encouraged by your reply, so I checked out the source, but it doesn't address my needs. At least, the branch I checked out (3.0 and jboss-head) could not run the testsuite successfully without first firing up JBoss. I want to be able to test my CMP's in an in-memory, lightweight EJB container that I can somehow quickly bootstrap from my JUnit testrunner. The CMP's would persist for the duration of the tests in the in-memory Hypersonic database. Perhaps EJB's are so resource intensive that something like this isn't feasible? -- Jim Dain Sundstrom [EMAIL PROTECTED] writes: Jim, How do you think we test JBoss? Take a look at the CMP tests in the testsuite. We have an addon to JUnit that can deploy and undeploy applications. Also we have a tool that can run the tests on the server side like (I wrote this to test local interfaces), but does not require a servlet tier. -dain On Tuesday, December 10, 2002, at 02:23 PM, Jim Crossley wrote: These are good points, and I appreciate yours and others' prompt replies. However, the solutions presented so far seem to force me to complicate my object model to facilitate testing. I agree that an app that is difficult to test probably suffers from poor design, but web apps by their very nature are difficult to test. The app I'm currently working on is very CRUD-ish; it does simple read/write maintenance on a bunch of related objects. I don't want the web tier to access the Entity beans directly -- this would violate the transactional requirements -- so they go through a Session Facade. Creating additional POJO's through which the session beans interact with the entities only adds an unnecessary layer of complexity IMHO. The app is currently implemented using OJB, and I'm interested in refactoring it to use CMP EJB's, which IMHO are much easier to create and maintain (with Xdoclet, of course) than OJB. The big benefit of using OJB, however, is that a user can easily test the entire app from end-to-end without deploying or even interacting with an external resource. This is possible with Hypersonic's in-memory database. It got me thinking that an in-memory EJB container would be just as cool. JBoss is architected so well that I figured there must be a way to do it. I'm currently trying to add enough stuff to the minimal configuration to support the deployment of EJB's, and then I'll see if it's not possible to invoke that configuration from the setup of my JUnit test runner. Does anyone else think this is possible or even worth pursuing? -- Jim Demyanovich, Craig - Apogent wrote: Jim, I currently do not unit test either Entity or Session Beans. Entity Beans are trivial to write, and I trust that the application server will persist them as advertised. To unit test Session Beans would require that they be deployed. Since deployment complicates unit testing and complicated or difficult unit tests suggest that the design could be done differently/better, I design Session Beans to be controllers of a number of collaborating objects. These objects are simply business objects that encode the business logic of the system. Since they are plain Java classes, I can unit test them very easily. Consider a message-driven bean. As I generally design them, MDBs receive a message, hand it to a parser, hand the results of parsing to other objects that do something with the message contents, hand the results of that work to a communictator, which knows how to send the final results where they need to go. So, I don't test any part of the MDB; rather, I test the various collaborating business objects. If I'm confident that they all
RE: [JBoss-user] Testing EJB's
Title: RE: [JBoss-user] Testing EJB's My advice will be to expose the remote interface of the component, so that you can test is with standard JUnit test cases. Its easy and you test framework is simple. But, you have to deploy your component to JBoss -Original Message- From: Jim Crossley [mailto:[EMAIL PROTECTED]] Sent: 10 December 2002 12:53 To: jboss-user Subject: [JBoss-user] Testing EJB's What's the current best practice for unit testing EJB's, (both Entity and Session)? I'm trying to avoid having to deploy them to a separate JBoss instance to test them. More precisely, I want to be able to deploy them to an in-memory container, if possible, similar to Hypersonic's in-memory database. Ideally, the EJB container would be running within the JVM of the JUnit test runner, persisting my CMP beans to the memory-resident Hypersonic db. Possible or stupid? -- Jim --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Testing EJB's
Hi - Not sure if I completely understand your question, but we use JUnitEE, which runs as a servlet inside the container. It invokes your unit tests and displays the results in HTML format. Very nice. Personally, we always run tests on the remote interfaces of our EJBs so that we can test them remotely as well as from inside the container. You will have to deploy your EJBs to the JBoss app server tho, as well as the tests and test servlet. Hope this helps. http://junitee.sourceforge.net/ Robert -Original Message- From: Jim Crossley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 9:53 AM To: jboss-user Subject: [JBoss-user] Testing EJB's What's the current best practice for unit testing EJB's, (both Entity and Session)? I'm trying to avoid having to deploy them to a separate JBoss instance to test them. More precisely, I want to be able to deploy them to an in-memory container, if possible, similar to Hypersonic's in-memory database. Ideally, the EJB container would be running within the JVM of the JUnit test runner, persisting my CMP beans to the memory-resident Hypersonic db. Possible or stupid? -- Jim --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Testing EJB's
Jim, I currently do not unit test either Entity or Session Beans. Entity Beans are trivial to write, and I trust that the application server will persist them as advertised. To unit test Session Beans would require that they be deployed. Since deployment complicates unit testing and complicated or difficult unit tests suggest that the design could be done differently/better, I design Session Beans to be controllers of a number of collaborating objects. These objects are simply business objects that encode the business logic of the system. Since they are plain Java classes, I can unit test them very easily. Consider a message-driven bean. As I generally design them, MDBs receive a message, hand it to a parser, hand the results of parsing to other objects that do something with the message contents, hand the results of that work to a communictator, which knows how to send the final results where they need to go. So, I don't test any part of the MDB; rather, I test the various collaborating business objects. If I'm confident that they all behave as expected, I'm confident that they will also do so when they interact via one another's interface. Hope that helps, Craig --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Testing EJB's
This aproach does not test deployment descriptors. I've had quite a few problems with missing ejb-ref, resource-ref, etc. What is especially bad is that you do not know if your deployment descriptor has a problem until you actually try to execute line of code that uses missing resource. Demyanovich, Craig - Apogent wrote: Jim, I currently do not unit test either Entity or Session Beans. Entity Beans are trivial to write, and I trust that the application server will persist them as advertised. To unit test Session Beans would require that they be deployed. Since deployment complicates unit testing and complicated or difficult unit tests suggest that the design could be done differently/better, I design Session Beans to be controllers of a number of collaborating objects. These objects are simply business objects that encode the business logic of the system. Since they are plain Java classes, I can unit test them very easily. Consider a message-driven bean. As I generally design them, MDBs receive a message, hand it to a parser, hand the results of parsing to other objects that do something with the message contents, hand the results of that work to a communictator, which knows how to send the final results where they need to go. So, I don't test any part of the MDB; rather, I test the various collaborating business objects. If I'm confident that they all behave as expected, I'm confident that they will also do so when they interact via one another's interface. Hope that helps, Craig -- Igor Fedorenko Think smart. Think automated. Think Dynamics. www.thinkdynamics.com --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Testing EJB's
These are good points, and I appreciate yours and others' prompt replies. However, the solutions presented so far seem to force me to complicate my object model to facilitate testing. I agree that an app that is difficult to test probably suffers from poor design, but web apps by their very nature are difficult to test. The app I'm currently working on is very CRUD-ish; it does simple read/write maintenance on a bunch of related objects. I don't want the web tier to access the Entity beans directly -- this would violate the transactional requirements -- so they go through a Session Facade. Creating additional POJO's through which the session beans interact with the entities only adds an unnecessary layer of complexity IMHO. The app is currently implemented using OJB, and I'm interested in refactoring it to use CMP EJB's, which IMHO are much easier to create and maintain (with Xdoclet, of course) than OJB. The big benefit of using OJB, however, is that a user can easily test the entire app from end-to-end without deploying or even interacting with an external resource. This is possible with Hypersonic's in-memory database. It got me thinking that an in-memory EJB container would be just as cool. JBoss is architected so well that I figured there must be a way to do it. I'm currently trying to add enough stuff to the minimal configuration to support the deployment of EJB's, and then I'll see if it's not possible to invoke that configuration from the setup of my JUnit test runner. Does anyone else think this is possible or even worth pursuing? -- Jim Demyanovich, Craig - Apogent wrote: Jim, I currently do not unit test either Entity or Session Beans. Entity Beans are trivial to write, and I trust that the application server will persist them as advertised. To unit test Session Beans would require that they be deployed. Since deployment complicates unit testing and complicated or difficult unit tests suggest that the design could be done differently/better, I design Session Beans to be controllers of a number of collaborating objects. These objects are simply business objects that encode the business logic of the system. Since they are plain Java classes, I can unit test them very easily. Consider a message-driven bean. As I generally design them, MDBs receive a message, hand it to a parser, hand the results of parsing to other objects that do something with the message contents, hand the results of that work to a communictator, which knows how to send the final results where they need to go. So, I don't test any part of the MDB; rather, I test the various collaborating business objects. If I'm confident that they all behave as expected, I'm confident that they will also do so when they interact via one another's interface. Hope that helps, Craig --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Testing EJB's
Jim, How do you think we test JBoss? Take a look at the CMP tests in the testsuite. We have an addon to JUnit that can deploy and undeploy applications. Also we have a tool that can run the tests on the server side like (I wrote this to test local interfaces), but does not require a servlet tier. -dain On Tuesday, December 10, 2002, at 02:23 PM, Jim Crossley wrote: These are good points, and I appreciate yours and others' prompt replies. However, the solutions presented so far seem to force me to complicate my object model to facilitate testing. I agree that an app that is difficult to test probably suffers from poor design, but web apps by their very nature are difficult to test. The app I'm currently working on is very CRUD-ish; it does simple read/write maintenance on a bunch of related objects. I don't want the web tier to access the Entity beans directly -- this would violate the transactional requirements -- so they go through a Session Facade. Creating additional POJO's through which the session beans interact with the entities only adds an unnecessary layer of complexity IMHO. The app is currently implemented using OJB, and I'm interested in refactoring it to use CMP EJB's, which IMHO are much easier to create and maintain (with Xdoclet, of course) than OJB. The big benefit of using OJB, however, is that a user can easily test the entire app from end-to-end without deploying or even interacting with an external resource. This is possible with Hypersonic's in-memory database. It got me thinking that an in-memory EJB container would be just as cool. JBoss is architected so well that I figured there must be a way to do it. I'm currently trying to add enough stuff to the minimal configuration to support the deployment of EJB's, and then I'll see if it's not possible to invoke that configuration from the setup of my JUnit test runner. Does anyone else think this is possible or even worth pursuing? -- Jim Demyanovich, Craig - Apogent wrote: Jim, I currently do not unit test either Entity or Session Beans. Entity Beans are trivial to write, and I trust that the application server will persist them as advertised. To unit test Session Beans would require that they be deployed. Since deployment complicates unit testing and complicated or difficult unit tests suggest that the design could be done differently/better, I design Session Beans to be controllers of a number of collaborating objects. These objects are simply business objects that encode the business logic of the system. Since they are plain Java classes, I can unit test them very easily. Consider a message-driven bean. As I generally design them, MDBs receive a message, hand it to a parser, hand the results of parsing to other objects that do something with the message contents, hand the results of that work to a communictator, which knows how to send the final results where they need to go. So, I don't test any part of the MDB; rather, I test the various collaborating business objects. If I'm confident that they all behave as expected, I'm confident that they will also do so when they interact via one another's interface. Hope that helps, Craig --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Testing EJB's
Igor, I'm not sure whether I consider the problem that you describe as one for unit tests, at least not for me and not now. I'll have to think about it more when I'm doing EJB work again. So far, the Session Beans that I've coded have not suffered from this problem, somewhat to my surprise: I do the deployment descriptors by hand. Someday I will download and use xdoclet or try the new EJB features of IDEA 3.0 (http://www.intellij.com/idea). In the end, I think that my design approach has helped me create Session Beans that are simple enough that the likelihood of having such problems is greatly minimized. Craig -Original Message- From: Igor Fedorenko [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 3:06 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Testing EJB's This aproach does not test deployment descriptors. I've had quite a few problems with missing ejb-ref, resource-ref, etc. What is especially bad is that you do not know if your deployment descriptor has a problem until you actually try to execute line of code that uses missing resource. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
RE: [JBoss-user] Testing EJB's
Jim, I've never written a web app. If I planned to write one, I would do my best to separate the user interface parts from the business logic parts from the persistence layer parts. I know that it may not be entirely possible to achieve a complete separation of layers, but we should strive to do so as much as is possible for each application. With such a separation of layers, you could unit test the model, or business logic, of your application separately from the user interface (the web pages) or the persistence layer (Entity Beans). Other people on this and other lists, like the JUnit, Test-Driven Development, Refactoring and Extreme Programming lists at http://groups.yahoo.com, have reported success with such a design. Perhaps you could seek some advice from those lists re: unit testing applications like yours. If I find the time, I will do some searches. Craig -Original Message- From: Jim Crossley [mailto:[EMAIL PROTECTED]] Sent: Tuesday, December 10, 2002 3:24 PM To: [EMAIL PROTECTED] Subject: Re: [JBoss-user] Testing EJB's These are good points, and I appreciate yours and others' prompt replies. However, the solutions presented so far seem to force me to complicate my object model to facilitate testing. I agree that an app that is difficult to test probably suffers from poor design, but web apps by their very nature are difficult to test. The app I'm currently working on is very CRUD-ish; it does simple read/write maintenance on a bunch of related objects. I don't want the web tier to access the Entity beans directly -- this would violate the transactional requirements -- so they go through a Session Facade. Creating additional POJO's through which the session beans interact with the entities only adds an unnecessary layer of complexity IMHO. snipped the rest... --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
Re: [JBoss-user] Testing EJB's
On Tue, Dec 10, 2002 at 02:32:17PM -0600, Dain Sundstrom wrote: Jim, How do you think we test JBoss? Take a look at the CMP tests in the testsuite. We have an addon to JUnit that can deploy and undeploy applications. Also we have a tool that can run the tests on the server side like (I wrote this to test local interfaces), but does not require a servlet tier. -dain The only reason I can find to use this junitee is testing localinterfaces and to solve the problem with security. There is a difference regarding security because you can specify a run-as parameter for web-apps but not for clients (like a junit-client), AFAIK. Is there any easy way to do this (other than logging in with a real user)? On Tuesday, December 10, 2002, at 02:23 PM, Jim Crossley wrote: These are good points, and I appreciate yours and others' prompt replies. However, the solutions presented so far seem to force me to complicate my object model to facilitate testing. I agree that an app that is difficult to test probably suffers from poor design, but web apps by their very nature are difficult to test. The app I'm currently working on is very CRUD-ish; it does simple read/write maintenance on a bunch of related objects. I don't want the web tier to access the Entity beans directly -- this would violate the transactional requirements -- so they go through a Session Facade. Creating additional POJO's through which the session beans interact with the entities only adds an unnecessary layer of complexity IMHO. The app is currently implemented using OJB, and I'm interested in refactoring it to use CMP EJB's, which IMHO are much easier to create and maintain (with Xdoclet, of course) than OJB. The big benefit of using OJB, however, is that a user can easily test the entire app from end-to-end without deploying or even interacting with an external resource. This is possible with Hypersonic's in-memory database. It got me thinking that an in-memory EJB container would be just as cool. JBoss is architected so well that I figured there must be a way to do it. I'm currently trying to add enough stuff to the minimal configuration to support the deployment of EJB's, and then I'll see if it's not possible to invoke that configuration from the setup of my JUnit test runner. Does anyone else think this is possible or even worth pursuing? -- Jim Demyanovich, Craig - Apogent wrote: Jim, I currently do not unit test either Entity or Session Beans. Entity Beans are trivial to write, and I trust that the application server will persist them as advertised. To unit test Session Beans would require that they be deployed. Since deployment complicates unit testing and complicated or difficult unit tests suggest that the design could be done differently/better, I design Session Beans to be controllers of a number of collaborating objects. These objects are simply business objects that encode the business logic of the system. Since they are plain Java classes, I can unit test them very easily. Consider a message-driven bean. As I generally design them, MDBs receive a message, hand it to a parser, hand the results of parsing to other objects that do something with the message contents, hand the results of that work to a communictator, which knows how to send the final results where they need to go. So, I don't test any part of the MDB; rather, I test the various collaborating business objects. If I'm confident that they all behave as expected, I'm confident that they will also do so when they interact via one another's interface. Hope that helps, Craig --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user -- MVH Marius Kotsbak Boost communications AS --- This sf.net
Re: [JBoss-user] Testing EJB's
On Tue, Dec 10, 2002 at 03:23:31PM -0500, Jim Crossley wrote: The app I'm currently working on is very CRUD-ish; it does simple read/write maintenance on a bunch of related objects. I don't want the web tier to access the Entity beans directly -- this would violate the transactional requirements -- so they go through a Session Facade. Creating additional POJO's through which the session beans interact with the entities only adds an unnecessary layer of complexity IMHO. The app is currently implemented using OJB, and I'm interested in refactoring it to use CMP EJB's, which IMHO are much easier to create and maintain (with Xdoclet, of course) than OJB. Interesting. Isn't there a extention to xdoclet for OJB then? If that is all that make it hard to maintain, I can't understand what you are talking about. I am in fact considering moving from CMP EJBs to hibernate, or other similar products like OJB, because of the complexity of CMPs. What I find complex and hard to create and maintain is the CMP-beans and the corresponding VO-objects. As I have read, you can work with ordinary java objects when using OJB/hibernate and use them as VO-objects. It is also annoying that you have to rerun xdoclet for every change in the CMP beans to have the clients (SL Session Beans for instance) that are using the CMPs to compile. Not at least is one reason to move away from CMP the slow performance. I am not sure other O/R-products are better but I think it is worth a try. -- MVH Marius Kotsbak Boost communications AS --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
