And what is the reason why you want to remove final? What are the use
cases? I understand your words, but just removing final to remove
final, IMO is not a good idea. I don't mind though to relax our
general position on removing final for these two methods if there is
real use case. I still think
On 12/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
so what you fix was nothing.
You still get swamped in exceptions on jetty for OSX and now also others
that do throw
the right socket exception are getting swamped with exceptions.
No, because I log a warning exluding the exception. But fine
so what you fix was nothing.
You still get swamped in exceptions on jetty for OSX and now also others
that do throw
the right socket exception are getting swamped with exceptions.
As i said. sending a status code doesn't make any sense. because the
response is already broken.
johan
On 12/6/06
(These are open votes, right?)
Sure, all votes are welcome. But your vote is non-binding where
committers' votes are binding.
Eelco
[X] Yes
[ ] no
Yes! My first vote here :)
(These are open votes, right?)
Erik.
Eelco Hillenius wrote:
I think using final for the onComponentTag and onComponentTagBody
methods have served their purposes fine during our wild two years of
development, but our core components are now stable
It just didn't work. It didn't work for Jetty on Linux and OSX, but it
did for Jetty on Windows. Jetty throws an EofException, which extends
IOException. And we were getting swamped with exceptions. That piece
of code only caught a number of cases it seems. I see the fix isn't
correct either, so w
yes fine.
On 12/6/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Is that a +1 on my proposal?
Eelco
On 12/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
> just look if there is not a gotcha somehow that we can open
> for the method you want to remove final.
> If you can't think of one then
I am not happy with this change.
We should try to ignore the client abort or connection reset as much as we
can
Now the log will be completely filled with exceptions you don't have
anything.
Sending a http response error/status code is by the way not possible then
because the connection is reset
Is that a +1 on my proposal?
Eelco
On 12/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote:
just look if there is not a gotcha somehow that we can open
for the method you want to remove final.
If you can't think of one then remove it.
Just look at this method for method
johan
On 12/6/06, Eelco
just look if there is not a gotcha somehow that we can open
for the method you want to remove final.
If you can't think of one then remove it.
Just look at this method for method
johan
On 12/6/06, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
I think using final for the onComponentTag and onCompo
in the current versioning we don't store a pointer. We only keep a reference
of that page when we encounter
it and then set it back when we deserialize it (that immediately happens)
So if that page is in the pagemap by itself or not doesn't really matter (it
is in the pagemap through the other pa
if this does happen then we do need to store the page. who knows what that
model is doing, it might be reading/writing properties on that page. dont
think we have much choice. and storing a pointer like we do for versioning
wont work because the page might be evicted from the pagemap. so i guess w
versioning can handle this. because it won't clone the page but you will
keep the reference to the old page for every of course.
and if that page2 gets saved to disk and reloaded back in it will also
instantiate the page1 again ofcourse.
So you will have always that baggage of that extra page.
i
I don't know. There are other frameworks that are great with such
services, and such services don't benefit as much from a stateful
model as web interfaces do. Theoretically, you can use Wicket for
anything that generates markup, but Wicket is not the golden hammer.
Eelco
On 12/6/06, Paolo Di T
write your own IRequestTargetUrlCodingStrategy class.
That can decode a request to a IRequestTarget and encode one to a url (that
shouldn't be to hard)
Then also have you own kind of IRequestTarget that is the service.
johan
On 12/6/06, Paolo Di Tommaso <[EMAIL PROTECTED]> wrote:
Wicket is a
+1
On 12/5/06, Korbinian Bachl <[EMAIL PROTECTED]> wrote:
+1
> -Ursprüngliche Nachricht-
> Von: Johan Compagner [mailto:[EMAIL PROTECTED]
> Gesendet: Dienstag, 5. Dezember 2006 10:30
> An: wicket-dev@incubator.apache.org
> Betreff: Re: [VOTE] [EDITED] Moving the wicket-extension's
> re
I thought so as well. And I've never shared a model across multiple pages.
On 12/6/06, Martijn Dashorst <[EMAIL PROTECTED]> wrote:
From the gotchas page on our wiki:
The other thing to avoid is anonymous or nested instances of IModel.
Usually you share an instance of a model between two page
From the gotchas page on our wiki:
The other thing to avoid is anonymous or nested instances of IModel.
Usually you share an instance of a model between two page instances.
If you create an anonymous or nested instance of IModel, then you
automatically get a 'this' reference to the class that su
I think using final for the onComponentTag and onComponentTagBody
methods have served their purposes fine during our wild two years of
development, but our core components are now stable enough to not have
to be worried about painting ourselves in the corner when we would
open up these methods (ie
Wicket is a wonderful framework for handle web pages request. But I'm
thinking that it would be nice too to publish general "web" service without
any visual component associated.
In other word would be very useful to use Wicket to expose a server side
services in protocol agnostic way.
For examp
20 matches
Mail list logo
