RE: Rollback transactions in unit testing
Marcin, the strategy you suggest should also work and is especially good for prototyping or smaller projects. In our case where we have a huge application with (>1.5 Mio LoC, > 1000 EJBs, > 100 database tables with complex relationships) we cannot drop (or empty) and create tables in junit tests. This would heavily impact the development and testing. this is the reason why in such cases a rollback after a unit test instead of makes sense. regards, andreas Marcin Kwapisz-2 wrote: > > [Marcin Kwapisz] > I do not understand why you want to rollback committed transaction, > especially in unit test. Even, I do not know how to do it in JEE > application. > Maybe our way will suit you: > > 1. set drop and create strategy in persistence.xml (property name depends > on JPA provider, we have separate file for unit testing) > 2. Start OpenEJB (for example: perform ejb lookup) -> database should be > empty now > 3. Create initial set of data in tables > 4. Run test > 5. Shutdown OpenEJB > > Now, you can repeat steps 2-5 for another tests > > Regards > -- > Marcin Kwapisz > Division of Computer Networks > Technical Univeristy of Lodz, Poland > > > > > > -- View this message in context: http://www.nabble.com/Rollback-transactions-in-unit-testing-tp19724095p19749405.html Sent from the OpenEJB User mailing list archive at Nabble.com.
RE: Rollback transactions in unit testing
[Marcin Kwapisz] I do not understand why you want to rollback committed transaction, especially in unit test. Even, I do not know how to do it in JEE application. Maybe our way will suit you: 1. set drop and create strategy in persistence.xml (property name depends on JPA provider, we have separate file for unit testing) 2. Start OpenEJB (for example: perform ejb lookup) -> database should be empty now 3. Create initial set of data in tables 4. Run test 5. Shutdown OpenEJB Now, you can repeat steps 2-5 for another tests Regards -- Marcin Kwapisz Division of Computer Networks Technical Univeristy of Lodz, Poland
Unknown error in Assembler for MessageDriven bean
Hi, I'm trying to deploy a bunch of MDBs on openejb and encounter this error: 2008-09-30 15:52:51,328 - ERROR - FATAL ERROR: Unknown error in Assembler. Plea se send the following stack trace and this message to [EMAIL PROTECTED] : java.lang.IllegalStateException: When annotating a bean class as @MessageDriven without declaring messageListenerInterface, the bean must implement exactly one interface, no more and no less. beanClass=com.oz.shared.transcoding.sti.protoco l.ejb.TranscodingProviderMessageListenerBean interfaces= at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.de ploy(AnnotationDeployer.java:854) (see full stack below) Those EJB were deployed successfully in weblogic, and I didn't yet properly create the corresponding Deployment descriptors for openejb – but this error seems an internal one and given My EJB are 2.0 (no annotations), I find it strange it complains about this annotation. Any ideas someone ? /jog 2008-09-30 15:52:51,328 - ERROR - FATAL ERROR: Unknown error in Assembler. Plea se send the following stack trace and this message to [EMAIL PROTECTED] : java.lang.IllegalStateException: When annotating a bean class as @MessageDriven without declaring messageListenerInterface, the bean must implement exactly one interface, no more and no less. beanClass=com.oz.shared.transcoding.sti.protoco l.ejb.TranscodingProviderMessageListenerBean interfaces= at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.de ploy(AnnotationDeployer.java:854) at org.apache.openejb.config.AnnotationDeployer$ProcessAnnotatedBeans.de ploy(AnnotationDeployer.java:489) at org.apache.openejb.config.AnnotationDeployer.deploy(AnnotationDeploye r.java:169) at org.apache.openejb.config.ConfigurationFactory$Chain.deploy(Configura tionFactory.java:148) at org.apache.openejb.config.ConfigurationFactory.configureApplication(C onfigurationFactory.java:440) at org.apache.openejb.config.ConfigurationFactory.configureApplication(C onfigurationFactory.java:391) at org.apache.openejb.config.ConfigurationFactory.getOpenEjbConfiguratio n(ConfigurationFactory.java:309) at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:2 49) at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:149) at org.apache.openejb.OpenEJB.init(OpenEJB.java:288) at org.apache.openejb.server.Server.init(Server.java:63) at org.apache.openejb.server.Main.initServer(Main.java:155) at org.apache.openejb.server.Main.main(Main.java:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.openejb.cli.MainImpl.main(MainImpl.java:151) at org.apache.openejb.cli.Bootstrap.main(Bootstrap.java:103) 2008-09-30 15:52:51,331 - FATAL - OpenEJB has encountered a fatal error and cann ot be started: Assembler failed to build the container system. org.apache.openejb.OpenEJBException: java.lang.IllegalStateException: When annot ating a bean class as @MessageDriven without declaring messageListenerInterface, the bean must implement exactly one interface, no more and no less. beanClass=c om.oz.shared.transcoding.sti.protocol.ejb.TranscodingProviderMessageListenerBean interfaces=: When annotating a bean class as @MessageDriven without declaring m essageListenerInterface, the bean must implement exactly one interface, no more and no less. beanClass=com.oz.shared.transcoding.sti.protocol.ejb.TranscodingPro viderMessageListenerBean interfaces= at org.apache.openejb.assembler.classic.Assembler.build(Assembler.java:2 63) at org.apache.openejb.OpenEJB$Instance.(OpenEJB.java:149) at org.apache.openejb.OpenEJB.init(OpenEJB.java:288) at org.apache.openejb.server.Server.init(Server.java:63) at org.apache.openejb.server.Main.initServer(Main.java:155) at org.apache.openejb.server.Main.main(Main.java:128) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.openejb.cli.MainImpl.main(MainImpl.java:151) at org.apache.openejb.cli.Bootstrap.main(Bootstrap.java:103) Caused by: java.lang.IllegalStateException: When annotating a bean class as @Mes sageDriven without declaring messageListenerInterface, the bean must implement e xactly one interface, no more and no less. beanClass=com.oz.shared.transcoding.s ti.proto
Re: exceptions handling with Webservices
Replying to myself... As a "workaround", I defined a dumb @HandlerChain (the dumbest possible... returns true to everything and an empty set for the headers) and my webfault started magically to be processed as expected. Bug or feature ??? Unfortunately, I have no time right now to look more thouroughly into the code of OpenEJB to see exactly what happened. But I definitively will as this seems to be too magic to me... To make my point clearer, I join a Maven/Eclipse project of a simple case that emphasises this. http://www.nabble.com/file/p19747196/FunnyFault.zip FunnyFault.zip I hope that somebody can come with an explanation... Thanks anyway for your great work on OpenEJB ! Regards, Juan Manuel uglything wrote: > > Hie. > > Here is my problem : > > I have a webservice defined in an OpenEJB server (embedded CXF and > JAXB-WS) > > This webservice declares a method that throws a checked exception that > is declared as a @WebFault. > > When the client calls the server and when the webmethod sends an > exception, the client receives a generic SoapFaultException with an > ApplicationException inside. > I expected my client to receive my business checked exception... > > After having investigated a little bit, it appears that the > WebFaultOutInterceptor class in the bundled CXF version works as > follow : > > When a fault is generated, it gets the cause. If the cause (or one of > it's parents) is annotated as a WebFault, a SOAP Fault containing the > correct webfault is formatted and sent and the client receives the > correct checked exception type as a result. > > If not, it formats a default SOAP Fault with the message of the exception. > So the client receives a generic SOAPFaultException. > > If I use CXF as a standalone server without OpenEJB, my exception is > correctly catched in the WebFaultOutInterceptor and as it is @WebFault > anotated, formats the corresponding soap fault. > > In OpenEJB, when the exception appears on the server, the Stateless > container catches it, processes it and chains it to the transaction > manager which in the end throws a new ApplicationException with my > exception as a cause. > But what the WebFaultOutInterceptor receives in this case is an > ApplicationException, which is NOT a @WebFault. So the interceptor > proceses this exception as a generic non-checked exception. Hence the > non typed exception on the client side... > > Having realized that I tried to skip the new ApplicationException > generation by > > 1- marking my stateless webservice as nontransactional > > @Stateless > @WebService(...) > @TransactionManagement(TransactionManagementType.BEAN) > @TransactionAttribute(TransactionAttributeType.NOT_SUPPORTED) > class MyClass ... > > 2 - marking my exception as @ApplicationException > > as it was my understanding of the specifications that > @ApplicationException should be re-thrown by the container as-is... > > both actions where desperately useless... > > So what can I do to have my server sending checked types ? > > Thanks anyway for the time you will spend on that problem. > -- View this message in context: http://www.nabble.com/exceptions-handling-with-Webservices-tp19668275p19747196.html Sent from the OpenEJB User mailing list archive at Nabble.com.
