Possible Roo bug with Converters?

[btlife]

Not sure if this is a bug or not, but when you move a Converter out of the Roo Aspect of a Controller, the call to the converter in registerConverters is removed.

Example:
Move OwnerController.getOwnerConverter out of OwnerController_Roo_Controller.aj and into OwnerController.java

Roo reports Managed OwnerController_Roo_Controller.aj

Upon looking at the new OwnerController_Roo_Controller.aj, the getOwnerConverter function was removed as expected, but the call to it in OwnerController.registerConverters (in the OwnerController_Roo_Controller.aj) was removed as well.

I had to move the registerConverters function into OwnerController.java and replace the conversionService.addConverter(getOwnerConverter() ) back in.

I would think it wouldn't need to remove the conversionService.addConverter call from the registerConverters.


I also found that moving registerConverters function into the .java file, causes Roo to delete all converters from the Roo_Controller.aj

[btlife]

Well I didn't get a response to this so I am not sure if its a bug or not.

I installed the new versions:
Spring Roo: 1.1.0.RELEASE

My goal was to change how the converter was converting an object to string.

The default was defined, int ROO_Controller.aj, as:

    Converter<Employee, String> getEmployeeConverter() {
        return new Converter<Employee, String>() {
            public String convert(Employee employee) {
                return new StringBuilder().append(employee.getFirstName()).append(" ").append(employee.getLastName()).append(" ").append(employee.getTelephone()).toString();
            }
        };
    }

Well say I only want the LastName and FirstName and want to change the order so I get something like "LastName, FirstName" and leave off the telelphone.

So like normal, I "Push In" the convert function into the Controller.
Works fine, Roo picks it up and removes it from ROO_Controller.aj.
Unfortunately, as stated above, the call to the function is removed as well from registerConverters.

Well, as stated before, I don't think this is supposed to happen, I didn't change or want anything to change in the registerConverters function. But maybe that's something AspectJ needs in order to do its thing.

So I "Push In" the registerConverters function and add back the call to the employeeConverter.

Now it complains that it can't find the conversionService variable, it's still in the .aj file defined as:

    @Autowired
    private GenericConversionService conversionService;

Ok so I "Push In" the conversionService variable.

Roo notices the change and pops up an error.

[FelixDispatchQueue] Field 'conversionService' already defined in target type 'com.iaim.subaru.web.DealerController' (ITD target 'com.iaim.subaru.web.DealerController_Roo_Controll er')

So it seems ROO can't move the conversionService variable from the .aj file to the Java File. Not exactly sure why.

So, again, is this a bug, or am I just doing this wrong? What is the process for adding a Converter, or modifying an existing one, in relation to ROO?

As stated in the documenation Spring Roo Section 9.1:

Converter<Person, String> getPersonConverter() {..}

Creates a better visual representation of Person instances (used to replace the default Roo generated Person.toString() method). This method can be adjusted if different visual representations of the Person instance are desired.

Well I know can't make the adjustment in the ROO handled .aj file, so what is the process for overriding ROO, so I can make the adjustment, if roo doesn't seem to be handling the "Push In" in this case?

Thanks a lot for any help!!!

[btlife]

I see Converters are being discussed with ROO-1655

Would still like to know the proper process for changing the logic a Converter uses, or adding a new Converter, in relation to ROO.

For now I just disabled the converters using

@RooWebScaffold(registerConverters=false)

Thanks

[btlife]

Also found this which describes my issue: ROO-1715

Looks like a change was made to attempt to resolve Pushing In the registerConverters with 1.1.1.RELEASE and I am using 1.1.0.RELEASE so I'll try the new version.

Thanks

[alaniel]

btlife did upgrating to roo 1.1.1.RELEASE fixe this issue for you. I'm using 1.1.0.RELEASE [rev 793f2b0].

[btlife]

btlife did upgrating to roo 1.1.1.RELEASE fixe this issue for you. I'm using 1.1.0.RELEASE [rev 793f2b0].

I haven't tried it yet, since 1.1.1.RELEASE hasn't been "released" yet, I would have to pull the unreleased version. So I worked around it, by not changing the converters and changed the stuff I needed to not use toString or the converters, and use the actual fields.

It wouldn't let me override the converters because of the issue with the private ConversionService variable, which I guess is fixed in the 1.1.1.RELEASE. The @RooWebScaffold(registerConverters=false) partially worked since it did allow me to use the toString(), but then it left field collections (defined as sets) without a toString() which resulted in unable to convert errors. So I decided to just leave it as is, and just changed things to use specific fields instead of letting it fall through to the toString().

I'm going to try out 1.1.1.RELEASE once it "officially" comes out.

I also changed the Roo select.tagx to allow the itemLabel to be passed in, so I could specify which field I wanted as the display field. The Roo generated select.tagx allows you to set the itemValue field which translates to the id part of the option list, and then does a toString()/Converter to determine the display value of the option list. By passing in the itemLabel, I can now tell the select.tagx which field I want displayed in the display part of the option list.

Hope that all makes sense