'Wicket different handling on page propertyModel depending on RuntimeConfiguration

So I have a Wicket 9.10.0 application, running under Java 17.

By the way: Wicket is great work, thanks to everyone working on the project.

We have a page managing mutations to domain entities using different sections to change the data.

Sections will be opened/closed by link attached to the WebMarkupContainer using AjaxEventBehavior("click").

Now if I open section "family" I can change partners and children. If family members already exist, there are shown on the left and are presented as well in edit-components (textfields, datefield) on the right.

Ajax will update the page deleting old or adding new members.

Now this is working fine if I am using RuntimeConfigurationType DEVELOPMENT.

If however we start the application in DEPLOYMENT mode, then somehow the editable values (e.g. first-/lastname) in the underlying property model are nulled out. As soon as I get the component in ListenerRequestHandler (breakpoint) and having a look at the model from the page from the component, the data is already modified.

So somehow I am missing the point between presenting the data in the page in the first request (where all the data is there) and the first ajax request to the page where the data is nulled out!? From my point of view at that point the data would just be retrieved from the page cache (perhaps deserialized), but it should still be the same than after fully rendered and presented the page.

This is reproducable: Starting in DEVELOPMENT mode working, starting application in DEPLOYMENT mode: not working.

So the questions:

  • Who is modifying the data in the underlying domain entity? How can I prevent?
  • Why is there a difference in both runtime configuration modes?

Any idea/help or pointer would be really much appreciated.

Thanks.



Solution 1:[1]

Ok, I found the problem: It was a serialization issue found when isolating to just serialize / deserialize the data. Extremely misleading that it was working (at all!) if in dev-mode. No clue how that correlated.

So implementing Serializable on the MappedSuperClass fixed the issue!

Thanks.

Solution 2:[2]

Maybe You can bind class and use different css classes:

Vue.component('MyChild',{
  template: `
    <div class="hello">
      <p>Hello from the child component</p>
      <div class="myDiv" :class="collorCurrent">
        here is my color, that I change
      </div>   
    </div>
  `,
  props: {
    colorChange: {
      type: String,
      default: "green",
    },
    colorDef: {
      type: String,
      default: "green",
    },
    isActive: {
      type: Boolean,
      default: false,
    },
  },
  computed: {
    collorCurrent() {
      return this.isActive ? this.colorChange : this.colorDef
    }
  }
})

new Vue({
  el: "#demo",
  data() {
    return {
      active: false,
    }
  },
})
.myDiv {   color: white;   padding: 1rem; }

.blue {
  background: blue;
  font-size: 22px;
}

.red {
  background: red;
  font-variant: small-caps;
}

.yellow {
  background: yellow;
  color: black;
}

.grey {
  background: grey;
  text-decoration: underline;
}

.green {
  background: green;
}
<script src="https://cdnjs.cloudflare.com/ajax/libs/vue/2.5.17/vue.js"></script>
<div id="demo">
  <p>Parent:</p>
  <button @click="active = !active">Click Me!</button>
  <my-child :is-active="active" :color-def="'grey'" :color-change="'blue'"></my-child>
  <my-child :is-active="active" :color-def="'blue'" :color-change="'grey'"></my-child>
  <my-child :is-active="active" :color-def="'red'" :color-change="'blue'"></my-child>
  <my-child :is-active="active" :color-def="'blue'" :color-change="'yellow'"></my-child>
</div>

Sources

This article follows the attribution requirements of Stack Overflow and is licensed under CC BY-SA 3.0.

Source: Stack Overflow

Solution Source
Solution 1 Tyler2P
Solution 2