Re: reloading of HTML and classes
You are right, I was able to reproduce it:
https://issues.apache.org/jira/browse/WICKET-4509
Christoph
On 20.04.2012 18:24, Andrew Geery wrote:
An issue I ran into with having Wicket reload the html files in development
mode is that it doesn't seem to work if the path to the html files has
spaces in it. For example, running under Eclipse with the workspace in
c:\Documents and Settings\... html reloading did not work. Taking the
exact same configuration but putting the workspace directly on the c:\
drive (e.g., c:\workspace), the htm reloading works perfectly.
Hope that helps.
Andrew
On Tue, Apr 10, 2012 at 2:45 AM, Martin Grigorovmgrigo...@apache.orgwrote:
On Sun, Apr 8, 2012 at 5:38 AM, Bernardbht...@gmail.com wrote:
Hi,
The HTML part is covered if your IDE copies HTML files to the
deployment directory when you save them. Wicket will then pick up this
change and reload the corresponding pages. This works for existing
markup but not for new markup that was missing.
https://github.com/wicketstuff/core/tree/master/jdk-1.7-parent/wicketstuff-wicket7
provides an extension of Wicket's default
ModificationWatcher that uses JDK7 NIO2 WatchService. This should help
for this problem.
The Java classes part can only be handled with debugging, JRebel or a
complete re-deployment. There is no hot-deployment of individual
classes in GlassFish (I don't know whether any other server supports
this). However GlassFish has session preservation so the re-deploy
process is seamless. To further speed up the deployment, one can copy
most libraries (including Wicket) into the GlassFish domain's lib dir
instead of copying them on every deployment.
The Deploy on Save feature is only useful for mini applications - it
is too slow.
Bernard
On Fri, 06 Apr 2012 16:48:11 +0200, you wrote:
I've been fighting this for the past two days, but I'm not succeeding.
I'm using Wicket 1.5.5 on GlassFish 3.1.2 and that runs without a problem.
I have configured
filter-classorg.apache.wicket.protocol.http.ReloadingWicketFilter/filter-class
to reload the classes, but that is not working. The only way to reload
the class file is by using JRebel.
Also Wicket reports that it runs in DEVELOPMENT mode, but it is not
reloading the HTML files. In an attempting to resolve that I explicitely
configured
getResourceSettings().setDefaultCacheDuration(Duration.ONE_SECOND);
but that does not make a difference. The only way I can get it to work
somewhat, is to add my own ResourceFinder directly on the src folder:
getResourceSettings().setResourceFinder(new IResourceFinder()
{
@Override
public IResourceStream find(Class? clazz, String pathname)
{
File f = new File(C:/Documents and Settings/User/My
Documents/s2m/sources/components/service/src/main/java/ + pathname);
if (f.exists())
{
return new FileResourceStream( f );
}
return null;
}
});
getResourceSettings().setUseDefaultOnMissingResource(true);
But still the source are not reloaded reliably. I figure if the cache
expires, a new call to the resource finder should be done, correct?
Is there any debugging of these autoreload features, so I can see what
Wicket is doing?
Tom
-
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
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
-
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
Re: tomcat deployment issues
try deleting work folder in Tomcat6. Fernando Wermus. www.linkedin.com/in/fernandowermus On Thu, Apr 12, 2012 at 4:29 AM, Martin Grigorov mgrigo...@apache.orgwrote: Hi, Can you put a breakpoint in WicketServlet#init() ? The only reason for that I see is this servlet to be initialized twice ... Even better set the breakpoint in Application#setName() and see who is calling it and how many times On Thu, Apr 12, 2012 at 4:41 AM, Alex Rass a...@itbsllc.com wrote: If someone could help me out with this issue, that would be awesome. Currently: Deploying on Tomcat 6. Default deploy folder is webapps webapps/ROOT is where my 1st wicket app is (lets call it App1) webapps.web2 is another Host record for a different URL. webapps.web2/app2 is my wicket app #2 No matter what I tried, app#2 doesn't get started (but servlets from same context work fine). When I go to the url, it says: java.lang.IllegalStateException: Application with name 'App2' already exists.' org.apache.wicket.Application.setName(Application.java:854) org.apache.wicket.protocol.http.WicketFilter.init(WicketFilter.java:337) org.apache.wicket.protocol.http.WicketServlet.init(WicketServlet.java:271) javax.servlet.GenericServlet.init(GenericServlet.java:212) ... I tried renaming it to App3 (in web.xml and I get same message except it says App3). I checked all the web.xml files on the server, no other one has App2 in it. I have lib folders under each app. I don't share anything beside DB drivers in Tomcat's lib folder. I have Wicket 1.5.4 for App1 and 1.5.5 for App2 (donno if that makes a diff). Any ideas? Regards, - Alex. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
StalePageException handling issue
While trying to understand what causes StalePageExceptions (using Wicket 1.5.4), I discovered a strange situation that can occur when DefaultExceptionMapper handles a StalePageException. I decided to ping the mailing list before creating a JIRA issue in case I'm misunderstanding intended behavior. Consider this scenario: 1) A user logs in and loads a few different pages, eventually landing on Page A. At this point, Page A's version is 5, e.g. /some/path/pageA?5 2) The user opens a new tab and loads Page B 3) The user logs out (or their session times out) while on Page B 4) The user logs back in and interacts with Page B, performing page-level actions that increase the render count of the page, until Page B's version is 5. At this point, a link listener url on Page B looks something like /some/path/pageB?5-3.ILinkListener-someLink 5) The user switches back to their old Page A tab 6) The user clicks an action link (with a listener url like /some/path/pageA?5-1.ILinkListener-someLink) on Page A 7) Wicket throws a StalePageException because the page with version 5 has a render count of 3, not 1 8) At this point, the strange thing occurs: instead of rendering a new version of Page A, Wicket renders Page B. Thus, even though the user attempted to do something on Page A, they are now looking at Page B. Digging into the code, it seems this is due to the implementation of PageProvider.getStoredPage(int pageId). Notably, the javadoc for the method states, If pageClass is specified then compares it against the stored instance class and returns the found instance only if they match. In the example, pageClass would be PageA.class, but storedPageInstance.getClass() would return PageB.class (the page with id=5 in the newest session). However, even though pageClass and storedPageInstance.getClass() aren't equal, the method still returns storedPageInstance. In this case, shouldn't getStoredPage() should return null, prompting a fresh instantiation of PageA.class? That way, when the user clicks the stale link on Page A, they'll get a fresh rendering of Page A. Thanks for your help! -Allen
