Re: [cleanup] gradle build files
Was there a discussion on the mailing list about this? On May 4, 2012 8:50 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: It looks like we are not going to use the gradle build files. Does anyone object to removing them? Martijn
Re: [cleanup] gradle build files
The fact that they are not going to be used anymore. On May 7, 2012 7:36 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, May 7, 2012 at 2:34 PM, James Carman jcar...@carmanconsulting.com wrote: Was there a discussion on the mailing list about this? About what ? This is the discussion to remove them. On May 4, 2012 8:50 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: It looks like we are not going to use the gradle build files. Does anyone object to removing them? Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: [cleanup] gradle build files
OK. I'm not against it. It's just the first I've heard of it. It would seem like an important discussion to have though, changing the build process. On May 7, 2012 7:42 AM, Martin Grigorov mgrigo...@apache.org wrote: Then this is the discussion. In fact they are/were not used even now. On Mon, May 7, 2012 at 2:40 PM, James Carman jcar...@carmanconsulting.com wrote: The fact that they are not going to be used anymore. On May 7, 2012 7:36 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, May 7, 2012 at 2:34 PM, James Carman jcar...@carmanconsulting.com wrote: Was there a discussion on the mailing list about this? About what ? This is the discussion to remove them. On May 4, 2012 8:50 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: It looks like we are not going to use the gradle build files. Does anyone object to removing them? Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: [cleanup] gradle build files
Ok, I thought I remembered there being a vote to go to Gradle. On Mon, May 7, 2012 at 8:22 AM, Martin Grigorov mgrigo...@apache.org wrote: We use Maven for the build. The .gradle build files were created several months ago as an experiment but they were not used officially at all. On Mon, May 7, 2012 at 3:19 PM, James Carman jcar...@carmanconsulting.com wrote: OK. I'm not against it. It's just the first I've heard of it. It would seem like an important discussion to have though, changing the build process. On May 7, 2012 7:42 AM, Martin Grigorov mgrigo...@apache.org wrote: Then this is the discussion. In fact they are/were not used even now. On Mon, May 7, 2012 at 2:40 PM, James Carman jcar...@carmanconsulting.com wrote: The fact that they are not going to be used anymore. On May 7, 2012 7:36 AM, Martin Grigorov mgrigo...@apache.org wrote: On Mon, May 7, 2012 at 2:34 PM, James Carman jcar...@carmanconsulting.com wrote: Was there a discussion on the mailing list about this? About what ? This is the discussion to remove them. On May 4, 2012 8:50 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: It looks like we are not going to use the gradle build files. Does anyone object to removing them? Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Carl-Eric Menzel is now part of the Wicket team!
Welcome, Carl-Eric! On Thu, Apr 26, 2012 at 5:55 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Carl-Eric Menzel has been invited to join the Wicket team. Please welcome Carl-Eric! Martijn Dashorst -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: 'Strange' code inside TagAttributes
On Fri, Apr 20, 2012 at 9:39 AM, Martin Grigorov mgrigo...@apache.org wrote: ? extends String looks strange too Yes, especially since String is final. Curiouser and curiouser. :)
Re: [vote] wicket-cdi in wicket 6.0?
I forgot to add my +1. I still think my suggestion is a good one, though. On Apr 16, 2012 6:07 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: why not just switch to osgi and run on a custom netty server? why support servlet containers? :) this vote is for inclusion of the wicket-cdi module as is... -igor On Mon, Apr 16, 2012 at 3:02 PM, James Carman jcar...@carmanconsulting.com wrote: Perhaps have wicket piece itself together using cdi! This might help it be more pluggable. It is much better these days but some things could be easier. On Apr 16, 2012 5:21 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Perhaps we can join forces with the deltaspike folks in the incubator and provide the required modules in their solution? Deltaspike is seam's future according to the Seam team after all. Martijn On Mon, Apr 16, 2012 at 9:40 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: we would like to merge wicket-cdi [1] into wicket-core. there is, however, a problem. in its current version CDI does not provide an SPI for controlling conversational scope, this will be part of the next major version of CDI. for now, wicket-cdi depends on seam-conversations JBOSS module which provides plugins for controlling conversational scope across various CDI implementations. the problem is that this module is not available in maven central, so we cannot publish wicket-cdi there as well. when and if JBOSS decides to push this module into central is unknown. here are our options 1. do not merge wicket-cdi until seam-conversations is available in central. may be never. currently wicket-cdi is available through a custom groupid in central, but it is not exactly kosher because of the same problem and can possibly be removed by maven folks in the future. 2. merge it into wicket and drop support for every CDI container other than JBOSS Weld, which is the reference impl and is probably the most widely used. 3. same as two, but rename the module to wicket-cdi-weld. when next CDI version comes out, or when seam-conversations becomes available in central we will rename the module back to wicket-cdi. -igor [1] https://github.com/42Lines/wicket-cdi [2] http://search.maven.org/#browse%7C-1741695030 -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: Move to servlet-api 3.0 for Wicket 6
I'm -0 to going to servlet 3.0. I think it's a bad idea, but I'm not currently using Wicket at my day job, so I wouldn't want to stand in the way of progress. I like the idea of having an optional module that depends on 3.0, though, with the core being 2.5-compatible. On Fri, Apr 13, 2012 at 9:13 AM, Peter Ertl pe...@gmx.org wrote: +1 atmosphere alone is reason enough, no reason to stay on 3.0 forever and there are enough servers out there supporting it Am 13.04.2012 um 14:32 schrieb Emond Papegaaij: Hi all, It was already mentioned by Martijn some time ago as a suggestion for the roadmap for Wicket 6, but it was never decided. The question is: should we move to servlet-api 3.0 or stay at 2.5. Servlet 3.0 has been around for over 2 years now and is supported by most (all?) servlet containers. It allows us to use things like the new annotations and asynchronous servlets. I'm +1 for moving to servlet 3.0 and already have some work done on the sandbox/atmosphere branch to get it working. Best regards, Emond
Re: wicket 6.0 and automatic model detachment
The user would have to turn it off via settings. Sent from tablet device. Please excuse typos and brevity. On Apr 8, 2012 6:28 AM, Sven Meier s...@meiers.net wrote: Once this is introduced you can't turn it off. You might use some components which depend on their models being detached externally, without you even being aware of it. Sven On 04/08/2012 12:15 PM, Johan Compagner wrote: i think it would be fine to have something like this, and enabled by default but only to have an option to turn it off On Sat, Apr 7, 2012 at 22:30, Igor Vaynbergigor.vaynberg@gmail.**comigor.vaynb...@gmail.com wrote: -1 on adding it if its not enabled by default. its a trivial class thats only about 40-50 lines of real code. adding it into extensions and not using it will just add to code rot because i doubt many people will go out looking for something like this since most of them wont even know that its possible to do this. -igor On Fri, Apr 6, 2012 at 11:28 PM, Sven Meiers...@meiers.net wrote: The listener won't be set in IFrameworkSettings by default, right? IMHO it's better located in extensions then. Sven On 04/07/2012 01:37 AM, James Carman wrote: Add the listener to core and if folks want to use it they can. You could have a component instantiation listener add the detach listener to the components. Another option would be an aspect. On Apr 6, 2012 12:43 PM, Igor Vaynbergigor.vaynberg@gmail.**comigor.vaynb...@gmail.com wrote: i wrote a IDetachListener that automatically detaches any IModel fields found on components. is this something we would be interested in for core? its been running in production for a while without any noticeable overhead and its nice not to have to implemenet onDetach() all the time just to forward it to secondary models. the only downside is that once we introduce this feature we can never remote it because doing so will break code. thoughts? -igor
Re: wicket 6.0 and automatic model detachment
Oh, sorry I didn't understand what you meant. Yeah that is a nasty scenario. I would much rather implement this as an aspect if it were me. Wicket should have a library of useful aspects like this. Sent from tablet device. Please excuse typos and brevity. On Apr 8, 2012 10:03 AM, James Carman jcar...@carmanconsulting.com wrote: The user would have to turn it off via settings. Sent from tablet device. Please excuse typos and brevity. On Apr 8, 2012 6:28 AM, Sven Meier s...@meiers.net wrote: Once this is introduced you can't turn it off. You might use some components which depend on their models being detached externally, without you even being aware of it. Sven On 04/08/2012 12:15 PM, Johan Compagner wrote: i think it would be fine to have something like this, and enabled by default but only to have an option to turn it off On Sat, Apr 7, 2012 at 22:30, Igor Vaynbergigor.vaynberg@gmail.**comigor.vaynb...@gmail.com wrote: -1 on adding it if its not enabled by default. its a trivial class thats only about 40-50 lines of real code. adding it into extensions and not using it will just add to code rot because i doubt many people will go out looking for something like this since most of them wont even know that its possible to do this. -igor On Fri, Apr 6, 2012 at 11:28 PM, Sven Meiers...@meiers.net wrote: The listener won't be set in IFrameworkSettings by default, right? IMHO it's better located in extensions then. Sven On 04/07/2012 01:37 AM, James Carman wrote: Add the listener to core and if folks want to use it they can. You could have a component instantiation listener add the detach listener to the components. Another option would be an aspect. On Apr 6, 2012 12:43 PM, Igor Vaynbergigor.vaynberg@gmail.**comigor.vaynb...@gmail.com wrote: i wrote a IDetachListener that automatically detaches any IModel fields found on components. is this something we would be interested in for core? its been running in production for a while without any noticeable overhead and its nice not to have to implemenet onDetach() all the time just to forward it to secondary models. the only downside is that once we introduce this feature we can never remote it because doing so will break code. thoughts? -igor
Re: wicket 6.0 and automatic model detachment
Add the listener to core and if folks want to use it they can. You could have a component instantiation listener add the detach listener to the components. Another option would be an aspect. On Apr 6, 2012 12:43 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i wrote a IDetachListener that automatically detaches any IModel fields found on components. is this something we would be interested in for core? its been running in production for a while without any noticeable overhead and its nice not to have to implemenet onDetach() all the time just to forward it to secondary models. the only downside is that once we introduce this feature we can never remote it because doing so will break code. thoughts? -igor
Missing 1.5.4 Release Tag?
Wicketeers, I was wanting to do some comparing between trunk and what's in the latest release tag (trying to backport something out of trunk). I went looking for the tag for the 1.5.4 release. I looked here: http://svn.apache.org/repos/asf/wicket/releases/ I can see 1.5.3, but there's no tag for 1.5.4. Did the build process change as far as where you guys are putting your tags? Thanks, James
Re: Missing 1.5.4 Release Tag?
OMG! I can't get it through my thick skull that you guys are on GIT now! DUH! Sorry for the traffic. On Sat, Mar 3, 2012 at 4:26 PM, James Carman ja...@carmanconsulting.com wrote: Wicketeers, I was wanting to do some comparing between trunk and what's in the latest release tag (trying to backport something out of trunk). I went looking for the tag for the 1.5.4 release. I looked here: http://svn.apache.org/repos/asf/wicket/releases/ I can see 1.5.3, but there's no tag for 1.5.4. Did the build process change as far as where you guys are putting your tags? Thanks, James
Re: JavaSerializer doesn't call SerializableChecker...
I don't know about your solution. What if someone tries to use one of the other methods of the ObjectOutputStream contract? You're not delegating all of them. That's why I did what I did. On Sun, Nov 27, 2011 at 6:50 AM, Martin Grigorov mgrigo...@apache.org wrote: Fixed it without API breaks and new classes. On Fri, Nov 25, 2011 at 6:19 PM, James Carman ja...@carmanconsulting.com wrote: JIRA created and patch attached: https://issues.apache.org/jira/browse/WICKET-4264 I ended up actually not using ObjectOutput. I created a new interface called ObjectWriter which only contains the writeObject() and close() methods. The ObjectOutput interface had too many methods in it and we were only using those two. Let me know if you guys want any more help from me on this or if you want me to include a test case that shows that SerializableChecker isn't called (don't know how to do that off the top of my head just yet). After installing 1.5-SNAPSHOT locally, I do see the nice messages now in my logs that tell me exactly where the field is that is causing the problem. Life is good again. Thanks, James On Fri, Nov 25, 2011 at 11:28 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I think it is OK to break it. The public API is ISerializer while your proposed changes are internals of JavaSerializer, imo. On Fri, Nov 25, 2011 at 6:24 PM, James Carman ja...@carmanconsulting.com wrote: While doing a bit of debugging today, I noticed that I didn't see that nice serialization issue message that tells me which field is the problem. So, I started looking into it (with some direction from martin-g on IRC): The Problem In the new JavaSerializer class, it has a CheckerOutputStream which extends ObjectOutputStream. The intent is to use the ObjectOutputStream.writeObjectOverride() support. However, the writeObjectOverride() method is never called unless you use the no-arg constructor from the ObjectOutputStream class (which sets the enableOverride flag to true). The CheckerOutputStream uses the ObjectOutputStream(OutputStream) constructor in its constructor. Worse yet, even if the writeObjectOverride() method were to be called, it would create a StackOverflowError because it's calling the super.writeObject() method which is what called it in the first place (infinite recursion). My Proposed Solution I propose we do the following: 1. Change the following JavaSerializer method: ObjectOutputStream newObjectOutputStream(OutputStream out) to ObjectOutput newObjectOutput(OutputStream out) 2. Change CheckerOutputStream to implement ObjectOutput instead of extending ObjectOutputStream. 3. Have CheckerOutputStream delegate its ObjectOutput methods to an internal ObjectOutputStream object. Now, this would break the existing API because you're changing the signature of the newObjectOutputSream() method, but I think this is how it should have been written in the first place (to the interface, not the class). What do you guys think? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
JavaSerializer doesn't call SerializableChecker...
While doing a bit of debugging today, I noticed that I didn't see that nice serialization issue message that tells me which field is the problem. So, I started looking into it (with some direction from martin-g on IRC): The Problem In the new JavaSerializer class, it has a CheckerOutputStream which extends ObjectOutputStream. The intent is to use the ObjectOutputStream.writeObjectOverride() support. However, the writeObjectOverride() method is never called unless you use the no-arg constructor from the ObjectOutputStream class (which sets the enableOverride flag to true). The CheckerOutputStream uses the ObjectOutputStream(OutputStream) constructor in its constructor. Worse yet, even if the writeObjectOverride() method were to be called, it would create a StackOverflowError because it's calling the super.writeObject() method which is what called it in the first place (infinite recursion). My Proposed Solution I propose we do the following: 1. Change the following JavaSerializer method: ObjectOutputStream newObjectOutputStream(OutputStream out) to ObjectOutput newObjectOutput(OutputStream out) 2. Change CheckerOutputStream to implement ObjectOutput instead of extending ObjectOutputStream. 3. Have CheckerOutputStream delegate its ObjectOutput methods to an internal ObjectOutputStream object. Now, this would break the existing API because you're changing the signature of the newObjectOutputSream() method, but I think this is how it should have been written in the first place (to the interface, not the class). What do you guys think?
Re: JavaSerializer doesn't call SerializableChecker...
JIRA created and patch attached: https://issues.apache.org/jira/browse/WICKET-4264 I ended up actually not using ObjectOutput. I created a new interface called ObjectWriter which only contains the writeObject() and close() methods. The ObjectOutput interface had too many methods in it and we were only using those two. Let me know if you guys want any more help from me on this or if you want me to include a test case that shows that SerializableChecker isn't called (don't know how to do that off the top of my head just yet). After installing 1.5-SNAPSHOT locally, I do see the nice messages now in my logs that tell me exactly where the field is that is causing the problem. Life is good again. Thanks, James On Fri, Nov 25, 2011 at 11:28 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I think it is OK to break it. The public API is ISerializer while your proposed changes are internals of JavaSerializer, imo. On Fri, Nov 25, 2011 at 6:24 PM, James Carman ja...@carmanconsulting.com wrote: While doing a bit of debugging today, I noticed that I didn't see that nice serialization issue message that tells me which field is the problem. So, I started looking into it (with some direction from martin-g on IRC): The Problem In the new JavaSerializer class, it has a CheckerOutputStream which extends ObjectOutputStream. The intent is to use the ObjectOutputStream.writeObjectOverride() support. However, the writeObjectOverride() method is never called unless you use the no-arg constructor from the ObjectOutputStream class (which sets the enableOverride flag to true). The CheckerOutputStream uses the ObjectOutputStream(OutputStream) constructor in its constructor. Worse yet, even if the writeObjectOverride() method were to be called, it would create a StackOverflowError because it's calling the super.writeObject() method which is what called it in the first place (infinite recursion). My Proposed Solution I propose we do the following: 1. Change the following JavaSerializer method: ObjectOutputStream newObjectOutputStream(OutputStream out) to ObjectOutput newObjectOutput(OutputStream out) 2. Change CheckerOutputStream to implement ObjectOutput instead of extending ObjectOutputStream. 3. Have CheckerOutputStream delegate its ObjectOutput methods to an internal ObjectOutputStream object. Now, this would break the existing API because you're changing the signature of the newObjectOutputSream() method, but I think this is how it should have been written in the first place (to the interface, not the class). What do you guys think? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
[wicketopia] Wicketopia has moved back to GitHub...
All, I have moved the active development of Wicketopia back to GitHub. You can now find it at: https://github.com/jwcarman/Wicketopia Some recent developments: 1. CDI Integration (including Weld adapter) 2. Rudimentary support for entity relationships (drop down chooser). Coming soon: 1. More robust support for relationships (one-to-many/many-to-many). 2. Better example applications (splitting into different examples). 3. A 1.0 release finally! Ideas for Future: 1. Automatic searching (anyone wanna help?) Thanks, James
CDI Library Implementation Question...
I'm having a bit of trouble with my CDI library's example. I'm not
sure if I'm attempting to do something that I shouldn't expect to work
or if my library isn't working correctly. I've got a couple of links
on my page:
add(new Link(convBegin)
{
@Override
public void onClick()
{
conversation.begin();
setResponsePage(this.getPage().getClass());
}
@Override
public boolean isVisible()
{
return conversation.isTransient();
}
});
add(new Link(convEnd)
{
@Override
public void onClick()
{
conversation.end();
setResponsePage(this.getPage().getClass());
}
@Override
public boolean isVisible()
{
return !conversation.isTransient();
}
});
If I comment out the setResponsePage() calls, it will blow up when I
click the convEnd link because it's eventually resolving to a
BufferedResponseRequestHandler and I get this in the logs:
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - New request cycle!
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Request handler
ListenerInterfaceRequestHandler resolved, searching for cid request
parameter...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Found request
parameter cid!
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Resuming conversation 2...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Saving
non-transient conversation id 2 to HomePage page's metadata...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Saving
non-transient conversation id 2 to page parameters...
11-19@13:36:25 DEBUG (Conversation) - WELD-000318 Returned
long-running conversation 2 to transient
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Removing ended
conversation id 2 from url ?2cid=2...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Removing ended
conversation id 2 from url ?2-3.ILinkListener-logincid=2...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Removing ended
conversation id 2 from url ?2-3.ILinkListener-convBegincid=2...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Removing ended
conversation id 2 from url ?2cid=2...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Removing
conversation id 2 from HomePage page's metadata...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Removing
conversation id parameter (2) from page parameters...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Abandoning
transient conversation...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - New request cycle!
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Request handler
BufferedResponseRequestHandler resolved, searching for cid request
parameter...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Found request
parameter cid!
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Resuming conversation 2...
11-19@13:36:25 DEBUG (CdiRequestCycleListener) - Conversation id
not found, initiating transient conversation...
11-19@13:36:25 ERROR (DefaultExceptionMapper) - Unexpected error occurred
org.jboss.weld.context.NonexistentConversationException: WELD-000321
No conversation found to restore for id 2
When I have the setResponse() page calls in, this is what the log looks like:
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - New request cycle!
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Request handler
ListenerInterfaceRequestHandler resolved, searching for cid request
parameter...
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Found request
parameter cid!
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Resuming conversation 3...
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Saving
non-transient conversation id 3 to HomePage page's metadata...
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Saving
non-transient conversation id 3 to page parameters...
11-19@13:37:55 DEBUG (Conversation) - WELD-000318 Returned
long-running conversation 3 to transient
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Removing
conversation id 3 from HomePage page's metadata...
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Removing
conversation id parameter (3) from page parameters...
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Abandoning
transient conversation...
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - New request cycle!
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Request handler
RenderPageRequestHandler resolved, searching for cid request
parameter...
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Conversation id
not found, initiating transient conversation...
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - Abandoning
transient conversation...
11-19@13:37:55 DEBUG (CdiRequestCycleListener) - New request cycle!
Re: Performance statistics for Wicket 1.5-SNAPSHOT
Perhaps we should re-write it using wicket-velocity! ;) On Thu, Jun 16, 2011 at 11:53 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: his test is hand-tailored to fail any true component oriented framework. 5000 items per page? really? show me a single website that does that. even facebook doesnt show that many comments on the wall without making you page. but, after looking at other i hate wicket posts on his blog i am not surprised with his testing approach :) if this situation came up in the real life any sane developer would wrap the entire product list into a single component that would stream html directly using string manipulation. and if you do that then wicket will be on par - if not faster - then the other ones. because at that point you are measuring the same thing - how fast the jvm loops. -igor On Thu, Jun 16, 2011 at 6:56 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: The application used in http://www.jtict.com/blog/rails-wicket-grails-play-lift-jsp/ has been controversial as it pits all popular frameworks against one another. I've tried to replicate the results on my box with AB, and did some modifications to the code: - removed the image from the markup: browsers will hit the non-existent image causing long load times - did the categories list in a similar way that the Tapestry implementation did: using a StringBuilder (saves ~300ms for a single user with 5000 items) - randomized the results for each query to the products() method such that caching the results is not an option I couldn't replicate the tapestry results with these settings (instead of being almost constant time, it now is linear but 1.5x faster than wicket). I'm not sure if the author actually looked at the results of the tapestry tests, but it seems to me that something went wrong. The code has been altered with the above changes, including changing the ListView into a RepeatingView, and rendering the categories in a StringBuilder. Here are the results of an ab test on my laptop for 200 products and 32 concurrent users: dashorst$ ab -c 32 -n 10240 http://localhost:8080/wicketapp/products3/200 This is ApacheBench, Version 2.3 $Revision: 655654 $ Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1024 requests Completed 2048 requests Completed 3072 requests Completed 4096 requests Completed 5120 requests Completed 6144 requests Completed 7168 requests Completed 8192 requests Completed 9216 requests Completed 10240 requests Finished 10240 requests Server Software: Jetty(6.1.16) Server Hostname: localhost Server Port: 8080 Document Path: /wicketapp/products3/200 Document Length: 34689 bytes Concurrency Level: 32 Time taken for tests: 57.509 seconds Complete requests: 10240 Failed requests: 9670 (Connect: 0, Receive: 0, Length: 9670, Exceptions: 0) Write errors: 0 Total transferred: 354991304 bytes HTML transferred: 352820424 bytes Requests per second: 178.06 [#/sec] (mean) Time per request: 179.714 [ms] (mean) Time per request: 5.616 [ms] (mean, across all concurrent requests) Transfer rate: 6028.16 [Kbytes/sec] received Connection Times (ms) min mean[+/-sd] median max Connect: 0 1 1.6 0 17 Processing: 11 179 123.2 163 1000 Waiting: 11 171 123.1 154 999 Total: 12 179 123.3 164 1000 Percentage of the requests served within a certain time (ms) 50% 164 66% 218 75% 248 80% 268 90% 337 95% 418 98% 491 99% 552 100% 1000 (longest request) The same test but then using 16 users: dashorst$ ab -c 16 -n 10240 http://localhost:8080/wicketapp/products3/200 This is ApacheBench, Version 2.3 $Revision: 655654 $ Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/ Licensed to The Apache Software Foundation, http://www.apache.org/ Benchmarking localhost (be patient) Completed 1024 requests Completed 2048 requests Completed 3072 requests Completed 4096 requests Completed 5120 requests Completed 6144 requests Completed 7168 requests Completed 8192 requests Completed 9216 requests Completed 10240 requests Finished 10240 requests Server Software: Jetty(6.1.16) Server Hostname: localhost Server Port: 8080 Document Path: /wicketapp/products3/200 Document Length: 34290 bytes Concurrency Level: 16 Time taken for tests: 54.005 seconds Complete requests: 10240 Failed requests: 6161 (Connect: 0, Receive: 0, Length: 6161, Exceptions: 0) Write errors: 0 Total transferred: 355066608 bytes HTML transferred: 352895728 bytes Requests per second: 189.61 [#/sec]
Re: Rework AttributeModifier to deprecate AttributeAppender and SimpleAttributeModifier
I like the idea of the builder pattern much better. DSLs rock! Sent from tablet device. Please excuse typos and brevity. On Jun 8, 2011 6:35 AM, Martin Grigorov mgrigo...@apache.org wrote: or builder pattern: AttributeModifier.attr(name).model(someModel).create().append() On Wed, Jun 8, 2011 at 12:27 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Taken from the user@ list, where it might get snowed under... The SimpleAttributeModifier, AttributeAppender and AttributePrepender classes are in my opinion stop gap measures to work around issues with AttributeModifier's API. I think that we could do better API wise with three factory methods (or 6 if we duplicate each method to take an IModel? and a String for convenience) on AttributeModifier, and deprecate SimpleAttributeModifier and AttributeAppender. I'd also merge the appender/prepender logic into attribute modifier, such that user specializations can make use of them. AttributeModifier.setAttribute(String attribute, IModel? value); AttributeModifier.setAttribute(String attribute, String value); AttributeModifier.prependAttribute(String attribute, String value); AttributeModifier.prependAttribute(String attribute, IModel? value); AttributeModifier.appendAttribute(String attribute, String value); AttributeModifier.appendAttribute(String attribute, IModel? value); Or perhaps: AttributeModifier.overwrite(String attribute, IModel? value); AttributeModifier.overwrite(String attribute, String value); AttributeModifier.prepend(String attribute, IModel? value); AttributeModifier.prepend(String attribute, String value); AttributeModifier.append(String attribute, IModel? value); AttributeModifier.append(String attribute, String value); I'd value input on the naming of things. Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
I'm -1 to gradle. We don't all use it. It's not like we're a groovy-based framework. On May 1, 2011 12:07 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i guess the question then is, do we switch to gradle for 1.5? can you check in the gradle build file so we can all take a look? -igor On Sun, May 1, 2011 at 8:20 AM, Juergen Donnerstag juergen.donners...@gmail.com wrote: I'm not a gradle expert which is why I had to try this and that. But my initial tests to create the ueber jars have now been successful. -Juergen On Fri, Apr 29, 2011 at 2:16 PM, Martin Grigorov mgrigo...@apache.org wrote: I'm interested to see how easy is to do what we weren't able to do with Maven: - create a new module which should: -- combine all the .class-es from -core, -util, -request (aka uber-jar) -- combine all -sources.jar from the above into one (uber-sources.jar) --- this is the reason to give up what we had in 1.5-RC1 -- combine all -javadocs.jar from the above into one (uber-javadocs.jar) On Fri, Apr 29, 2011 at 3:06 PM, Juergen Donnerstag juergen.donners...@gmail.com wrote: I played a bit with gradle recently. - Transfered Wicket's build process which was fairly straight forward; compile, test, install. jetty:run etc. - eclipse project files generated seem to be ok - maven repositories to get artifacts - successfully installed a new snapshot in my local repo I didn't test anything beyond though, especially not our release process. And I didn't look at report etc. -Juergen On Fri, Apr 29, 2011 at 11:35 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Thu, Apr 28, 2011 at 9:10 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: we tried to create the uber jar but it failed. maybe if we used something like gradle we couldve done it, but switching build systems just for this seems a little extreme. Not quite: I've had enough problems with Maven at $dayjob that I'm considering dumping it for either gradle or buildr. While I haven't looked at gradle in detail, I suspect it would make releasing Wicket a bit simpler. It wouldn't necessarily break our support for Maven, just that we now use another build system, but still deploy our artifacts to the maven repo, including pom files. Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: [Wicketstuff 1.5] Code formatting
On Thu, Apr 7, 2011 at 2:04 AM, Attila Király kiralyattila...@gmail.com wrote: We can add the eclipse prefs to git so it gets configured automatically. Do not know how to do it for other IDE-s. If we add this I do not think that we should reformat all projects at once. Only to do it when we touch a project or file. A complete reformat could make it harder to dig in the version history of the files. Just use checkstyle: http://checkstyle.sourceforge.net/
Re: [Wicketstuff 1.5] Code formatting
On Thu, Apr 7, 2011 at 6:47 AM, James Carman ja...@carmanconsulting.com wrote: On Thu, Apr 7, 2011 at 2:04 AM, Attila Király kiralyattila...@gmail.com wrote: We can add the eclipse prefs to git so it gets configured automatically. Do not know how to do it for other IDE-s. If we add this I do not think that we should reformat all projects at once. Only to do it when we touch a project or file. A complete reformat could make it harder to dig in the version history of the files. Just use checkstyle: http://checkstyle.sourceforge.net/ Sorry, hit send too early (it's too early for me apparently). Trying to maintain all of these settings for different IDEs and checking them into SVN isn't a good idea. Checkstyle can help you flag code that looks funny using the CI server (or when they build it locally)
Re: [Wicketstuff 1.5] Code formatting
On Thu, Apr 7, 2011 at 7:48 AM, Attila Király kiralyattila...@gmail.com wrote: (Also an answer to Hans Lesmeister) Afaik there is no checkstyle plugin that can do the same as eclipse formatter + save actions: format and clean up code upon save. Checkstyle will only test that the rules are met or not. It is not very convenient (also not possible to reformat whole projects with one click). Again, we don't all use Eclipse. The Checkstyle plugin is convenient because it works in any environment (IDE or not).
Re: Wicket Stuff commit access
Thanks for taking point on this wicketstuff/github/maven report stuff, Michael. Your work is much appreciated! On Mar 22, 2011 8:56 PM, Michael Oapos;Cleirigh michael.ocleir...@rivulet.ca wrote: Hi, I've added you to the committers team in github.com Let me know when your module is in and working and I can cut wicketstuff-core point releases to get it distributed into maven central. Regards, Mike Can I please have wicketstuff commit access? I want to add a new module. My github username is cretzel. Thanks. - Nick -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Stuff-commit-access-tp3397928p3397928.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Removing Pagemap lock post 1.5?
What about AJAX requests coming from multiple places for the same session? On Fri, Mar 18, 2011 at 11:45 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: I'm not sure if this is still happening in 1.5, but could it be possible to nix the pagemap lock (or severely shorten it to 1-2 seconds) and abandon request processing at the first possible moment when a new request for the pagemap arrives at the server? It's not like the browser is expecting an answer for the original request AFAIK. Expected behavior: - request1: starts processing, locks pagemap - request2: comes in: tries to acquire lock - request2: waits for max N seconds (N being a small number, 1 or 2 seconds) - request2: sets kill switch for request1 - request1: first time in wicket managed code: throws Abort exception, does not commit page hierarchy to pagemap - request2: starts processing its request Probably this will become quite complex and I have my friday afternoon goggles on, so just think of this as a thought experiment. Homework: think out what happens when request3 joins the party. Martijn
Re: HEADS UP: A change in web.xml setup is required
I don't think he was saying it was incorrect. He was saying that he's okay with the added inconvenience if it makes everything work correctly. On Fri, Mar 18, 2011 at 1:51 PM, tetsuo ronald.tet...@gmail.com wrote: Why would it (Igor's proposal) be not correct? On Fri, Mar 18, 2011 at 2:28 PM, Peter Ertl pe...@gmx.org wrote: in general I prefer correctness over convenience ... so if we need a context listener to do everything right so should it be (remember having the same kind of trouble with jetty) +0 Am 18.03.2011 um 17:50 schrieb Igor Vaynberg: another possible solution is to serialize the page into SerializedPage before sticking it into session...this may introduce some overhead, especially for non-clustered apps. however, we can have a special pagemanager for non-clustered apps that does not change page instances into SerializedPage...kind of like HttpSessionStore works in 1.4 compared to a store that uses DiskPageStore. -igor On Fri, Mar 18, 2011 at 9:35 AM, Martin Grigorov mgrigo...@apache.org wrote: On Fri, Mar 18, 2011 at 5:04 PM, tetsuo ronald.tet...@gmail.com wrote: Well, I was trying to understand the problem before posting random thoghts :) SegFault commented the issue with this question: the only problem I see is that there is no one to clean the static org.apache.wicket.page.PersistentPageManager.managers = maybe a stupid question, but how does this behave in case of many context reloading (for example in developpement mode), is this cleaned up by container ? or this will end up with a PermGen space error ? I think that, unless you hold references to webapp-specific classes in server-loaded classes' static fields, or leave zombie threads, PermGen shouldn't occur, and all classes should be gc'ed. Does the page manager do anything that prevents it to be gc'ed? Does it need any extra clean-up, besides being unloaded with the webapp classloader? The problem is that the web container first destroys WicketFilter and then goes to serialize/persist the session. Wicket puts Page instances in the session, but before serialization these Page instances are transformed to SerializedPage which is a struct of int pageId; String sessionId; byte[] data; // the page itself and to be able to transform them Wicket needs the configured IPageManager. With the destroy of WicketFilter all information is removed (null-ified) including the PageManager and thus the serialization fails. With the new ServletContextListener (SCL) we will move the application start and stop from the Filter to SCL and solve this problem. Additionally by Servlet specification the container may restart servlets/filters at any time without completely stopping the application, i.e. w/o calling javax.servlet.ServletContextListener.contextDestroyed(ServletContextEvent). So the new way will improve the current behavior. On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i would say that the lack of response shows that people dont care about a couple more xml lines they have to add to web.xml once and forget about. -igor On Fri, Mar 18, 2011 at 7:47 AM, Martin Grigorov mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, To solve https://issues.apache.org/jira/browse/WICKET-3470 we need to introduce ServletContextListener in Wicket. In comment https://issues.apache.org/jira/browse/WICKET-3470?focusedCommentId=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166Idescribed a proposal how we can change web.xml configuration to make it working. The proposal is based on a discussion between me and Igor in IRC. This is a rather big change and we need more opinions, so please share if you have ideas. By big here I mean conceptually, not code wise. Technically it doesn't seem to be big or complex. --martin-g P.S. I'm interested to understand why there is no such problem with Wicket 1.4? I guess sessions in 1.4 are cleared earlier and never persisted between web container restarts. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Re: Spring Annotations supoprt for IoC on WebPages
On Wed, Feb 23, 2011 at 8:56 AM, tetsuo ronald.tet...@gmail.com wrote: Since Spring 3.0, scoped proxies are Serializable. So, it's perfectly possible to use @Configurable, @Autowired, and lots of AspectJ magic, for Pages and Components, instead of wicket-spring/@SpringBean. Provided, of course, that all beans you inject into Components are scope-proxied (aop:scoped-proxy/ or @Scope(value = singleton, proxyMode = ScopedProxyMode.INTERFACES)). That's a pretty big gotcha, IMHO.
Re: Spring Annotations supoprt for IoC on WebPages
On Wed, Feb 23, 2011 at 2:46 PM, tetsuo ronald.tet...@gmail.com wrote: Yes, it is. Just use @SpringBean. Agreed! :)
Re: Spring Annotations supoprt for IoC on WebPages
The problem with that is that it doesn't address the situation where
the reference is passed elsewhere (like to a DataProvider). With the
proxy-based approach (which wicket-spring does now), it does.
On Tue, Feb 22, 2011 at 4:34 PM, Bruno Borges bruno.bor...@gmail.com wrote:
Hi everyone,
A friend was playing with Wicket and Spring and suggested that the
Spring integration could have a injector that could call the
AutowireCapableFactory of Spring to process Spring-native annotations, like
@Autowired and @Value.
@Override
public void onInstantiation(Component arg0) {
contextLocator.getSpringContext().getAutowireCapableBeanFactory().autowireBean(arg0);
}
What do you guys think of this?
Best regards,
Bruno Borges
www.brunoborges.com.br
+55 21 76727099
The glory of great men should always be
measured by the means they have used to
acquire it.
- Francois de La Rochefoucauld
Re: Upgrade spring dependency to 3.0-latest prior to 1.5 final?
On Thu, Feb 17, 2011 at 2:26 PM, Maarten Bosteels mbosteels@gmail.com wrote: -1 for updating to spring 3 (especially when wicket-spring doesn't need features not available in 2.5.6) How about version[2.5.6,)/version ? It clearly indicates that 2.5.6 is the minimum required version for wicket-spring http://docs.codehaus.org/display/MAVEN/Dependency+Mediation+and+Conflict+Resolution#DependencyMediationandConflictResolution-DependencyVersionRanges I've never had much luck with this sort of version specification. If you specify 2.5.6 and the containing project is using a newer version, then Maven will just use the newer version (provided the groupId and artifactId are the same, which they would be if we just switch to using spring-web rather than spring).
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Mon, Jan 24, 2011 at 12:32 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: with the new split we have introduced iprovider interface which decouples the mess. a good example is that if now some part of request processing needs a configurable option it gets it via iprovider which in turn gets it from an application setting. this allows us to unit test that part of code without requiring the application to be set up and thus without requiring wicket tester. It sounds like you've fixed some of the problem(s) that caused you to split stuff up in the first place, but you did it using *code design* which is the correct way to go about this. The module gymnastics approach just leads to confusion, IMHO.
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
On Tue, Jan 25, 2011 at 11:50 AM, Jeremy Thomerson jer...@wickettraining.com wrote: The separate modules is a good way to enforce the separation. If you have other ideas for enforcing them, I'd be happy to hear them. It doesn't really enforce anything. Folks can still put classes in the wrong module and screw things up. So, either way, you're adhering to a convention. So, why muddy up the project structure?
Re: RC1 parameter name style guide
Sure blame us commons people :) On Jan 25, 2011 12:21 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: that code was taking out of apache commons upload afair. -igor On Tue, Jan 25, 2011 at 9:16 AM, richard emberson richard.ember...@gmail.com wrote: While going through RC1 wicket-util I noted that in the org.apache.wicket.util.upload package there are a number of places where the parameter names to methods and constructors are of the form pName (e.g., pSizeMax. pIn, pHeaders. pContentLength. etc.). I think that this is the first time I've seen this Java coding style used in Wicket (though, I could be wrong). Does the Wicket coding style guidelines cover parameter names? While not wanting to be labeled by Emerson (not Emberson) concerning consistency, sometimes there is some merit to it. Richard -- Quis custodiet ipsos custodes
Re: Do Lucene developers use FindBugs?
So, what does this have to do with Lucene? 2011/1/24 César Couto cesar...@dcc.ufmg.br: Dear developers, I am a PhD student at UFMG, Brazil and as part of my research I am making a study about the relevance of the warnings reported by the FindBugs bug finding tool. Since I am planning to use Wicket as a subject system in my research, I would like to know if Wicket's developers usually run FindBugs as part of the system development process. Thanks in advance, Cesar Couto -- http://www.decom.cefetmg.br/cesar
Re: Do Lucene developers use FindBugs?
I figured that. :) Otherwise, if it said only stuff about Lucene, I would have asked what it had to do with Wicket. On Mon, Jan 24, 2011 at 11:40 AM, Jeremy Thomerson jer...@wickettraining.com wrote: I think it was a form letter he's sending out. The body of the message says Wicket -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* On Mon, Jan 24, 2011 at 10:38 AM, James Carman ja...@carmanconsulting.comwrote: So, what does this have to do with Lucene? 2011/1/24 César Couto cesar...@dcc.ufmg.br: Dear developers, I am a PhD student at UFMG, Brazil and as part of my research I am making a study about the relevance of the warnings reported by the FindBugs bug finding tool. Since I am planning to use Wicket as a subject system in my research, I would like to know if Wicket's developers usually run FindBugs as part of the system development process. Thanks in advance, Cesar Couto -- http://www.decom.cefetmg.br/cesar
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
I have also questioned the usefulness of this new approach, compared to all of the hoops you have to go through to get it to work? What are we saving here? Are wicket-request and wicket-util really intended to be used outside of Wicket? I really don't see the benefit, at least when you consider the cost. On Mon, Jan 24, 2011 at 12:02 PM, Jeremy Thomerson jer...@wickettraining.com wrote: There are two issues [1] and [2] that deal with 1.5-RC1 having an aggregate jar for the wicket-core, wicket-request, and wicket-util classes, but not having an aggregate of the sources. Martin graciously assigned it to me, but I want to discuss it with the community to figure out how we should resolve it. First, some background (hopefully I'm remembering it all correctly) What was all previously in the wicket subfolder was split into wicket / wicket-core / wicket-util in the early development of 1.5. I don't know why - can someone comment on why? I don't think it could possibly give us that much benefit or be *that much* cleaner. But, maybe it is. Then, to avoid confusion for those who previously depended on wicket.jar (which now is missing all -util and -request classes), the wicket subfolder was renamed to wicket-core, and wicket.jar was built as an aggregate of wicket-core, wicket-util, and wicket-request. This was really just done for non-Maven users so that they could get all the core Wicket dependencies in one jar rather than three. Problems: 1 - if you use Maven, you should just depend on wicket-core, which will depend on the others. But, if you incorrectly depend on wicket.jar, and wicket-auth-roles or extensions, etc, you end up with duplicated classes because you'll have wicket.jar and the three independent jars. 2 - If you don't use Maven, you can just use wicket.jar, but we're not building wicket-sources.jar (or it's built empty), so you can't really attach sources in your IDE. Solutions: 1 - Martin suggests that we don't deploy wicket.jar to maven repos because it's not intended for maven users. I agree with this, but it doesn't fix all the problems above 2 - We could somehow build wicket-sources (and wicket-javadocs) jar files. These should be deployed wherever wicket.jar is, but like #1 mentions, none should go to Maven repos. 3 - Combine all three projects back into one. All these problems are solved instantly. 4 - Don't build the aggregated jar(s) at all. Really, I'd opt for #3. I don't think we need all three separate projects. I don't see a benefit. If we must keep the three separate code modules, then I opt for #4. I don't like the idea of deploying multiple artifacts with the same stuff in them. It's too easy for folks to end up with duplicated classes in their classpath. We don't want to contribute to that. Whatever we decide, I feel that if we build wicket.jar (aggregated classes), we *must* build a sources and javadocs jar. Input? [1] - https://issues.apache.org/jira/browse/WICKET-3365 [2] - https://issues.apache.org/jira/browse/WICKET-3376 -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: How to streamline ajax page region toggle
On Thu, Jan 20, 2011 at 3:07 PM, Jeremy Thomerson jer...@wickettraining.com wrote: I, too, like the idea. Couldn't it be simpler? Couldn't he: Yes, it could be simpler. It could be easier to add a listener to the ART in-general. :)
Re: Scala-Wicket Help and Advice
Don't get me wrong, I'm all about seeing a Wicket-like Scala-based
project (and would contribute to it), but that's not what we've been
debating here lately on this thread. If you guys want to talk about
coming up with a from-the-ground-up Scala-based, Wicket-inspired
project, then I'm all ears and think we should start putting something
in github or something.
On Wed, Jan 19, 2011 at 12:09 PM, Martin Makundi
martin.maku...@koodaripalvelut.com wrote:
What about rewriting wicket into most wonderful tight functional scala style?
def : webserver {
homepage,
logoutpage,
onlinestore,
}
...
;)
**
Martin
2011/1/19 James Carman ja...@carmanconsulting.com:
I believe this conversation has gone enough off-course that it no
longer belongs on this mailing list. We're not discussing anything
related to Wicket anymore.
On Wed, Jan 19, 2011 at 11:57 AM, richard emberson
richard.ember...@gmail.com wrote:
On 01/19/2011 07:22 AM, Martin Makundi wrote:
The only thing that bugs me about scala is its flexibility of
accepting different kind of notation. It's that what was the
downfall of html: making complilers flexible to allow various human
input and as end result none of the browsers work correctly because
the truth is only in the eye of the beholder (or creator only, in
this case).
I guess concerning HTML, I would say that it did not have a good
enough spec soon enough and, of course, MS did whatever they wanted
anyway.
Scala has a very, very detailed spec (do not try to learn the
language by reading the spec first).
Scala also has the incredible advantage that the Scala team
can make changes that are not backward compatible, which is to
say, Scala has had a long gestation period.
This advantage was particularly useful in going from the 2.7 to 2.8
releases where the whole collection framework was redone. They are
finding out what works best and folding those changes back into the
language. This will slow down with time (I expect the collection
re-write is the last super big change).
Scala maybe needs a bit more syntactical canonicity?
I agree, languages have multiple ways of doing things:
while-loop and for-loops
i++ vs i += 1 vs i = i + 1 (Scala does not support i++)
First, Scala is both OO and FP, so there are generally a
couple of approaches - one that looks like Java and one that
is more pipelined, data flowing through functions.
So, it is true that Scala allows one to be creative!?.
Some of this comes from the vastly richer set of capabilities
associated with the collection classes. In Java one has
Iterator while in Scala there is a whole lot of extra
standard methods.
Just yesterday while working on my NIST RBAC code, I had to
decide how to check access rights in a test class:
Does a Session have a given Permission, where
Roles are in a Set and RolesToPerm is a Map from Role to Permission:
def checkAccess(session: Session, perm: Permission): Boolean = {
// version 0, very Java-like, never considered
for (role - session.getRoles) {
val pOp = roleToPerms.get(role)
if (permOp.isDefined)
if (permOp.get == perm) return true
}
false
// or version 1, handling Option the Scala-way
for (role - session.getRoles) {
roleToPerms.get(role) match {
case Some(p) = if (p == perm) return true
case None = // ignore
}
}
false
// or version 2, rather more functional
sesson.getRoles.foldLeft(false) { _ || roleToPerms.get(_).getOrElse(null)
== perm }
}
The first two versions are not too hard to understand, but the last
one, unless you know what foldLeft does, is, I imagine, opaque to most
Java programmers.
[foldLeft sets the result value with an initial value, false, and
then iterates over the values of the container, roles, performing
the operation, ||, creating a new result value on each iteration
where the first _ is the current result value and the second _ is
the value from the container. getOrElse returns the value looked up
from roleToPerms and, if it does not exist, returns null. Lastly,
the iteration stops when the first true value, == perm is true;
the normal || shortcutting.]
That said, I consider the code to be functional
programming in-the-small, a single line of code and, ultimately, more
understandable (and more maintainable) than either of the proceeding
versions. [There maybe a better way to pipeline the evaluation, this
is just what I did.]
I have very mixed feelings about DSLs. If every programmer in your
project creates their own DSLs for their own section or, even worse,
per class, then DSLs are very bad; less understandable code, a
maintenance problem and a barrier to getting new hires up to speed.
On the other hand, if a project controls the use of DSLs and they
are well documented, they could (not will be, but could) be a boon
rather than a bust.
**
Martin
2011/1/19 richard embersonrichard.ember...@gmail.com:
Yea
Re: Renaming IInitializer?
ApplicationLifecycleListener? On Jan 18, 2011 8:14 AM, Major Péter majorpe...@sch.bme.hu wrote: Hi, since IInitializer now also works as an IDestroyer, wouldn't be ApplicationContextListener a better name for it? (based on ServletContextListener) Regards, Peter
Re: [vote] release wicket-1.5-rc1
Releases can't be vetoed but it is good to see a binding -1 vote. Just call the vote cancelled because there was a problem identified On Jan 13, 2011 9:26 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: here is a binding -1 to close this officially. -igor 2011/1/13 Major Péter majorpe...@sch.bme.hu: Sadly I have a -1 for this, because of https://issues.apache.org/jira/browse/WICKET-3329 and https://issues.apache.org/jira/browse/WICKET-3330 3329 is almost a don't care, but 3330 sounds more serious to me. Best regards, Peter 2011-01-13 08:20 keltezéssel, Igor Vaynberg írta: this vote is to release wicket 1.5-rc1. the trunk has been stable for a while without any major bugs found. the api has also stabilized nicely. it is time for rc1. branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC1 artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC1/ maven repo: https://repository.apache.org/content/repositories/orgapachewicket-023/ changelog: https://issues.apache.org/jira/secure/IssueNavigator.jspa?reset=truepid=12310561fixfor=12315483sorter/field=issuekeysorter/order=DESC this vote ends Saturday, January 15 at 11:30pm GMT-8 please test the release and offer your vote cheers, -igor
Re: Display component feedback message once: safety net renders them always before
It's like crossing the streams on Ghostbusters. Just don't do it. :) On Jan 13, 2011 9:27 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: if you put two of them on a page do you get an infinite loop? :) -igor On Thu, Jan 13, 2011 at 12:19 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jan 4, 2011 at 10:13 AM, Jeremy Thomerson jer...@wickettraining.com wrote: I had encountered this issue and for one of my training classes, I threw together a solution. Your post prodded me to go ahead and post my solution as a blog post. After dusting off my long-forgotten blog, here it is: http://www.jeremythomerson.com/blog/2011/01/catching-all-feedback -messages-that-arent-rendered-by-other-feedback-panels/ (or http://bit.ly/eHUEuN if that gets chopped up). Moving this discussion to dev@ - does anyone think that I should commit this catch all feedback panel to core? Would it be useful to others? I've used it, or something similar in several applications - not sure if others have had similar requirements. -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org*
Re: Scala-Wicket Help and Advice
Since scala is statically-typed, the ide can (and does) give you contextual help very easily On Jan 8, 2011 2:21 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: But it will do the right thing about 90% of the time. you'll subconsciously work around 4 or 5% of the rest that doesn't work, and the remaining 5-6% will irritate you. I am used to coding 90% using context help with eclipse (ctrl+space). I am a fast writer but that speeds up my coding by 1000%. Will an IDE do that for scala 90%? I consider context help and quickfix proposals most important for speedy work. - imports sometimes get messed up (relative vs absolute, I hate that in scala) and require a manual correction Import organization is important to me also. I like to spend my time coding logic instead of organizing text files. - analysis is useful about 90% of the time, but it's so slow you may just not care for it What is analysis? I hope it isn't the context help ;) ** Martin - it crashes the JVM on Oracle's JRockit (although IDEA is much faster in that jvm) On Fri, Jan 7, 2011 at 5:37 PM, Liam Clarke-Hutchinson l...@steelsky.co.nzwrote: Define complete. On Sat, Jan 8, 2011 at 7:52 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Nice or complete? ** Martin 2011/1/7 Jonathan Locke jonathan.lo...@gmail.com: Have you checked out IDEA? My Scala friends tell me it has pretty nice Scala support. Jon Less is more. http://www.amazon.com/Coding-Software-Process-Jonathan-Locke/dp/0615404820/ -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Scala-Wicket-Help-and-Advice-tp3174601p3185239.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Scala-Wicket Help and Advice
On Sat, Jan 8, 2011 at 1:25 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: What I hate about java is its one-dimensionality... ehh.. say you have: object man object man carrying bag bag carrying pencil case. This isn't a Java problem. This is a design problem. How would you workaround the design assuming you cannot change the releations between the object models (object model has its own requirements/sweetspot)? You would use a more domain-oriented design approach. Setters/getters are merely used because of all the frameworks that support (and expect) them. Why do you care where the man is carrying his pencil? Perhaps he's keeping it in his sock. All you want to do is ask the man object for a pencil. Having to go through his carrying bag to his pencil case to get his pencil is exposing the implementation. If the man exposes his bag/pencil case to the world, then someone can just steal the pencil from him without him knowing about it. However, if you have to ask him for the pencil and then he can go dig in his bag to get his pencil case to find a pencil, then perhaps he can do something at that point and jot down a note that you've just borrowed a pencil from him.
Re: Scala-Wicket Help and Advice
On Sat, Jan 8, 2011 at 2:59 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: It should be possible to say that man will proxy by default all get methods of his belongings, It should be possible to say that bag will proxy by default all get methods of his belongings. Same with pencil casing. In such situation i wouldn't need to CODE all thsoe get.get.get.get methods but the framework or compilation procedure would provide them automatically. WHEN I want to intervene the GET method (and track borrowed pencils for example) I could just override the man.getPencil explicitly to do that. Okay, I see your point. This type of thing is possible in a language like Ruby where you can merely send messages to an object as opposed to calling methods. However, then you have to put all sorts of logic in the handle any message method to try to figure out what the heck you're trying to do (like ActiveRecord's dynamic finders). Is this any better than just writing a method like this in Java: public T T borrowObject(ClassT objectType) where you can do Pencil p = man.borrowObject(Pencil.class); Either way, you have to put logic somewhere that tries to figure out what the heck you want to borrow and then figure out where the heck to get it. I don't necessarily think I would consider this a shortcoming of the Java language.
Re: Scala-Wicket Help and Advice
On Sat, Jan 8, 2011 at 4:19 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: Either way, you have to put logic somewhere that tries to figure out what the heck you want to borrow and then figure out where the heck to get it. If it is done at compile time you don't need messaging logic. It would be uniquely defined what you can get. Please explain.
Re: Scala-Wicket Help and advice
On Thu, Jan 6, 2011 at 7:24 PM, Gustavo Hexsel ghex...@gmail.com wrote: One of the cool things about scala is that you could have a model concept without a model class. You just need to receive 2 functions, a setter and a getter (or just a setter for read-only models). So for instance a ListView could have a model-less signature like: ListView[T](id:String, = Iterable[T]) or the like. You can then just use first-class functions to do that: add(new ListView(rows, myService.list)) What about detaching?
Re: Scala-Wicket Help and Advice
Is this in IntelliJ IDEA? On Wed, Jan 5, 2011 at 6:04 PM, Gerolf Seitz gerolf.se...@gmail.com wrote: It's cmd+shift+G (OSX) and it works quite well ;) On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee evancho...@gmail.com wrote: You can paste a java class into a .scala file and it'll autoconvert. there's a shortcut keystroke, too, but i don't remember what it is. On Wed, Jan 5, 2011 at 10:40 AM, richard emberson richard.ember...@gmail.com wrote: No IDE, I use Vim. Also, my build environment is Ant-based using scalac and javac. Of course, what I was doing was porting from Java to Scala. To that end I've got some 400 Vim scripts that aid in the port. For instance, :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1] =/g converts final B a[] = to val a: Array[B] = I don't know if IDEs provide such scripting with regex support. Also, with a simple Vim script and key combination, I can be viewing a ported Scala file and jump to its corresponding source Java Wicket file - very useful when porting or debugging. Yea, IDEs can do stuff me and my Vim scripts can not do, but my fingers know Vim. I also built a JUnit driver class in Scala (and Java) that allowed me to execute a single test method in a given test class by setting two properties in a file that my Ant script reads. This was vital for hunting down bugs. I looked into the tool that allowed Vim to be the front-end and Eclipse to run in server mode which allows a Vim user to access many of the extra features the IDE offers, but, as of a couple of months ago, there was no Scala support in the tool. The father of Scala, Martin Odersky uses Emacs. Richard On 01/05/2011 12:38 AM, Juergen Donnerstag wrote: Cool. May I ask which tools (IDE) you've been using and what your experience with these tools has been. -Juergen On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jan 4, 2011 at 5:15 PM, richard emberson richard.ember...@gmail.com wrote: Dev Wicketers, What: I have ported Wicket to Scala A couple of months ago I took a 1.5 snapshot and ported to Scala. This encompasses all of the source and test code. As successive 1.5 snapshots were released, I ported those differences to my Scala version. I am current with 1.5 M3. The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not counting all the println statements I put into the Scala code for debugging). I used cloc (http://cloc.sourceforge.net/) to count lines of code. I haven't used CLOC before. I've used Ohcount ( http://www.ohloh.net/p/ohcount) and like it. I'll have to give this a try. I have also replaced all of the Java collection classes with Scala collection classes (though a small number of Java collection classes remain that did not have comparable Scala implementations). I have changed many method return types from the Java returning some object or null to Scala returning Some(object) or None (using the Scala Option[return-type] construct) - trying to eliminate nulls. Lastly, I pushed the IModel[T] typing down to the Component class making get/set DefaultModel and get/set DefaultModelObject strong typed. This included using Scala companion object apply methods which eliminated having to explicitly declare type parameters in most end-user code (I had read that one of the objections to pushing strong typing down to the Component class in Wicket was that there were too many notes, end-user code was too verbose). It can not interoperate with Java Wicket because Scala compiles to JVM class files and so all of the classes in Java Wicket also appear in Scala-Wicket. I have an internal name for my Scala port of Wicket which acknowledges its Wicket heritage as well as advertises its enterprise level capabilities. For external communications, I am currently simply call it Scala-Wicket. Why: Scala is a better Java I was introduced to Scala 9 months ago and quickly determined that it was a better Java (at least IMO). For Scala to succeed it requires more programmers to use it. Many on the Scala mailing lists were from a functional background and seemed not to recognize that Haskell and Lisp are not blindingly successful but, rather, niche languages and that the heavy selling of Scala's function and typing capabilities might turn off Java programmers. Scala struck me in many ways as a strong-typed JavaScript, at least, much of the code did not have to have type declarations because the compiler could infer types in many cases. In addition, a whole lot of the Java boil-plate code was not needed. As such, it could be sold as simply a better Java; a more-to-the-point object oriented language
Re: Scala-Wicket Help and Advice
I've got to try it! On Jan 5, 2011 6:10 PM, Gerolf Seitz gerolf.se...@gmail.com wrote: Is this in IntelliJ IDEA? yes On Wed, Jan 5, 2011 at 6:04 PM, Gerolf Seitz gerolf.se...@gmail.com wrote: It's cmd+shift+G (OSX) and it works quite well ;) On Wed, Jan 5, 2011 at 11:55 PM, Justin Lee evancho...@gmail.com wrote: You can paste a java class into a .scala file and it'll autoconvert. there's a shortcut keystroke, too, but i don't remember what it is. On Wed, Jan 5, 2011 at 10:40 AM, richard emberson richard.ember...@gmail.com wrote: No IDE, I use Vim. Also, my build environment is Ant-based using scalac and javac. Of course, what I was doing was porting from Java to Scala. To that end I've got some 400 Vim scripts that aid in the port. For instance, :g/final \([a-zA-Z]\+\) \([a-zA-Z]\+\)\[\]\s*=/s//val \2: Array[\1] =/g converts final B a[] = to val a: Array[B] = I don't know if IDEs provide such scripting with regex support. Also, with a simple Vim script and key combination, I can be viewing a ported Scala file and jump to its corresponding source Java Wicket file - very useful when porting or debugging. Yea, IDEs can do stuff me and my Vim scripts can not do, but my fingers know Vim. I also built a JUnit driver class in Scala (and Java) that allowed me to execute a single test method in a given test class by setting two properties in a file that my Ant script reads. This was vital for hunting down bugs. I looked into the tool that allowed Vim to be the front-end and Eclipse to run in server mode which allows a Vim user to access many of the extra features the IDE offers, but, as of a couple of months ago, there was no Scala support in the tool. The father of Scala, Martin Odersky uses Emacs. Richard On 01/05/2011 12:38 AM, Juergen Donnerstag wrote: Cool. May I ask which tools (IDE) you've been using and what your experience with these tools has been. -Juergen On Wed, Jan 5, 2011 at 2:34 AM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jan 4, 2011 at 5:15 PM, richard emberson richard.ember...@gmail.com wrote: Dev Wicketers, What: I have ported Wicket to Scala A couple of months ago I took a 1.5 snapshot and ported to Scala. This encompasses all of the source and test code. As successive 1.5 snapshots were released, I ported those differences to my Scala version. I am current with 1.5 M3. The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not counting all the println statements I put into the Scala code for debugging). I used cloc (http://cloc.sourceforge.net/) to count lines of code. I haven't used CLOC before. I've used Ohcount ( http://www.ohloh.net/p/ohcount) and like it. I'll have to give this a try. I have also replaced all of the Java collection classes with Scala collection classes (though a small number of Java collection classes remain that did not have comparable Scala implementations). I have changed many method return types from the Java returning some object or null to Scala returning Some(object) or None (using the Scala Option[return-type] construct) - trying to eliminate nulls. Lastly, I pushed the IModel[T] typing down to the Component class making get/set DefaultModel and get/set DefaultModelObject strong typed. This included using Scala companion object apply methods which eliminated having to explicitly declare type parameters in most end-user code (I had read that one of the objections to pushing strong typing down to the Component class in Wicket was that there were too many notes, end-user code was too verbose). It can not interoperate with Java Wicket because Scala compiles to JVM class files and so all of the classes in Java Wicket also appear in Scala-Wicket. I have an internal name for my Scala port of Wicket which acknowledges its Wicket heritage as well as advertises its enterprise level capabilities. For external communications, I am currently simply call it Scala-Wicket. Why: Scala is a better Java I was introduced to Scala 9 months ago and quickly determined that it was a better Java (at least IMO). For Scala to succeed it requires more programmers to use it. Many on the Scala mailing lists were from a functional background and seemed not to recognize that Haskell and Lisp are not blindingly successful but, rather, niche languages and that the heavy selling of Scala's function and typing capabilities might turn off Java programmers. Scala struck me in many ways as a strong-typed JavaScript, at least, much of the code did not have to have type declarations because the compiler could infer types in many cases. In addition, a whole lot of the Java boil-plate code was not needed.
Re: Scala-Wicket Help and Advice
I haven't had time to read all of this (hard to get through it all on my phone), but I don't think that mere port of Wicket to Scala is what is needed. I'd rather see a project built for Scala from the ground up based on some of the concepts from Wicket. Wicket wasn't designed with a functional programming language in mind and I think there are a lot of places where the functional style could simplify things quite a bit. I am very interested in seeing what you have put together. Are you planning on putting the code up on Github or something? On Tue, Jan 4, 2011 at 6:15 PM, richard emberson richard.ember...@gmail.com wrote: Dev Wicketers, What: I have ported Wicket to Scala A couple of months ago I took a 1.5 snapshot and ported to Scala. This encompasses all of the source and test code. As successive 1.5 snapshots were released, I ported those differences to my Scala version. I am current with 1.5 M3. The Java 137,791 loc in 1.5 M3 are now 100,077 loc Scala (not counting all the println statements I put into the Scala code for debugging). I used cloc (http://cloc.sourceforge.net/) to count lines of code. I have also replaced all of the Java collection classes with Scala collection classes (though a small number of Java collection classes remain that did not have comparable Scala implementations). I have changed many method return types from the Java returning some object or null to Scala returning Some(object) or None (using the Scala Option[return-type] construct) - trying to eliminate nulls. Lastly, I pushed the IModel[T] typing down to the Component class making get/set DefaultModel and get/set DefaultModelObject strong typed. This included using Scala companion object apply methods which eliminated having to explicitly declare type parameters in most end-user code (I had read that one of the objections to pushing strong typing down to the Component class in Wicket was that there were too many notes, end-user code was too verbose). It can not interoperate with Java Wicket because Scala compiles to JVM class files and so all of the classes in Java Wicket also appear in Scala-Wicket. I have an internal name for my Scala port of Wicket which acknowledges its Wicket heritage as well as advertises its enterprise level capabilities. For external communications, I am currently simply call it Scala-Wicket. Why: Scala is a better Java I was introduced to Scala 9 months ago and quickly determined that it was a better Java (at least IMO). For Scala to succeed it requires more programmers to use it. Many on the Scala mailing lists were from a functional background and seemed not to recognize that Haskell and Lisp are not blindingly successful but, rather, niche languages and that the heavy selling of Scala's function and typing capabilities might turn off Java programmers. Scala struck me in many ways as a strong-typed JavaScript, at least, much of the code did not have to have type declarations because the compiler could infer types in many cases. In addition, a whole lot of the Java boil-plate code was not needed. As such, it could be sold as simply a better Java; a more-to-the-point object oriented language with functional programming in-the-small. To get more Java programmers to try Scala I looked for a significant Java application with a strong support and user community that I could port to Scala. I ended up with Wicket. Wicket is an enterprise level web framework (unlike existing Scale web frameworks which place restrictions on enterprise IT organizations, e.g., by requiring sticky sessions). It is well documented. And, as it turned out, very, very importantly it had a large number of unit tests (the unit tests saved my butt, without them I would never had succeeded in getting a port that worked). No, Really, Why: I like Scala and I took the time to learn it. Right now about 20% of programmers use Java while only some 0.4% use Scala. I did not want my effort of learning Scala to be wasted so my solution is to increase the number of Scala programmers. Where to get them? Again, my solution is from the existing horde of Java programmers. Plans: Release, Evolve and Proselytize I would like to release Scala-Wicket. I do not know if Apache hosts anything other than Java code. Growing a community is important. Still Todo: Comments: All of the existing class and inline comments are still Java related. This would have to be a long, on-going task to edit the comments so they reflect the code's Scala usage. Package path: The code still uses the org.apache.wicket package path and this must be changed - unless this became an Apache project.
Re: Wicket Stuff Commit Access
Please add me too. My username is jwcarman. Thanks. On Tue, Jan 4, 2011 at 8:32 AM, Martin Grigorov mgrigo...@apache.org wrote: On Tue, Jan 4, 2011 at 2:29 PM, Sebastian nospam...@gmx.net wrote: Please add me too. username: sebthom Added Thanks! Seb On 01.01.2011 15:47, Michael O'Cleirigh wrote: Hi Péter, I've added you into the Committers team and you can push and pull from wicketstuff/core and wicketstuff/sandbox. Regards, Mike Hi, My github username is: aldaris p.s.: Happy new year! ;) Thanks, Peter
Re: wicketst...@github: re-organize now or later?
+1 On Dec 29, 2010 12:49 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i think core and sandbox are probably better names and more clearly communicate the intent. -igor On Wed, Dec 29, 2010 at 9:30 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Currently our wicketstuff repo at github is one gigantic repo containing everything. I'd like to propose to split the repository into two: - github.com/wicketstuff/wicketstuff (containing just the core project) - github.com/wicketstuff/archive (containing all the side projects) The idea is that wicketstuff core is already a huge project, and I'd like to make the footprint contain just that, without the legacy projects that surround the core. I'd like to do this before folks start cloning away, so before we announce the availability. But if anyone wants to wait that's fine with me as well... Anyone got ideas or a different opinion? Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: WICKET-3261
-1, sounds very confusing to me. I was just looking for something last night in the source. It was something that I assumed would be in the core of the framework, but I had to look in wicket-util for it. I don't like that. If it's required to run Wicket, then it should be part of the core. On Tue, Dec 21, 2010 at 11:53 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, With https://issues.apache.org/jira/browse/WICKET-3261 I added a new Maven module to 1.5: wicket-core. Its purpose is to create a .jar that contains the classes from wicket.jar, wicket-util.jar and wicket-request.jar (aka uberjar, jarjar, ...). We split wicket/ to three modules : wicket/, wicket-util and wicket-request to make it more modular and easier to maintain, but now (non-Maven) users complain about class loading problems because they didn't add -util and -request in their classpath. The purpose of the new module is to hide the fact that we split the code internally and tell all users to use the new uberjar. We can even not publish the smaller ones in the Maven repos. The open question is: should we rename current wicket module to wicket-core and the new module to become 'wicket' ? Pros: - all user apps will continue to have dependency to org.apache.wicket:wicket Cons: - merging code from 1.4 to 1.5 can become a bit harder If we agree on that renaming of the modules then I need a date when other devs don't commit anything to do it. martin-g
Re: WICKET-3261
I'm objecting to continuing down the path of what has happened in trunk. :) On Wed, Dec 22, 2010 at 8:41 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Unfortunately, the part you are objecting to is not a part of this ticket. It was done a long time ago on trunk. This ticket is only about making dependency management easier on the non-maven folks. If you'd rather see all three (now sort of four) modules re-combined, I think it'd be better to start a separate discussion. Jeremy Thomerson http://wickettraining.com -- sent from my smart phone, so please excuse spelling, formatting, or compiler errors On Dec 22, 2010 7:34 AM, James Carman ja...@carmanconsulting.com wrote: -1, sounds very confusing to me. I was just looking for something last night in the source. It was something that I assumed would be in the core of the framework, but I had to look in wicket-util for it. I don't like that. If it's required to run Wicket, then it should be part of the core. On Tue, Dec 21, 2010 at 11:53 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, With http...
Re: Future hosting of wicket stuff
+1 for Apache Extras. On Tue, Dec 14, 2010 at 11:29 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Things change and while we had a nice stay at sf.net, I think it is time to move on with Wicket Stuff to newer ground. We have had this discussion before and the discussion stalled mostly because Apache and Google were in talks about a new service called Apache Extras [1]. Fortunately those talks are now over and we can continue our future of Wicket Stuff hosting discussion. In my opinion there are two possible hosting solutions for Wicket Stuff: - the newly announced Apache Extras - github's organization feature For Wicket Stuff we have a couple of things that worked fairly badly in the past. SVN connectivity from our build system connecting to SF.net was spotty at best, and didn't work most of the time. This has improved considerably by using Hudson instead of Teamcity (though not all builds that were done on teamcity have been migrated to hudson) I declare the JIRA instance of wicket stuff officially dead and gone to meet its maker. While we could opt for another JIRA enterprise license, I find maintaining the service a chore, and having to upgrade every now and then a waste of time better used to build cool stuff. While the issue trackers of Apache Extras (i.e. google code) and github are barebones, they have enough features to work with—we're not building missile guidance software requiring CMM level 5, SAS-71 etc certification. A similar issue arises with confluence. While I appreciate confluence being the best wiki available, again maintaining and upgrading it is no picnic, and both Apache Extras and github provide fine implementations of wikis. So I'd like to propose the following options: - stay at sf.net but use the sf.net hosted issue tracker and wikis - move everything over to an Apache Extras Wicket Stuff project - move everything over to a Github Wicket Stuff organization Staying at sf.net - scm options: SVN, Git, Mercurial, Bazaar, or CVS - no social options - No Apache Extras brand name - account management a drag - no limitation on allowed open source licenses - web UI a complete travesty Moving to Apache Extras - scm options: HG and SVN - no social options - Apache Extras brand name - account management a drag - limitation on allowed open source licenses Moving to Github - scm options: git - many social options (easy forking/merging/pull requests, etc) - No Apache Extras exposure - account management possibly easier (less need to actually add accounts to projects for sure) - no limitation on allowed open source licenses For this exercise I assumed the wiki and issue trackers of both github and Apache Extras are equally barebones. What do you think? If I've missed something add to this thread. If you prefer one solution over the other speak up! Martijn [1] https://blogs.apache.org/foundation/entry/the_apache_software_foundation_launches
Re: Question on LoadableDetachableModel
What do you do with docModel in that constructor?
On Fri, Dec 3, 2010 at 4:15 PM, Don donle...@yahoo.com wrote:
Hi,
I would suspect that having a class like below I wouldnt really need to use a
LoadableDetachableModel model because I dont store it in some field of the
class (or any of the components used by it) so if the page gets stored into
session, that wouldnt bloat the session.
Am I right in my thinking here, please?
public class ResultPage extends WebPage {
// note no model stored as private fields of some type
// DocumentModel model;
public ResultPage(DocumentModel docModel) {
// ...
}
}
Tks
Re: overriding isVisible bad?
On Thu, Dec 2, 2010 at 9:36 PM, Clint Checketts checke...@gmail.com wrote: While I appreciate having onConfigure as an option it seems like overriding isVisible is still the cleaner and clearer way. Folks just need to follow the rule that expensive calls should be contained in an LDM. The expense isn't the problem. It's the dynamic nature of the value returned that causes issues, IIUC.
Re: overriding isVisible bad?
I am glad we have something new that's better, but going from do this to this is evil is the troubling part. A lot of us have a lot of code that is based on the previous advice. Now declaring that code is evil is kind of scary, especially in the middle of a major version. If something is evil, then we should probably try to avoid it, so what do we do, go clean up all of our existing code (and re-test it)? On Mon, Nov 29, 2010 at 3:52 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: how so? we added something new that we think will work better. -igor On Mon, Nov 29, 2010 at 12:45 PM, James Carman ja...@carmanconsulting.com wrote: On Mon, Nov 29, 2010 at 1:13 PM, Eelco Hillenius eelco.hillen...@gmail.com wrote: Niether is evil. It has potential pitfalls, which you should just be aware of. We use such overrides all over the place and never have problems with them either. :-) Avoiding it is safer, but also more verbose (in 1.3.x at least). Well, in the past, the canned answer was override isEnabled/isVisible. Changing that paradigm and doing a complete 180 is troubling.
Re: Maven
No, it's not necessary, but it makes it a heck of a lot easier. If you really don't want to use Maven in the long run, it might help you get started and figure out which jars you absolutely need on your classpath. Start a maven-based project and once you get stuff working, you can do mvn dependency:list to see what jars were/are used. On Fri, Nov 26, 2010 at 3:08 AM, aaashu amitsuryawansh...@gmail.com wrote: is it necessary to use maven with wicket for web development...pls replyed me. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Maven-tp3059867p3059867.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: [announce] Pedro Santos added to Wicket PMC / Committer
Congratulations, Pedro!
On Mon, Nov 22, 2010 at 10:08 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
I'd just like to pass this on to everyone on the list. Pedro Santos
has been added as a committer and PMC member for Apache Wicket. Pedro
has been increasingly active in the Wicket community in recent months,
and his patches continue to improve in quality. Additionally, Pedro
is always willing to do the grunt work of creating great test cases
for his patches, or for JIRA issues that others have attached patches
to. Test cases are invaluable to the development of Wicket because
they help us not introduce regressions as we fix bugs and add
features.
Thanks Pedro, and we look forward to working with you!
PS - the message below is Pedro's first commit to Wicket - already
improving test cases!
--
Jeremy Thomerson
http://wickettraining.com
Need a CMS for Wicket? Use Brix! http://brixcms.org
-- Forwarded message --
From: pe...@apache.org
Date: Mon, Nov 22, 2010 at 5:45 PM
Subject: svn commit: r1037925 - in
/wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree:
MoveChildToParentNodeMarkedForRecreationTest.java
MoveChildToParentNodeMarkedForRecreationTestPage.java
To: comm...@wicket.apache.org
Author: pedro
Date: Mon Nov 22 22:45:41 2010
New Revision: 1037925
URL: http://svn.apache.org/viewvc?rev=1037925view=rev
Log:
adding an assert line in the test to turn it more meaningful
Modified:
wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTest.java
wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTestPage.java
Modified:
wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTest.java
URL:
http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTest.java?rev=1037925r1=1037924r2=1037925view=diff
==
---
wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTest.java
(original)
+++
wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTest.java
Mon Nov 22 22:45:41 2010
@@ -38,7 +38,9 @@ public class MoveChildToParentNodeMarked
public void test()
{
WicketTester tester = new WicketTester();
-
tester.startPage(MoveChildToParentNodeMarkedForRecreationTestPage.class);
+ MoveChildToParentNodeMarkedForRecreationTestPage
testPage = new MoveChildToParentNodeMarkedForRecreationTestPage();
+ tester.startPage(testPage);
tester.clickLink(moveC3ToC2);
+ assertTrue(testPage.c2.isNodeChild(testPage.c3));
}
}
Modified:
wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTestPage.java
URL:
http://svn.apache.org/viewvc/wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTestPage.java?rev=1037925r1=1037924r2=1037925view=diff
==
---
wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTestPage.java
(original)
+++
wicket/branches/wicket-1.4.x/wicket-extensions/src/test/java/org/apache/wicket/extensions/markup/html/tree/MoveChildToParentNodeMarkedForRecreationTestPage.java
Mon Nov 22 22:45:41 2010
@@ -28,8 +28,8 @@ public class MoveChildToParentNodeMarked
private static final long serialVersionUID = 1L;
private final Tree treeTable;
- private DefaultMutableTreeNode c2;
- private DefaultMutableTreeNode c3;
+ DefaultMutableTreeNode c2;
+ DefaultMutableTreeNode c3;
public MoveChildToParentNodeMarkedForRecreationTestPage()
{
Re: JRebel and wicket
Yeah that's not gonna work with the way people typically use wicket
On Nov 19, 2010 9:02 AM, ekabanov jevg...@zeroturnaround.com wrote:
We are looking into solving this for anon classes in the next version. Our
typical suggestion for workaround is to use named method classes, like this:
// Constructor
public MyComponent {
class FirstNameLabel extends Label {
//...
}
add(new FirstNameLabel());
}
This way the generated classes are named, but still scoped inside the
method.
JK
On 19.11.2010, at 13:26, Peter Ertl-3 [via Apache Wicket] wrote:
The most annoying thing is when you suddenly decide to anonymously
subclass a component - then you have to restart.
I do that all the time so this is a showstopper for me...
Am 19.11.2010 um 12:17 schrieb Leszek Gawron:
On 2010-11-18 14:25, Martijn Dashorst wrote:
Relaxing the add() method has been proposed before (by Eelco). It is
not something new, and if it helps people using jrebel to improve
their productivity, that would be a great side effect.
The workaround is indeed to go back to a different page and do the
appropriate clicks again.
It is several times faster to do that instead of booting the whole
container and doing exacly that again.
JRebel really shines when it comes to building a page from scratch.
When I didn't have it I tried to come up with the most complete page/panel
design i could think of at the moment. Now I start with completely empty
panel and add child components one by one refreshing the browser as I go.
Adding form components or DataTable columns feels like you are coding
in scripting language (in the good sense).
The most annoying thing is when you suddenly decide to anonymously
subclass a component - then you have to restart.
From my experience there is only a little margin of strange errors.
Either the code runs as expected or it throws with huge JRebel exception
telling you to reboot the container.
--
Leszek Gawron http://lgawron.blogspot.com
View message @
http://apache-wicket.1842946.n4.nabble.com/JRebel-and-wicket-tp3048578p3050207.html
To unsubscribe from JRebel and wicket, click here.
Jevgeni Kabanov: Founder CTO at ZeroTurnaround
jevg...@zeroturnaround.com | Skype: ekabanov | http://twitter.com/ekabanov
Woohoo! I won a #javaRebel license at #javaBin today! - Ole Chr. Rynning
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/JRebel-and-wicket-tp3048578p3050364.html
Sent from the Forum for Wicket Core developers mailing list archive at
Nabble.com.
Re: JRebel and wicket
I've used jrebel pretty successfully with wicket. There are a lot more
compatible changes you can make than non-compatible ones.
On Nov 18, 2010 7:53 AM, Martijn Dashorst martijn.dasho...@gmail.com
wrote:
I've been trying out jrebel and wicket a couple of times, and I
thought it didn't work. It does, but the way Wicket development works
is undoing most of the benefits of using jrebel.
The idea of jrebel is to replace hotswap with something that actually
works for normal development: adding methods, renaming them, creating
new (anonymous inner) classes etc, without having to restart your
application. And that works quite well...
Until you start developing with Wicket.
The problem is that our component hierarchy doesn't work well with
code replacement. A typical workflow is that you navigate in your
application to a page, and want to add a new component to it. So you
go into that class:
public class LinkCounter extends WebPage {
public LinkCounter() {
}
}
add a field:
private int counter;
add a label:
public LinkCounter() {
add(new Label(counter, new PropertyModelInteger(this, counter)));
}
span wicket:id=counter/span
add a link:
public LinkCounter() {
...
add(new LinkVoid(click) {
public void onClick() {
counter++;
});
}
}
a href=# wicket:id=clickClick me/a
All is well, and when you refresh the page (as long as you had a
bookmarkable link to it) it shows the new label and link. You click
the link and the URL changes from a bookmarkable URL to a link to a
specific instance.
Now you want to add another link:
add(new LinkVoid(minus) {
public void onClick() {
counter--;
}
});
Don't forget to modify the markup:
span wicket:id=minus/span
JRebel does its thing: adding the code to the constructor including
the anonymous inner class. You refresh your page and are presented
with a component not found exception: minus is added in the markup,
but not in the java code
The problem is that jrebel doesn't invoke the constructor (again) when
replacing the code. Moving the code to onInitialize() might enable the
jrebel plugin to call that method when it modifies a component class.
This won't work because you typically then get:
java.lang.IllegalArgumentException: A child with id 'counter'
already exists:
Now we could ask folks to use addOrReplace() instead of add(), or we
could relax the multi add restriction to alleviate this problem.
I wouldn't be against relaxing add() and deprecating addOrReplace().
Now calling onInitialize again on a constructed component might open
up another can of worms.
Is this something worth pursuing? Or should we just write an article
with how to do jrebel no-redeploy wicket coding?
Martijn
Re: JRebel and wicket
Email them. They have a wicket plugin and they're very responsive
On Nov 18, 2010 7:53 AM, Martijn Dashorst martijn.dasho...@gmail.com
wrote:
I've been trying out jrebel and wicket a couple of times, and I
thought it didn't work. It does, but the way Wicket development works
is undoing most of the benefits of using jrebel.
The idea of jrebel is to replace hotswap with something that actually
works for normal development: adding methods, renaming them, creating
new (anonymous inner) classes etc, without having to restart your
application. And that works quite well...
Until you start developing with Wicket.
The problem is that our component hierarchy doesn't work well with
code replacement. A typical workflow is that you navigate in your
application to a page, and want to add a new component to it. So you
go into that class:
public class LinkCounter extends WebPage {
public LinkCounter() {
}
}
add a field:
private int counter;
add a label:
public LinkCounter() {
add(new Label(counter, new PropertyModelInteger(this, counter)));
}
span wicket:id=counter/span
add a link:
public LinkCounter() {
...
add(new LinkVoid(click) {
public void onClick() {
counter++;
});
}
}
a href=# wicket:id=clickClick me/a
All is well, and when you refresh the page (as long as you had a
bookmarkable link to it) it shows the new label and link. You click
the link and the URL changes from a bookmarkable URL to a link to a
specific instance.
Now you want to add another link:
add(new LinkVoid(minus) {
public void onClick() {
counter--;
}
});
Don't forget to modify the markup:
span wicket:id=minus/span
JRebel does its thing: adding the code to the constructor including
the anonymous inner class. You refresh your page and are presented
with a component not found exception: minus is added in the markup,
but not in the java code
The problem is that jrebel doesn't invoke the constructor (again) when
replacing the code. Moving the code to onInitialize() might enable the
jrebel plugin to call that method when it modifies a component class.
This won't work because you typically then get:
java.lang.IllegalArgumentException: A child with id 'counter'
already exists:
Now we could ask folks to use addOrReplace() instead of add(), or we
could relax the multi add restriction to alleviate this problem.
I wouldn't be against relaxing add() and deprecating addOrReplace().
Now calling onInitialize again on a constructed component might open
up another can of worms.
Is this something worth pursuing? Or should we just write an article
with how to do jrebel no-redeploy wicket coding?
Martijn
Re: JRebel and wicket
Has anyone looked at how Tapestry solved this problem? I know they
did some work to make sure reloading happened in a smart way.
On Thu, Nov 18, 2010 at 10:44 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote:
invoking a constructor on a constructed class can lead to a lot more
weirder state problems. dont forget, constructors dont just add class,
they initialize state. invoking the constructor itself is not enough,
you also need to invoke field initializations that are inlined, etc.
at that point you might as well create a new instance of the page -
since that is what you are essentially doing.
-igor
On Thu, Nov 18, 2010 at 4:52 AM, Martijn Dashorst
martijn.dasho...@gmail.com wrote:
I've been trying out jrebel and wicket a couple of times, and I
thought it didn't work. It does, but the way Wicket development works
is undoing most of the benefits of using jrebel.
The idea of jrebel is to replace hotswap with something that actually
works for normal development: adding methods, renaming them, creating
new (anonymous inner) classes etc, without having to restart your
application. And that works quite well...
Until you start developing with Wicket.
The problem is that our component hierarchy doesn't work well with
code replacement. A typical workflow is that you navigate in your
application to a page, and want to add a new component to it. So you
go into that class:
public class LinkCounter extends WebPage {
public LinkCounter() {
}
}
add a field:
private int counter;
add a label:
public LinkCounter() {
add(new Label(counter, new PropertyModelInteger(this, counter)));
}
span wicket:id=counter/span
add a link:
public LinkCounter() {
...
add(new LinkVoid(click) {
public void onClick() {
counter++;
});
}
}
a href=# wicket:id=clickClick me/a
All is well, and when you refresh the page (as long as you had a
bookmarkable link to it) it shows the new label and link. You click
the link and the URL changes from a bookmarkable URL to a link to a
specific instance.
Now you want to add another link:
add(new LinkVoid(minus) {
public void onClick() {
counter--;
}
});
Don't forget to modify the markup:
span wicket:id=minus/span
JRebel does its thing: adding the code to the constructor including
the anonymous inner class. You refresh your page and are presented
with a component not found exception: minus is added in the markup,
but not in the java code
The problem is that jrebel doesn't invoke the constructor (again) when
replacing the code. Moving the code to onInitialize() might enable the
jrebel plugin to call that method when it modifies a component class.
This won't work because you typically then get:
java.lang.IllegalArgumentException: A child with id 'counter'
already exists:
Now we could ask folks to use addOrReplace() instead of add(), or we
could relax the multi add restriction to alleviate this problem.
I wouldn't be against relaxing add() and deprecating addOrReplace().
Now calling onInitialize again on a constructed component might open
up another can of worms.
Is this something worth pursuing? Or should we just write an article
with how to do jrebel no-redeploy wicket coding?
Martijn
Re: Maven license header plugin
+1 to the maven plugin. And, yes IDEA does it too. On Tue, Nov 16, 2010 at 8:15 AM, Martin Grigorov mgrigo...@apache.org wrote: On Tue, Nov 16, 2010 at 2:04 PM, James Carman ja...@carmanconsulting.comwrote: On Tue, Nov 16, 2010 at 3:08 AM, Martin Grigorov mgrigo...@apache.org wrote: Eclipse adds the licence for me when I create new files. We don't all use Eclipse. :-) I'm sure Intellij IDEA/Netbeans/... can do that too. Come on, even my vim can do it :-) As I said - I'm +1 for using the Maven plugin if it does the same as the unit test does. I'd suggest to keep the unit test as disabled for a week or two until the Maven plugin proves itself.
Re: TimeOfDay problem with DTS
Where are you that DST changed last night? Ours (EDT timezone) doesn't change until next Sunday at 2:00 AM. At least that's what the time settings dialog in Windows 7 says. On Sun, Oct 31, 2010 at 9:02 AM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Locally org.apache.wicket.util.time.TimeOfDayTest.test() fails today due to Daylight Time Savings change last night. Is this a bug in TimeOfDay that we care about ? Setting the default time zone to one without DTS (e.g. 'GMT') makes the test pass. martin-g
Re: TimeOfDay problem with DTS
On Sun, Oct 31, 2010 at 9:54 AM, Martin Grigorov mgrigo...@apache.org wrote: Where are you that DST changed last night? Ours (EDT timezone) doesn't change until next Sunday at 2:00 AM. At least that's what the time settings dialog in Windows 7 says. Europe. Figures. I don't know why everyone doesn't just do this stuff the same way. Better yet, don't do it at all. :) Darn that Benjamin Franklin!
Re: How to get the resource path of files
This is a user question. Please send your question to the user list. On Tue, Sep 28, 2010 at 6:52 AM, elesi jsar...@gmail.com wrote: could anyone explain how wicket searches the context path for resources? i mean is it different from the local drive path that i use for non-web applications? because im having a hard time tracing the url of wicket pages, and trying to guess where my resources are... thanks in advance ciao, -elesi -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-to-get-the-resource-path-of-files-tp2716961p2716961.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Stream Resource into Javascript
This isn't a Wicket question. On Tue, Sep 28, 2010 at 2:54 AM, elesi jsar...@gmail.com wrote: drobson drob...@... writes: The files are being stored on the server but i've found a way of doing what I need and it seems pretty nice. By creating a new xml file, named audio.xml, in the tomcat dir conf\catalina\localhost and defining my music folder as a docbase, i can access the folder through the http address http://localhost:8080/audio/[what ever my music file is]. This also means the music folder is available to all your Web Apps hosted by tomcat. hi, where can i find the tomcat directory? there are no 'catalina' folder here in my tomcat installation directory...
Re: Stream Resource into Javascript
Why not ask this question on the user list? That's where you're supposed to ask this type of question. On Tue, Sep 28, 2010 at 9:58 AM, elesi jsar...@gmail.com wrote: im sorry for that, but let me ask if there's another way of getting the mp3 resource... besides creating an xml file like drobson did? thanks -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Stream-Resource-into-Javascript-tp2262751p2717229.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Making Wicket Fully Compatible with Google App Engine
Jira supports tags right? On Sep 20, 2010 8:55 AM, Clint Checketts checke...@gmail.com wrote: Sure I could take whichever approach the core team prefers. A bonus of having a master issue is once it gets resolved that the release notes will specifically mark that it is compatible with GAE. On Mon, Sep 20, 2010 at 7:52 AM, Peter Ertl pe...@gmx.org wrote: Why not prefix all issue titles with something like [GAE] problem description ? This should be easy to filter or lookup Am 20.09.2010 um 14:43 schrieb Clint Checketts: There is a 'Will it play in app engine' page that tracks libraries that are compatible with Google App Engine (aka GAE): http://groups.google.com/group/google-appengine-java/web/will-it-play-in-app-engine?pli=1 Correctly, Wicket is listed as Semi-Compatible. As a project I've been looking through the Wicket codebase locating the pieces that need to change to make it fully compatible. Does it make sense to have a master Jira that tracks the overall 'compatible with GAE' state while making individual issues for the specific changes that reference back to the master issue? Thanks, -Clint Checketts
Re: Simple page navigation - newbie
On Mon, Sep 13, 2010 at 4:32 PM, norm.pence norm.pe...@gmail.com wrote: I have been working with Wicket for only a few days so please bare with me. First of all, this is a user question, it should be sent to the user list, not the developer list.
Test
This is a test to see if we can still post to the dev mailing list via nabble. Did this get through? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Test-tp2538143p2538143.html Sent from the Wicket Dev (Old) mailing list archive at Nabble.com.
Re: Test
Heh! Yeah, I got it on my machine, too. Martijn thought he had this turned off. I wanted to see if I could successfully post. Looks like we've got to figure out how to turn this off. On Mon, Sep 13, 2010 at 6:23 PM, Philip Chapman pchap...@pcsw.us wrote: Nope. I never saw it. Sorry. On Mon, Sep 13, 2010 at 3:14 PM, James Carman ja...@carmanconsulting.com wrote: This is a test to see if we can still post to the dev mailing list via nabble. Did this get through? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Test-tp2538143p2538143.html Sent from the Wicket Dev (Old) mailing list archive at Nabble.com. -- Philip A. Chapman Java Software Development Enterprise, Web, and Desktop
Re: Test
Well, the intent was not to mess with him per se. It's just a nice side effect. Sorry, Martijn. :) We were talking via IM earlier and he said he thought he had it turned off. He asked me if I had the new topic link and I did, so I thought I'd test it out. On Mon, Sep 13, 2010 at 6:27 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: i was hoping you were doing this just to mess with martijn... -igor On Mon, Sep 13, 2010 at 3:25 PM, James Carman ja...@carmanconsulting.com wrote: Heh! Yeah, I got it on my machine, too. Martijn thought he had this turned off. I wanted to see if I could successfully post. Looks like we've got to figure out how to turn this off. On Mon, Sep 13, 2010 at 6:23 PM, Philip Chapman pchap...@pcsw.us wrote: Nope. I never saw it. Sorry. On Mon, Sep 13, 2010 at 3:14 PM, James Carman ja...@carmanconsulting.com wrote: This is a test to see if we can still post to the dev mailing list via nabble. Did this get through? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Test-tp2538143p2538143.html Sent from the Wicket Dev (Old) mailing list archive at Nabble.com. -- Philip A. Chapman Java Software Development Enterprise, Web, and Desktop
Re: Wicket Spring integration issue
Why the snapshots? On Thu, Sep 9, 2010 at 9:52 AM, chitrabhanu.das chitrabhanu@gmail.com wrote: thanks for your prompt reply now i have removed 1.3 versions and have set the following jars in classpath: wicket-ioc-1.4-SNAPSHOT.jar wicket-spring-1.4-SNAPSHOT.jar wicket-spring-annot-1.4-20080409.121345-1.jar Still i am getting the same errors -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Wicket-Spring-integration-issue-tp2532788p2532904.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Wicket Hibernate Integration
A better question is why are you so averse to a service layer in between? On Wed, Sep 8, 2010 at 9:09 AM, chitrabhanu.das chitrabhanu@gmail.com wrote: How do we integrate Wicket and Hibernate without any service layer in between Is it even possible??? I have tried to but in vein Whenever i try to call HibernateUtil to configure it fails saying... Sep 8, 2010 6:34:03 PM org.apache.wicket.RequestListenerInterface registerRequestListenerInterface INFO: registered listener interface [RequestListenerInterface name=INewBrowserWindowListener, method=public abstract void org.apache.wicket.markup.html.INewBrowserWindowListener.onNewBrowserWindow()] Sep 8, 2010 6:34:03 PM org.hibernate.cfg.Environment clinit INFO: Hibernate 3.5.5-Final Sep 8, 2010 6:34:03 PM org.hibernate.cfg.Environment clinit INFO: hibernate.properties not found Sep 8, 2010 6:34:03 PM org.hibernate.cfg.Environment buildBytecodeProvider INFO: Bytecode provider name : javassist Sep 8, 2010 6:34:03 PM org.hibernate.cfg.Environment clinit INFO: using JDK 1.4 java.sql.Timestamp handling Sep 8, 2010 6:34:03 PM org.hibernate.cfg.Configuration addResource INFO: Reading mappings from resource: hibernate.cfg.xml org.hibernate.InvalidMappingException: Could not parse mapping document from resource hibernate.cfg.xml at org.hibernate.cfg.Configuration.addResource(Configuration.java:641) at nic.fts.dao.persistence.HibernateUtil.getSessionFactory(HibernateUtil.java:13) at nic.fts.LoginForm.authenticate(LoginForm.java:75) at nic.fts.LoginForm.onSubmit(LoginForm.java:55) at org.apache.wicket.markup.html.form.Form.delegateSubmit(Form.java:1545) at org.apache.wicket.markup.html.form.Form.process(Form.java:938) at org.apache.wicket.markup.html.form.Form.onFormSubmitted(Form.java:900) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.wicket.RequestListenerInterface.invoke(RequestListenerInterface.java:182) at org.apache.wicket.request.target.component.listener.ListenerInterfaceRequestTarget.processEvents(ListenerInterfaceRequestTarget.java:73) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1250) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1329) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1428) at org.apache.wicket.RequestCycle.request(RequestCycle.java:545) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:479) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:312) at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:405) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:295) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:503) at org.mortbay.jetty.HttpConnection$RequestHandler.content(HttpConnection.java:841) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:639) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:210) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:379) at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:226) at org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:442)Invalid User Name or Pass Word Caused by: org.hibernate.InvalidMappingException: Could not parse mapping document from input stream at org.hibernate.cfg.Configuration.addInputStream(Configuration.java:610) at org.hibernate.cfg.Configuration.addResource(Configuration.java:638) ... 34 more Caused by: org.dom4j.DocumentException: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory Nested exception: org.dom4j.DocumentFactory cannot be cast to org.dom4j.DocumentFactory at org.dom4j.io.SAXReader.read(SAXReader.java:484) at org.hibernate.cfg.Configuration.addInputStream(Configuration.java:601) ... 35 more Any help will be highly
Re: testRenderClientSideImageMapPage fails (1.5)
The test case compares the output to a static file on disk that was generated in a non-de environment. I would imagine that's why it's failing. ClientSideImageMap is a new class, so it's not changing existing functionality. It merely attaches itself to an existing Image component (via an attribute modifier if I recall correctly), so the Image should work just like it always does (with a usemap attribute added of course). On Aug 28, 2010 2:50 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: not sure i follow. if the locale changes on the next request the url will change as well no? -igor On Sat, Aug 28, 2010 at 11:43 AM, Juergen Donnerstag juergen.donners...@gmail.com wrote: I know, but is that change by purpose? What if the locale changes before the next request. With the current implementation the German image is retrieved, ignoring a possible locale change. -Juergen
Re: Remove support for Portlets in Wicket 1.5
I'd say at least move it to wicketstuff, so that if there's some other person out there with the will and means to take the project on, they can do so. On Wed, Aug 11, 2010 at 2:35 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, I just created a ticket (https://issues.apache.org/jira/browse/WICKET-2976) to remove the support for Portlets in Wicket 1.5. It is currently broken because of the re-work of WicketFilter and request processing. Since none of the active core developers use this technology in his daily job it is hard for us to support it. Now is the time to vote against this decision and give us a hand to improve it or just silently agree. martin-g P.S. I sent this email earlier today but for some reason it was rejected. Excuse me if you receive it for second time.
Re: [proposal] Replace TeamCity on wicketstuff.org with Hudson for building wicketstuff projects
This will give you a rough idea of what you need for Hudson. It does need some disk space: http://wiki.hudson-ci.org/display/HUDSON/Administering+Hudson On Wed, Jul 21, 2010 at 8:51 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Security needs to be enabled and other stuff. Deploying as a war does have some drawbacks: restarting using the UI won't work, installing/updating plugins/new versions of hudson is enabled by default. Martijn On Wed, Jul 21, 2010 at 2:46 PM, Johan Compagner jcompag...@gmail.com wrote: hudson is just a war right? so that can be dumped by anybody of the wicket devs to onto the tomcat webapp dir. What more does hudson need? On Wed, Jul 21, 2010 at 11:14, Martijn Dashorst martijn.dasho...@gmail.com wrote: My little bird told me that no build server is part of the new deal which is slated to be announced mid-august, so IMO we should not delay the migration off of teamcity and setup hudson. I'll contact the sysadmin for the box to see if I can grant direct access, or that only trusted folks are allowed. Martijn On Wed, Jul 21, 2010 at 9:43 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: There are some developments unfolding in the near future that might help out on the future of our wicketstuff server and/or its infrastructure. I don't have the full details to those plans yet, and don't know if they entail a build server of some sorts. I'm perfectly happy with switching to hudson—we use it at work and it has been a godsend compared to the other available solutions (though I still don't like the UI). I hope we can wait a (couple of) week(s) and see the future plans unfold to see what the details are, especially with respect to a build server. I'll ask around to see if it is part of that deal. Martijn On Wed, Jul 21, 2010 at 4:06 AM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, I've been using Hudson reliably to build wicketstuff core snapshot's and deploying them into the sonatype maven repository. I put together an older machine for this purpose (P4 1.8Ghz) and while it worked at first recently there have been memory issues (at least one of the DDR1 DIMM's is bad and the JVM keeps crashing). I have the builds running temporarily somewhere else but the long term solution is to run Hudson on a box that can be opened up to the other wicketstuff developers. My proposal is to replace TeamCity on wicketstuff.org with Hudson and then do the necessary setup to allow wicketstuff developers access to it for initiating builds and viewing the projects status. I am willing to do all of the necessary setup and configuration to make this happen; basically copying over what I have working right now plus adding in user authentication. The easiest way would be if I could get a user account on the wicketstuff.org server (at least initially) and then get everything setup. There are still some questions around if the wicketstuff.org box is still banned by sourceforge but I think the best way to find out the answer is to try and see what happens. Regards, Mike -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Re: [proposal] Replace TeamCity on wicketstuff.org with Hudson for building wicketstuff projects
Here are the instructions for setting it up on linux/unix: http://wiki.hudson-ci.org/display/HUDSON/Installing+Hudson#InstallingHudson-Unix%2FLinuxInstallation You *can* just do: java -jar hudson.war and it'll run. That's just a quick way to get it up and running to play around with it. On Wed, Jul 21, 2010 at 9:11 AM, Johan Compagner jcompag...@gmail.com wrote: how do you deploy then? has hudson its container (tomcat)?? Then we also need another port. And have all kind of apache config to support things like: wicketstuff.org/hudson hmm that i dont like. It should just run on the tomcat instance we have. On Wed, Jul 21, 2010 at 14:51, Martijn Dashorst martijn.dasho...@gmail.com wrote: Security needs to be enabled and other stuff. Deploying as a war does have some drawbacks: restarting using the UI won't work, installing/updating plugins/new versions of hudson is enabled by default. Martijn On Wed, Jul 21, 2010 at 2:46 PM, Johan Compagner jcompag...@gmail.com wrote: hudson is just a war right? so that can be dumped by anybody of the wicket devs to onto the tomcat webapp dir. What more does hudson need? On Wed, Jul 21, 2010 at 11:14, Martijn Dashorst martijn.dasho...@gmail.com wrote: My little bird told me that no build server is part of the new deal which is slated to be announced mid-august, so IMO we should not delay the migration off of teamcity and setup hudson. I'll contact the sysadmin for the box to see if I can grant direct access, or that only trusted folks are allowed. Martijn On Wed, Jul 21, 2010 at 9:43 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: There are some developments unfolding in the near future that might help out on the future of our wicketstuff server and/or its infrastructure. I don't have the full details to those plans yet, and don't know if they entail a build server of some sorts. I'm perfectly happy with switching to hudson—we use it at work and it has been a godsend compared to the other available solutions (though I still don't like the UI). I hope we can wait a (couple of) week(s) and see the future plans unfold to see what the details are, especially with respect to a build server. I'll ask around to see if it is part of that deal. Martijn On Wed, Jul 21, 2010 at 4:06 AM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, I've been using Hudson reliably to build wicketstuff core snapshot's and deploying them into the sonatype maven repository. I put together an older machine for this purpose (P4 1.8Ghz) and while it worked at first recently there have been memory issues (at least one of the DDR1 DIMM's is bad and the JVM keeps crashing). I have the builds running temporarily somewhere else but the long term solution is to run Hudson on a box that can be opened up to the other wicketstuff developers. My proposal is to replace TeamCity on wicketstuff.org with Hudson and then do the necessary setup to allow wicketstuff developers access to it for initiating builds and viewing the projects status. I am willing to do all of the necessary setup and configuration to make this happen; basically copying over what I have working right now plus adding in user authentication. The easiest way would be if I could get a user account on the wicketstuff.org server (at least initially) and then get everything setup. There are still some questions around if the wicketstuff.org box is still banned by sourceforge but I think the best way to find out the answer is to try and see what happens. Regards, Mike -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8 -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Re: PagingNavigation - click pagination
The DefaultDataTable has a navigation component at the top that allows you to go to a page. You could borrow from that (or use DefaultDataTable). On Wed, Jul 14, 2010 at 8:47 AM, Alis ajcalve...@yahoo.es wrote: Hello! I doing a DataTable, and i need implement in .java go to a page. DataTable.goPage? i don´t have idea Help me! -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/PagingNavigation-click-pagination-tp2288683p2288683.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: I' new in Wicket how Can I start?
Try going to http://mywebserverurl/mycontext/wicket On Sat, Jul 3, 2010 at 1:16 PM, ujtordai ujtordaikov...@gmail.com wrote: Hello everybody, I'm new in Wicket. I use NetBeans 6.9 and Glassfish. I made a simple J2EE project. The project deployed successfully. My project is a skeleton of EE app it means actually not contain any entity, session, and only contains in the web part the pre generated classes, for example Application.java, BasePage.java HeaderPanel.html, headerPanel.java, HomePage.html, HomePage.java, style.css. My project does not work, emit the an error: HTTP Status 404 - type Status report message descriptionThe requested resource () is not available. GlassFish Server Open Source Edition 3.0.1 What need to do for work the base example? Thanks. My web xml is: ?xml version=1.0 encoding=UTF-8? web-app version=3.0 xmlns=http://java.sun.com/xml/ns/javaee; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd; filter filter-nameWicketApplication/filter-name filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class init-param param-nameapplicationClassName/param-name param-valuecom.myapp.wicket.Application/param-value /init-param /filter filter-mapping filter-nameWicketApplication/filter-name url-pattern/wicket/*/url-pattern /filter-mapping session-config session-timeout 30 /session-timeout /session-config welcome-file-list welcome-file/ /welcome-file-list /web-app -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/I-new-in-Wicket-how-Can-I-start-tp2277335p2277335.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: How make to what a row the a datatable has two event: onClick y onSelect
On Thu, Jul 1, 2010 at 3:57 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: But how does your user select the row? Clicking a checkbox or what? Do you need an ajax event for each? The user has to underline the row with a marker to select it. But, if they scroll, won't the marker just stay where it is on the monitor and then the selection will change? Perhaps we should require that they wipe off the marker first, then scroll, then re-underline. That should do the trick. Better yet, the user should use a permanent marker on their monitor. They should write This row is selected - and all they have to do is scroll their screen so that the row they want to select is pointed to by the marker. That way, it can be re-used on any web page with no code changes!
Re: [proposal] Use apache nexus repository for org.apache.wicket release and snapshot artifacts.
We use Artifactory at work, too! :) But, Nexus wasn't around when I installed it. Artifactory works okay, I guess, but it does have its bugs of course. On Wed, Jun 30, 2010 at 8:07 AM, nino martinez wael nino.martinez.w...@gmail.com wrote: No problem, we use nexus our self's where I work.. It's just that Artifactory was WICKET powered :) 2010/6/24 James Carman ja...@carmanconsulting.com And, a LOT of the maven-based projects are going that route. Nexus even makes it easier to do releases The Apache Way. On Thu, Jun 24, 2010 at 10:03 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Because Nexus is hosted and supported by Apache. Jeremy Thomerson -- sent from my smartphone - please excuse formatting and spelling errors On Jun 24, 2010 10:01 AM, nino martinez wael nino.martinez.w...@gmail.com wrote: I know this is sort of off topic, but why don't we use artifactory, it's opensource and based on wicket.. 1=http://www.jfrog.org/products.php 2010/6/23 Michael O'Cleirigh michael.ocleir...@rivulet.ca Thanks Martijn and Jeremy for all your work on getting this to work. I have the 1.4.10-SNAPSH...
Re: How make to what a row the a datatable has two event: onClick y onSelect
How do you click vs. select? On Wed, Jun 30, 2010 at 3:04 PM, Alis ajcalve...@yahoo.es wrote: Hello! How are you? I´m implement a DataTable, and the rows is link, i need make click the row and implement a process and when select row do other process. Help me, please and very thank. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-make-to-what-a-row-the-a-datatable-has-two-event-onClick-y-onSelect-tp2272766p2272766.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Another back button issue - question on answer given in another thread
So, whatever happened with this issue? I'm just curious. On Thu, Jun 24, 2010 at 3:19 PM, Boneless1213 boneless1...@gmail.com wrote: I tried replying using email and it didn't seem to work, hope this doesn't double post, sorry if it does. I'm not near my app right now, but I do recall that when I start up my wicketapplciation that it throws an error saying it cannot serialize PhotoContainer(A small class I use to hold 4 URLs each for the different sizes of the same photo, I do use objects of this type to build both pages). I don't see this error after the initialization though. So it doesn't happen every time I click a link, or ever when I click a link. I can try making that class serializable and get back to you, unless it would only cause a problem if it happens on every link click. But yes I will definitely get back to you on that, see if that is the problem.(probably is causing problems) Thank you very much, I learned awhile ago that I should not fix other bugs until I've fixed exceptions, I don't know why I ignored that this time. Thank you again. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Another-back-button-issue-question-on-answer-given-in-another-thread-tp2266535p2267522.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Another back button issue - question on answer given in another thread
What do you mean by rebuilds? Wicket is designed so that links (non-bookmarkable ones at least) will always point back at the page from whence they came, so that their state remains consistent. So, if you mean that the link seems to be dealing with the same page instance that it came from, then that's how it's supposed to work. On Thu, Jun 24, 2010 at 2:34 AM, Boneless1213 boneless1...@gmail.com wrote: Hello, I fixed a previous problem I had with a back button that I described as unlike the other back button issues. This time it is more like the other back button issues, and I wonder about this post made by another person in this thread http://apache-wicket.1842946.n4.nabble.com/wicket-back-button-problem-td1912501.html#a1912501 http://apache-wicket.1842946.n4.nabble.com/wicket-back-button-problem-td1912501.html#a1912501 I'm experiencing the problem where you hit the back button click on a link and it's like it hit the link on the other page instead of the one you are on. When I click a link it seems to rebuild the page instead of any undoing, There is obviously something I don't understand about the undo functionality. When it rebuilds it obviously has all the same data as I had before and rebuilds based on that data. I don't expect it to undo all of my fields on my class I realize that is ridiculous, how I understood the comment in that thread is that it replaces your components with older versions while I see through debugging that it rebuilds the view. Otherwise I suppose I would store the data on the component class(Such as add a field to my link and have it link there). I'll be happy to hear any advice on the issue I'm having even if it has nothing to do with the post I referenced. Thank you very much. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Another-back-button-issue-question-on-answer-given-in-another-thread-tp2266535p2266535.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [proposal] Use apache nexus repository for org.apache.wicket release and snapshot artifacts.
And, a LOT of the maven-based projects are going that route. Nexus even makes it easier to do releases The Apache Way. On Thu, Jun 24, 2010 at 10:03 AM, Jeremy Thomerson jer...@wickettraining.com wrote: Because Nexus is hosted and supported by Apache. Jeremy Thomerson -- sent from my smartphone - please excuse formatting and spelling errors On Jun 24, 2010 10:01 AM, nino martinez wael nino.martinez.w...@gmail.com wrote: I know this is sort of off topic, but why don't we use artifactory, it's opensource and based on wicket.. 1=http://www.jfrog.org/products.php 2010/6/23 Michael O'Cleirigh michael.ocleir...@rivulet.ca Thanks Martijn and Jeremy for all your work on getting this to work. I have the 1.4.10-SNAPSH...
Re: Another back button issue - question on answer given in another thread
Do you see any error messages in your console. Perhaps Wicket can't serialize your page(s)? On Thu, Jun 24, 2010 at 1:00 PM, Boneless1213 boneless1...@gmail.com wrote: Here is what I mean by rebuilds. For this instance I have a browse page and a viewDetails page, you click links on the browse page and it changes the contents on the browse page.(I've tried stateless and regular link). So lets say I hit the next link twice and then I hit the back button on my browser. So i hit next twice goes browse.0 - browse.1 then browse.1-browse.2 then I hit back so then I'm once again on browse.1 now I place 2 debug breakpoints one in browse constructor and one in viewdetails constructor. I click a viewdetails link and the first thing it does is hit the browse constructor again rebuilding in other words re-constructing from the constructor keeping all data that was there when I left browse.2 and it rebuilds the browse page the way browse.2 was built because it has all the same data. So then the viewdetails link displays details for one of the vehicles that was on browse.2. So as for dealing with a same instance, it is not, it is creating a new instance when I click a link on browse.1. I would rather that it clicks a link on the previous instance of browse.1 that i had(Is this what you were explaining as the way wicket should work?). Or anything else that would give the effect of clicking the back button and having the links displayed actually point to the details of that vehicle. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Another-back-button-issue-question-on-answer-given-in-another-thread-tp2266535p2267305.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Please remove me from wicket dev list
Just send an email to dev-unsubscr...@wicket.apache.org On Thu, Jun 24, 2010 at 3:22 PM, Heather Trumbower htrumbo...@navigenics.com wrote: Please remove me from dev@wicket.apache.org. Thank you. Heather Trumbower htrumbo...@navigenics.com
Re: [proposal] Use apache nexus repository for org.apache.wicket release and snapshot artifacts.
I believe that repository is for software published by the ASF, but I could be wrong. On Tue, Jun 15, 2010 at 7:56 PM, Michael O'Cleirigh michael.ocleir...@rivulet.ca wrote: Hello, The wicketstuff.org site seems to have gone down over the weekend. The main item for me is that the maven repository is also missing which is breaking the wicketstuff-core trunk build (we depend on 1.4-SNAPSHOT). Apache has a sonatype nexus instance that is available for projects to use. As far as I can tell this is not being used by Apache Wicket right now. I propose that the current wicketstuff.org maven repository unavailable issue be resolved by migrating the Apache Wicket artifact deployment process from using the wicketstuff repository to the Apache Nexus maven repository. This page has the registration details: http://www.apache.org/dev/repository-faq.html It says to create a sub issue on this one: https://issues.apache.org/jira/browse/INFRA-1896 The creation of the issue has to be done by a project committer. If this migration is deemed acceptable I would be able to assist since its similar to what we did for wicketstuff-core to be deployed into the oss.sonatype.org repository. Here is a summary of how we deploy wicketstuff-core into a nexus repository: We use hudson to build and deploy the artifacts into the oss nexus repository: 1. create profile that defines the repository url for snapshots 2. create server section in settings.xml with the username/password to use when deploying e.g. in wicketstuff core we use this profile: profile idoss.sonatype.org-snapshots/id distributionManagement snapshotRepository idsonatype-nexus-snapshots/id nameSonatype Nexus Snapshots/name urlhttp://oss.sonatype.org/content/repositories/snapshots/url uniqueVersionfalse/uniqueVersion /snapshotRepository /distributionManagement /profile and then we specify a custom settings.xml file to the hudson job that defines a server like this: ?xml version=1.0? settings servers !-- todo replace this with the hudson-wicketstuff user -- server idsonatype-nexus-snapshots/id usernameusername/username passwordsomepassword/password /server /servers /settings Then we activate the profile in the goals and options section like this: -P oss.sonatype.org-snapshots -fae deploy Regards, Mike
Re: [proposal] Use apache nexus repository for org.apache.wicket release and snapshot artifacts.
Sorry, I saw the wicketstuff in the original email. Long day, man. On Tue, Jun 15, 2010 at 8:42 PM, Jeremy Thomerson jer...@wickettraining.com wrote: On Tue, Jun 15, 2010 at 6:58 PM, James Carman ja...@carmanconsulting.comwrote: I believe that repository is for software published by the ASF, but I could be wrong. He wants us to deploy Wicket to it, so I think that fits the bill. :) I'm +1 for this. I'll do the committer part with the help of Michael. Let's see if anyone has an objection. Michael, could you open a JIRA for this and attach a patch for our pom? If nobody has an objection, I'll work on it later in the week. -- Jeremy Thomerson http://www.wickettraining.com
Re: [vote] Revert WICKET-2846
Yeah, I saw that. I don't know if they manually clean the ITL's or not, but they're definitely getting cleaned up. Perhaps trying it with Jetty (unless someone knows that they also clean up after themselves) might show that these references leak? On Wed, May 26, 2010 at 1:18 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: The newest tomcat has improved permgen cleanup which they backported from tomcat 7 iiuc. Martijn On Wed, May 26, 2010 at 3:10 AM, James Carman ja...@carmanconsulting.com wrote: I've done some playing with Tomcat undeploy and it does appear that the ITL reference is cleared (perhaps Sun/Oracle/Sunacle should close the bug?). However, this does not make the ITL implementation valid, IMHO. It doesn't work (out of the box) for the preferred method of executing asynchronous tasks, which is to use a thread pool. On Tue, May 25, 2010 at 6:38 PM, Alex Objelean alex.objel...@gmail.com wrote: Jeremy, I've tried with redeploy... same story. I'm not insisting on bringing the issue back. If is the willing of the majority, I'm ok. It is just to help me understand something that I'm not find that obvious. Alex -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230845.html Sent from the Wicket - Dev mailing list archive at Nabble.com. -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.4 increases type safety for web applications Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.4.8
Re: [vote] Revert WICKET-2846
It has been shown many times why this change was a bad idea. Nevermind the theoretical nature of the initial objections, which have also been shown to be true concerns (see http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6489540). It has been shown that this change doesn't really solve anything anyway. In fact, it encourages a programming practice (starting short-lived, one-off threads) that most feel is not a good idea and doesn't scale. On Mon, May 24, 2010 at 4:40 PM, Alex Objelean alex.objel...@gmail.com wrote: My vote is -1. Unless we have a good way to prove the problem, not only theoretical presumption, we shouldn't revert it in next release. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2229151.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [vote] Revert WICKET-2846
You don't create the thread yourself. Java does! On Tue, May 25, 2010 at 9:32 AM, Alex Objelean alex.objel...@gmail.com wrote: Hi Adriano again! I know you have no time for creating the quickstart. That is why I am trying to reproduce it. I want to make a quickstart to prove if the problem reported by you is true or false and will publish it when it is ready. I need some help from you. Could you give a simple example of how you create the thread in your application which handles the java2d and any other code you may find useful. Thanks! Alex -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230013.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [vote] Revert WICKET-2846
Just try using something like JFreeChart On Tue, May 25, 2010 at 9:36 AM, Alex Objelean alex.objel...@gmail.com wrote: OK, then just give me whatever code you use which causes the memory leak... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230020.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [vote] Revert WICKET-2846
Or draw something yourself if you want to skip the dependency On Tue, May 25, 2010 at 9:38 AM, James Carman ja...@carmanconsulting.com wrote: Just try using something like JFreeChart On Tue, May 25, 2010 at 9:36 AM, Alex Objelean alex.objel...@gmail.com wrote: OK, then just give me whatever code you use which causes the memory leak... -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230020.html Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [vote] Revert WICKET-2846
Here's an example page that you can plug into a quickstart to show the bug:
public class HomePage extends WebPage
{
private static final long serialVersionUID = 1L;
static
{
System.out.println(I'm being initialized within the context
of thread + Thread.currentThread().getName() + .);
}
public HomePage()
{
add(new Image(image, new MyImageResource()));
}
private class MyImageResource extends DynamicImageResource
{
private MyImageResource()
{
super(png);
}
@Override
protected byte[] getImageData()
{
final BufferedImage bufferedImage = new BufferedImage(100,
100, BufferedImage.TYPE_4BYTE_ABGR);
Graphics2D g2d = (Graphics2D) bufferedImage.getGraphics();
g2d.setPaint(Color.white);
g2d.fillRect(0, 0, 100, 100);
g2d.setPaint(Color.red);
g2d.drawOval(45, 45, 10, 10);
final ByteArrayOutputStream bout = new ByteArrayOutputStream();
try
{
ImageIO.write(bufferedImage, png, bout);
bout.close();
}
catch (IOException e)
{
throw new WicketRuntimeException(Unable to render image., e);
}
return bout.toByteArray();
}
}
}
On Tue, May 25, 2010 at 10:08 AM, Alex Objelean alex.objel...@gmail.com wrote:
Thanks!
It is enough for me. I'll do the rest from here..
Alex
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230086.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: [vote] Revert WICKET-2846
I ran this page and then fired up jvisualvm and took a heap dump.
Go to the Classes view. Find the java.lang.Thread class. Click on
it and it will bring up a list of instances. Go through them until
you find one with the name Java2D Disposer (#13 for me). Then, look
for the field called inheritableThreadLocals and look in its table
field. In there, you'll find a reference to the WicketApplication
object. There's your leak! The Java2D Disposer thread runs for the
duration of the VM and won't let go of that sucker.
On Tue, May 25, 2010 at 10:15 AM, James Carman
ja...@carmanconsulting.com wrote:
Here's an example page that you can plug into a quickstart to show the bug:
public class HomePage extends WebPage
{
private static final long serialVersionUID = 1L;
static
{
System.out.println(I'm being initialized within the context
of thread + Thread.currentThread().getName() + .);
}
public HomePage()
{
add(new Image(image, new MyImageResource()));
}
private class MyImageResource extends DynamicImageResource
{
private MyImageResource()
{
super(png);
}
�...@override
protected byte[] getImageData()
{
final BufferedImage bufferedImage = new BufferedImage(100,
100, BufferedImage.TYPE_4BYTE_ABGR);
Graphics2D g2d = (Graphics2D) bufferedImage.getGraphics();
g2d.setPaint(Color.white);
g2d.fillRect(0, 0, 100, 100);
g2d.setPaint(Color.red);
g2d.drawOval(45, 45, 10, 10);
final ByteArrayOutputStream bout = new ByteArrayOutputStream();
try
{
ImageIO.write(bufferedImage, png, bout);
bout.close();
}
catch (IOException e)
{
throw new WicketRuntimeException(Unable to render image., e);
}
return bout.toByteArray();
}
}
}
On Tue, May 25, 2010 at 10:08 AM, Alex Objelean alex.objel...@gmail.com
wrote:
Thanks!
It is enough for me. I'll do the rest from here..
Alex
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/vote-Revert-WICKET-2846-tp2226987p2230086.html
Sent from the Wicket - Dev mailing list archive at Nabble.com.
