Re: Fwd: wicket 1.5-rc2 and aggregate jar for osgi

[Eike Kettner]

Hi Daniele,

sorry for answering this late, anyways, inline reply.


On [Fri, 22.04.2011 16:09], Daniele Dellafiore wrote:
 Hi, sorry I read your reply only today...
 I got basically to the same results yesterday, but I've some problem which I
 summarized in the last message in this thread on felix mailing list:
 
 http://old.nabble.com/A-better-life%3A-quick-webapp-deploy-to31334158.html
 
 I'll go into details point by point.
 
 On Fri, Apr 8, 2011 at 3:29 PM, Eike Kettner n...@eknet.org wrote:
 
  Hi Daniele,
 
  I might have not understood your concern well enough... But here is what I
  do: I deploy a really small war file (without any deps of course) into the
  osgi container (I use felix...). There is another bundle from pax,
  called pax-web-extender, that listens for war files coming into the
  container and will then register them on the embedded jetty instance.
 
  I use the following pax bundles:
  * org.ops4j.pax.web.pax-web-extender-war
  * org.ops4j.pax.web.pax-web-jetty-bundle
  * org.ops4j.pax.web.pax-web-jsp   (might be superfluous)
 
 
 yeah I've everything installed. I do not remember what osgi features
 installed this but there is:
 
 [  54] [Active ] [] [   ] [   60] OPS4J Pax Web -
 Runtime (1.0.1)
 [  55] [Active ] [] [   ] [   60] OPS4J Pax Web - API
 (1.0.1)
 [  56] [Active ] [] [   ] [   60] OPS4J Pax Web - Jetty
 (1.0.1)
 [  57] [Active ] [] [   ] [   60] OPS4J Pax Web -
 Service SPI (1.0.1)
 [  59] [Active ] [] [   ] [   60] OPS4J Pax Web -
 Extender - Whiteboard (1.0.1)
 [  60] [Active ] [] [   ] [   60] OPS4J Pax Web -
 FileInstall Deployer (1.0.1)
 [  61] [Active ] [] [   ] [   60] OPS4J Pax Url - war:,
 war-i: (1.2.5)
 [  62] [Active ] [] [   ] [   60] OPS4J Pax Web -
 Extender - WAR (1.0.1)
 [  63] [Active ] [] [   ] [   60] OPS4J Pax Web - Jsp
 Support (1.0.1)
 
 on Karaf 2.2.0
 
 
 
  Then I use the felix-bundle plugin to create a MANIFEST.MF for my war
  file. It looks like that:
 
 plugins
   plugin
 groupIdorg.apache.felix/groupId
 artifactIdmaven-bundle-plugin/artifactId
 executions
   execution
 idbundle-manifest/id
 phaseprocess-classes/phase
 goals
   goalmanifest/goal
 /goals
   /execution
 /executions
 configuration
   supportedProjectTypes
 supportedProjectTypejar/supportedProjectType
 supportedProjectTypewar/supportedProjectType
 supportedProjectTypebundle/supportedProjectType
   /supportedProjectTypes
   instructions
 _include-osgi.bnd/_include
   /instructions
 /configuration
   /plugin
   plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-war-plugin/artifactId
 configuration
   archive
 manifestFile
   ${project.build.outputDirectory}/META-INF/MANIFEST.MF
 /manifestFile
   /archive
 /configuration
   /plugin
 /plugins
 
 
 
 it's almost the same as mine, also the war-plugin config is identical.
 I do not have
 
_include-osgi.bnd/_include
 
 but I have this instructions
 
   _wabsrc/main/webapp/_wab
 Web-ContextPath/myApp/Web-ContextPath


I didn't know about tha _wab configuration, This will maybe then add the
web bundle class path to the headers, so it needn't be specified
explicitely.
 
 There are some more instructions in the osgi.bnd file. You could have
  written them directly in the instructions section of the bundle plugin:
 
   Bundle-Classpath: ., WEB-INF/classes
   Web-ContextPath: mywebapp
   DynamicImport-Package: *
   Webapp-Context: mywebapp
 
 
 It seems that maven-bundle-plugin, at least 2.3.4 version, automatically
 add  Bundle-Classpath: WEB-INF/classes if the project is a WAR or have a
 Webapp-Context (that make the bundle a WAB, as for OSGI in Action), in fact
 I do not have that intructions and the war project  Bundle-Classpath:
 WEB-INF/classes in the MANIFEST (note, without the dot).
 I think also that Webapp-Context has been deprecated in favor of the new
 Web-ContextPath you also have.

ok, thanks for the info, I used both headers (web-contextpath and
webapp-context) so far without issues, so I didn't worry to modify this
so far.

 As for DynamicImport-Package: *
 what does this do?


This is a very generic import header for the bundle. It is needed, if
you plan to have other bundles contribute wicket pages/components.
Wicket uses reflection to create page instances. In this case, the
classes must be available to the class loader. If you do not know them
up front, you can use the DynamicImport-Package statement.

 
 It does not seem you do not have specific Import or Export package
 instructions, so you

Re: [osgi] package org.apache.wicket.request exported either from core and request packages

[Eike Kettner]

