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 > >
