You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Eike Kettner <ne...@eknet.org> on 2010/10/01 08:34:37 UTC

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-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket 1.5 and OSGi

Posted by Nico Guba <ng...@mac.com>.
  On 10/3/2010 1:35 PM, Eike Kettner wrote:
> 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?
Maybe this project helps reduce the complexity working with OSGI?

http://wiki.ops4j.org/display/ops4j/Pax+Wicket


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket 1.5 and OSGi

Posted by Eike Kettner <ne...@eknet.org>.
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 <ne...@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 <ne...@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-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > >
> > > --
> > > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> >
> > --
> > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >

-- 
email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket 1.5 and OSGi

Posted by Eike Kettner <ne...@eknet.org>.
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 <ei...@eknet.org> 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 <ne...@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 <ne...@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-unsubscribe@wicket.apache.org
> > > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > > >
> > > > > > >
> > > > >
> > > > > --
> > > > > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > >
> > > > --
> > > > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> >
> > --
> > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >

-- 
email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket 1.5 and OSGi

Posted by Martin Grigorov <mg...@apache.org>.
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 <ei...@eknet.org> 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 <ne...@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 <ne...@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-unsubscribe@wicket.apache.org
> > > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > > >
> > > > > >
> > > >
> > > > --
> > > > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > >
> > > --
> > > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
>
> --
> email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Wicket 1.5 and OSGi

Posted by Eike Kettner <ei...@eknet.org>.
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 <ne...@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 <ne...@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-unsubscribe@wicket.apache.org
> > > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > > >
> > > > >
> > >
> > > --
> > > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> >
> > --
> > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >

-- 
email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket 1.5 and OSGi

Posted by Martin Grigorov <mg...@apache.org>.
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 <ne...@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 <ne...@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-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> >
> > --
> > email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
>
> --
> email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>

Re: Wicket 1.5 and OSGi

Posted by Eike Kettner <ne...@eknet.org>.
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 <ne...@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-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> 
> -- 
> email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
> 

-- 
email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket 1.5 and OSGi

Posted by Eike Kettner <ne...@eknet.org>.
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 <ne...@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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >

-- 
email: eike@eknet.org   https://www.eknet.org  pgp: 481161A0

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket 1.5 and OSGi

Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Oct 1, 2010 at 10:05 AM, Martin Grigorov <mg...@apache.org>wrote:

> Hi Elke,
>
> On Fri, Oct 1, 2010 at 8:34 AM, Eike Kettner <ne...@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.
>
Here I wanted to say "...there is *no*..." :-)

> 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-unsubscribe@wicket.apache.org
>> For additional commands, e-mail: users-help@wicket.apache.org
>>
>>
>

Re: Wicket 1.5 and OSGi

Posted by Eike Kettner <ne...@eknet.org>.
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 <ne...@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.
> 

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-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org


Re: Wicket 1.5 and OSGi

Posted by Martin Grigorov <mg...@apache.org>.
Hi Elke,

On Fri, Oct 1, 2010 at 8:34 AM, Eike Kettner <ne...@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-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>