the uber-jar is only concerning wicket, not any war bundle. while it
would be of course nicer to have all wicket jars as separate bundles
available out of the box. but one solution I find quite ok is creating
one bundle out of core, request and util. this will then be a uber-jar
that brings wicket into the osgi mix. It's just containing the core
packages of wicket. 

I think the different jars help the wicket developers to cleaner
dependencies (when creating a class the dependencies make you think
about where to put it, so you don't create a RequestClass in the core
package/module, for example) -- please correct me if this is wrong. 

But from the client or user point of view, the jars wicket-core,util and
request are all kind of core modules. You'll need them all (I think) to
use wicket. this makes it in my opinion ok to use the one big wicket
jar. all others (auth-roles etc) are still separate bundles.

regards
Eike


On [Mon, 25.04.2011 19:08], Daniele Dellafiore wrote:
 Are you referring to this conversation?
 http://apache-wicket.1842946.n4.nabble.com/wicket-1-5-rc2-and-aggregate-jar-for-osgi-td3356667.html
 
 If so, I read it and answered that I'm not interested in any solution that
 involves the uber-jar. I do not see any advantage in that solution over a
 normal war.
 
 I do not find any other advice from you and Eike, maybe you can point me out
 the right conversation.
 
 
 On Mon, Apr 25, 2011 at 6:25 PM, Martin Grigorov mgrigo...@apache.orgwrote:
 
  Hi Daniele,
 
  Me and later Eike explained to you in the other thread you started few
  months ago how to solve exactly this problem.
  It seems you didn't read it at all. Please read again the part
  mentioning Wicket 1.5 RC1.
 
  On Mon, Apr 25, 2011 at 6:30 PM, Daniele Dellafiore
  dani...@dellafiore.net wrote:
   I did it. Yes, the tough way but I did it.
   Now the 1.5RC3 quickstart app just started on my karaf 2.2 with the
   1.5-SNAPSHOT I built.
  
   Basically I renamed the .util and .request packages in -core bundle to be
   .core.util and .core.request.
   I had to make a class public in another package under -request bundle to
   make it visible, but it's a minor thing.
  
   I open a bug on jira now... wow, is down :) well, as soon as it get back
   online.
  
   On Mon, Apr 25, 2011 at 4:03 PM, Daniele Dellafiore
   dani...@dellafiore.netwrote:
  
   it is not.
  
   I'm hacking on the trunk to make that work.
   Maybe a quick solution is just change org.apache.wicket to
   org.apache.wicket.core in the -core bundle.
  
   Of course there are some default scope classes that works through
  different
   packages but I can just make them public for now.
  
   On Mon, Apr 25, 2011 at 3:18 PM, James Carman 
  ja...@carmanconsulting.comwrote:
  
   On Mon, Apr 25, 2011 at 10:15 AM, Daniele Dellafiore 
  ilde...@gmail.com
   wrote:
   
I think that the wicket package layout should be changed now that
  -util
   and
-request bundles have been detached from -core.
   
  
   From an OSGi perspective, we should probably try to make sure that
   packages don't span jar files.  Everything in
   org.apache,wicket.request should be in wicket-request.jar, for
   example.  I don't know if that's the case, currently or not.
  
   -
   To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
   For additional commands, e-mail: users-h...@wicket.apache.org
  
  
  
  
 
 
 
  --
  Martin Grigorov
  jWeekend
  Training, Consulting, Development
  http://jWeekend.com
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

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

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

Re: [osgi] package org.apache.wicket.request exported either from core and request packages

[Eike Kettner]

Hi Daniele,

On [Tue, 26.04.2011 12:19], Daniele Dellafiore wrote:
 On Tue, Apr 26, 2011 at 11:48 AM, Eike Kettner e...@eknet.org wrote:
 
  the uber-jar is only concerning wicket, not any war bundle. while it
  would be of course nicer to have all wicket jars as separate bundles
  available out of the box. but one solution I find quite ok is creating
  one bundle out of core, request and util. this will then be a uber-jar
  that brings wicket into the osgi mix. It's just containing the core
  packages of wicket.
 
  I think the different jars help the wicket developers to cleaner
  dependencies (when creating a class the dependencies make you think
  about where to put it, so you don't create a RequestClass in the core
  package/module, for example) -- please correct me if this is wrong.
 
  But from the client or user point of view, the jars wicket-core,util and
  request are all kind of core modules. You'll need them all (I think) to
  use wicket. this makes it in my opinion ok to use the one big wicket
  jar. all others (auth-roles etc) are still separate bundles.
 
  regards
  Eike
 
 
 This is not as bad as having to package the uber-jar with the war, sure.
 Better than keeping a separate wicket codebase, at least :)
 
 Anyway it's still a custom solution that I, and all wicket developers, have
 to do. More over, they have to discover that this has to be done, that
 wicket bundles are working bundles, but not usable.
 Wicket bundles are some sort of raw jars+metadata that can be assemled in a
 custom way to become a usable OSGI bundle. Whatever you consider the
 uber-jar solution to go good or not, this is a flaw.

