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

Once I finish this POST I realize that it's only for my relief, so you may ignore it.

This POST is about an issue that comes for trying to use a Roo web project (we call it "helper module") as a MAVEN JAR dependency for another Roo web project (that we call "main application")

We had a problem solved thanks to Ken Rimple who kindly gives us a lot of useful ideas, mainly in this POST: http://www.manning-sandbox.com/thread.jspa?threadID=46259

The new problem comes philosophically for not using Convention Over Configuration: Roo creates a unique web application and we want to mix code from two (or more) Roo projects)

The problem is that now we're trying to re-use the web classes: the Controllers.

The creation of the web application is a power feature of Roo. However, it comes with characteristics and bugs:
- When the web scaffold is created, it comes with the web application context XML file: webmvc-config.xml (in src/main/webapp/WEB-INF/spring/)
- It contains this two lines:

<mvc:annotation-driven conversion-service="applicationConversionService"/>

<bean class="com.malsolo.app.web.ApplicationConversionServiceFactoryBean" id="applicationConversionService"/>

- Roo creates the ApplicationConversionServiceFactoryBean for the entire application, but Roo puts it in the first package that you declare as web package.

For instance, if your first web scaffold is for helper classes, you will find the ApplicationConversionServiceFactoryBean in a package like com.malsolo.app.secondary.helper.web

Now I don't find the POST in the Spring forums where I receive an answer for this: Roo can't know the future structure of your packages for the web classes (Controllers) and it uses the first one.

But, what is the problem?

If I have a "main project" (one Roo web project) that tries to use classes from other Roo projects, there won't a way to reference all the that comes with them.

Even more:

If you have Enities with composed keys, I mean, Entities that use Embeddable classes (value-object) as indentifiers (actually, EmbeddedId in JPA jargon)...

...their Controllers will need a ConversionService, Autowired in their constructor, in order to show the REST urls with more than a unique value when creating, updating, showing and so on.

Besides

The Controllers have the ConversionService Autowired in the Constructor, actually via ASpectj with a .new(ConversionService conversionService) method (find it in the *_Roo_Controller.aj file)...

...if you try to extend a class, you'll have to override the constructor, BUT, the constructor doesn't accept the annotation @Qualifier, in order to choose one of the potential obects that could be autowired.

And even worst

There are some bugs regarding the customization of the Application Conversion Service:

http://forum.springsource.org/showthread.php?112524-Application-Conversion-Service-Customising

Why do you have to worry about that?

Well, there's no reason if you create a Roo application as expected.

So, why am I doing that?

Because the Roo script doesn't allow me to specify a lot of things I need because I will deploy the application in WebSphere with DB2. So I though that a repository of functional Roo projects could be used in new Roo projects.

And why do I tell you this issue?

Because it took me the whole day to discover the problem.

Thanks for reading.
MikB (202) [Avatar] Offline
#2
Re: ApplicationConversionService problems using a Roo web project from another
Great post. Thanks for sharing your experiences.
ken.rimple (246) [Avatar] Offline
#3
Re: ApplicationConversionService problems using a Roo web project from another
I think the best course of action right now is to post a link to this forum thread in the JIRA for issue 120- so they can see where the problems lie. They are a good group - sometimes it just takes making the case clear to them to see if they can address it.

The URL is:

https://jira.springsource.org/browse/ROO-120

And you can join and submit bugs as a third party. I think Javier you said you voted 120 up. I think I did as well (and will check) as it is important.

I'm looking into an alternative to what they do - maybe chaining Converters. I'll get back to you in a bit. It may be possible to do it with the generated code and also add other classes to a list of converters. I'll keep you updated.

Ken
bbaron (61) [Avatar] Offline
#4
Re: ApplicationConversionService problems using a Roo web project from another
Must be a quirk of JIRA, but ROO-120 has a priority of Trivial.
ken.rimple (246) [Avatar] Offline
#5
Re: ApplicationConversionService problems using a Roo web project from another
The FormattingServiceConversionFactoryBean is generated but the formatters are dynamically generated. Why not inject the others as @Autowired and then call their format registers?
Roo wont change the Java class, only its ITD.
Ken
jbbarquero (84) [Avatar] Offline
#6
Re: ApplicationConversionService problems using a Roo web project from another
Hello:

I have good news: it seems we'll see multi module maven support soon: http://forum.springsource.org/showthread.php?114394-Spring-Roo-Roadmap

Regarding ServiceConversion, I'll try to edit the Factory created in the main project in order to include in it the converters that already exists in the helper modules.

I need to review the Autowiring because there was an execution error, because the Spring context cannot choose among all the candidates when it tries to build the application, before using the mvc context and its namespace.

It happened the day before yesterday (yesterday was holiday in Madrid), so I'll continue on the next Monday.

