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 <n...@eknet.org> 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 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 <n...@eknet.org> 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 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. > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > -- > > > 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 > > > > > > > -- > > 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 > > > > -- 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
