Found it. wasn't wicket related at all. The apache conf was wrong.
ProxyPass /
http://localhost:8080/blog/
I used / instead of /blog/ as in the forward. So on every call a
/blog/ was added and the link could not be found.
On 3/3/07, Leon Pennings <[EMAIL PROTECTED]> wrote:
> Hi all, first pos
> i think this is generally an antipattern. its never a good idea to put
> jars
> like wicket,spring into server's shared lib dirs because anything
static
> then becomes shared across all webapps. it can have some strange
> sideffects.
>
> for example take wicket's springbean injection stuff. it k
> > For regular posts, there is a way out of this: stateless pages with
> > stateless forms. For Ajax calls there isn't currently. I'm still
> > advocating that, but we're not sure how that would work best yet.
> > Concrete ideas are welcome. Johan, maybe you could state your
> > objections or diff
For regular posts, there is a way out of this: stateless pages with
stateless forms. For Ajax calls there isn't currently. I'm still
advocating that, but we're not sure how that would work best yet.
Concrete ideas are welcome. Johan, maybe you could state your
objections or difficulties with that
But if it is null then you could have a problem that things should be
versioned but arent..
So adding null checks is not the fix.
johan
On 3/2/07, Aaron HIniker <[EMAIL PROTECTED]> wrote:
That's why I was pointing at mayTrackChangesFor().. I looked at the
method and I can't see a loophole,
> i think this is generally an antipattern. its never a good idea to put jars
> like wicket,spring into server's shared lib dirs because anything static
> then becomes shared across all webapps. it can have some strange sideffects.
>
> for example take wicket's springbean injection stuff. it keeps
> I worked around this by extending the WicketFilter with the override:
>
> protected ClassLoader getClassLoader() {
> return Thread.currentThread().getContextClassLoader();
> }
>
> so that my new WicketFilter would keep the default context class loader.
> Mow I can
i think this is generally an antipattern. its never a good idea to put jars
like wicket,spring into server's shared lib dirs because anything static
then becomes shared across all webapps. it can have some strange sideffects.
for example take wicket's springbean injection stuff. it keeps the inje
Chris Colman wrote:
> I found the problem: had to put the wicket jars in my web app's 'lib'
> directory and not in 'common/lib'.
>
I noticed this "problem" with jetty.
wicket.protocol.http.WicketFilter sets the context class loader to the
filters class loader
which can't see your web application
Doğru seçimi yapın
Bazen, bir işe girişmeye ve farklı bir şeyler yapmaya karar vermek çok kolay
olmayabilir.
Ortalama küçük ölçekli bir işletme kurma maliyetinin çok pahalı olduğunu ve bu
işletmelerin birçoğunun ilk yıllarında kapanmak zorunda kaldığını biliyor
muydunuz? Herbalite ile kendi işin
On 3/4/07, Jean-Baptiste Quenot <[EMAIL PROTECTED]> wrote:
> So, you're using Wicket 1.2.5?
Yes, Wicket 1.2.5
--
Filippo Diotalevi
http://www.diotalevi.com
http://www.jugmilano.it
-
Take Surveys. Earn Cash. Influence the Fu
So, you're using Wicket 1.2.5?
I came across the same thing, and had to disable a unit test:
See bugTestPageConstructor() in WicketTesterTest
And like you it uses the startPage(Page) method.
What is really strange is that the same code runs smoothly in
Wicket 2. Help from the team would
On 3/2/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > All the components are logged as 'not rendered', but all tests are
> > passed and the application works.
> > Is this the normal behaviour of tests?
>
> That doesn't look normal to me. Did you get any further insight?
Yes, what I discovered
> I was impressed by the simplicity and modularity of Wicket so I would
> like to change to this.
Cheers. We're not gonna hold you back! :)
Eelco
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's
Eelco Hillenius wrote:
>> but why are these things tied to request threads? doesnt sound like they
>> should be.
>>
>
> If I understand Robert correctly that is due to an architectural
> choice he just has to live with. Also, I'm wondering in what way
> Tapestry is at fault here. I thought it
I think Matt Raible has a PDF online somewhere.
Martijn
On 3/1/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
>
> Does anyone know of a feature grid/matrix comparing web frameworks.
> --
> View this message in context:
> http://www.nabble.com/Feature-Grid-tf3328003.html#a9253121
> Sent from the W
16 matches
Mail list logo
