[pkit]

After generating a dao I wanted to add a bespoke method and so turned off autogeneration under code generation of the DSL. This method required an import.

After adding the method and re-saving the class it miraculously turns the autogeneration back on and removes the import! The import was a SpringUtils class.

Is this expected behaviour or a bug?

Thanks

[Heflin Hogan]

I’m not seeing this behavior. Could you tell me exactly which generation option(s) you turned off?

[pkit]

It may just have been this one – I’ll try creating again…. what I repeatedly did after creating the DAO using DSL was to go into code generation tab and deselect all. After saving, I returned to the class to add a new method. After building this was removed (probably because not in DSL?). Revisiting the code generation tab revealed the class generation was selected again.

[Heflin Hogan]

Is the Build Automatically on or off?

[pkit]

Oh, er, its on – does that make a difference?

[Heflin Hogan]

It shouldn’t, but I’m trying to figure out why your set up is acting differently than mine. Just for reference, even if you left the code generation on, we shouldn’t wipe out code you’ve added to a class (and don’t, in my case), with the exception of things marked with the @generated notation. And I believe we try and preserve changes in the @generated annotated section as much as possible, but I’d have to check that. Just to be sure, you are using the MyEclipse for Spring 8.5 GA release, correct?

[pkit]

OK I’ve seen the behaviour on another DAO – created in Spring DL, deselected everything in code generation and saved, then modified class and observed generation again and a revisit to the code generation showed the class generation checked!!

[pkit]

Think there is a post that was missed off from last night when I confirmed that yes I am using the latest Spring 8.5 release. I also said that I am very much loving this code generation stuff and am so glad I upgraded to the Spring license. I’m using it in conjunction with springfaces and webflow and so I have to switch code generation off for tests as they include the spring web flow which has a pattern it barfs at. Talking about the tests and as an aside to this issue, why are the context files referenced as full paths? I switch from machine to machine one which has this stuff on D: and one on C: so I have to amend and recompile each time. Lastly, what is intended to be stored in the code repostory? Just the generated classes and config or all the meta data some of which seems to change everytime I build? Many thanks!

[Heflin Hogan]

I’m glad you like the code gen stuff. We think it’s pretty cool, but it’s nice to hear other people do, too.

I’m still trying to isolate the conditions that causes the code generation to turn back on. The basic steps I’ve taken (with some variations), are:

Create a web project
Add Spring code gen capabilities
Add a model package to the Spring DSL
Add a DAO to the package
Open the Spring DSL editor and go to the Code gen tab
Deselect all of the code generation and save
Go to the DAO impl class and add an import and a custome method and save.

Can you suggest any differences? Also, I was wondering what OS you were running on?

I’m using it in conjunction with springfaces and webflow and so I have to switch code generation off for tests as they include the spring web flow which has a pattern it barfs at.

I’d be interested in knowing what pattern it has issues with. It may be something we can improve in a future release.

Talking about the tests and as an aside to this issue, why are the context files referenced as full paths?

Could you provide an example of this with the context file and the reference?

Lastly, what is intended to be stored in the code repostory? Just the generated classes and config or all the meta data some of which seems to change everytime I build?

The meta data in the Spring DSL models will react to changes in the code, which would be my best guess as to why you may be seeing it update. The builders work both from model to code, and code to model, so changes in either will potentially result in updated files in the other. You can put either or both in your repository, but if you are actively modifying both DSL and code, I’d suggest both.

[pkit]

I have a flash file (captivate) which shows me doing as you’ve described and getting the behaviour where the implementation class becomes under the control of the code generation after unchecking it and making some modification. Can I upload it for your info?

This is the pattern in the webflow which means that the reference to this file must be excluded in the test classes which generates the references:-
<!– registers and maps logical names of flows to flows in /WEB-INF/flows/xxx –>
<webflow:flow-registry id=”flowRegistry” flow-builder-services=”facesFlowBuilderServices” base-path=”/WEB-INF/flows”>
<webflow:flow-location-pattern value=”**/*-flow.xml” />
</webflow:flow-registry>

Could you provide an example of this with the context file and the reference? Yes I can 😉 I’m talking about the full path used in the generated test classes where the context files are referenced thusly:-

“file:/C:/Users/Pete/Documents/My%20Workspace/reproduced/WebRoot/WEB-INF/config/reproduced-generated-webflow-config.xml”

– fine if they’re on the C:\ drive on all my development machines – but they’re not!

I get the model to code to model updates and this and it is great. However, the generated uniqueResourceName in generated-dao-context.xml and the date in the generated -dao.properties file always change on build all and so Subversion always shows a file modified against the repository.

Lastly, an extra one, when generating an annotated service it capitalizes the first letter of the name given to the service. Is there anywhere to set this so that it can use the standard sentence case.

[Heflin Hogan]

You should be able to attach the file to a PM to me. Thank you for the info! I’ll be looking into the rest of the details you provided. I have some ideas on some of it, but I need to verify a few things.

[pkit]

Hi, right, I think its about 2MEG – not sure what the limit is – I’ll try to PM you tonight.

Just a quickie – I wanted to complete my info about things becoming modified against Subversion when nothings actually changed! I just checked the domain objects and for some reason it reorders the named queries randomly, which again leads to differences against the code repository… so a bit misleading when they are essentially the same.

Cheers!

[Heflin Hogan]

OK, first the context paths in the test classes: that’s obviously not a good thing. I’ve submitted an issue to change what we emit to a relative path. You can manually change it in the code as well. It doesn’t seem to get overwritten unless you make changes in the referenced model. The improvement has been targeted for the next release.

Thanks for the upload. That is very definitely a bug, and I’m raising it internally right now. You can work around at least part of it by adding “@generated NOT” under the @ModelReference annotation. I’m not sure what to do about the import statements yet.

I’m still looking into your other items.

Regards,
Heflin

[pkit]

Hi Heflin, that @generated NOT didn’t seem to work – turned all autogen off and stuck it in the comments under model ref and it just got removed along with the change to the method. Am I doing something wrong – below both the annotation and sysout are removed after building:-

/**
     * JPQL Query - findMembersBySearchCriteria
     * @ModelReference [platform:/resource/reproduced/.springDSL/member/dao/MemberDAO/findMembersBySearchCriteria.query]JPASelectWithPagination
     * @generated NOT
     */
    @SuppressWarnings("unchecked")
    @Transactional(isolation = Isolation.DEFAULT, propagation = Propagation.REQUIRED)
    public List<Member> findMembersBySearchCriteria(member.dao.helper.SearchCriteria searchCriteria, int startResult, int maxRows) throws DataAccessException {
        System.out.println();
        Query query = createNamedQuery("findMembersBySearchCriteria", startResult, maxRows, searchCriteria.getSearchPattern());
        return new LinkedList<Member>(query.getResultList());
    }

[Heflin Hogan]

Yep. I tried it elsewhere and it works, but it’s pretty clearly busted in the DAO. I even tried removing the @ModelReference to see if that would work, but I get duplicate methods. The only way I can see around it is to copy the generated DAO classes, delete the DAO object, and rename the copies. Less than optimal, I know. On the positive side, the fix is already in the 8.6 release, and the bug should only affect the DAO objects, not the other types.

I’ll also be entering an issue for the scenarios for the not-changed-changed stuff. If you spot any more instances where this occurs, please let me know and I’ll add them into the issue.

[Author]

Posts