two separate managers with same DAO and domaon model class
|
|
jackalista
|
Hi,
I want to create a secondary manager interface (i/f) and implementation for an existing DAO and (hibernate) domain model class. I've been using the dao and model class a lot so am not having trouble with them but when I tried to create a 2nd manager i/f & impl, I got strange errors when running the manager test. The error I'm seeing doesn't seem to make sense, it's complaining about a class cast that shouldn't be a problem. The reason I want to do this is because I want a 2nd-ary service class to use in a mule message flow and I don't want that flow invoked when the primary service class is in use, just when the 2nd-ary service class is being used. I *could* create a 2nd-ary dao i/f and impl too but that seems to be wasteful so I am trying to do it this way but perhaps I'm seeing some auto-wiring problems with what I'm trying to do? I'm using the Order.java domain class I've got which I've been using successfully without issue and also the OrderDao.java / OrderDaoHibernate.java. I have an Ordermanager.java and OrderManagerImpl.java, which I've exposed as web services and which I've tested and used a fair amount so that part works. I have done some more annotation to make the service amenable to mule and CXF, which is doc'ed here: post about integrating mule and appfuse 2.02 I then created an AggregatingOrderManager.java and an AggregatingOrderManagerImpl.java and declared the manager in my applicationContext.xml (I'm creating my own managers, daos etc. rather than using the Generic or Universal ones). I injected the orderDao from above into this new manager so I've now got 2 managers that use the same dao which doesn't seem like it would be a problem. Here's the declaration, I'll show the orderDao, orderManager, and then the new aggregatoingOrdermanager: <bean id="orderDao" class="org.jackalista.integration.dao.hibernate.OrderDaoHibernate"> <property name="sessionFactory" ref="sessionFactory"/> </bean> <bean id="orderManager" class="org.jackalista.integration.service.impl.OrderManagerImpl"> <constructor-arg ref="orderDao"/> </bean> <bean id="aggregatingOrderManager" class="org.jackalista.integration.service.impl.AggregatingOrderManagerImpl"> <constructor-arg ref="orderDao"/> </bean> The AggregatingManager.java looks like this (I removed the imports for clarity): @WebService public interface AggregatingOrderManager extends GenericManager<Order, Long> { /** * pass through to save an order */ @WebResult(name="saveOrderResult") public Order placeOrder( @WebParam(name="order") Order order); } The manager implementation looks like the following, which uses the original orderDao: @WebService(serviceName = "AggregatingOrderService", endpointInterface = "org.jackalista.integration.service.AggregatingOrderManager") public class AggregatingOrderManagerImpl extends GenericManagerImpl<Order, Long> implements AggregatingOrderManager { OrderDao orderDao; public AggregatingOrderManagerImpl(OrderDao orderDao) { super(orderDao); this.orderDao = orderDao; } public Order placeOrder(Order order) { log.debug( "received order: "+order ); //return super.save(order); return this.orderDao.save(order); } } The Manager test looks like this: @Test public void testPlaceOrder() { log.debug("testing placeOrder..."); final Order order = new Order(); order.setName( "test order" ); order.setDescription( "this is a test order" ); order.setCreatedBy( "testadmin" ); order.setModifiedBy( "testadmin" ); order.setQuantity( new Long( 1 ) ); // enter all required fields // set expected behavior on dao context.checking(new Expectations() {{ one(dao).save(with(same(order))); }}); manager.placeOrder(order); } When I run this manager test, I'm getting a class cast exception, which I don't understand, it looks like the return value from the (generic manager superclass) "save" method is an java.lang.Object and can't be cast to an Order, which is what the the OrderDaoHibernate that extends it is trying to return. The line specified in the exception trace says the error is happning at this line in the manager implemenbtation class where the generic method save is invoked and it's result (which is usually an Order but is somehow a java.lang.Object here) is returned as the returnb value for the method call: return this.orderDao.save(order); Here's the exception trace, does anybody know why this is happening? ------------------------------------------------------- T E S T S ------------------------------------------------------- Running org.jackalista.integration.service.impl.AggregatingOrderManagerImplTest [integration] DEBUG [main] AggregatingOrderManagerImplTest.testPlaceOrder(33) | testing placeOrder... [integration] DEBUG [main] AggregatingOrderManagerImpl.placeOrder(29) | received order: org.jackalista.integration.model.Order@15093f1[ name=test order description=this is a test order quantity=1 createdBy=testadmin createdDate=Tue Nov 10 09:28:25 PST 2009 modifiedBy=testadmin modifiedDate=Tue Nov 10 09:28:25 PST 2009 ] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.313 sec <<< FAILURE! testPlaceOrder(org.jackalista.integration.service.impl.AggregatingOrderManagerImplTest) Time elapsed: 0.296 sec <<< ERROR! java.lang.ClassCastException: java.lang.Object cannot be cast to org.jackalista.integration.model.Order at org.jackalista.integration.service.impl.AggregatingOrderManagerImpl.placeOrder(AggregatingOrderManagerImpl.java:31) at org.jackalista.integration.service.impl.AggregatingOrderManagerImplTest.testPlaceOrder(AggregatingOrderManagerImplTest.java:48) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.junit.internal.runners.TestMethod.invoke(TestMethod.java:59) at org.jmock.integration.junit4.JMock$1.invoke(JMock.java:36) at org.junit.internal.runners.MethodRoadie.runTestMethod(MethodRoadie.java:98) at org.junit.internal.runners.MethodRoadie$2.run(MethodRoadie.java:79) at org.junit.internal.runners.MethodRoadie.runBeforesThenTestThenAfters(MethodRoadie.java:87) at org.junit.internal.runners.MethodRoadie.runTest(MethodRoadie.java:77) at org.junit.internal.runners.MethodRoadie.run(MethodRoadie.java:42) at org.junit.internal.runners.JUnit4ClassRunner.invokeTestMethod(JUnit4ClassRunner.java:88) at org.junit.internal.runners.JUnit4ClassRunner.runMethods(JUnit4ClassRunner.java:51) at org.junit.internal.runners.JUnit4ClassRunner$1.run(JUnit4ClassRunner.java:44) at org.junit.internal.runners.ClassRoadie.runUnprotected(ClassRoadie.java:27) at org.junit.internal.runners.ClassRoadie.runProtected(ClassRoadie.java:37) at org.junit.internal.runners.JUnit4ClassRunner.run(JUnit4ClassRunner.java:42) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345) at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009) Results : Tests in error: testPlaceOrder(org.jackalista.integration.service.impl.AggregatingOrderManagerImplTest) |
||||||||||||||||
|
jackalista
|
Hey there...
Well, I resolved this by creating a secondary dao and dao implementation (hibernate based) which kind of surprises me. Both managers and daos operate on the same domain model class and I really only needed the manager interface and impl but I couldn't figure out what was blowing up. When I created the secondary dao and added that in, no sweat, it just worked... Matt, do you know why this is? I'm kind of surprised... For example, *both* of my daos and mgr's that operate on the single domain model class are probably sharing the same Generic manager and dao superclass, right? I'd love to have a clearer understanding of why this was a problem without the daos, if you're in the know...!! BTW, I love your ideas for the future of appfuse. I took a split second look at grails and a longer, client mandated look at seam and frankly, I couldn't sell many of our clients on either of those, compared to the Java EE standard that many of our (admittedly pretty corporate) clients are looking for. I also am wondering (& have been for a while) about the future of web UIs as currently implemented, SOFEA makes a lot of sense so GWT and / or flex (I'd prefer both I think) sound good to me... --j
|
||||||||||||||||
mraible
|
In reply to this post
by jackalista
I'm unsure of what could be causing your issues w/o trying to reproduce the problem myself. The only thing I can think of is your OrderManager and AggregatingOrderManager have the same superclass and types. Maybe you should extend one from the other to eliminate confusion.
Matt On Tue, Nov 10, 2009 at 11:04 AM, jackalista <[hidden email]> wrote:
|
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
