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