I totally agree with you. Wicket is such a great web framework and
people who like to use it with osgi shouldn't have a hard time to get
both workgin together. The fact that the three wicket modules have osgi
related meta data but don't work as osgi bundles is really confusing. So
a distributed uber-jar would be a quick fix for that. People can easily
deploy wicket to an osgi container.

 
 I agree that you have to use -util -request  and -core to make wicket work,
 but so, if they are so coupled, why to make different bundles at all?
 Alexandros already asked for this.You say modularization helps wicket
 developer.I would agree but what is the difference between the .request and
 .util package in -request, -util and in -core?
 
 As Martin pointed out, there are no more implementation of wicket, to date.
 So the -core is not a specific implementation of -request and -util. Maybe
 just more concret classes?
 
 Again I think that the package that span across different modules is a
 flawed design. For sure it is not OSGi-compliant.

Again I agree with you. The uber jar is good to get wicket quickly
running with osgi, but it is more a workaround.  I'm not deep in wicket
code, but it feels awkward to first package classes in one package and
than split this package across modules (which is even harder grained). A
while ago I tried to create different package names per module using
wicket-trunk codebase. But it was more work than it seemed. Many classes
rely on package visibility (also many test classes) on packages that are
split across modules. I think, this is an indication that those modules
are tightly coupled as you said. It's probably not an easy task to
decouple them. But imho something to think about. Then it shouldn't be a
problem to have different package names per module, which will solve the
osgi problem right away;) Just my opinion...

 I do not want to bother more, anyway. I'll go for the uber-jar with wicket
 1.5. I'll open an issue to fix this flaw so maybe wicket 1.6 will work out
 of the box in OSGi.


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

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

Re: Fwd: wicket 1.5-rc2 and aggregate jar for osgi

[Eike Kettner]

Hi Daniele,

I might have not understood your concern well enough... But here is what I
do: I deploy a really small war file (without any deps of course) into the
osgi container (I use felix...). There is another bundle from pax,
called pax-web-extender, that listens for war files coming into the
container and will then register them on the embedded jetty instance.

I use the following pax bundles:
* org.ops4j.pax.web.pax-web-extender-war  
* org.ops4j.pax.web.pax-web-jetty-bundle
* org.ops4j.pax.web.pax-web-jsp   (might be superfluous)

Then I use the felix-bundle plugin to create a MANIFEST.MF for my war
file. It looks like that:

plugins
  plugin
groupIdorg.apache.felix/groupId
artifactIdmaven-bundle-plugin/artifactId
executions
  execution
idbundle-manifest/id
phaseprocess-classes/phase
goals
  goalmanifest/goal
/goals
  /execution
/executions
configuration
  supportedProjectTypes
supportedProjectTypejar/supportedProjectType
supportedProjectTypewar/supportedProjectType
supportedProjectTypebundle/supportedProjectType
  /supportedProjectTypes
  instructions
_include-osgi.bnd/_include
  /instructions
/configuration
  /plugin
  plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
configuration
  archive
manifestFile
  ${project.build.outputDirectory}/META-INF/MANIFEST.MF
/manifestFile
  /archive
/configuration
  /plugin
/plugins
 
There are some more instructions in the osgi.bnd file. You could have
written them directly in the instructions section of the bundle plugin:

  Bundle-Classpath: ., WEB-INF/classes
  Web-ContextPath: mywebapp
  DynamicImport-Package: *
  Webapp-Context: mywebapp

This creates a MANIFEST with Import-Package statements for all your
dependencies - they are not included in the war file. The war file has
no /lib folder, just WEB-INF/classes and META-INF/ are there. The bundle
classpath is extended to include the classes in WEB-INF/classes. I
use the scope provided for all dependencies. 

When the war file is deployed to the osgi container, the pax bundles
from above will make it available to jetty.

In my case the war file contains a simple wicket application that itself
listens for other bundles to finally create content. So its just a few
bytes and I can reload/redeploy the content bundles without affecting
the whole application.

Regards
Eike

On [Wed, 06.04.2011 23:09], Daniele Dellafiore wrote:
  yes the idea is not to have the huber jar, it's all about this, is the main
 feature :)
 some guys in the felix maling list suggested me that's actually possible and
 supported, it's called WAB, that's a war without /lib (a partially reverse
 recursive achronim for A Better War)
 
 http://old.nabble.com/A-better-life%3A-quick-webapp-deploy-to31334158.html
 
 I'll go for that tomorrow.
 
 On Wed, Apr 6, 2011 at 4:27 PM, Martin Grigorov mgrigo...@apache.orgwrote:
 
  I'm not an OSGi user but here is what I'll do.
 
  1) create a new Maven project with packaging type 'pom'
  2) combine all wicket jars in one (uber-jar)
   there are several approaches here:
  1) maven-shade-plugin
  2) the way we did it in RC1 with maven-dependency-plugin: see
 
  http://repo2.maven.org/maven2/org/apache/wicket/wicket/1.5-RC1/wicket-1.5-RC1.pom
 
  Here check that works with simple Wicket app (e.g. the quickstart).
 
  Creating one big jar with all dependendies is against OSGi idea. The goal
  is
  to be able to replace dependencies without restarting, e.g. upgrade the
  service layer without undeploying the presentation.
  But if you still want to do it:  start adding more dependencies to be
  packed
  in the uber jar (spring, hibernate)
 
  About WicketFilter:
  - you can use embedded Jetty or Guice Filter
  and org.apache.wicket.protocol.http.WicketFilter.FILTER_MAPPING_PARAM (I
  explained this earlier today in another thread)
  - OSGi 4.1+ has the notion of enterprise OSGi and you can use plain OSGi
  gymnastics to do that (I have no experience at all in this)
 
 
 
 
 
 
 --
  Martin Grigorov
  jWeekend
  Training, Consulting, Development
  http://jWeekend.com http://jweekend.com/
 

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

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

