Search:

Attached as requested. Looking forward to your email.

Thanks,
Ryan Ovrevik

Sorry... I created the patch and didn't attach it to the email.
I didn't see what appeared to be a similar jira issue to attach it to so I put it here.

Thanks,
Ryan

Well, I am not sure that the existing high-level use cases are affected.

I am guessing the current use cases are something like:
• Roo shall provide the user with the capability to create fully...

I have implemented the capability to supplement the existing project/maven addon with additional templates.
With this new functionality, one can easily add new templates defined by resources...

The problem is that the jndi-based bean is being instantiated out side of any container’s context and the InitialContext does not have the information it needs to create the real jndi implementation

The reason your table is not reflecting updates as you expect is because the change has not occurred yet. When you create another thread, you are asking the vm to execute the runnable’s run method...

Oh… that is a definite possibility of the situation giving the opportunity modification to occur out from under the iterator (and an astute speculation).

I think calling it a threading issue is...

I don’t think that this actually has anything to do with Spring or threading.

I think it is simply a case of how the Java collections API is designed. Iterators are not meant to function across...

Your assumption is correct... the default is for beans to be singletons. You are wanting to use prototype beans.

Read the "Bean Scopes" section of the The Spring Framework - Reference...