You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jean-Baptiste Quenot <jb...@apache.org> on 2007/01/30 22:38:12 UTC
About WicketFilter refactoring
First, congratulations for the great work that you did on
refactoring URL generation in Wicket. Seems to work great.
However launching the examples is now far slower than before,
because you parse web.xml for every WebApplication.
Therefore I suggest to compute the filter path in a static block,
as web.xml is not supposed to change during the lifetime of the
app, nor between initialization of the various WicketFilters.
WDYT?
--
Jean-Baptiste Quenot
aka John Banana Qwerty
http://caraldi.com/jbq/
Re: About WicketFilter refactoring
Posted by Johan Compagner <jc...@gmail.com>.
just use string.indexOf() ;)
johan
On 2/3/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> we already have a pull parser in wicket, why arent we using that?
>
> -igor
>
>
> On 2/3/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > Therefore I suggest to compute the filter path in a static block,
> > > as web.xml is not supposed to change during the lifetime of the
> > > app, nor between initialization of the various WicketFilters.
> >
> > Usually, using static backfires in some way or the other.
> >
> > I think wicket-example's startup time is still reasonable, though a
> > lot slower for sure. An optimization could be to use SAX parsing
> > rather then DOM. With a static block, I would be afraid to introduce
> > classloader problems for some setups (even if it is against the spec
> > etc); this way of parsing the web.xml pretty much guarantees that will
> > never happen.
> >
> > My 2c,
> >
> > Eelco
> >
>
Re: About WicketFilter refactoring
Posted by Igor Vaynberg <ig...@gmail.com>.
html is a superset of xml
-igor
On 2/3/07, Al Maw <wi...@almaw.com> wrote:
>
> Igor Vaynberg wrote:
> > we already have a pull parser in wicket, why arent we using that?
>
> Hmmm. Do we? It seemed like it was written for HTML. The code is
> probably trivial - feel free to improve it, or point me in the right
> direction to.
>
> Al
>
Re: About WicketFilter refactoring
Posted by Al Maw <wi...@almaw.com>.
Igor Vaynberg wrote:
> we already have a pull parser in wicket, why arent we using that?
Hmmm. Do we? It seemed like it was written for HTML. The code is
probably trivial - feel free to improve it, or point me in the right
direction to.
Al
Re: About WicketFilter refactoring
Posted by Igor Vaynberg <ig...@gmail.com>.
we already have a pull parser in wicket, why arent we using that?
-igor
On 2/3/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > Therefore I suggest to compute the filter path in a static block,
> > as web.xml is not supposed to change during the lifetime of the
> > app, nor between initialization of the various WicketFilters.
>
> Usually, using static backfires in some way or the other.
>
> I think wicket-example's startup time is still reasonable, though a
> lot slower for sure. An optimization could be to use SAX parsing
> rather then DOM. With a static block, I would be afraid to introduce
> classloader problems for some setups (even if it is against the spec
> etc); this way of parsing the web.xml pretty much guarantees that will
> never happen.
>
> My 2c,
>
> Eelco
>
Re: About WicketFilter refactoring
Posted by Eelco Hillenius <ee...@gmail.com>.
> Therefore I suggest to compute the filter path in a static block,
> as web.xml is not supposed to change during the lifetime of the
> app, nor between initialization of the various WicketFilters.
Usually, using static backfires in some way or the other.
I think wicket-example's startup time is still reasonable, though a
lot slower for sure. An optimization could be to use SAX parsing
rather then DOM. With a static block, I would be afraid to introduce
classloader problems for some setups (even if it is against the spec
etc); this way of parsing the web.xml pretty much guarantees that will
never happen.
My 2c,
Eelco