wicket 1.5-rc2 and aggregate jar for osgi

[Eike Kettner]

Hi,

I'm using wicket 1.5-RC1 in an OSGi container. There was an issue when
upgrading related to package names
(https://issues.apache.org/jira/browse/WICKET-3088)

Now I tried upgrading to 1.5-rc2 and found that there is no aggregate
jar file anymore. I then read the discussion-thread [discuss] How to
resolve wicket aggregate classes / sources jar issues. 
(nabble:
http://apache-wicket.1842946.n4.nabble.com/discuss-How-to-resolve-wicket-aggregate-classes-sources-jar-issues-td3234420.html
 )
As it states, the aggregate jar has been removed from the wicket
distribution. Now, this introduces the very same issues described in
WICKET-3088 again.

While I can just repackage wicket myself and create a aggregate jar to
feed the osgi container, it is first more inconvenient :) and secondly,
there is then no real reason to have the wicket-xxx jars export
packages, as they won't work in an OSGi container one by one anyways. I
cannot add all single jars to the osgi container, because of the clashes
in export-package.

so in summary, there is another use case where the aggregate jar is
really helpful: when using wicket with osgi. But it only is, because
the single wicket jars export the same packages (for example,
wicket-request and wicket-core both export
org.apache.wicket.request.handler).

Are there any thoughts of adding this aggregate jar to the distribution
back again?

kind regards,
eike

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

Re: wicket 1.5-rc2 and aggregate jar for osgi

[Eike Kettner]

Hi Martin,

thanks for your response and no need to apologize! It's good to have rcX
candidate releases to play with so issues can be found.

For me a wicket-osgi dependency would be great! And I really don't care
about where to download :) I don't think that providing it from wicketstuff
would bother users...

If you decide to not support osgi out-of-the-box, it's still no problem
to create an aggregate jar myself. I'd think most osgi users have to do
this (unfortunately) quite often to add other  no-bundle-jars. But
with a distributed jar, it's of course a lot easier - I would appreciate
it (as probably other osgi users would).

regards,
Eike

On [Tue, 15.03.2011 20:43], Martin Grigorov wrote:
 Hi Eike,
 
 Sorry that we broke OSGi support again.
 The problem was that many users wanted -sources and -javadoc for the
 aggregate .jar and it became a bit complex and confusing.
 
 I think we can add wicket-osgi project in wicketstuff/core repository that
 will do the same we did initially in WICKET-3088 and then you will use
 org.wicketstuff:wicket-osgi dependency instead. We release wicketstuff core
 projects few days after Wicket releases.
 
 Other opinions/suggestions ?
 
 martin-g
 
 On Tue, Mar 15, 2011 at 3:05 PM, Eike Kettner n...@eknet.org wrote:
 
  Hi,
 
  I'm using wicket 1.5-RC1 in an OSGi container. There was an issue when
  upgrading related to package names
  (https://issues.apache.org/jira/browse/WICKET-3088)
 
  Now I tried upgrading to 1.5-rc2 and found that there is no aggregate
  jar file anymore. I then read the discussion-thread [discuss] How to
  resolve wicket aggregate classes / sources jar issues.
  (nabble:
 
  http://apache-wicket.1842946.n4.nabble.com/discuss-How-to-resolve-wicket-aggregate-classes-sources-jar-issues-td3234420.html)
  As it states, the aggregate jar has been removed from the wicket
  distribution. Now, this introduces the very same issues described in
  WICKET-3088 again.
 
  While I can just repackage wicket myself and create a aggregate jar to
  feed the osgi container, it is first more inconvenient :) and secondly,
  there is then no real reason to have the wicket-xxx jars export
  packages, as they won't work in an OSGi container one by one anyways. I
  cannot add all single jars to the osgi container, because of the clashes
  in export-package.
 
  so in summary, there is another use case where the aggregate jar is
  really helpful: when using wicket with osgi. But it only is, because
  the single wicket jars export the same packages (for example,
  wicket-request and wicket-core both export
  org.apache.wicket.request.handler).
 
  Are there any thoughts of adding this aggregate jar to the distribution
  back again?
 
  kind regards,
  eike
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 
 
 
 -- 
 Martin Grigorov
 jWeekend
 Training, Consulting, Development
 http://jWeekend.com http://jweekend.com/

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

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

RestartResponseAtInterceptPage

[Eike Kettner]

Hi

For wicket 1.5.x I created a custom RequestHandler that also renders
pages. Now I like to use this handler in
RestartResponseAtInterceptPageException. But the class only accepts a
Page, and then schedules a RenderingPageRequestHandler. Is there any
reason why not having a custom handler be the target for an intercept
request? I used the InterceptData class which is public for now and
found it working ok. But I'm not sure if I miss something? I'm also
remembering that it also did not work in wicket 1.4.x to set a custom
RequestTarget to use for RestartResponseAtInterceptPageException.

Thanks in advance for any help!
Regards,
Eike



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

Re: RestartResponseAtInterceptPage

[Eike Kettner]

Hi Martin,

thank you for your response. Of course I was expecting
RestartResponseAtIntercept*Page*Exception to accept a Page, while
looking for something like RestartResponseAtInterceptHandlerException
;-)

