Re: Auto-reloading markup during development
Guten Tag mscoon, am Samstag, 22. November 2014 um 21:44 schrieben Sie: Is it possible to set wicket to reload markup and other resources during development so that one does not need to redeploy-restart the server in order to see their changes? From my understanding this should work automatically, because properties files are added to a watcher and if you have enabled development mode templates are observed as well. What you need to make sure is that Eclipse had the time to republish the changed files and such. A short test with changes to a property and template file worked for me, though I often restarted the server in the past for various reasons as well. http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/settings/IResourceSettings.html#setResourcePollFrequency(org.apache.wicket.util.time.Duration) http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/settings/IResourceSettings.html#setResourceWatcher(org.apache.wicket.util.watch.IModificationWatcher) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Auto-reloading markup during development
Hi, On Sun, Nov 23, 2014 at 11:46 AM, Thorsten Schöning tschoen...@am-soft.de wrote: Guten Tag mscoon, am Samstag, 22. November 2014 um 21:44 schrieben Sie: Is it possible to set wicket to reload markup and other resources during development so that one does not need to redeploy-restart the server in order to see their changes? From my understanding this should work automatically, because properties files are added to a watcher and if you have enabled development mode templates are observed as well. What you need to make sure is that Eclipse had the time to republish the changed files and such. A short test with changes to a property and template file worked for me, though I often restarted the server in the past for various reasons as well. Right! In DEV mode Wicket tracks changes to markup files and i18n resources. DCEVM (or JRebel, or even simply running the JVM in DEBUG mode) will allow you to make changes in your *Java* code without restart. http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/settings/IResourceSettings.html#setResourcePollFrequency(org.apache.wicket.util.time.Duration) http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/settings/IResourceSettings.html#setResourceWatcher(org.apache.wicket.util.watch.IModificationWatcher) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bes practice for deployment to avoid ClassNotFoundException
Hi, You are experiencing Tomcat Session Persistence - http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts Just disable it for development to avoid such kind of problems. I'd also recommend to use Jetty for development if possible. It is much faster to restart. See src/test/java/.../Start.java in Wicket Quickstart. Martin Grigorov Wicket Training and Consulting https://twitter.com/mtgrigorov On Fri, Nov 21, 2014 at 6:22 PM, Thorsten Schöning tschoen...@am-soft.de wrote: Hi all, I'm new to wicket and just recently started to use it for a new web app for one of our projects. Today I came across a similar issue like described in [1], a ClassNotFoundException during deserialization of a page. The interesting part about this in my mind is, that the mentioned missing class was missing for a good reason: I simply refactored a bit and renamed the class, redeployed and restarted my Tomcat. This looks like a normal use case to me, but is something I didn't thought of when I've read through the docs because. My deployment is very simple: I check out a SVN working copy with a pre-configured tag containing the whole application once and afterwards just need to merge/update and stop/start the web server/app. How is deployment supposed to work in Wicket after I have refactored or otherwise changed my classes regarding cached and serialized pages? Is there anything I need to tell wicket to clear its caches on each deployment or ignore those or whatever? Am I forced to not delete once deployed classes for a fair period of time? That would be a litte nightmare... Or is there any other issue I ran into I should have avoided? Obviously others do deploy their Wicket apps as well, so I hope you have some input on how to avoid the problem I've ran into. Thanks! The important parts of the stacktrace: java.lang.ClassNotFoundException: de.am_soft.util.frontend.wicket.markup.link.LogoutLink at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1720) at org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1571) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Unknown Source) at org.apache.wicket.application.AbstractClassResolver.resolveClass(AbstractClassResolver.java:108) at org.apache.wicket.serialize.java.JavaSerializer$ClassResolverObjectInputStream.resolveClass(JavaSerializer.java:218) at java.io.ObjectInputStream.[...] [...] at org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:122) at org.apache.wicket.pageStore.DefaultPageStore.deserializePage(DefaultPageStore.java:396) at org.apache.wicket.pageStore.DefaultPageStore.getPage(DefaultPageStore.java:135) at org.apache.wicket.page.PageStoreManager$SessionEntry.getPage(PageStoreManager.java:203) at org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPage(PageStoreManager.java:360) at org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager.java:107) [1]: https://issues.apache.org/jira/browse/WICKET-4785 Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bes practice for deployment to avoid ClassNotFoundException
Guten Tag Martin Grigorov,
am Sonntag, 23. November 2014 um 11:22 schrieben Sie:
You are experiencing Tomcat Session Persistence -
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts
Just disable it for development to avoid such kind of problems.
But the exception clearly comes from wicket's page store, I already
found the code where the exception is captured and rethrown as
RuntimeException. I really doubt this is a problem of the Tomcat.
122: return ois.readObject();
at
org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:122)
java.lang.RuntimeException: Could not deserialize object from byte[]
throw new RuntimeException(Could not deserialize object from byte[], cnfx);
Additionally, deactivating this feature for development only in Tomcat
wouldn't change anything, if I update the production system after
refactoring I would get the same error there of course.
From looking at the code I think what I would need to do instead is
create my own delegating serializer, which encapsulates the default
Wicket one, catches the problematic exception and returns null instead
of throwing the exception. It looks like that all code mentioned in
the stacktrace is using null if things are not found or such and would
ultimately lead to PageProvider.isNewPageInstance believing that a new
instance is needed:
public boolean isNewPageInstance()
{
boolean isNew = pageInstance == null;
if (isNew pageId != null)
{
IRequestablePage storedPageInstance =
getStoredPage(pageId);
if (storedPageInstance != null)
{
pageInstance =
storedPageInstance;
isNew = false;
}
}
return isNew;
}
storedPageInstance would simply be null when using my own serializer.
From my opinion this should be a at least configurable default
behavior in Wicket anyways, I don't see how else it can handle things
like refactoring with using it's own page store of serialized Java
classes. It must ignore ClassNotFoundException in such cases somehow
because it's a perfectly valid situation.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...05151- 9468- 55
Fax...05151- 9468- 88
Mobil..0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bes practice for deployment to avoid ClassNotFoundException
Hallo Thorsten,
On Sun, Nov 23, 2014 at 1:02 PM, Thorsten Schöning tschoen...@am-soft.de
wrote:
Guten Tag Martin Grigorov,
am Sonntag, 23. November 2014 um 11:22 schrieben Sie:
You are experiencing Tomcat Session Persistence -
http://tomcat.apache.org/tomcat-7.0-doc/config/manager.html#Persistence_Across_Restarts
Just disable it for development to avoid such kind of problems.
But the exception clearly comes from wicket's page store, I already
found the code where the exception is captured and rethrown as
RuntimeException. I really doubt this is a problem of the Tomcat.
Here is what happens:
1) Wicket stores a Page into the HTTP session
2) Tomcat shuts down and persists all HTTP sessions into the disk
3) you deploy and new version of the app (with incompatible changes in the
classes, like renaming a class)
4) you start Tomcat and it tries to load the persisted sessions
4.1) Since Wicket stores its data
as org.apache.wicket.pageStore.DefaultPageStore.SerializedPage (a triple of
pageId (int) / sessionId (String) / pageData (byte[])) it is Wicket's job
to deserialize the pageData byte[] to SomePage instance. That's why you
think Wicket is to blame here. But even if there was a Page stored as an
attribute in the http session then Tomcat would fail the same way since
there is no such class in the webapp class loader anymore.
In both cases I think Tomcat will just log an error that an old session
cannot be loaded and continue with the start of the application.
Am I correct or Tomcat fails to start ?
Please paste the complete exception if I am not correct.
122: return ois.readObject();
at
org.apache.wicket.serialize.java.JavaSerializer.deserialize(JavaSerializer.java:122)
java.lang.RuntimeException: Could not deserialize object from byte[]
throw new RuntimeException(Could not deserialize object from byte[],
cnfx);
Additionally, deactivating this feature for development only in Tomcat
wouldn't change anything, if I update the production system after
refactoring I would get the same error there of course.
No.
Wicket cleans up its data storages at session invalidation time (per
sessionId) or at application stop (for all sessions).
So there is nothing to load at start time and no knowledge about old stuff.
From looking at the code I think what I would need to do instead is
create my own delegating serializer, which encapsulates the default
Wicket one, catches the problematic exception and returns null instead
of throwing the exception. It looks like that all code mentioned in
the stacktrace is using null if things are not found or such and would
ultimately lead to PageProvider.isNewPageInstance believing that a new
instance is needed:
public boolean isNewPageInstance()
{
boolean isNew = pageInstance == null;
if (isNew pageId != null)
{
IRequestablePage storedPageInstance =
getStoredPage(pageId);
if (storedPageInstance != null)
{
pageInstance =
storedPageInstance;
isNew = false;
}
}
return isNew;
}
storedPageInstance would simply be null when using my own serializer.
From my opinion this should be a at least configurable default
behavior in Wicket anyways, I don't see how else it can handle things
like refactoring with using it's own page store of serialized Java
classes. It must ignore ClassNotFoundException in such cases somehow
because it's a perfectly valid situation.
Mit freundlichen Grüßen,
Thorsten Schöning
--
Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de
AM-SoFT IT-Systeme http://www.AM-SoFT.de/
Telefon...05151- 9468- 55
Fax...05151- 9468- 88
Mobil..0178-8 9468- 04
AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln
AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Bes practice for deployment to avoid ClassNotFoundException
Guten Tag Martin Grigorov, am Sonntag, 23. November 2014 um 12:20 schrieben Sie: 4) you start Tomcat and it tries to load the persisted sessions 4.1) Since Wicket stores its data as org.apache.wicket.pageStore.DefaultPageStore.SerializedPage (a triple of pageId (int) / sessionId (String) / pageData (byte[])) it is Wicket's job to deserialize the pageData byte[] to SomePage instance. I'm pretty sure this is not what is happening and the provided stacktrace makes clear that Wicket is doing everything. The only thing where Tomcat comes into play is the actual class loading itself, but that's correct of course because Tomcat provides at least a parent classloader to use. Wicket does serialize and deserialize the pages on it's own just because of an incoming request. In both cases I think Tomcat will just log an error that an old session cannot be loaded and continue with the start of the application. Am I correct or Tomcat fails to start ? Tomcat doesn't log anything and just succeeds to start, at least I didn't find any log messages from Tomcat in Eclipse and requesting other pages from Wicket after ClassNotFoundException succeeded as well. Simply because there were newly created. Please paste the complete exception if I am not correct. I attached the saved HTML file with everything Wicket told me, but there's nothing more interesting than what I've already posted in my fist mail. No. Wicket cleans up its data storages at session invalidation time (per sessionId) or at application stop (for all sessions). So there is nothing to load at start time and no knowledge about old stuff. If that was true, Tomcat wouldn't be able to run into any problems with a serialized session as well because there wouldn't be anything left from Wicket to serialize. Or does Wicket only clear persistent storage in files, but retains it's session data? That wouldn't make much sense to me, because the problem would remain. Besides that, I just tested with a request for some page: Wicket did create a folder to save the serialized page during runtime of Tomcat. So I stopped Tomcat to see if the folder gets deleted or such and it didn't, instead Wicket created the additional file DiskDataStoreIndex as serialized Java object, which clearly contains the path to the serialized page. Afterwards I restarted Tomcat, issued another request, DiskDataStoreIndex got read (monitored using ProcMon) and afterwards deleted. The only thing I didn't see was reading the former persisted page... But the former behavior corresponds to the code: DiskDataStore.destroy doesn't just empty anything, data gets persisted in a file and there's even a load method to load the data. So the only interesting thing is if pages are used as well after the restart or not: Application.internalDestroy does call a lot of destroy methods, but DiskDataStore.destroy e.g. is implemented to persist data, while other caches seem to really be just cleared, like that for markup. Which is the codepath where I can see that persisted pages get forgotten on shutdown of Wicket? Following Application.internalDestroy and it's call of internalGetPageManager().destroy(); lead me to DiskDataStore which clearly doesn't destroy the data... A simple explanation for my problem could as well be that I didn't restart the Tomcat and that during it's restart it works like you say, but in that case I want to make sure that really session and persistent page store are abandoned and currently it doesn't look so... Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Applet jdialog confirmed value to wicket page
I call an photo taking applet contained html from wicket page,after pic taker approves based on the applet's JDialaog confirmation, I need to get back to wicket page, If user does not confirm he needs to stay in applet only. any ideas please -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Applet-jdialog-confirmed-value-to-wicket-page-tp4668511.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Auto-reloading markup during development
You are both right, thank you for your answers. I'm not sure what I was doing wrong, but I tried again and markup files are being reloaded. On Sun, Nov 23, 2014 at 11:56 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, On Sun, Nov 23, 2014 at 11:46 AM, Thorsten Schöning tschoen...@am-soft.de wrote: Guten Tag mscoon, am Samstag, 22. November 2014 um 21:44 schrieben Sie: Is it possible to set wicket to reload markup and other resources during development so that one does not need to redeploy-restart the server in order to see their changes? From my understanding this should work automatically, because properties files are added to a watcher and if you have enabled development mode templates are observed as well. What you need to make sure is that Eclipse had the time to republish the changed files and such. A short test with changes to a property and template file worked for me, though I often restarted the server in the past for various reasons as well. Right! In DEV mode Wicket tracks changes to markup files and i18n resources. DCEVM (or JRebel, or even simply running the JVM in DEBUG mode) will allow you to make changes in your *Java* code without restart. http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/settings/IResourceSettings.html#setResourcePollFrequency(org.apache.wicket.util.time.Duration) http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/settings/IResourceSettings.html#setResourceWatcher(org.apache.wicket.util.watch.IModificationWatcher) Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail: thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to suppress AJAX Debug JS
Hi, The Ajax debug window should not appear in deployment mode at all. On Thu, Nov 20, 2014 at 3:07 PM, Christian Smolka christian.smo...@etecture.de wrote: Hi @all! I'm using 6.18 and I'm in deployment mode and I already called this.getDebugSettings().setAjaxDebugModeEnabled(false); Wicket does this for you in DEPLOYMENT mode. No need to do it explicitly. But still the JQuery AJAX debug JS file is present in the final markup. So dropping following lines Wicket.Ajax.DebugWindow.enabled=true; Wicket.Ajax.DebugWindow.init(); in the browser's console still shows the debug panel. How do I really switch it off? Put a breakpoint at org.apache.wicket.resource.CoreLibrariesContributor#contributeAjax() and see why it goes into the 'if' branch. Thx in advance! Christian
Re: Wicket and microdata
Hi, On Thu, Nov 20, 2014 at 7:03 AM, Hendy Irawan he...@soluvas.com wrote: Hi Dirk and Martin, Dirk Forchel wrote Martin Grigorov-4 wrote Another way is to add these attributes directly in the markup. No need to add Behavior to the components for something that is always true. Yes, but I prefer the dynamic way. A Component/Page provides some kind of microdata and implements an interface. The AttributeAppender takes the information and writes the appropriate attribute at the tag. I agree. Some markups are customizable by designers, I'd rather let them worry about presentation structure rather than semantic data, which are closer to the model. Martin Grigorov-4 wrote seen this before)? Or is this marker value for internal use only? At least the generated HTML code looks like intended. I would like to know whether there is a kind of general solution to deal with microdata, say a bunch of Behavior-classes to add this kind of data. AttributeModifier is a Behavior itself. There is no special code in Wicket for microdata. This specification is not broadly used. I thought someone has had the same requirements within his project and came with a general solution for this specification. Okay, fair enough. Martin, This [microdata] specification is not broadly used. some of us disagree with that (some refers to Google, Bing, and Yahoo, for a start) ;-) : https://blog.kissmetrics.com/get-started-using-schema/ Feel free to contribute your code as a module at https://github.com/wicketstuff/core if you think it would be useful for others and it is reusable. Thanks ! Dirk, yes I have exactly the same requirements as yours for Bippo http://www.bippo.co.id/ . Do you share your solution somewhere? I'm planning to put my work as part of soluvas-web project on GitHub https://github.com/soluvas/soluvas-web since it's most comfortable within our build environment, but if anybody wants it in wicketstuff I can also contribute. Thanks. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-and-microdata-tp4661135p4668468.html Sent from the Users forum mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RE: Question on Double Submit and rendering strategy
Hi Please give more details what you try to avoid exactly by making changes in this area. [MH] Hello again, [MH] Well, I'm trying to avoid Double Submit through repeatedly button clicking (or submitting a form). We're currently [MH] porting all our web applications to Wicket. We have had to include a veil function around the Next button [MH] to block subsequent clicks explicitly as Wicket's Double Submit prevention (we are using the default RENDER_TO_BUFFER render strategy) [MH] is allowing repeated requests through. I've stepped through WebPageRenderer::respond() and noticed that there's a call [MH] to getAndRemoveBufferedResponse() and stopped looking since I could see that responses were being discarded. I just assumed that I am misunderstanding [MH] the full intent of the Double Submit treatment in Wicket. Hope that makes sense. I'm not wanting to *change* Wicket here, I'm chasing clarification only given what [MH] what I've stepped through and hear that from the maintainers directly. I guess I'm confused about what happens when there's more than one duplicate request when [MH] clearly the implementation is discarding (by design) the buffered response to an identical earlier request. [MH] [MH] Many thanks Hello, I just wanted to know what the impact of removing the buffered response (referring to javadoc below for REDIRECT_TO_BUFFER) for a request is if there's presumably a bunch of other duplicate requests following it on solving the Double Submit problem. ( http://ci.apache.org/projects/wicket/apidocs/6.x/org/apache/wicket/set tings/IRequestCycleSettings.html ) I'm puzzled about throwing a response away when I would have thought it's buffered and reused to service the (duplicate) requests following? Many thanks cheers. -m. -- - This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. -- - --- This email, and any attachments, may be confidential and also privileged. If you are not the intended recipient, please notify the sender and delete all copies of this transmission along with any attachments immediately. You should not copy or use it for any purpose, nor disclose its contents to any other person. ---
