facebook

Editing inverse relation in SpringDSL does not reflect in generated code

  1. MyEclipse IDE
  2.  > 
  3. Spring Development
Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #523387 Reply

    Luis Pedro
    Participant

    Hello,

    I have a scaffolded Spring application. After a recent DB modification and a rescaffolding, there must have been a little bug that created an ill-defined relation in one of the Spring DSL datatypes. Namely, the inverse relation is not the right one.
    I want to avoid rescaffolding again, because it takes a long time for me (see previous messages in the forum), so I went and edited the inverse relation name in the Spring DSL datatype, then I did a “Generate artifacts from Spring DSL” from the edited datatype.
    However, the generated java file still has the old inverse relationship – it is not taking into account my modification. I also tried removing the java file and regenerating it from scratch, but it yelded the same results.
    Is there anything I am not getting about how this is supposed to be done?

    Thank you. Here below a few more details that might be useful for your reference.

    The database has a table fundstructureelement, primary key is its id column.
    Then there is a masterfeeder table, which has 3 columns: id, master and feeder. The primary key is id, while master and feeder are foreign keys to the id of fundstructureelement.

    The generated SpringDSL datatype for fundstructureelement, Fundstructureelement.datatype, shows that there are two relations:
    masterfeedersForMaster --> Inverse name: fundstructureelementByMaster (this looks fine)
    masterfeedersForFeeder --> Inverse name: fundstructureelementByMaster (this is not right: the inverse name should be fundstructureelementByFeeder)

    Note that the Masterfeeder.datatype correctly has the following relations:
    fundstructureelementByMaster --> Inverse name: masterfeedersForMaster
    fundstructureelementByFeeder --> Inverse name: masterfeedersForFeeder

    What I did was going to Fundstructureelement.datatype, click on the inverse name for masterfeedersForFeeder, and select fundstructureelementByFeeder in the dropdown (I have both fundstructureelementByMaster and fundstructureelementByFeeder as possible proposed values).
    Then I did the “Generate artifacts from Spring DSL”.

    However in the Fundstructureelement.java file that is generated I have the following:

       /**
       * @ModelReference [platform:/resource/oligoWorld/.springDSL/ch/oligofunds/oligoworld/domain/Fundstructureelement.datatype#//@relationships%5Bname='masterfeedersForFeeder'%5D]
        */
       @OneToMany(mappedBy = "fundstructureelementByMaster", cascade = { CascadeType.REMOVE }, fetch = FetchType.LAZY)
    
       @XmlElement(name = "", namespace = "")
       java.util.Set<ch.oligofunds.oligoworld.domain.Masterfeeder> masterfeedersForFeeder;
    

    At this point, I have one error in the Problems view:
    fundstructureelementByMaster must be referenced by its inverse relationship (referring to Masterfeeder.datatype)

    And if I run the Spring application, it fails to start with:

    May 19, 2017 10:57:52 AM org.apache.catalina.core.ContainerBase addChildInternal
    SEVERE: ContainerBase.addChild: start: 
    org.apache.catalina.LifecycleException: Failed to start component [StandardEngine[Catalina].StandardHost[localhost].StandardContext[/oligoWorld]]
       at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:154)
       at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:901)
       at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:877)
       at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:649)
       at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1247)
       at org.apache.catalina.startup.HostConfig$DeployDirectory.run(HostConfig.java:1897)
       at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
       at java.util.concurrent.FutureTask.run(FutureTask.java:266)
       at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
       at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
       at java.lang.Thread.run(Thread.java:745)
    Caused by: java.lang.NoClassDefFoundError: org/springframework/web/context/WebApplicationContext
       at java.lang.Class.getDeclaredFields0(Native Method)
       at java.lang.Class.privateGetDeclaredFields(Class.java:2583)
       at java.lang.Class.getDeclaredFields(Class.java:1916)
       at org.apache.catalina.util.Introspection.getDeclaredFields(Introspection.java:106)
       at org.apache.catalina.startup.WebAnnotationSet.loadFieldsAnnotation(WebAnnotationSet.java:270)
       at org.apache.catalina.startup.WebAnnotationSet.loadApplicationServletAnnotations(WebAnnotationSet.java:139)
       at org.apache.catalina.startup.WebAnnotationSet.loadApplicationAnnotations(WebAnnotationSet.java:65)
       at org.apache.catalina.startup.ContextConfig.applicationAnnotationsConfig(ContextConfig.java:415)
       at org.apache.catalina.startup.ContextConfig.configureStart(ContextConfig.java:892)
       at org.apache.catalina.startup.ContextConfig.lifecycleEvent(ContextConfig.java:386)
       at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:117)
       at org.apache.catalina.util.LifecycleBase.fireLifecycleEvent(LifecycleBase.java:90)
       at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5380)
       at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
       ... 10 more
    Caused by: java.lang.ClassNotFoundException: org.springframework.web.context.WebApplicationContext
       at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720)
       at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571)
       ... 24 more
    • This topic was modified 7 years, 6 months ago by Luis Pedro.
    #523389 Reply

    Luis Pedro
    Participant

    PS: I might add that I tried manually changing the mappedBy attribute in the Java file, but the result is the same.

    #523399 Reply

    Luis Pedro
    Participant

    Ok, I had a litte progress; after manually editing the Java to reflect the modification in the datatype, I removed the app from tomcat and republished it from scratch, which allowed me to at least run it.

    However the error in the Problem view stays, and the fact that my DSL modification were not reflected in the code is still an issue. How can I find a way to do this without errors popping up and in a more reliable way?

    #523757 Reply

    support-tony
    Keymaster

    Luis,

    This looks like a bug and I’ve filed a problem report for the developers to investigate. It looks as though an associated XML file is not being generated correctly and not being updated when you changed the mapping to the correct one.

    Please try this workaround. Open your project folder in a system explorer (right click on the project and select Open in Explorer). Make sure you are viewing hidden files as you will need to look for the “.springDSL” folder. Under there are the folders that correspond you your package name, down to your domain package. You’ll find the files fundstructureelement.datatype and fundstructureelement.datatypebinding. You’ve already corrected the first, via MyEclipse but you’ll need to manually edit the second to make a similar correction. Once that is done, save the file and then go back to MyEclipse and refresh the project to pick up externally made edits. Now, when you Generate Artifacts from Spring DSL, you should get the correctly generated java file.

    The edits to the datatypebinding file can be made inside MyEclipse, via the Navigator view, but can lead to some unwanted settings that are tedious to undo, so it’s probably easier to made the edits outside.

    Please let us know how you get on.

    #523954 Reply

    Luis Pedro
    Participant

    Hello Tony,

    A-ha, I see. As a matter of fact, the datatypebinding _did_ miss the correction. I can’t test this now, but as a rescaffolding is coming up soon anyway, I will make sure to give that a shot.
    Thanks, best.

    #524053 Reply

    support-tony
    Keymaster

    Luis,

    Good; it looks like that is the underlying problem, when trying to manually correct the mapping. Please let us know how you get on when needing to do the correction again.

    Apologies for the inconvenience.

    #524388 Reply

    Luis Pedro
    Participant

    Tony,

    I can confirm the workaround (editing the .datatypebinding by hand, refreshing, and regenerating the class from the DSL) works indeed.
    Remains to be seen, why the inverse relationships name were generated wrong in the first place. As I see it, this seems a separate bug. Is there a problem when a table has two separate foreign keys referencing the same parent table?
    I seem to recall that I had similar problems with other relationships in my DB in the past, when I had this same kind of pattern; only, I had not identified this inverse relationship generation problem at the time, so I had worked around this by removing foreign keys and ensuring consistency in the code instead. This might have been the cause those other times as well. It may be worth having a look at that too.

    #524587 Reply

    support-tony
    Keymaster

    Luis,

    Thanks for letting us know that the workaround works for you. Yes, indeed, looking back, we have had a similar issue but not for someone working with Spring DSL. I have added further information to the bug (which may be two bugs, as you say) to help developers track this down.

Viewing 8 posts - 1 through 8 (of 8 total)
Reply To: Editing inverse relation in SpringDSL does not reflect in generated code

You must be logged in to post in the forum log in