I created my own Exception that accepts a request handler. I subclassed
ResetResponseEx as well, which schedules my RequestHandler. But then I
don't know how to make Component.continueToOriginalDestination() work
again. RestartRespAtInterceptPageEx uses a class InterceptData to save
the original request url in the session.
Component.continueToOringinalDestination() calls the same named static
method of RestartResponseAtInterceptPageExc. So I just used the class
InterceptData the same way, but its javadoc comment states, that it's
not part of wickets public api and will be package private in near
future. So I don't know where to plugin my code.

Regards,
Eike


On [Tue, 11.01.2011 14:15], Martin Grigorov wrote:
 Hi,
 
 I guess it accepts a Page because this is what the class name
 states: RestartResponseAtIntercept*Page*Exception
 
 But looking at the source it should be quite easy to create your own
 Exception which accepts IRequestHandler and does the same.
 If you think it should be in the framework then file a ticket in Jira for
 improvement.
 
 On Tue, Jan 11, 2011 at 1:09 PM, Eike Kettner n...@eknet.org wrote:
 
  Hi
 
  For wicket 1.5.x I created a custom RequestHandler that also renders
  pages. Now I like to use this handler in
  RestartResponseAtInterceptPageException. But the class only accepts a
  Page, and then schedules a RenderingPageRequestHandler. Is there any
  reason why not having a custom handler be the target for an intercept
  request? I used the InterceptData class which is public for now and
  found it working ok. But I'm not sure if I miss something? I'm also
  remembering that it also did not work in wicket 1.4.x to set a custom
  RequestTarget to use for RestartResponseAtInterceptPageException.
 
  Thanks in advance for any help!
  Regards,
  Eike
 
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 
 

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

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

Re: why is there no redirectToIntercept *Target*

[Eike Kettner]

This is what worked for me, maybe this is of use for someone else

  IPageMap pageMap = //get page map (like in
//RestartResponseAtInterceptPageException#redirectToInterceptPage())

  IRequestTarget target = createMySpecialTarget();
  //now just to setup intercept url
  pageMap.redirectToInterceptPage(SomePageIdontCareAbout.class);
  //reset the target ..
  cycle.setRequestTarget(target);
  

regards,
Eike

On [Mon, 27.09.2010 23:36], Eike Kettner wrote:
 Hi!
 I found two methods redirectToInterceptPage(Class) and
 redirectToInterceptPage(Page). I was wondering why there is no
 overloaded method with a IRequestTarget as argument. I'd like to use
 this with a custom request target, that's why i stumbled into this. So I
 like to do something like this:
 
throw new Restart..InterceptException(new MyRequestTarget(..));
 
 
 But maybe there is a better way?
 
 Thank you for your time!
 regards, Eike
 
 -
 To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
 For additional commands, e-mail: users-h...@wicket.apache.org
 

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

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

Re: Wicket 1.5 and OSGi

[Eike Kettner]

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 e...@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 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

Re: Wicket 1.5 and OSGi

[Eike Kettner]

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

Re: Wicket 1.5 and OSGi

[Eike Kettner]

Hi Martin

thanks for your advice. I didn't know the maven-shade-plugin, but I
create on big wicket jar containing all wicket jars like wicket-request,
wicket-xyz with pax:wrap-jar. This also works fine.

Just want to mention that with this change in wicket 1.5, wicket cannot
be used in OSGi environments as easiliy as wicket 1.4. One usually has
to create a wrapped jar somehow. Maybe this is worth to mention on the
migration guide wiki page?


