jbbarquero (84) [Avatar] Offline
#1
Hello,

I don't see the source code for the chapter 10, not at https://github.com/krimple/spring-roo-in-action-examples nor in the zip from the book main page.

Did I miss something?

Thank you very much.
ken.rimple (246) [Avatar] Offline
#2
Re: Chapter 10 source code
Right. Let me check with Srini on this. Also, in the move to git, I may have inadvertently forgotten to check it in.
jbbarquero (84) [Avatar] Offline
#3
Re: Chapter 10 source code
OK, thanks.

In the meantime, copy-paste from the book works well.
srini.penchikala (20) [Avatar] Offline
#4
Re: Chapter 10 source code
I found chapter 10 example code inside chapter 8 directory (link below).

https://github.com/krimple/spring-roo-in-action-examples/tree/master/chapter-08-security/chapter-10

But the JMS classes in chapter-10 folder are not the latest version. They don't have the design refactoring changes I did to simplify the JMS testing logic. I will upload the latest chapter-10 code this weekend and send another message to the group here.

Thanks
Srini
jbbarquero (84) [Avatar] Offline
#5
Re: Chapter 10 source code
Thank you very much for your effort.

It would be a good idea to also include the code as a downloadable zip in the book web page at manning.com, once the book get published.
srini.penchikala (20) [Avatar] Offline
#6
Re: Chapter 10 source code
Hi,

I uploaded the new version of chapter 10 source code to github repo. Checkout the following link:

https://github.com/krimple/spring-roo-in-action-examples/tree/master/chapter-10-email-jms

Let me know if you have any questions or run into any problems running the test classes.

Thanks
Srini
MikB (202) [Avatar] Offline
#7
Re: Chapter 10 source code
That's great Srini! Thank you.
jvnadshab (1) [Avatar] Offline
#8
Re: Chapter 10 source code
Just wish to say your post is as surprising. The clarity in your post is just nice and i could assume you are an expert on this subject. Fine with your permission allow me to grab manning feed to keep updated with forthcoming post. Budget Rajasthan Tours Thanks a million.
jbbarquero (84) [Avatar] Offline
#9
Re: Chapter 10 source code
Hello:

WARNING

I was trying to create a JMS using the explanations from the chapter 10, but using a previous project with JPA configured and working (ie, the tests succeed)

I created a QUEUE and a Listener, just like in the 10.5 chapter.

There was no problems when executing the tests separately, but when running as JUnit all the test folder in STS 3.0.0 I have this error:

java.rmi.server.ExportException: Port already in use: 1099; nested exception is: java.net.BindException: Address already in use: JVM_Bind

I've seen that the Spring CommonAnnotationBeanPostProcessor tries to invoke init method on ActiveMQ's XBeanBrokerService for each test class.

The first test executed was a success, that is, the first test class had no errors, but from this moment on, all the tests had errors.

CONFIGURATION

The JPA test is configurated in the _Roo_Integration_test aspect using:

@ContextConfiguration(locations = "classpath:/META-INF/spring/applicationContext*.xml")

The JMS test used the configuration from the book, in the very test class:

@ContextConfiguration(locations = {
"classpath:/META-INF/spring/applicationContext.xml",
"classpath:/META-INF/spring/applicationContext-jms.xml"
})

SOLUTION

I'd like to know best how test context works, because the solution was to configure both tests in the same way.

I chose @ContextConfiguration(locations = "classpath:/META-INF/spring/applicationContext*.xml") but with the other it works too.
jbbarquero (84) [Avatar] Offline
#10
Re: Chapter 10 source code
Interesting information regarding Context Configuration for testing in Spring:

10.3.5.2 Context management
http://static.springsource.org/spring/docs/3.1.x/spring-framework-reference/html/testing.html#testcontext-ctx-management

Find the explanation for "Context caching"

Since the tests are not load with the same combination of the configuration parameters, they don't belong to a unique test suite.

Thus, the application context should be reloaded. However, they run on the same JVM, where the JMX port is already in use.

I don't know if it's possible to stop the broker by closing the application context with a @DirtiesContext method, but I don't care, because having the same @ContextConfiguration for all the tests is what I really want.

Thanks for listening to me (actually, read my thoughts)