[x] Yes, release
Stefan
Hello,
the first three examples here
http://www.wicketstuff.org/wicket14/repeater/ seem to be broken. At
least when accessing it I get an Internal Error.
Could someone with please have a look at this?
Best,
Korbinian
You can run them pretty easily yourself:
svn co http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.x
http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.xcd
wicket-1.4.x
mvn install
cd wicket-examples
mvn jetty:run
Now, go to http://localhost:8080/wicket-examples
--
Jeremy
cool - one of those guys should notice. i just thought you might need to
see the examples NOW :)
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, May 19, 2010 at 3:03 AM, Korbinian Bachl - whiskyworld
korbinian.ba...@whiskyworld.de wrote:
Hi Jeremy,
I know that I can do :)
I
Just two hours ago one of our developers pulled the trigger and
committed his Wicket 1.4.8 porting work for our flagship application
EduArte to our trunk. This means that as of this moment we finally
are near trunk and can start uncovering and fixing bugs for 1.4.x. We
expect to start work on
Hi!
I see that on the to be released 1.4.9 and worried. Was its consequences
really thought about?
I do think this can introduce memory leaks, when some Java code creates
threads (like Java 2D code when dealing with images) that never dies.
Or what am I missing?
Adriano
I still don't see why using InheritableThreadLocal would introduce memory
leaks when dealing with threads. Do you have a good example to prove it? I
don't see any difference...
--
View this message in context:
On 19/05/2010 09:50, Alex Objelean wrote:
I still don't see why using InheritableThreadLocal would introduce memory
leaks when dealing with threads. Do you have a good example to prove it? I
don't see any difference...
The application instance would go to arbitrary (like ones possible
Why would the application object itself need to be garbage collected?
On Wed, May 19, 2010 at 8:53 AM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 19/05/2010 09:50, Alex Objelean wrote:
I still don't see why using InheritableThreadLocal would introduce memory
leaks when dealing
On 19/05/2010 10:57, James Carman wrote:
Why would the application object itself need to be garbage collected?
To hot-deployment not eat your memory.
Adriano
PS: I'm much more worried in production environments. Restarting the
container because you need to update the application is
Sounds good, so do you expect that you'll find some bugs in core
wicket that the community will benefit from?
btw, just back from geecon where this speaker ,
Eugene Ciurana ( http://2010.geecon.org/speakerdetails/12 ) mentioned
(very discretely) wicket in conjunction with jboss as his
Since you've never needed the Application instance in threads you had
created, why would you need it from now on? The only problem related to
memory leaks may be caused by your custom implementation, not with the fact
of using InheritableThreadLocal.
--
View this message in context:
On 19/05/2010 12:48, Alex Objelean wrote:
Since you've never needed the Application instance in threads you had
created, why would you need it from now on? The only problem related to
memory leaks may be caused by your custom implementation, not with the fact
of using InheritableThreadLocal.
On 19/05/2010 12:50, James Carman wrote:
Use JRebel! Problem solved. :)
I suggest to not change something in a minor release that breaks things
that is working. I also suggest this shouldn't be done by default in
major releases as well.
I see no way JRebel or any tool going to remove
Please, correct me if I'm wrong, but the Application won't become the root of
child threads. Using InheritableThreadLocal will only make Application
available from the threads created during a request cycle. There is
absolutely no memory related problem with it.
Alex
--
View this message in
On 19/05/2010 13:06, Alex Objelean wrote:
Please, correct me if I'm wrong, but the Application won't become the root of
child threads. Using InheritableThreadLocal will only make Application
available from the threads created during a request cycle. There is
absolutely no memory related problem
On Wed, May 19, 2010 at 11:56 AM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
I suggest to not change something in a minor release that breaks things that
is working. I also suggest this shouldn't be done by default in major
releases as well.
I see no way JRebel or any tool going
On 19/05/2010 14:35, James Carman wrote:
On Wed, May 19, 2010 at 11:56 AM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
I suggest to not change something in a minor release that breaks things that
is working. I also suggest this shouldn't be done by default in major
releases as
JRebel is intended to be used in development, not in production. In
production, you want to undeploy and redeploy your application and,
hopefully, leave no old ClassLoader reference behind.
I'm not sure if InheritableThreadLocal will create memory leaks, but I know
it is something to be very
How about we put the request back on you:
Please prove that WICKET-2846 DOES introduce a nasty regression.
This is much easier to prove / disprove than what you request.
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, May 19, 2010 at 12:43 PM, Adriano dos Santos Fernandes
If I understand it correctly, the InheritedThreadLocal (ITL) wil hold the
Application reference only if its corresponding thread stays alive. If the
thread dies, the ITL value is eligible for gc, right?
Well, if your application creates a new thread, that is kept alive even
after the webapp is
On 19/05/2010 14:49, Jeremy Thomerson wrote:
How about we put the request back on you:
Please prove that WICKET-2846 DOES introduce a nasty regression.
This is much easier to prove / disprove than what you request.
Jeremy, as an open source developer, I understand your position and what
Do you have a quickstart application that exhibits this behavior?
On Wed, May 19, 2010 at 2:44 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 19/05/2010 14:49, Jeremy Thomerson wrote:
How about we put the request back on you:
Please prove that WICKET-2846 DOES introduce a
On 19/05/2010 15:48, James Carman wrote:
Do you have a quickstart application that exhibits this behavior?
How would I could do it?
This requires someone willing to change the code (if there is a problem)
to redeploy the application with have previously created a thread.
About the sun
Here's how you create a quickstart:
http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
If you find that there is a bug, you zip your quickstart directory and
attach it to a JIRA issue. Then we fix it and build a new release and start
a new vote (if the bug is serious
- Original message -
On 19/05/2010 13:06, Alex Objelean wrote:
This currently make web-classloader leaks. If you start using
InheritableThreadLocal's with arbitrary objects, you're going to make
even more leaks.
Also note, there is something not good here. AFAIK, Wicket sets the
On 19/05/2010 15:57, Jeremy Thomerson wrote:
Here's how you create a quickstart:
http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
If you find that there is a bug, you zip your quickstart directory and
attach it to a JIRA issue. Then we fix it and build a new release and
On 19/05/2010 16:16, Johan Compagner wrote:
- Original message -
On 19/05/2010 13:06, Alex Objelean wrote:
This currently make web-classloader leaks. If you start using
InheritableThreadLocal's with arbitrary objects, you're going to make
even more leaks.
Also note, there is
What itch are we trying to scratch, here, anyway? When do folks need
access to the Application object outside of a request thread? What is
the usecase?
On Wed, May 19, 2010 at 3:30 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 19/05/2010 16:16, Johan Compagner wrote:
-
On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
I can't, however, do it now. But I would have no reason to do it knowing
some folks just consider a normal thing restart the container to update the
application. So if Wicket devs are in this way, I could
On Wed, May 19, 2010 at 4:30 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
I do not think the application object is general enough to be passed
implicitly to threads.
Now, this is a valid argument!
I agree wholeheartedly that Application.get() shouldn't be accessible to
child
On 19/05/2010 16:37, tetsuo wrote:
On Wed, May 19, 2010 at 4:20 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
I can't, however, do it now. But I would have no reason to do it knowing
some folks just consider a normal thing restart the container to update the
application. So
So, your itch or usecase is that you're trying to use Wicket in a
way it was not intended.
On Wed, May 19, 2010 at 3:48 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 19/05/2010 16:36, James Carman wrote:
What itch are we trying to scratch, here, anyway? When do folks need
On Wed, May 19, 2010 at 2:20 PM, Adriano dos Santos Fernandes
adrian...@gmail.com wrote:
On 19/05/2010 15:57, Jeremy Thomerson wrote:
Here's how you create a quickstart:
http://www.jeremythomerson.com/blog/2008/11/wicket-quickstart-tutorial/
If you find that there is a bug, you zip your
To clarify this, I use Application.set and Application.unset there.
Although public, they're not part of Wicket public API. So IMO, the
initial issue would be better done making these methods part of the public
API.
And then people all over will have memory leak issues because they'll
On 19/05/2010 17:03, Jeremy Thomerson wrote:
To clarify this, I use Application.set and Application.unset there.
Although public, they're not part of Wicket public API. So IMO, the
initial issue would be better done making these methods part of the public
API.
And then people all over
Will the inheritance of the application really work correctly? For pooled
threads that are created at application startup, the threadlocal will be
null, because the parent thread is the thread that starts the container.
For threads that are created within the context of the request thread, they
I wondered about this too: would this work with a job framework like
Quartz? The thread is not started in a wicket context, but by the
thing that quartz is managing. Therefore the inherited thing would not
work and the Application would not be set.
Martijn
On Wed, May 19, 2010 at 11:41 PM, James
why would a request thread start your executor pool? the pool would
most likely be started from a context listener which uses a separate
thread. the usecase for the inheritable is for short-lived threads
started from a request thread.
-igor
On Wed, May 19, 2010 at 2:41 PM, James Carman
thinking about this more, in 1.5 these short-lived threads will not
even be needed. most often you need to start a new thread so you have
a properly configured wicket environment which depends on
threadlocals. this environment is usually configured by wicket tester
which sets up mock session,
If you where using threads in your application
Then i would do it this way:
Your WebApplication class has a method:
getExecutor() that returns a ThreadPoolExecutor
That threadpoolexecutor (that you extend) overrides 2 methods
protected void beforeExecute(Thread t, Runnable r) { }
that sets the
Sure this might work, but then again you wouldn't need the
InheritableThreadLocal for this. The question is, does the
InheritableThreadLocal really solve anything? Is it really addressing
the problem? Or, would you have to do code like this to manage it
properly anyway? And, if so, then why
It solves this problem, which is specifically why it was requested:
onClickOrSomethingSimilar() {
new Thread(new Runnable() {
void run() {
doSomethingWith(Application.get());
}
}).start();
}
--
Jeremy Thomerson
http://www.wickettraining.com
On Wed, May 19,
It solves that one particular usecase, but I doubt folks would be
starting threads like that. Most folks, if they're smart, would use a
thread pool for something like that. For the pooled thread case, it
doesn't work.
On Wed, May 19, 2010 at 9:29 PM, Jeremy Thomerson
jer...@wickettraining.com
Agreed - I use pools for stuff like this. But, it's not broken for pools -
nothing functionally changed, right?
Jeremy Thomerson
http://www.wickettraining.com
-- sent from a wireless device
-Original Message-
From: James Carman ja...@carmanconsulting.com
Sent: Wednesday, May 19, 2010
onClickOrSomethingSimilar() {
final Application app = Application.get();
new Thread(new Runnable() {
void run() {
doSomethingWith(app);
}
}).start();
}
On Wed, May 19, 2010 at 10:29 PM, Jeremy Thomerson
jer...@wickettraining.com wrote:
It solves this problem,
46 matches
Mail list logo