Greetings.
ken.rimple (246) [Avatar] Offline
#7
Re: ApplicationConversionService problems using a Roo web project from another
> Hello:
>
> I have good news: it seems we'll see multi module
> maven support soon:
> http://forum.springsource.org/showthread.php?114394-Sp
> ring-Roo-Roadmap

That is good news indeed. I will reach out to Allen Stewart and see if I can get the basic info while updating the chapters. I cannot add any chapters but I can revise a few sections before our technical review.

Message was edited by:
ken.rimple
ken.rimple (246) [Avatar] Offline
#8
Re: ApplicationConversionService problems using a Roo web project from another
In version 1.2.0-M2. Alan Stewart just tagged it.
jbbarquero (84) [Avatar] Offline
#9
Re: ApplicationConversionService problems using a Roo web project from another
> The FormattingServiceConversionFactoryBean is
> generated but the formatters are dynamically
> generated. Why not inject the others as @Autowired
> and then call their format registers?
> Roo wont change the Java class, only its ITD.
> Ken

Well,

What I tried is to create a Controller by extending the one existing in the helper module. As it needs a ConversionService in the constructor, I provided with Autowiring one as expected:


@Autowired
public MyExtendedController(ConversionService conversionService) {
super(conversionService);
}

For providing this, Roo creates a class called ApplicationConversionServiceFactoryBean within the first web package created with the Roo's "controller" command.

This class extends org.springframework.format.support.FormattingConversionServiceFactoryBean that is "a factory for a {@link FormattingConversionService} " (a GenericConversionService that implements the desired ConversionService)

As you said, the converters are generated in the _Roo_ConversionService AspectJ and you can customize new converters using the ApplicationConversionServiceFactoryBean java class.

This is what I've done: I've just copied the converters from the .aj within the helper module to the ApplicationConversionServiceFactoryBean java class within the main Roo web project.

It would seem a cumbersome manual work, but it works fine, since I don't have to add any extra configuration in the webmvc-config.xml.

Take into account that these classes are using in the creation of the Spring container, and the @Qualifier annotation is not allowed in the constructor, the place where I must to add the @Autowired annotation (due to the inheritance that I made)
ken.rimple (246) [Avatar] Offline
#10
Re: ApplicationConversionService problems using a Roo web project from another
I see what you're saying. Sounds like maybe they need to square this with ROO-120 or perhaps in a future revision that supports multi-war applications and EARs. I don't get the feeling that ROO-120 will be an EAR-based approach, rather a WAR that aggregates other POM dependencies, but we'll see.

Ken
jbbarquero (84) [Avatar] Offline
#11
Re: ApplicationConversionService problems using a Roo web project from another
I agree.

According my experience, they are very reluctant to using EARs. In fact, Spring tries to avoid the need of EJBs, and there're few reasons for using EARs if you don't have JARs containing EJBs (in my case we use WebSphere and we're used to providing EARs only for historical reasons)

Besides, at development time, a war that can be deployed to a Servlet container (or in some kind of Cloud Service, I think that some things could change soon) is enough.

Furthermore, when I argued with them about the localization of the ApplicationConversionServiceFactoryBean, I realized they were right, because it's hard for a code generation tool to guess the final (and even the first) package layout of the project.

As you well said, we'll see.
stsmedia (1) [Avatar] Offline
#12
Re: ApplicationConversionService problems using a Roo web project from another
Hi guys,

Thanks for providing feedback on various Roo-related topics discussed in this thread. Apologies for responding delayed here. Usually, we monitor the Roo community forum (http://forum.springsource.org/forumdisplay.php?67-Roo).

As you have noted there is currently no awareness of multi-module configurations in Roo. This means the ApplicationConversionService will only provide converters for domain entities in the module Roo is currently maintaining. There are a number of options to add your own converters (while letting Roo still maintain the converters from the current module). The documentation for this can be found here http://static.springsource.org/spring-roo/reference/html-single/index.html#conversion-service

The ApplicationConversionService will initially be located in the same package as the controllers (for reasons I explained in the Roo forums) but you are free to move it to a separate package (within the same module until Roo-120 is resolved). Roo will be able to find it and add new converters to it via its ITD if needed.

If you feel that it would be beneficial to perform field injection rather than constructor injection of the ApplicationConversionService in MVC controllers, please open a Jira improvement ticket so we can review and adjust this.

There have also been various improvements with the Roo 1.2.0.M1 release so I would encourage you to try that out on trial projects.

If there are any issues, please log a bug ticket https://jira.springsource.org/browse/ROO or write us a message here http://forum.springsource.org/forumdisplay.php?67-Roo.

Regards,
Stefan Schmidt
Spring Roo team
alankstewart (1) [Avatar] Offline
#13
Re: ApplicationConversionService problems using a Roo web project from another
> Must be a quirk of JIRA, but ROO-120 has a priority
> of Trivial.

I changed it to Critical today smilie

Alan