Re: Java 8 access to effectively final variables/method parameters from anonymous classes
Hi, You can file a feature request to Java developers. A compiler flag can forbid this behavior. On Sun, Aug 4, 2019, 14:05 mscoon wrote: > Thomas, > > Thanks for the info. > > The domain objects not being serializable is certainly a valid option. > > To return to my original point, even this does not completely solve the > issue with unintended serialization. Sure, you are going to get a > serialization exception but this is a runtime error (hidden in the logs if > I recall correctly) - much more cumbersome from the programmer's point of > view compared to getting immediate visual feedback in the IDE or a compiler > error. > > Also with view models you may end up again serializing a view model > unintentionally. Granted this is usually not as bad, but still... > > The IntelliJ option seems to do what I want. Unfortunately we use eclipse > and I wasn't able to find an equivalent option. > > Cheers > Marios > > > > On Sun, Aug 4, 2019 at 1:07 PM Thomas Heigl wrote: > > > > > > > Would you mind to elaborate on this a bit? What do you do in your > forms? > > > How do you handle state there? Do you use view models that are > > > serializable? Do you keep state in local variables and propagate it to > > the > > > domain object in every request after it is reloaded? > > > > > > Sure. > > > > We use DTOs/View Models for most of our forms. We started out with > > manipulating domain objects directly, but it caused too many headaches > with > > serialization and detaching/re-attaching entities etc. > > Domain objects are only used as Wicket (loadable detachable) models when > > the manipulation is just a single step that can be persisted to the DB > > right away. Your ajax link is a good example. Also single-page forms > where > > the final "Save/Next" button persists the changes to the DB. Whenever we > > have a multi-step process (like a wizard) for creating or editing domain > > objects, we use custom view models. > > > > Thomas > > > > On Sun, Aug 4, 2019 at 11:53 AM mscoon wrote: > > > > > Hi, > > > > > > If you don't mind me following up on your comment... > > > > > > > > > > Personally, I rarely encounter serialization issues. None of our > domain > > > > objects implement Serializable. They can only be used with > > > > LoadableDetachableModels that only store the identifier. > > > > > > > >> > > > >> > > > Would you mind to elaborate on this a bit? What do you do in your > forms? > > > How do you handle state there? Do you use view models that are > > > serializable? Do you keep state in local variables and propagate it to > > the > > > domain object in every request after it is reloaded? > > > > > > We often use serializable domain objects so that keeping state on the > > > object is simple. For example if you have an ajax link that increments > a > > > property of the domain object, you simply increment the property and > rely > > > on the object being serialized for keeping state. > > > > > > Cheers > > > Marios > > > > > >
Re: WebSockets: page deserialisation on close (performance issue?)
Hi, Thanks for your answer. I have created a JIRA issue with Quickstart: https://issues.apache.org/jira/browse/WICKET-6692 -- Daniel On Sat, Aug 3, 2019 at 10:05 PM Sven Meier wrote: > > Hi Daniel, > > can you create a quickstart and attach it to a Jura issue please? > > Thanks > Sven > > On 01.08.19 10:57, Daniel Stoch wrote: > > Correction to my previous message (I have debugged this more precisely): > > > > AbstractWebSocketProcessor.onClose method is called in both Jetty > > versions (not only in a newer one). > > The difference is in connection: > > - in Jetty 9.4.12.v20180830 connection is closed > > - in Jetty 9.4.18.v20190429 connection is still open > > > > So message is broadcasted only in a newer version. > > > > -- > > Daniel > > > > On Thu, Aug 1, 2019 at 10:25 AM Daniel Stoch wrote: > >> Hi, > >> > >> We are using web sockets (with wicket-native-core) on many pages in > >> our application. After upgrade a Jetty from 9.4.12.v20180830 to a > >> newer version 9.4.18.v20190429, I have found a different behaviour in > >> application: > >> > >> When user navigates to another page, a websocket connection is closed > >> and AbstractWebSocketProcessor.onClose method is called. This causes > >> broadcasting a message to connected page: > >> > >>broadcastMessage(new ClosedMessage(getApplication(), getSessionId(), > >> key)); > >> > >> and leads to page deserialisation (from PageStore). > >> I think something was changed in a new version of Jetty, because in > >> the previous used version this was not called. Maybe because of this: > >> https://github.com/eclipse/jetty.project/issues/3835 > >> https://github.com/eclipse/jetty.project/commit/2383bf4974ba7d82109cedfc4a8e7693d106abf0 > >> > >> I believe that now it works correctly (as was designed) and onClose > >> should be called. But I wonder how it can affect performance: almost > >> every page navigation causes page deserialization (when it should > >> occur only for back button or when some web socket message comes and > >> application need to process it). > >> > >> Maybe this message should be send only when needed or maybe I should > >> not care and current behaviour does not affect performance? > >> > >> -- > >> Best regards, > >> Daniel Stoch > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