On [Sun, 03.10.2010 13:59], Martin Grigorov wrote:
 Hi Elke,
 
 As I said I don't use OSGi so I can say something that is against OSGi
 rules, but here is what I'd do in your case:
 create a Maven project (named for example 'wicket-bundle'), packaging type
 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one
 bigger .jar out of all required ones (wicket-util, wicket-request, wicket,
 wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
 META-INF/MANIFEST.MF.
 
 Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
 see a reason not to mix them all in one bigger jar for OSGi environments.
 
 On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner n...@eknet.org wrote:
 
  Hi there,
 
  Just a few updates from my side :
 
  I recompiled wicket-trunk with changed a package structure and then my
  application starts happily with wicket 1.5-M21. (by the way, I'm using
  Apache Felix 3.0.2)
 
  I now use the workaround of wrapping the wicket jars I need into one
  jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
  surely not as convienient as before.
 
  Is anybody having these issues with wicket 1.5+OSGi, too? Or even
  better, is anybody not having issues with this combination?
 
  Regards,
  Eike
 
  On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
  
   Hello again,
  
   I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
   found some differences. For example, wicket 1.5 has a new artifact
   wicket-request and comparing the package structure there are some
   changes, which are probably related to my problem:
  
   wicket-1.4.12.jar:
   org.apache
   `-- wicket
   |-- authorization
   |   |-- Action.java
   |   |-- AuthorizationException.java
   |   |-- strategies
   |   |   |-- action
   |   |   |   |-- ActionAuthorizationStrategy.java
   |   |   |   `-- IActionAuthorizer.java
   |   |   |-- CompoundAuthorizationStrategy.java
   |   |   `-- page
   |   |   |-- AbstractPageAuthorizationStrategy.java
   |   |   `-- SimplePageAuthorizationStrategy.java
   |   |-- UnauthorizedActionException.java
   |   `-- UnauthorizedInstantiationException.java
  
  
   wicket-auth-roles-1.4.12.jar:
   org.apache
   `-- wicket
  |-- authentication
  |   |-- AuthenticatedWebApplication.java
  |   |-- AuthenticatedWebSession.java
  |   |-- pages
  |   |   |-- SignInPage_fr.html
  `-- authorization
  `-- strategies
  `-- role
  |-- AbstractRoleAuthorizationStrategy.java
  |   |-- ActionPermissions.java
  `-- Roles.java
  
   This looks good to OSGi as the classes are in disjoint packages in the
   two bundles.
  
  
   This changed in 1.5. There the structure looks like this:
  
   wicket-1.5-M2.1.jar
   org.apache
   `-- wicket
   |-- authentication
   |   |-- IAuthenticationStrategy.java
   |   `-- strategy
   |   |-- DefaultAuthenticationStrategy.java
   |   `-- NoOpAuthenticationStrategy.java
  
   wicket-auth-roles-1.5-M2.1.jar
   org.apache
   `-- wicket
   |-- authentication
   |   |-- AuthenticatedWebApplication.java
   |   |-- AuthenticatedWebSession.java
   |   |-- pages
   |   |   |-- SignInPage.html
   |   |   |-- SignInPage.java
  
  
   The problem is the package org.apache.wicket.authentication now, because
   the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
   classes from this package. The same refers to org.apache.wicket.request,
   which is exported by wicket-request and wicket in 1.5. This leads to
   problems in an OSGi environment. OSGi discourages those scenarios, but
   still offers an solution for this. A (rather old) blog post on osgi.org
   gives some hints on this:
  
   http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
  
   It probably gets to weird loading errors if two classes from the same
   package want to access each others fields or methods with package access,
   but come from a different classloader...
  
   I'm no OSGi expert, so I don't know the right OSGi header that solves
   this. Of course, a real solution would be to only have disjoint packages
   :) I usually put the artifact name in my package name, to avoid any
   clashes (in fact it makes sense in my module structure).
  
  
   Kind regards,
   Eike
  
  
   On [Fri, 01.10.2010 10:05], Martin Grigorov wrote:
Hi Elke,
   
On Fri, Oct 1, 2010 at 8:34 AM, Eike

Re: Wicket 1.5 and OSGi

[Eike Kettner]

Hi Martin

thanks for your advice. I didn't know the maven-shade-plugin, but I
create on big wicket jar containing all wicket jars like wicket-request,
wicket-xyz with pax:wrap-jar. This also works fine.

Just want to mention that with this change in wicket 1.5, wicket cannot
be used in OSGi environments as easiliy as wicket 1.4. One usually has
to create a wrapped jar somehow. Maybe this is worth to mention on the
migration guide wiki page?


