Re: Fwd: wicket 1.5-rc2 and aggregate jar for osgi
Hi Daniele,
sorry for answering this late, anyways, inline reply.
On [Fri, 22.04.2011 16:09], Daniele Dellafiore wrote:
> Hi, sorry I read your reply only today...
> I got basically to the same results yesterday, but I've some problem which I
> summarized in the last message in this thread on felix mailing list:
>
> http://old.nabble.com/A-better-life%3A-quick-webapp-deploy-to31334158.html
>
> I'll go into details point by point.
>
> On Fri, Apr 8, 2011 at 3:29 PM, Eike Kettner wrote:
>
> > Hi Daniele,
> >
> > I might have not understood your concern well enough... But here is what I
> > do: I deploy a really small war file (without any deps of course) into the
> > osgi container (I use felix...). There is another bundle from pax,
> > called pax-web-extender, that "listens" for war files coming into the
> > container and will then register them on the embedded jetty instance.
> >
> > I use the following pax bundles:
> > * org.ops4j.pax.web.pax-web-extender-war
> > * org.ops4j.pax.web.pax-web-jetty-bundle
> > * org.ops4j.pax.web.pax-web-jsp (might be superfluous)
> >
>
> yeah I've everything installed. I do not remember what osgi features
> installed this but there is:
>
> [ 54] [Active ] [] [ ] [ 60] OPS4J Pax Web -
> Runtime (1.0.1)
> [ 55] [Active ] [] [ ] [ 60] OPS4J Pax Web - API
> (1.0.1)
> [ 56] [Active ] [] [ ] [ 60] OPS4J Pax Web - Jetty
> (1.0.1)
> [ 57] [Active ] [] [ ] [ 60] OPS4J Pax Web -
> Service SPI (1.0.1)
> [ 59] [Active ] [] [ ] [ 60] OPS4J Pax Web -
> Extender - Whiteboard (1.0.1)
> [ 60] [Active ] [] [ ] [ 60] OPS4J Pax Web -
> FileInstall Deployer (1.0.1)
> [ 61] [Active ] [] [ ] [ 60] OPS4J Pax Url - war:,
> war-i: (1.2.5)
> [ 62] [Active ] [] [ ] [ 60] OPS4J Pax Web -
> Extender - WAR (1.0.1)
> [ 63] [Active ] [] [ ] [ 60] OPS4J Pax Web - Jsp
> Support (1.0.1)
>
> on Karaf 2.2.0
>
>
> >
> > Then I use the felix-bundle plugin to create a MANIFEST.MF for my war
> > file. It looks like that:
> >
> >
> >
> >org.apache.felix
> >maven-bundle-plugin
> >
> >
> >bundle-manifest
> >process-classes
> >
> > manifest
> >
> >
> >
> >
> >
> >jar
> >war
> >bundle
> >
> >
> ><_include>-osgi.bnd
> >
> >
> >
> >
> >org.apache.maven.plugins
> >maven-war-plugin
> >
> >
> >
> > ${project.build.outputDirectory}/META-INF/MANIFEST.MF
> >
> >
> >
> >
> >
> >
> >
>
> it's almost the same as mine, also the war-plugin config is identical.
> I do not have
>
><_include>-osgi.bnd
>
> but I have this instructions
>
> <_wab>src/main/webapp
> /myApp
I didn't know about tha <_wab> configuration, This will maybe then add the
web bundle class path to the headers, so it needn't be specified
explicitely.
> There are some more instructions in the "osgi.bnd" file. You could have
> > written them directly in the section of the bundle plugin:
> >
> > Bundle-Classpath: ., WEB-INF/classes
> > Web-ContextPath: mywebapp
> > DynamicImport-Package: *
> > Webapp-Context: mywebapp
> >
>
> It seems that maven-bundle-plugin, at least 2.3.4 version, automatically
> add Bundle-Classpath: WEB-INF/classes if the project is a WAR or have a
> Webapp-Context (that make the bundle a WAB, as for OSGI in Action), in fact
> I do not have that intructions and the war project Bundle-Classpath:
> WEB-INF/classes in the MANIFEST (note, without the dot).
> I think also that Webapp-Context has been deprecated in favor of the new
> Web-ContextPath you also have.
ok, thanks for the info, I used both headers (web-contextpath and
webapp-context) so far without issues, so I didn't worry to modify this
so far.
> As for DynamicImport-Package: *
> what does this do?
This is a very generic import header for the bundle. It is needed, if
you plan to have other bundles contribute wicket pages/components.
Wicket uses reflection to c
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
Hi Daniele, On [Tue, 26.04.2011 12:19], Daniele Dellafiore wrote: > On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner wrote: > > > the "uber-jar" is only concerning wicket, not any war bundle. while it > > would be of course "nicer" to have all wicket jars as separate bundles > > available out of the box. but one solution I find quite ok is creating > > one bundle out of core, request and util. this will then be a uber-jar > > that brings wicket into the osgi mix. It's just containing the core > > packages of wicket. > > > > I think the different jars help the wicket developers to cleaner > > dependencies (when creating a class the dependencies make you think > > about where to put it, so you don't create a RequestClass in the core > > package/module, for example) -- please correct me if this is wrong. > > > > But from the client or user point of view, the jars wicket-core,util and > > request are all kind of core modules. You'll need them all (I think) to > > use wicket. this makes it in my opinion ok to use the one big wicket > > jar. all others (auth-roles etc) are still separate bundles. > > > > regards > > Eike > > > > This is not as bad as having to package the uber-jar with the war, sure. > Better than keeping a separate wicket codebase, at least :) > > Anyway it's still a custom solution that I, and all wicket developers, have > to do. More over, they have to discover that this has to be done, that > wicket bundles are working bundles, but not usable. > Wicket bundles are some sort of raw jars+metadata that can be assemled in a > custom way to become a usable OSGI bundle. Whatever you consider the > uber-jar solution to go good or not, this is a flaw. I totally agree with you. Wicket is such a great web framework and people who like to use it with osgi shouldn't have a hard time to get both workgin together. The fact that the three wicket modules have osgi related meta data but don't work as osgi bundles is really confusing. So a distributed uber-jar would be a quick fix for that. People can easily deploy wicket to an osgi container. > I agree that you have to use -util -request and -core to make wicket work, > but so, if they are so coupled, why to make different bundles at all? > Alexandros already asked for this.You say modularization helps wicket > developer.I would agree but what is the difference between the .request and > .util package in -request, -util and in -core? > > As Martin pointed out, there are no more implementation of wicket, to date. > So the -core is not a specific implementation of -request and -util. Maybe > just more concret classes? > > Again I think that the package that span across different modules is a > flawed design. For sure it is not OSGi-compliant. Again I agree with you. The uber jar is good to get wicket quickly running with osgi, but it is more a workaround. I'm not deep in wicket code, but it feels awkward to first package classes in one package and than split this package across modules (which is even harder grained). A while ago I tried to create different package names per module using wicket-trunk codebase. But it was more work than it seemed. Many classes rely on package visibility (also many test classes) on packages that are split across modules. I think, this is an indication that those modules are tightly coupled as you said. It's probably not an easy task to decouple them. But imho something to think about. Then it shouldn't be a problem to have different package names per module, which will solve the osgi problem right away;) Just my opinion... > I do not want to bother more, anyway. I'll go for the uber-jar with wicket > 1.5. I'll open an issue to fix this flaw so maybe wicket 1.6 will work out > of the box in OSGi. -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [osgi] package org.apache.wicket.request exported either from core and request packages
the "uber-jar" is only concerning wicket, not any war bundle. while it would be of course "nicer" to have all wicket jars as separate bundles available out of the box. but one solution I find quite ok is creating one bundle out of core, request and util. this will then be a uber-jar that brings wicket into the osgi mix. It's just containing the core packages of wicket. I think the different jars help the wicket developers to cleaner dependencies (when creating a class the dependencies make you think about where to put it, so you don't create a RequestClass in the core package/module, for example) -- please correct me if this is wrong. But from the client or user point of view, the jars wicket-core,util and request are all kind of core modules. You'll need them all (I think) to use wicket. this makes it in my opinion ok to use the one big wicket jar. all others (auth-roles etc) are still separate bundles. regards Eike On [Mon, 25.04.2011 19:08], Daniele Dellafiore wrote: > Are you referring to this conversation? > http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html > > If so, I read it and answered that I'm not interested in any solution that > involves the uber-jar. I do not see any advantage in that solution over a > normal war. > > I do not find any other advice from you and Eike, maybe you can point me out > the right conversation. > > > On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov wrote: > > > Hi Daniele, > > > > Me and later Eike explained to you in the other thread you started few > > months ago how to solve exactly this problem. > > It seems you didn't read it at all. Please read again the part > > mentioning Wicket 1.5 RC1. > > > > On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore > > wrote: > > > I did it. Yes, the tough way but I did it. > > > Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the > > > 1.5-SNAPSHOT I built. > > > > > > Basically I renamed the .util and .request packages in -core bundle to be > > > .core.util and .core.request. > > > I had to make a class public in another package under -request bundle to > > > make it visible, but it's a minor thing. > > > > > > I open a bug on jira now... wow, is down :) well, as soon as it get back > > > online. > > > > > > On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore > > > wrote: > > > > > >> it is not. > > >> > > >> I'm hacking on the trunk to make that work. > > >> Maybe a quick solution is just change org.apache.wicket to > > >> org.apache.wicket.core in the -core bundle. > > >> > > >> Of course there are some default scope classes that works through > > different > > >> packages but I can just make them public for now. > > >> > > >> On Mon, Apr 25, 2011 at 3:18 PM, James Carman < > > ja...@carmanconsulting.com>wrote: > > >> > > >>> On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore < > > ilde...@gmail.com> > > >>> wrote: > > >>> > > > >>> > I think that the wicket package layout should be changed now that > > -util > > >>> and > > >>> > -request bundles have been detached from -core. > > >>> > > > >>> > > >>> From an OSGi perspective, we should probably try to make sure that > > >>> packages don't span jar files. Everything in > > >>> org.apache,wicket.request should be in wicket-request.jar, for > > >>> example. I don't know if that's the case, currently or not. > > >>> > > >>> - > > >>> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > >>> For additional commands, e-mail: users-h...@wicket.apache.org > > >>> > > >>> > > >> > > > > > > > > > > > -- > > Martin Grigorov > > jWeekend > > Training, Consulting, Development > > http://jWeekend.com > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Fwd: wicket 1.5-rc2 and aggregate jar for osgi
Hi Daniele,
I might have not understood your concern well enough... But here is what I
do: I deploy a really small war file (without any deps of course) into the
osgi container (I use felix...). There is another bundle from pax,
called pax-web-extender, that "listens" for war files coming into the
container and will then register them on the embedded jetty instance.
I use the following pax bundles:
* org.ops4j.pax.web.pax-web-extender-war
* org.ops4j.pax.web.pax-web-jetty-bundle
* org.ops4j.pax.web.pax-web-jsp (might be superfluous)
Then I use the felix-bundle plugin to create a MANIFEST.MF for my war
file. It looks like that:
org.apache.felix
maven-bundle-plugin
bundle-manifest
process-classes
manifest
jar
war
bundle
<_include>-osgi.bnd
org.apache.maven.plugins
maven-war-plugin
${project.build.outputDirectory}/META-INF/MANIFEST.MF
There are some more instructions in the "osgi.bnd" file. You could have
written them directly in the section of the bundle plugin:
Bundle-Classpath: ., WEB-INF/classes
Web-ContextPath: mywebapp
DynamicImport-Package: *
Webapp-Context: mywebapp
This creates a MANIFEST with Import-Package statements for all your
dependencies - they are not included in the war file. The war file has
no /lib folder, just WEB-INF/classes and META-INF/ are there. The bundle
classpath is extended to include the classes in WEB-INF/classes. I
use the scope "provided" for all dependencies.
When the war file is deployed to the osgi container, the pax bundles
from above will make it available to jetty.
In my case the war file contains a simple wicket application that itself
listens for other bundles to finally create content. So its just a few
bytes and I can reload/redeploy the "content bundles" without affecting
the whole application.
Regards
Eike
On [Wed, 06.04.2011 23:09], Daniele Dellafiore wrote:
> yes the idea is not to have the huber jar, it's all about this, is the main
> feature :)
> some guys in the felix maling list suggested me that's actually possible and
> supported, it's called WAB, that's a war without /lib (a partially reverse
> recursive achronim for A Better War)
>
> http://old.nabble.com/A-better-life%3A-quick-webapp-deploy-to31334158.html
>
> I'll go for that tomorrow.
>
> On Wed, Apr 6, 2011 at 4:27 PM, Martin Grigorov wrote:
>
> > I'm not an OSGi user but here is what I'll do.
> >
> > 1) create a new Maven project with packaging type 'pom'
> > 2) combine all wicket jars in one (uber-jar)
> > there are several approaches here:
> > 1) maven-shade-plugin
> > 2) the way we did it in RC1 with maven-dependency-plugin: see
> >
> > http://repo2.maven.org/maven2/org/apache/wicket/wicket/1.5-RC1/wicket-1.5-RC1.pom
> >
> > Here check that works with simple Wicket app (e.g. the quickstart).
> >
> > Creating one big jar with all dependendies is against OSGi idea. The goal
> > is
> > to be able to replace dependencies without restarting, e.g. upgrade the
> > service layer without undeploying the presentation.
> > But if you still want to do it: start adding more dependencies to be
> > packed
> > in the uber jar (spring, hibernate)
> >
> > About WicketFilter:
> > - you can use embedded Jetty or Guice Filter
> > and org.apache.wicket.protocol.http.WicketFilter.FILTER_MAPPING_PARAM (I
> > explained this earlier today in another thread)
> > - OSGi 4.1+ has the notion of enterprise OSGi and you can use plain OSGi
> > gymnastics to do that (I have no experience at all in this)
> >
>
>
>
>
>
> --
> > Martin Grigorov
> > jWeekend
> > Training, Consulting, Development
> > http://jWeekend.com
Re: wicket 1.5-rc2 and aggregate jar for osgi
Hi Martin, thanks for your response and no need to apologize! It's good to have rcX candidate releases to play with so issues can be found. For me a wicket-osgi dependency would be great! And I really don't care about where to download :) I don't think that providing it from wicketstuff would bother users... If you decide to not support osgi out-of-the-box, it's still no problem to create an aggregate jar myself. I'd think most osgi users have to do this (unfortunately) quite often to add other "no-bundle-jars". But with a distributed jar, it's of course a lot easier - I would appreciate it (as probably other osgi users would). regards, Eike On [Tue, 15.03.2011 20:43], Martin Grigorov wrote: > Hi Eike, > > Sorry that we broke OSGi support again. > The problem was that many users wanted -sources and -javadoc for the > aggregate .jar and it became a bit complex and confusing. > > I think we can add wicket-osgi project in wicketstuff/core repository that > will do the same we did initially in WICKET-3088 and then you will use > org.wicketstuff:wicket-osgi dependency instead. We release wicketstuff core > projects few days after Wicket releases. > > Other opinions/suggestions ? > > martin-g > > On Tue, Mar 15, 2011 at 3:05 PM, Eike Kettner wrote: > > > Hi, > > > > I'm using wicket 1.5-RC1 in an OSGi container. There was an issue when > > upgrading related to package names > > (https://issues.apache.org/jira/browse/WICKET-3088) > > > > Now I tried upgrading to 1.5-rc2 and found that there is no aggregate > > jar file anymore. I then read the discussion-thread "[discuss] How to > > resolve wicket aggregate classes / sources jar issues". > > (nabble: > > > > http://apache-wicket.1842946.n4.nabble.com/discuss-How-to-resolve-wicket-aggregate-classes-sources-jar-issues-td3234420.html) > > As it states, the aggregate jar has been removed from the wicket > > distribution. Now, this introduces the very same issues described in > > WICKET-3088 again. > > > > While I can just repackage wicket myself and create a aggregate jar to > > feed the osgi container, it is first more inconvenient :) and secondly, > > there is then no real reason to have the wicket-xxx jars export > > packages, as they won't work in an OSGi container one by one anyways. I > > cannot add all single jars to the osgi container, because of the clashes > > in export-package. > > > > so in summary, there is another use case where the aggregate jar is > > really helpful: when using wicket with osgi. But it only is, because > > the single wicket jars export the same packages (for example, > > wicket-request and wicket-core both export > > org.apache.wicket.request.handler). > > > > Are there any thoughts of adding this aggregate jar to the distribution > > back again? > > > > kind regards, > > eike > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com <http://jweekend.com/> -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicket 1.5-rc2 and aggregate jar for osgi
Hi, I'm using wicket 1.5-RC1 in an OSGi container. There was an issue when upgrading related to package names (https://issues.apache.org/jira/browse/WICKET-3088) Now I tried upgrading to 1.5-rc2 and found that there is no aggregate jar file anymore. I then read the discussion-thread "[discuss] How to resolve wicket aggregate classes / sources jar issues". (nabble: http://apache-wicket.1842946.n4.nabble.com/discuss-How-to-resolve-wicket-aggregate-classes-sources-jar-issues-td3234420.html ) As it states, the aggregate jar has been removed from the wicket distribution. Now, this introduces the very same issues described in WICKET-3088 again. While I can just repackage wicket myself and create a aggregate jar to feed the osgi container, it is first more inconvenient :) and secondly, there is then no real reason to have the wicket-xxx jars export packages, as they won't work in an OSGi container one by one anyways. I cannot add all single jars to the osgi container, because of the clashes in export-package. so in summary, there is another use case where the aggregate jar is really helpful: when using wicket with osgi. But it only is, because the single wicket jars export the same packages (for example, wicket-request and wicket-core both export org.apache.wicket.request.handler). Are there any thoughts of adding this aggregate jar to the distribution back again? kind regards, eike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RestartResponseAtInterceptPage
Hi Martin, thank you for your response. Of course I was expecting RestartResponseAtIntercept*Page*Exception to accept a Page, while looking for something like RestartResponseAtInterceptHandlerException ;-) I created my own Exception that accepts a request handler. I subclassed ResetResponseEx as well, which schedules my RequestHandler. But then I don't know how to make Component.continueToOriginalDestination() work again. RestartRespAtInterceptPageEx uses a class "InterceptData" to save the original request url in the session. Component.continueToOringinalDestination() calls the same named static method of RestartResponseAtInterceptPageExc. So I just used the class InterceptData the same way, but its javadoc comment states, that it's not part of wickets public api and will be package private in near future. So I don't know where to plugin my code. Regards, Eike On [Tue, 11.01.2011 14:15], Martin Grigorov wrote: > Hi, > > I guess it accepts a Page because this is what the class name > states: RestartResponseAtIntercept*Page*Exception > > But looking at the source it should be quite easy to create your own > Exception which accepts IRequestHandler and does the same. > If you think it should be in the framework then file a ticket in Jira for > improvement. > > On Tue, Jan 11, 2011 at 1:09 PM, Eike Kettner wrote: > > > Hi > > > > For wicket 1.5.x I created a custom RequestHandler that also renders > > pages. Now I like to use this handler in > > RestartResponseAtInterceptPageException. But the class only accepts a > > Page, and then schedules a RenderingPageRequestHandler. Is there any > > reason why not having a custom handler be the target for an intercept > > request? I used the InterceptData class which is public for now and > > found it working ok. But I'm not sure if I miss something? I'm also > > remembering that it also did not work in wicket 1.4.x to set a custom > > RequestTarget to use for RestartResponseAtInterceptPageException. > > > > Thanks in advance for any help! > > Regards, > > Eike > > > > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
RestartResponseAtInterceptPage
Hi For wicket 1.5.x I created a custom RequestHandler that also renders pages. Now I like to use this handler in RestartResponseAtInterceptPageException. But the class only accepts a Page, and then schedules a RenderingPageRequestHandler. Is there any reason why not having a custom handler be the target for an intercept request? I used the InterceptData class which is public for now and found it working ok. But I'm not sure if I miss something? I'm also remembering that it also did not work in wicket 1.4.x to set a custom RequestTarget to use for RestartResponseAtInterceptPageException. Thanks in advance for any help! Regards, Eike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: why is there no redirectToIntercept *Target*
This is what worked for me, maybe this is of use for someone else IPageMap pageMap = //get page map (like in //RestartResponseAtInterceptPageException#redirectToInterceptPage()) IRequestTarget target = createMySpecialTarget(); //now just to setup intercept url pageMap.redirectToInterceptPage(SomePageIdontCareAbout.class); //reset the target .. cycle.setRequestTarget(target); regards, Eike On [Mon, 27.09.2010 23:36], Eike Kettner wrote: > Hi! > I found two methods redirectToInterceptPage(Class) and > redirectToInterceptPage(Page). I was wondering why there is no > overloaded method with a IRequestTarget as argument. I'd like to use > this with a custom request target, that's why i stumbled into this. So I > like to do something like this: > >throw new Restart..InterceptException(new MyRequestTarget(..)); > > > But maybe there is a better way? > > Thank you for your time! > regards, Eike > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Authorization using PageParameters
Hi Peter, this probably not the best way, I don't know, but I would start with throwing an UnauthorizedInstantiationException in my page constructor. regards, Eike On [Wed, 06.10.2010 13:53], Peter Munro wrote: > Hi all, > > I'm confused... I'd like to setup authorization for a page, where the > authorization decision is based on the parameters passed to the page. For > example, http://blahblah/MyPage/?date=2010-10-06 would authorize correctly > (show the page), but previous dates would not. > > Subclassing MyAuthorisationStrategy and overriding isPageAuthorized(final > Class pageClass) doesn't work, since I don't get passed the page > parameters. > > What's the best way? > > Many thanks, > Peter -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.5 and OSGi
Hi Martin, added WICKET-3088. Thank you for your support! Eike On [Sun, 03.10.2010 17:36], Martin Grigorov wrote: > Hi Eike, > > Please file a bug in Jira with link to this mail thread. > > On Sun, Oct 3, 2010 at 2:33 PM, Eike Kettner wrote: > > > Hi Martin > > > > thanks for your advice. I didn't know the maven-shade-plugin, but I > > create on big wicket jar containing all wicket jars like wicket-request, > > wicket-xyz with pax:wrap-jar. This also works fine. > > > > Just want to mention that with this change in wicket 1.5, wicket cannot > > be used in OSGi environments as easiliy as wicket 1.4. One usually has > > to create a wrapped jar somehow. Maybe this is worth to mention on the > > migration guide wiki page? > > > > > > On [Sun, 03.10.2010 13:59], Martin Grigorov wrote: > > > Hi Elke, > > > > > > As I said I don't use OSGi so I can say something that is against OSGi > > > rules, but here is what I'd do in your case: > > > create a Maven project (named for example 'wicket-bundle'), packaging > > type > > > 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce > > one > > > bigger .jar out of all required ones (wicket-util, wicket-request, > > wicket, > > > wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in > > > META-INF/MANIFEST.MF. > > > > > > Since Wicket's artefacts are not splitted in -api and -impl .jars I don't > > > see a reason not to mix them all in one bigger jar for OSGi environments. > > > > > > On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner wrote: > > > > > > > Hi there, > > > > > > > > Just a few updates from my side : > > > > > > > > I recompiled wicket-trunk with changed a package structure and then my > > > > application starts happily with wicket 1.5-M21. (by the way, I'm using > > > > Apache Felix 3.0.2) > > > > > > > > I now use the workaround of wrapping the wicket jars I need into one > > > > jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but > > > > surely not as convienient as before. > > > > > > > > Is anybody having these issues with wicket 1.5+OSGi, too? Or even > > > > better, is anybody not having issues with this combination? > > > > > > > > Regards, > > > > Eike > > > > > > > > On [Fri, 01.10.2010 22:12], Eike Kettner wrote: > > > > > > > > > > Hello again, > > > > > > > > > > I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I > > > > > found some differences. For example, wicket 1.5 has a new artifact > > > > > "wicket-request" and comparing the package structure there are some > > > > > changes, which are probably related to my problem: > > > > > > > > > > wicket-1.4.12.jar: > > > > > org.apache > > > > > `-- wicket > > > > > |-- authorization > > > > > | |-- Action.java > > > > > | |-- AuthorizationException.java > > > > > | |-- strategies > > > > > | | |-- action > > > > > | | | |-- ActionAuthorizationStrategy.java > > > > > | | | `-- IActionAuthorizer.java > > > > > | | |-- CompoundAuthorizationStrategy.java > > > > > | | `-- page > > > > > | | |-- AbstractPageAuthorizationStrategy.java > > > > > | | `-- SimplePageAuthorizationStrategy.java > > > > > | |-- UnauthorizedActionException.java > > > > > | `-- UnauthorizedInstantiationException.java > > > > > > > > > > > > > > > wicket-auth-roles-1.4.12.jar: > > > > > org.apache > > > > > `-- wicket > > > > >|-- authentication > > > > >| |-- AuthenticatedWebApplication.java > > > > >| |-- AuthenticatedWebSession.java > > > > >| |-- pages > > > > >| | |-- SignInPage_fr.html > > > > >`-- authorization > > > > >`-- strategies > > > > >`-- role > > > > >|-- AbstractRoleAuthorizationStrategy.java > > > > >| |-- ActionPermissions.java > > > &g
Re: Wicket 1.5 and OSGi
Hi Martin thanks for your advice. I didn't know the maven-shade-plugin, but I create on big wicket jar containing all wicket jars like wicket-request, wicket-xyz with pax:wrap-jar. This also works fine. Just want to mention that with this change in wicket 1.5, wicket cannot be used in OSGi environments as easiliy as wicket 1.4. One usually has to create a wrapped jar somehow. Maybe this is worth to mention on the migration guide wiki page? On [Sun, 03.10.2010 13:59], Martin Grigorov wrote: > Hi Elke, > > As I said I don't use OSGi so I can say something that is against OSGi > rules, but here is what I'd do in your case: > create a Maven project (named for example 'wicket-bundle'), packaging type > 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one > bigger .jar out of all required ones (wicket-util, wicket-request, wicket, > wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in > META-INF/MANIFEST.MF. > > Since Wicket's artefacts are not splitted in -api and -impl .jars I don't > see a reason not to mix them all in one bigger jar for OSGi environments. > > On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner wrote: > > > Hi there, > > > > Just a few updates from my side : > > > > I recompiled wicket-trunk with changed a package structure and then my > > application starts happily with wicket 1.5-M21. (by the way, I'm using > > Apache Felix 3.0.2) > > > > I now use the workaround of wrapping the wicket jars I need into one > > jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but > > surely not as convienient as before. > > > > Is anybody having these issues with wicket 1.5+OSGi, too? Or even > > better, is anybody not having issues with this combination? > > > > Regards, > > Eike > > > > On [Fri, 01.10.2010 22:12], Eike Kettner wrote: > > > > > > Hello again, > > > > > > I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I > > > found some differences. For example, wicket 1.5 has a new artifact > > > "wicket-request" and comparing the package structure there are some > > > changes, which are probably related to my problem: > > > > > > wicket-1.4.12.jar: > > > org.apache > > > `-- wicket > > > |-- authorization > > > | |-- Action.java > > > | |-- AuthorizationException.java > > > | |-- strategies > > > | | |-- action > > > | | | |-- ActionAuthorizationStrategy.java > > > | | | `-- IActionAuthorizer.java > > > | | |-- CompoundAuthorizationStrategy.java > > > | | `-- page > > > | | |-- AbstractPageAuthorizationStrategy.java > > > | | `-- SimplePageAuthorizationStrategy.java > > > | |-- UnauthorizedActionException.java > > > | `-- UnauthorizedInstantiationException.java > > > > > > > > > wicket-auth-roles-1.4.12.jar: > > > org.apache > > > `-- wicket > > >|-- authentication > > >| |-- AuthenticatedWebApplication.java > > >| |-- AuthenticatedWebSession.java > > >| |-- pages > > >| | |-- SignInPage_fr.html > > >`-- authorization > > >`-- strategies > > >`-- role > > >|-- AbstractRoleAuthorizationStrategy.java > > >| |-- ActionPermissions.java > > >`-- Roles.java > > > > > > This looks good to OSGi as the classes are in disjoint packages in the > > > two bundles. > > > > > > > > > This changed in 1.5. There the structure looks like this: > > > > > > wicket-1.5-M2.1.jar > > > org.apache > > > `-- wicket > > > |-- authentication > > > | |-- IAuthenticationStrategy.java > > > | `-- strategy > > > | |-- DefaultAuthenticationStrategy.java > > > | `-- NoOpAuthenticationStrategy.java > > > > > > wicket-auth-roles-1.5-M2.1.jar > > > org.apache > > > `-- wicket > > > |-- authentication > > > | |-- AuthenticatedWebApplication.java > > > | |-- AuthenticatedWebSession.java > > > | |-- pages > > > | | |-- SignInPage.html > > > | | |-- SignInPage.java > > > > > > > > > The problem is the package org.apache.wicket.authentication now, because > > > the bu
Re: Wicket 1.5 and OSGi
Hi Martin thanks for your advice. I didn't know the maven-shade-plugin, but I create on big wicket jar containing all wicket jars like wicket-request, wicket-xyz with pax:wrap-jar. This also works fine. Just want to mention that with this change in wicket 1.5, wicket cannot be used in OSGi environments as easiliy as wicket 1.4. One usually has to create a wrapped jar somehow. Maybe this is worth to mention on the migration guide wiki page? On [Sun, 03.10.2010 13:59], Martin Grigorov wrote: > Hi Elke, > > As I said I don't use OSGi so I can say something that is against OSGi > rules, but here is what I'd do in your case: > create a Maven project (named for example 'wicket-bundle'), packaging type > 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one > bigger .jar out of all required ones (wicket-util, wicket-request, wicket, > wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in > META-INF/MANIFEST.MF. > > Since Wicket's artefacts are not splitted in -api and -impl .jars I don't > see a reason not to mix them all in one bigger jar for OSGi environments. > > On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner wrote: > > > Hi there, > > > > Just a few updates from my side : > > > > I recompiled wicket-trunk with changed a package structure and then my > > application starts happily with wicket 1.5-M21. (by the way, I'm using > > Apache Felix 3.0.2) > > > > I now use the workaround of wrapping the wicket jars I need into one > > jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but > > surely not as convienient as before. > > > > Is anybody having these issues with wicket 1.5+OSGi, too? Or even > > better, is anybody not having issues with this combination? > > > > Regards, > > Eike > > > > On [Fri, 01.10.2010 22:12], Eike Kettner wrote: > > > > > > Hello again, > > > > > > I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I > > > found some differences. For example, wicket 1.5 has a new artifact > > > "wicket-request" and comparing the package structure there are some > > > changes, which are probably related to my problem: > > > > > > wicket-1.4.12.jar: > > > org.apache > > > `-- wicket > > > |-- authorization > > > | |-- Action.java > > > | |-- AuthorizationException.java > > > | |-- strategies > > > | | |-- action > > > | | | |-- ActionAuthorizationStrategy.java > > > | | | `-- IActionAuthorizer.java > > > | | |-- CompoundAuthorizationStrategy.java > > > | | `-- page > > > | | |-- AbstractPageAuthorizationStrategy.java > > > | | `-- SimplePageAuthorizationStrategy.java > > > | |-- UnauthorizedActionException.java > > > | `-- UnauthorizedInstantiationException.java > > > > > > > > > wicket-auth-roles-1.4.12.jar: > > > org.apache > > > `-- wicket > > >|-- authentication > > >| |-- AuthenticatedWebApplication.java > > >| |-- AuthenticatedWebSession.java > > >| |-- pages > > >| | |-- SignInPage_fr.html > > >`-- authorization > > >`-- strategies > > >`-- role > > >|-- AbstractRoleAuthorizationStrategy.java > > >| |-- ActionPermissions.java > > >`-- Roles.java > > > > > > This looks good to OSGi as the classes are in disjoint packages in the > > > two bundles. > > > > > > > > > This changed in 1.5. There the structure looks like this: > > > > > > wicket-1.5-M2.1.jar > > > org.apache > > > `-- wicket > > > |-- authentication > > > | |-- IAuthenticationStrategy.java > > > | `-- strategy > > > | |-- DefaultAuthenticationStrategy.java > > > | `-- NoOpAuthenticationStrategy.java > > > > > > wicket-auth-roles-1.5-M2.1.jar > > > org.apache > > > `-- wicket > > > |-- authentication > > > | |-- AuthenticatedWebApplication.java > > > | |-- AuthenticatedWebSession.java > > > | |-- pages > > > | | |-- SignInPage.html > > > | | |-- SignInPage.java > > > > > > > > > The problem is the package org.apache.wicket.authentication now, because > > > the bu
Re: Wicket 1.5 and OSGi
Hi there, Just a few updates from my side : I recompiled wicket-trunk with changed a package structure and then my application starts happily with wicket 1.5-M21. (by the way, I'm using Apache Felix 3.0.2) I now use the workaround of wrapping the wicket jars I need into one jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but surely not as convienient as before. Is anybody having these issues with wicket 1.5+OSGi, too? Or even better, is anybody not having issues with this combination? Regards, Eike On [Fri, 01.10.2010 22:12], Eike Kettner wrote: > > Hello again, > > I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I > found some differences. For example, wicket 1.5 has a new artifact > "wicket-request" and comparing the package structure there are some > changes, which are probably related to my problem: > > wicket-1.4.12.jar: > org.apache > `-- wicket > |-- authorization > | |-- Action.java > | |-- AuthorizationException.java > | |-- strategies > | | |-- action > | | | |-- ActionAuthorizationStrategy.java > | | | `-- IActionAuthorizer.java > | | |-- CompoundAuthorizationStrategy.java > | | `-- page > | | |-- AbstractPageAuthorizationStrategy.java > | | `-- SimplePageAuthorizationStrategy.java > | |-- UnauthorizedActionException.java > | `-- UnauthorizedInstantiationException.java > > > wicket-auth-roles-1.4.12.jar: > org.apache > `-- wicket >|-- authentication >| |-- AuthenticatedWebApplication.java >| |-- AuthenticatedWebSession.java >| |-- pages >| | |-- SignInPage_fr.html >`-- authorization >`-- strategies >`-- role >|-- AbstractRoleAuthorizationStrategy.java >| |-- ActionPermissions.java >`-- Roles.java > > This looks good to OSGi as the classes are in disjoint packages in the > two bundles. > > > This changed in 1.5. There the structure looks like this: > > wicket-1.5-M2.1.jar > org.apache > `-- wicket > |-- authentication > | |-- IAuthenticationStrategy.java > | `-- strategy > | |-- DefaultAuthenticationStrategy.java > | `-- NoOpAuthenticationStrategy.java > > wicket-auth-roles-1.5-M2.1.jar > org.apache > `-- wicket > |-- authentication > | |-- AuthenticatedWebApplication.java > | |-- AuthenticatedWebSession.java > | |-- pages > | | |-- SignInPage.html > | | |-- SignInPage.java > > > The problem is the package org.apache.wicket.authentication now, because > the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide > classes from this package. The same refers to org.apache.wicket.request, > which is exported by wicket-request and wicket in 1.5. This leads to > problems in an OSGi environment. OSGi discourages those scenarios, but > still offers an solution for this. A (rather old) blog post on osgi.org > gives some hints on this: > > http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html > > It probably gets to weird loading errors if two classes from the same > package want to access each others fields or methods with package access, > but come from a different classloader... > > I'm no OSGi expert, so I don't know the right OSGi header that solves > this. Of course, a real solution would be to only have disjoint packages > :) I usually put the artifact name in my package name, to avoid any > clashes (in fact it makes sense in my module structure). > > > Kind regards, > Eike > > > On [Fri, 01.10.2010 10:05], Martin Grigorov wrote: > > Hi Elke, > > > > On Fri, Oct 1, 2010 at 8:34 AM, Eike Kettner wrote: > > > > > Hello! > > > > > > I developed a wicket app using OSGi (felix) where different bundles may > > > contribute content to the wicket bundle. It works really nice using > > > wicket 1.4.9+. Now I want to upgrade to wicket 1.5 and I run in problems > > > starting the osgi container. > > > > > > It complains with the good-known classnotfound-exception for classes > > > like IClusterable and AuthenticatedWebapplication which all are classes > > > in packages exported by more than one bundle (for example > > > org.apache.wicket or org.apache.wicket.authentication). Earlier I found > > > this was a problem or at least a "not-good" for OSGi bundles. But as am > > > using OSGi 4.2 this may work with some special treatment (I'v never > > > tried this though). Do you think
Re: Wicket 1.5 and OSGi
Hello again, I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I found some differences. For example, wicket 1.5 has a new artifact "wicket-request" and comparing the package structure there are some changes, which are probably related to my problem: wicket-1.4.12.jar: org.apache `-- wicket |-- authorization | |-- Action.java | |-- AuthorizationException.java | |-- strategies | | |-- action | | | |-- ActionAuthorizationStrategy.java | | | `-- IActionAuthorizer.java | | |-- CompoundAuthorizationStrategy.java | | `-- page | | |-- AbstractPageAuthorizationStrategy.java | | `-- SimplePageAuthorizationStrategy.java | |-- UnauthorizedActionException.java | `-- UnauthorizedInstantiationException.java wicket-auth-roles-1.4.12.jar: org.apache `-- wicket |-- authentication | |-- AuthenticatedWebApplication.java | |-- AuthenticatedWebSession.java | |-- pages | | |-- SignInPage_fr.html `-- authorization `-- strategies `-- role |-- AbstractRoleAuthorizationStrategy.java | |-- ActionPermissions.java `-- Roles.java This looks good to OSGi as the classes are in disjoint packages in the two bundles. This changed in 1.5. There the structure looks like this: wicket-1.5-M2.1.jar org.apache `-- wicket |-- authentication | |-- IAuthenticationStrategy.java | `-- strategy | |-- DefaultAuthenticationStrategy.java | `-- NoOpAuthenticationStrategy.java wicket-auth-roles-1.5-M2.1.jar org.apache `-- wicket |-- authentication | |-- AuthenticatedWebApplication.java | |-- AuthenticatedWebSession.java | |-- pages | | |-- SignInPage.html | | |-- SignInPage.java The problem is the package org.apache.wicket.authentication now, because the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide classes from this package. The same refers to org.apache.wicket.request, which is exported by wicket-request and wicket in 1.5. This leads to problems in an OSGi environment. OSGi discourages those scenarios, but still offers an solution for this. A (rather old) blog post on osgi.org gives some hints on this: http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html It probably gets to weird loading errors if two classes from the same package want to access each others fields or methods with package access, but come from a different classloader... I'm no OSGi expert, so I don't know the right OSGi header that solves this. Of course, a real solution would be to only have disjoint packages :) I usually put the artifact name in my package name, to avoid any clashes (in fact it makes sense in my module structure). Kind regards, Eike On [Fri, 01.10.2010 10:05], Martin Grigorov wrote: > Hi Elke, > > On Fri, Oct 1, 2010 at 8:34 AM, Eike Kettner wrote: > > > Hello! > > > > I developed a wicket app using OSGi (felix) where different bundles may > > contribute content to the wicket bundle. It works really nice using > > wicket 1.4.9+. Now I want to upgrade to wicket 1.5 and I run in problems > > starting the osgi container. > > > > It complains with the good-known classnotfound-exception for classes > > like IClusterable and AuthenticatedWebapplication which all are classes > > in packages exported by more than one bundle (for example > > org.apache.wicket or org.apache.wicket.authentication). Earlier I found > > this was a problem or at least a "not-good" for OSGi bundles. But as am > > using OSGi 4.2 this may work with some special treatment (I'v never > > tried this though). Do you think I'm doing something wrong or is this > > something on the road for 1.5? > > > I don't have much experience with OSGi so can you give more details what > exactly is the problem ? > I think there is no difference in these two classes between 1.4.x and 1.5.x. > They are packed the same way. > There is no difference in the bnd-maven-plugin configuration as well. > If you can find where the problem comes from then we can improve it. > > > > > Also, since I have implemented ..UrlCodingStrategy and a custom > > RequestTarget I'm studying the new request handling in 1.5 sources to > > find out where to "plugin" my stuff. Are there any documentation besides > > source and javadoc for the new concepts? The code is good to read but if > > there are some pictures and text available it would be of great help. > > > Unfortunately there is other documentation yet. > The idea is: > with application.getRootRequestMapperAsCompound().add(myMapper) you can add > a IRequestMapper to the list of
Re: Wicket 1.5 and OSGi
Hi Martin, On [Fri, 01.10.2010 10:05], Martin Grigorov wrote: > Hi Elke, > > On Fri, Oct 1, 2010 at 8:34 AM, Eike Kettner wrote: > > > Hello! > > > > I developed a wicket app using OSGi (felix) where different bundles may > > contribute content to the wicket bundle. It works really nice using > > wicket 1.4.9+. Now I want to upgrade to wicket 1.5 and I run in problems > > starting the osgi container. > > > > It complains with the good-known classnotfound-exception for classes > > like IClusterable and AuthenticatedWebapplication which all are classes > > in packages exported by more than one bundle (for example > > org.apache.wicket or org.apache.wicket.authentication). Earlier I found > > this was a problem or at least a "not-good" for OSGi bundles. But as am > > using OSGi 4.2 this may work with some special treatment (I'v never > > tried this though). Do you think I'm doing something wrong or is this > > something on the road for 1.5? > > > I don't have much experience with OSGi so can you give more details what > exactly is the problem ? > I think there is no difference in these two classes between 1.4.x and 1.5.x. > They are packed the same way. > There is no difference in the bnd-maven-plugin configuration as well. > If you can find where the problem comes from then we can improve it. > thank you for the quick reply. As you said, there shouldn't be any difference from 1.4 to 1.5 as the packaging remained the same. That sounds like a problem on my side. I will look into this more this evening. But to tell you the steps I took: I replaced the wicket-version in the poms, removed the resulting compile errors by rudely deleting everything... until I ended up with one application class (extending AuthenticatedWebApplication). And I maked sure the packages are properly stated in the "Import-Package" header. I put the wicket-request and wicket-util bundles in the container and tried to startup. Now, one thing I forgot to mention: I use spring (spring-dm) and have my web application created by the spring osgi extender. This means, my MyWebApplication class is declared as a spring bean and the spring extender cannot instantiate the class because it cannot find "org.apache.wicket.authentication.AuthenticatedWebapplication". This is most detail I can give for now, I will give more later. > > > > Also, since I have implemented ..UrlCodingStrategy and a custom > > RequestTarget I'm studying the new request handling in 1.5 sources to > > find out where to "plugin" my stuff. Are there any documentation besides > > source and javadoc for the new concepts? The code is good to read but if > > there are some pictures and text available it would be of great help. > > > Unfortunately there is other documentation yet. > The idea is: > with application.getRootRequestMapperAsCompound().add(myMapper) you can add > a IRequestMapper to the list of mappers. > When a request comes Wicket asks all registered mappers whether they are > able to process the request. Mappers with bigger > org.apache.wicket.request.IRequestMapper.getCompatibilityScore(Request) are > asked first. So Wicket calls > org.apache.wicket.request.IRequestMapper.mapRequest(Request) for each mapper > and if it returns non-null IRequestHandler then this is the handler which > will be used. In #mapRequest(Request) use have to check request's segments > (this is similar to httpServletRequest#getPath()) and request's parameters > (get and post) and decide whether they match to your logic. > After the handling of the request > (org.apache.wicket.request.IRequestHandler.respond(IRequestCycle)) Wicket > will ask the mapper to create a Url which will be used for all urlFor() > calls, i.e. to create the urls for all links, form action, etc. via > org.apache.wicket.request.IRequestMapper.mapHandler(IRequestHandler) > > There are IRequestMapper implementations for all url coding strategies from > 1.4.x so you can use them as examples. > Let us know if you need more help. Thank you! This already helps me alot. Once I get the main idea, the code is alot easier to read! I will gladly ask questions here when they come. Eike > > > > Thanks in advance! > > Eike > > > > martin-g > > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket 1.5 and OSGi
Hello! I developed a wicket app using OSGi (felix) where different bundles may contribute content to the wicket bundle. It works really nice using wicket 1.4.9+. Now I want to upgrade to wicket 1.5 and I run in problems starting the osgi container. It complains with the good-known classnotfound-exception for classes like IClusterable and AuthenticatedWebapplication which all are classes in packages exported by more than one bundle (for example org.apache.wicket or org.apache.wicket.authentication). Earlier I found this was a problem or at least a "not-good" for OSGi bundles. But as am using OSGi 4.2 this may work with some special treatment (I'v never tried this though). Do you think I'm doing something wrong or is this something on the road for 1.5? Also, since I have implemented ..UrlCodingStrategy and a custom RequestTarget I'm studying the new request handling in 1.5 sources to find out where to "plugin" my stuff. Are there any documentation besides source and javadoc for the new concepts? The code is good to read but if there are some pictures and text available it would be of great help. Thanks in advance! Eike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
why is there no redirectToIntercept *Target*
Hi! I found two methods redirectToInterceptPage(Class) and redirectToInterceptPage(Page). I was wondering why there is no overloaded method with a IRequestTarget as argument. I'd like to use this with a custom request target, that's why i stumbled into this. So I like to do something like this: throw new Restart..InterceptException(new MyRequestTarget(..)); But maybe there is a better way? Thank you for your time! regards, Eike - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: AutoCompleteTextField uses wrong encoding?
Hi Matt
some long time ago I had a similiar problem with AjaxEditableLabel. I
used tomcat and there you need to configure the connector using
"useBodyEncodingForURI=true" to make tomcat use utf8 for encoding ajax
requests.
eike
On 10.05.2010 15:27, Matthias Keller wrote:
Hi
I'm using an autocompletefield and it works fine so far. Except that
when entering special characters, they don't get encoded correctly.
The query String is correct and sends the special character in encoded
UTF-8:
GET http://localhost:9080/.../...&q=%C3%B6&random=...
%C3%B6 is UTF8 for "ö"
But in:
org.apache.wicket.extensions.ajax.markup.html.autocomplete.AbstractAutoCompleteBehavior.respond(AjaxRequestTarget)
The following line
final String val = requestCycle.getRequest().getParameter("q");
returns an incorrect string: "ö" which would be the %C3%B6 in
ISO-8859-1 (which happens to be my platform encoding)...
Thus the input parameter to my getChoices() call contains strange
characters in this case...
It appears that the request isn't read out as UTF-8 somehow.. Since I
don't know the AJAX internals, it's hard to find the culprit for me
I'm using Wicket 1.4.8
Matt
problem using pager inside a listview
hi all, I'm using a list view that renders 2 or 3 more complex panels. Each of this panel has (among other panels) a data view with a pager component. Now, when I click on one of the page links, i'm getting back to the page, but the data view shows the same results as before. I often used the PagingNavigator component successfully but not inside a list view. I also tried AjaxPagingNavigator and PagingNavigator, while AjaxPagingNAvigator threw an exception because it couldn't find itself and using PagingNavigator yielded in the same result as mentioned above. I might miss something... can anyone give me some hints here? Thank you for your time! Eike -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: encoding issue on ajax form post (portlet)
Hi Francisco, i ran into a similiar problem with ajax and umlauts. in my case i had a tomcat running the webapp. and for the ajax requests, i had to configure the tomcat connector with useBodyEncodingForURI="true". then the content of ajax requests got correctly encoded (using utf8). since i didn't use porltlets i don't know if this is of any help for you... eike On [Wed, 11.03.2009 11:00], Francisco Diaz Trepat - gmail wrote: > Hi all, I have a wicket project that suddenly required to support portlets. > I traveled through a lot of (I guess) normal issues from not being familiar > with portlets technology. But now I am at a cross rode (quoting obama) :-) > > I have an encoding issue in which, for as much as I could investigate, > begins something like this: > > 1- type [Hómer] in a textfield > 2- wicket javascript functions to handle post encode the field value to > H%C3%D3 (or similar) > 3-portlet handles the request and redireccionates it to wicket. > 4-on wicket side H\ufffd is the resulting string. > 5- when ajax returns H?omer is the resulting string. > I have ISO-8859-1 in the main page (and only page) of my wicket application. > All the rest is ajax. > With my application inside the portlet container the UTF-8 is the encoding > but this doesn't seam to be because I change the encoding for the > portlet-driver and it didn't work at all. > Any Ideas? > f(t) -- email: e...@eknet.org https://www.eknet.org pgp: 481161A0 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
