I just wanted to circle back on this as I have an update. I haven't created
any special mappers for the URLs and they are now working within my
framework with the inmethod grid component. I built an app from the ground
up rather than modifying the quickstart. I am not currently mounting any
pages since I don't expose the pages directly and I feel that was the
issue. I may need to fix this eventually if I start mounting pages and will
post an update if I need to fix anything.

Thanks for the pointers.

cheers,
Steve

On Wed, Oct 8, 2014 at 4:32 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:

> Hi,
>
> On Tue, Oct 7, 2014 at 10:14 PM, Steve Swinsburg <
> steve.swinsb...@gmail.com>
> wrote:
>
> > Hi Martin,
> >
> > The context bits of /portal/tool/UUID are added by the framework that I
> am
> > using. All webapps are addressable in this way since the webapps are all
> > registered with the framework.
> >
> > You then add placements of the webapps onto pages and they get the UUID.
> > This used to work fine in Wicket 1.4 but with the changes in 1.5 and up
> it
> > no longer works, for some components.
> >
> > The servlet context path of this particular webapp is
> > /inmethod-grid-examples, and we need to use the WicketServlet, not the
> > WicketFilter. You can't get to a webapp directly, it all goes through the
> > portal framework as there are filters that inject things like
> authorisation
> > etc.
> >
>
> I'm afraid you are on your own here.
> We don't know how your framework works and what exactly breaks.
> Fire the debugger and let us know when you have more information.
>
>
> >
> > cheers,
> > Steve
> >
> > On Tue, Oct 7, 2014 at 8:06 PM, Martin Grigorov <mgrigo...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > On Mon, Oct 6, 2014 at 6:31 AM, Steve Swinsburg <
> > steve.swinsb...@gmail.com
> > > >
> > > wrote:
> > >
> > > > Hi all,
> > > >
> > > > I've been working on Wicket 1.4 for a while and in upgrading to
> Wicket
> > 6
> > > > I've found an inconsistency in the way URLs are handled, specifically
> > in
> > > > the inmethod data grid but also the editable data grid.
> > > >
> > > > I have a particular context path that I need to maintain as the
> webapp
> > > > rendering is inside a portal type framework.
> > > >
> > > > I have taken the example webapps from both 1.4 and 6 and customised
> > them
> > > so
> > > > they run in the framework.
> > > >
> > > > In Wicket 1.4, the page is mounted like:
> > > >
> > > > mount(new HybridUrlCodingStrategy("/data-grid/editable",
> > > > EditableDataGridPage.class));
> > > >
> > > > and works fine. The URL is:
> > > >
> > > >
> > >
> >
> http://localhost:8080/portal/tool/a79c7348-6c8b-4912-8cc7-3b4419344f7f/data-grid/editable.3
> > > >
> > > > In Wicket 6, the page is mounted as:
> > > >
> > > > mount("/data-grid/editable", EditableDataGridPage.class);
> > > >
> > >
> > > The line above will not compile!
> > >
> > >
> > > > ...
> > > > getRootRequestMapperAsCompound().add(new MountedMapper(mountPath,
> > > > pageClass));
> > > >
> > >
> > > This is equivalent to: mountPage(mountPath, pageClass)
> > >
> > >
> > > >
> > > > and it does not work. It strips my leading context bits
> > > > (/portal/tool/UUID).
> > > >
> > >
> > > How do you set these context bits ?
> > >
> > >
> > > >
> > > > I tried to mount it myself:
> > > > mountPage("/a79c7348-6c8b-4912-8cc7-3b4419344f7f",
> > > > EditableDataGridPage.class);
> > > >
> > > > But that goes into an infinite redirect loop if I mount it to the
> > webapp
> > > I
> > > > want. If I mount it to a non wicket webapp, then that mount works
> fine.
> > > >
> > > > I am not sure how to restore the old URL mapping strategy.
> > > >
> > >
> > > Give us more information about your setup to be able to help you.
> > > Especially what is the value of ServletContext#getContextPath() and
> what
> > is
> > > the value of WicketFilter#getFilterPath().
> > > These two "bits" are used as prefixes for the mount paths you use for
> > your
> > > pages.
> > >
> > >
> > > >
> > > > Can anyone help?
> > > >
> > > > thanks,
> > > > Steve
> > > >
> > >
> >
>

Reply via email to