On [Sun, 03.10.2010 13:59], Martin Grigorov wrote:
 Hi Elke,
 
 As I said I don't use OSGi so I can say something that is against OSGi
 rules, but here is what I'd do in your case:
 create a Maven project (named for example 'wicket-bundle'), packaging type
 'jar' and empty src/ folder. Then use maven-shade-plugin just to produce one
 bigger .jar out of all required ones (wicket-util, wicket-request, wicket,
 wicket-xyz, ...) and maven-bnd-plugin to add the OSGi stuff in
 META-INF/MANIFEST.MF.
 
 Since Wicket's artefacts are not splitted in -api and -impl .jars I don't
 see a reason not to mix them all in one bigger jar for OSGi environments.
 
 On Sun, Oct 3, 2010 at 1:48 PM, Eike Kettner n...@eknet.org wrote:
 
  Hi there,
 
  Just a few updates from my side :
 
  I recompiled wicket-trunk with changed a package structure and then my
  application starts happily with wicket 1.5-M21. (by the way, I'm using
  Apache Felix 3.0.2)
 
  I now use the workaround of wrapping the wicket jars I need into one
  jar. So it's no big deal to use wicket in OSGi as a wrapped jar, but
  surely not as convienient as before.
 
  Is anybody having these issues with wicket 1.5+OSGi, too? Or even
  better, is anybody not having issues with this combination?
 
  Regards,
  Eike
 
  On [Fri, 01.10.2010 22:12], Eike Kettner wrote:
  
   Hello again,
  
   I just had a look at the wicket packages of 1.4.12 and 1.5-M2.1 and I
   found some differences. For example, wicket 1.5 has a new artifact
   wicket-request and comparing the package structure there are some
   changes, which are probably related to my problem:
  
   wicket-1.4.12.jar:
   org.apache
   `-- wicket
   |-- authorization
   |   |-- Action.java
   |   |-- AuthorizationException.java
   |   |-- strategies
   |   |   |-- action
   |   |   |   |-- ActionAuthorizationStrategy.java
   |   |   |   `-- IActionAuthorizer.java
   |   |   |-- CompoundAuthorizationStrategy.java
   |   |   `-- page
   |   |   |-- AbstractPageAuthorizationStrategy.java
   |   |   `-- SimplePageAuthorizationStrategy.java
   |   |-- UnauthorizedActionException.java
   |   `-- UnauthorizedInstantiationException.java
  
  
   wicket-auth-roles-1.4.12.jar:
   org.apache
   `-- wicket
  |-- authentication
  |   |-- AuthenticatedWebApplication.java
  |   |-- AuthenticatedWebSession.java
  |   |-- pages
  |   |   |-- SignInPage_fr.html
  `-- authorization
  `-- strategies
  `-- role
  |-- AbstractRoleAuthorizationStrategy.java
  |   |-- ActionPermissions.java
  `-- Roles.java
  
   This looks good to OSGi as the classes are in disjoint packages in the
   two bundles.
  
  
   This changed in 1.5. There the structure looks like this:
  
   wicket-1.5-M2.1.jar
   org.apache
   `-- wicket
   |-- authentication
   |   |-- IAuthenticationStrategy.java
   |   `-- strategy
   |   |-- DefaultAuthenticationStrategy.java
   |   `-- NoOpAuthenticationStrategy.java
  
   wicket-auth-roles-1.5-M2.1.jar
   org.apache
   `-- wicket
   |-- authentication
   |   |-- AuthenticatedWebApplication.java
   |   |-- AuthenticatedWebSession.java
   |   |-- pages
   |   |   |-- SignInPage.html
   |   |   |-- SignInPage.java
  
  
   The problem is the package org.apache.wicket.authentication now, because
   the bundle wicket-1.5-M2.1 and wicket-auth-roles-1.5-M2.1 provide
   classes from this package. The same refers to org.apache.wicket.request,
   which is exported by wicket-request and wicket in 1.5. This leads to
   problems in an OSGi environment. OSGi discourages those scenarios, but
   still offers an solution for this. A (rather old) blog post on osgi.org
   gives some hints on this:
  
   http://www.osgi.org/blog/2006/04/misconceptions-about-osgi-headers.html
  
   It probably gets to weird loading errors if two classes from the same
   package want to access each others fields or methods with package access,
   but come from a different classloader...
  
   I'm no OSGi expert, so I don't know the right OSGi header that solves
   this. Of course, a real solution would be to only have disjoint packages
   :) I usually put the artifact name in my package name, to avoid any
   clashes (in fact it makes sense in my module structure).
  
  
   Kind regards,
   Eike
  
  
   On [Fri, 01.10.2010 10:05], Martin Grigorov wrote:
Hi Elke,
   
On Fri, Oct 1, 2010 at 8:34 AM, Eike

Wicket 1.5 and OSGi

[Eike Kettner]

Hello!

I developed a wicket app using OSGi (felix) where different bundles may
contribute content to the wicket bundle. It works really nice using
wicket 1.4.9+. Now I want to upgrade to wicket 1.5 and I run in problems
starting the osgi container.

It complains with the good-known classnotfound-exception for classes
like IClusterable and AuthenticatedWebapplication which all are classes
in packages exported by more than one bundle (for example
org.apache.wicket or org.apache.wicket.authentication). Earlier I found
this was a problem or at least a not-good for OSGi bundles. But as am
using OSGi 4.2 this may work with some special treatment (I'v never
tried this though). Do you think I'm doing something wrong or is this
something on the road for 1.5?

Also, since I have implemented ..UrlCodingStrategy and a custom
RequestTarget I'm studying the new request handling in 1.5 sources to
find out where to plugin my stuff. Are there any documentation besides
source and javadoc for the new concepts? The code is good to read but if
there are some pictures and text available it would be of great help.

Thanks in advance!
Eike


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

Re: Wicket 1.5 and OSGi

[Eike Kettner]

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

thank you for the quick reply. As you said, there shouldn't be any
difference from 1.4 to 1.5 as the packaging remained the same. That
sounds like a problem on my side. I will look into this more this
evening. But to tell you the steps I took: I replaced the wicket-version
in the poms, removed the resulting compile errors by rudely deleting
everything... until I ended up with one application class (extending
AuthenticatedWebApplication). And I maked sure the packages are properly
stated in the Import-Package header. I put the wicket-request and
wicket-util bundles in the container and tried to startup.

Now, one thing I forgot to mention: I use spring (spring-dm) and have my
web application created by the spring osgi extender. This means, my
MyWebApplication class is declared as a spring bean and the spring
extender cannot instantiate the class because it cannot find
org.apache.wicket.authentication.AuthenticatedWebapplication. This is
most detail I can give for now, I will give more later.


 
  Also, since I have implemented ..UrlCodingStrategy and a custom
  RequestTarget I'm studying the new request handling in 1.5 sources to
  find out where to plugin my stuff. Are there any documentation besides
  source and javadoc for the new concepts? The code is good to read but if
  there are some pictures and text available it would be of great help.
 
 Unfortunately there is other documentation yet.
 The idea is:
 with application.getRootRequestMapperAsCompound().add(myMapper) you can add
 a IRequestMapper to the list of mappers.
 When a request comes Wicket asks all registered mappers whether they are
 able to process the request. Mappers with bigger
 org.apache.wicket.request.IRequestMapper.getCompatibilityScore(Request) are
 asked first. So Wicket calls
 org.apache.wicket.request.IRequestMapper.mapRequest(Request) for each mapper
 and if it returns non-null IRequestHandler then this is the handler which
 will be used. In #mapRequest(Request) use have to check request's segments
 (this is similar to httpServletRequest#getPath()) and request's parameters
 (get and post) and decide whether they match to your logic.
 After the handling of the request
 (org.apache.wicket.request.IRequestHandler.respond(IRequestCycle)) Wicket
 will ask the mapper to create a Url which will be used for all urlFor()
 calls, i.e. to create the urls for all links, form action, etc. via
 org.apache.wicket.request.IRequestMapper.mapHandler(IRequestHandler)
 
 There are IRequestMapper implementations for all url coding strategies from
 1.4.x so you can use them as examples.
 Let us know if you need more help.

Thank you! This already helps me alot. Once I get the main idea, the
code is alot easier to read! I will gladly ask questions here when they
come.


Eike

 
  Thanks in advance!
  Eike
 
  martin-g
 
 
  -
  To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
  For additional commands, e-mail: users-h...@wicket.apache.org
 

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

Re: Wicket 1.5 and OSGi

[Eike Kettner]

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

why is there no redirectToIntercept *Target*

[Eike Kettner]

Hi!
I found two methods redirectToInterceptPage(Class) and
redirectToInterceptPage(Page). I was wondering why there is no
overloaded method with a IRequestTarget as argument. I'd like to use
this with a custom request target, that's why i stumbled into this. So I
like to do something like this:

   throw new Restart..InterceptException(new MyRequestTarget(..));


But maybe there is a better way?

Thank you for your time!
regards, Eike

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

Re: AutoCompleteTextField uses wrong encoding?

[Eike Kettner]

Hi Matt

some long time ago I had a similiar problem with AjaxEditableLabel. I 
used tomcat and there you need to configure the connector using 
useBodyEncodingForURI=true to make tomcat use utf8 for encoding ajax 
requests.




Connector port=8009  protocol=AJP/1.3
   redirectPort=8443
   useBodyEncodingForURI=true  /




eike

On 10.05.2010 15:27, Matthias Keller wrote:

Hi

I'm using an autocompletefield and it works fine so far. Except that 
when entering special characters, they don't get encoded correctly.
The query String is correct and sends the special character in encoded 
UTF-8:

GET http://localhost:9080/.../...q=%C3%B6random=...
%C3%B6 is UTF8 for ö

But in:
org.apache.wicket.extensions.ajax.markup.html.autocomplete.AbstractAutoCompleteBehavior.respond(AjaxRequestTarget) 


The following line
final String val = requestCycle.getRequest().getParameter(q);
returns an incorrect string: ö which would be the %C3%B6 in 
ISO-8859-1 (which happens to be my platform encoding)...
Thus the input parameter to my getChoices() call contains strange 
characters in this case...


It appears that the request isn't read out as UTF-8 somehow.. Since I 
don't know the AJAX internals, it's hard to find the culprit for me


I'm using Wicket 1.4.8

Matt

Re: encoding issue on ajax form post (portlet)

[Eike Kettner]

Hi Francisco,

i ran into a similiar problem with ajax and umlauts. in my case i had
a tomcat running the webapp. and for the ajax requests, i had to
configure the tomcat connector with useBodyEncodingForURI=true. then
the content of ajax requests got correctly encoded (using utf8). since
i didn't use porltlets i don't know if this is of any help for you...

eike



On [Wed, 11.03.2009 11:00], Francisco Diaz Trepat - gmail wrote:
 Hi all, I have a wicket project that suddenly required to support portlets.
 I traveled through a lot of (I guess) normal issues from not being familiar
 with portlets technology. But now I am at a  cross rode (quoting  obama) :-)
 
 I have an encoding issue in which, for as much  as I could investigate,
 begins something like this:
 
 1- type  [Hómer] in a textfield
 2- wicket javascript functions to handle post encode the field value to
 H%C3%D3 (or similar)
 3-portlet handles the request and redireccionates it to wicket.
 4-on wicket side H\ufffd is the resulting string.
 5- when ajax returns H?omer is the resulting string.
 I have ISO-8859-1 in the main page (and only page) of my wicket application.
 All the rest is ajax.
 With my application inside the portlet container the UTF-8 is the encoding
 but this doesn't seam to be because I change the encoding for the
 portlet-driver and it didn't work at all.
 Any Ideas?
 f(t)

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

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

problem using pager inside a listview

[Eike Kettner]

hi all,

I'm using a list view that renders 2 or 3 more complex panels. Each of
this panel has (among other panels) a data view with a pager
component.

Now, when I click on one of the page links, i'm getting back to the
page, but the data view shows the same results as before. 

I often used the PagingNavigator component successfully but not inside
a list view. I also tried AjaxPagingNavigator and PagingNavigator,
while AjaxPagingNAvigator threw an exception because it couldn't find
itself and using PagingNavigator yielded in the same result as
mentioned above.

I might miss something... can anyone give me some hints here?

Thank you for your time!
Eike



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

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