Re: Wicket 1.5: request mapper to make all urls absolute

[Igor Vaynberg]

that sounds correct.

essentially this is the same as running the url through
requestcycle.geturlrenderer().renderFullUrl(url) but with a different
prefix

-igor

On Wed, Sep 14, 2011 at 4:54 PM, Bas Gooren  wrote:
> Hi,
>
> Another wicket 1.5 migration question:
> In 1.4 we created a IRequestCodingStrategy decorator which, in encode(),
> translates all urls to be absolute.
> We did this by checking if the url started with "/", and if not, removing
> all occurrences of "../" and "./".
>
> To handle being behind a reverse proxy, the constructor optionally accepted
> a prefix which was always prepended.
>
> In 1.5 it seems this could be implemented as an IRequestMapper which
> decorates the root mapper.
> However, since we are passed a Url instead of a String, and a lot has
> changed surrounding url generation, what is the best way to make all urls
> absolute?
>
> I'm thinking:
> - check Url.isAbsolute()
> - remove segments which are ".." or "."
> - prepend prefix segments
>
> Is this the correct way?
>
> Sebastian
>

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

Wicket 1.5: request mapper to make all urls absolute

[Bas Gooren]

Hi,

Another wicket 1.5 migration question:
In 1.4 we created a IRequestCodingStrategy decorator which, in encode(), 
translates all urls to be absolute.
We did this by checking if the url started with "/", and if not, 
removing all occurrences of "../" and "./".


To handle being behind a reverse proxy, the constructor optionally 
accepted a prefix which was always prepended.


In 1.5 it seems this could be implemented as an IRequestMapper which 
decorates the root mapper.
However, since we are passed a Url instead of a String, and a lot has 
changed surrounding url generation, what is the best way to make all 
urls absolute?


I'm thinking:
- check Url.isAbsolute()
- remove segments which are ".." or "."
- prepend prefix segments

Is this the correct way?

Sebastian

Re: LocaleFirstMapper in wicket 1.5

[Bas Gooren]

Ok, done: https://issues.apache.org/jira/browse/WICKET-4055

Sebastian

Op 14-9-2011 21:32, schreef Igor Vaynberg:

yes, good catch Bas. please open a jira ticket.

-igor

On Wed, Sep 14, 2011 at 12:12 PM, Bas Gooren  wrote:

Hi all,

I'm in the process of migrating our internal code library to 1.5.
So far the main feeling is: wow, most things became a lot easier and
cleaner.
In other words: thanks wicket team!

Now on to my question: If I look at the LocaleFirstMapper [1] in
wicket-examples, I see that in #getCompatibilityScore() it forwards the call
to the chain.
For as far as I can see this would not work, since most mappers (if not all)
have their own getCompatibilityScore() based on the amount of matching
segments from the start of the url.

So in other words: by not stripping the locale from the request url before
forwarding the call to the chain, will this not result in a 0 score for all
mappers?

Sebastian

[1]
http://grepcode.com/file_/repo1.maven.org/maven2/org.apache.wicket/wicket-examples/1.5-M3/org/apache/wicket/examples/requestmapper/LocaleFirstMapper.java/?v=source


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

Re: LocaleFirstMapper in wicket 1.5

[Igor Vaynberg]

yes, good catch Bas. please open a jira ticket.

-igor

On Wed, Sep 14, 2011 at 12:12 PM, Bas Gooren  wrote:
> Hi all,
>
> I'm in the process of migrating our internal code library to 1.5.
> So far the main feeling is: wow, most things became a lot easier and
> cleaner.
> In other words: thanks wicket team!
>
> Now on to my question: If I look at the LocaleFirstMapper [1] in
> wicket-examples, I see that in #getCompatibilityScore() it forwards the call
> to the chain.
> For as far as I can see this would not work, since most mappers (if not all)
> have their own getCompatibilityScore() based on the amount of matching
> segments from the start of the url.
>
> So in other words: by not stripping the locale from the request url before
> forwarding the call to the chain, will this not result in a 0 score for all
> mappers?
>
> Sebastian
>
> [1]
> http://grepcode.com/file_/repo1.maven.org/maven2/org.apache.wicket/wicket-examples/1.5-M3/org/apache/wicket/examples/requestmapper/LocaleFirstMapper.java/?v=source
>

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

LocaleFirstMapper in wicket 1.5

[Bas Gooren]

Hi all,

I'm in the process of migrating our internal code library to 1.5.
So far the main feeling is: wow, most things became a lot easier and 
cleaner.

In other words: thanks wicket team!

Now on to my question: If I look at the LocaleFirstMapper [1] in 
wicket-examples, I see that in #getCompatibilityScore() it forwards the 
call to the chain.
For as far as I can see this would not work, since most mappers (if not 
all) have their own getCompatibilityScore() based on the amount of 
matching segments from the start of the url.


So in other words: by not stripping the locale from the request url 
before forwarding the call to the chain, will this not result in a 0 
score for all mappers?


Sebastian

[1] 
http://grepcode.com/file_/repo1.maven.org/maven2/org.apache.wicket/wicket-examples/1.5-M3/org/apache/wicket/examples/requestmapper/LocaleFirstMapper.java/?v=source 

Re: Apache Wicket releases Wicket 1.5

[gilbertoca]

Martin Grigorov-4 wrote:
> 
> http://repo1.maven.org/maven2/org/apache/wicket/wicket-extensions/1.5.0/
> http://repo1.maven.org/maven2/org/wicketstuff/wicketstuff-jasperreports/1.5-RC7/
> 
> WicketStuff 1.5.0 will be released soon. But since Wicket 1.5.0 is
> actually RC7 without code changes they are fully compatible.
> 

Thanks, Martin!
For now we are using the wicketstuff-jasperreports 1.5-RC7 and application
is working.
But all of our integration tests fails with the following exception:


> testLoginFormWrongAuthentication(br.gov.to.secad.seg.view.LoginPageTest) 
> Time elapsed: 0.008 sec  <<< ERROR!
> java.lang.IllegalStateException: Application name can only be set once.
>   at org.apache.wicket.Application.setName(Application.java:846)
>   at
> org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:291)
>   at
> org.apache.wicket.util.tester.BaseWicketTester.(BaseWicketTester.java:241)
>   at
> org.apache.wicket.util.tester.WicketTester.(WicketTester.java:192)
>   at br.gov.to.secad.seg.view.LoginPageTest.setUp(LoginPageTest.java:32)
>   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>   at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
>   at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
>   at java.lang.reflect.Method.invoke(Method.java:597)
>   at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:44)
> 

And every test has the following class header:



> @RunWith(SpringJUnit4ClassRunner.class)
> @ContextConfiguration(locations =
> {"classpath:applicationContext-dataSource.xml",
> "classpath:applicationContext-jpa.xml"})
> @TransactionConfiguration(transactionManager = "transactionManager",
> defaultRollback = false)
> public class LoginPageTest {
> 
> private WicketTester tester;
> @Autowired
> private ApplicationContext ctx;
> @Autowired
> private SEGApplication myWebApplication;
> 
> @Before
> public void setUp() {
> tester = new WicketTester(myWebApplication);
> }
> 
> @Test
> @Transactional
> @Rollback(true)
> public void testRenderMyPage() {
> tester.startPage(LoginPage.class);
> tester.assertRenderedPage(LoginPage.class);
> //tester.assertComponent("login", LoginComponent.class);
> }
> 

I've search in the google and wicket user list, but didn't find any
information about this problem.
Any tip here?

Regards,

Gilberto

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Apache-Wicket-releases-Wicket-1-5-tp3797412p3813838.html
Sent from the Users forum mailing list archive at Nabble.com.

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

Re: Wicket 1.5: AjaxRequestTarget.appendJavaScript() - multiple javascript evaluations

[Igor Vaynberg]

instead of using ajaxrequettarget.appendjavascript() use
iheadercontributor#renderOnDomReadyJavascript(String), these
contributions are filtered and only unique ones are executed.

the ordering is a different problem. if you need such ordering instead
of using headercontributor let your components implement some other
interface and let the parents visit children that implement that
interface so it can collect and sort the javascript however it sees
fit before writing it out.

-igor


On Wed, Sep 14, 2011 at 6:10 AM, armandoxxx  wrote:
> Hi guys
>
> I have a question about how to avoid multiple evaluations of same
> javascripts in AjaxRequestTarget.appendJavaScript().
> I have a lots of components that append javascript to AjaxRequestTarget.
> Some of these javascript strings are same and some are different. So what
> I'm trying to figure out is how to avoid adding the same javascript to
> AjaxRequestTarget.
> Another thing I'm trying to figure out is how to add these strings in
> appropriate order.
>
> use case:
> - ajax button is clicked
> - an event is created (AjaxRequestTarget is set as parameter) and send to
> components
> - Component A gets an event .. adds itself to AjaxRequestTarget and appends
> some JS ("resizeLayout()");
> - Component B gets an event .. adds itself to AjaxRequestTarget and appends
> some JS ("resizeLayout()", "initScrollbar('ComponentB')");
> - Component C gets an event .. adds itself to AjaxRequestTarget and appends
> some JS ("resizeLayout()", "initScrollbar('ComponentC')");
>
>
> Kind regards
> Armando
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-AjaxRequestTarget-appendJavaScript-multiple-javascript-evaluations-tp3812785p3812785.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> 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: stateless page + click on stateless link = stateful page

[Martin Grigorov]

The issue is WICKET-3991.

On Wed, Sep 14, 2011 at 6:00 PM, Bertrand Guay-Paquet
 wrote:
> Thank you for your answers.
>
> Indeed, "setResponsePage(getPage());" will also result in a stateful page.
>
> I did the following to workaround the issue for now since the panel
> containing the stateless link appears on all pages of my site:
>    Page page = getPage();
>    if (page.isStateless())
>        // Creates a new stateless page instance
>        setResponsePage(page.getClass());
>    else
>        setResponsePage(page);
>
> Martin, is WICKET-4046 
> the issue you mentioned for this?
>
> On 14/09/2011 3:50 AM, Martin Grigorov wrote:
>>
>> Indeed this change was reverted after RC7.
>> Now only "setResponsePage(new StatelessPage());" is automatically
>> promoted to stateful.
>>
>> We tried to make it more general but apparently it was wrong...
>>
>> On Wed, Sep 14, 2011 at 9:06 AM, Mike Mander  wrote:
>>>
>>> Am 13.09.2011 23:59, schrieb Bertrand Guay-Paquet:

 This is fixed in trunk. The fix will be available in 1.5.1
>>>
>>> Martin wrote to me in a former post

 This is fixed in trunk. The fix will be available in 1.5.1
>>>
>>> Maybe we should try it again with 1.5.1
>>>
>>> -
>>> 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
>
>



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

Re: how to get HttpServletRequest in wicket 1.5

[Igor Vaynberg]

and by complain he means a compile error...

-igor


On Wed, Sep 14, 2011 at 4:37 AM, Martin Grigorov  wrote:
> Ah, yes.
> A child class which overrides the method and is "protected" will
> complain that visibility is reduced ...
> Have to wait for Wicket.next.
>
> On Wed, Sep 14, 2011 at 2:30 PM, Peter Ertl  wrote:
>> @Martin:
>>
>> yeah, switching from protected to public should at most yield a warning in 
>> an overloaded class. Igor didn't like it. Maybe my English confused him and 
>> he thought about going from public to protected?!
>>
>> Would be great if we could change this in 1.5.
>>
>> What you think?
>>
>>
>>
>> Am 14.09.2011 um 13:17 schrieb Martin Grigorov:
>>
>>> On Wed, Sep 14, 2011 at 2:07 PM, Peter Ertl  wrote:

 Am 14.09.2011 um 09:32 schrieb nhsoft.yhw:

> inputStream = 
> packageResource.getCacheableResourceStream().getInputStream();

 I think this needs some clarification...

 PackageResource has these methods for getting a stream:

  (1)  protected IResourceStream getResourceStream()

 and

  (2) public IResourceStream getCacheableResourceStream()

 the intention is:

 -  (1) locates the default resource without taking any client preferences 
 into account.

 -  (2) is there to get a client-specific resoure stream that is supposed 
 to be immutable for the lifetime of the application and should be cached.

 the sooner (1) locates the resource stream based on

 - anchor class
 - name
 - locale
 - style
 - variation

 as specified in the constructor(!) of PackageResource. So for example when 
 using CssResourceReference (which is a descendant of 
 PackageResourceReference) like that in your page:

  private static final PackageResourceReference CSS = new 
 CssResourceReference(MyPage.class, "mycss", Locale.ENGLISH, "style1", 
 "variation1");

 these parameters will be applied to PackageResource when resolving the 
 reference and yield:

 - anchor class = MyPage.class
 - name = "mycss"
 - locale = Locale.ENGLISH
 - style = "style1"
 - variation = "variation1"

 and getResourceStream (1) will locate the resource based on the above 
 criteria.

 In contrary getCacheableResourceStream (2) will override the values for 
 locale and style with the values of the current session.

 - anchor class = MyPage.class
 - name = "mycss"
 - Session.getLocale() if not empty, otherwise Locale.ENGLISH
 - Session.getStyle() if not empty, otherwise "style1"
 - variation = "variation1"

 So (1) returns the default stream and (2) returns the stream fitting the 
 client's preferences.

 Unfortunately I realized it too late that (1) which was 'public' in 1.4 is 
 now 'protected' in 1.5. It's too late to change this without breaking the 
 API. This can change in 1.6 to 'public' again unless things change 
 completely (don't think so :-)
>>> I think 'protected' -> 'public' is not a problem.
>>> The opposite ('public' -> 'protected') is not allowed in 1.5.x.

 So In case you need to access (1) but miss the 'public' I can suggest the 
 following workaround / kludge.

 public class MyPackageResource extends PackageResource
 {
        public MyPackageResource(Class scope, String name, Locale 
 locale, String style,
                String variation)
        {
                super(scope, name, locale, style, variation);
        }

        // change access to public here
        public IResourceStream getResourceStream()
        {
                return super.getResourceStream();
        }
 }

 If you only need to open a stream of a package located file use this 
 instead - no need for PackageResource in that case at all:

  InputStream is = MyPage.class.getResourceAsStream("mycss.css")


 Cheers
 Peter
 -
 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
>>>
>>
>>
>> -
>> 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: user

Re: stateless page + click on stateless link = stateful page

[Bertrand Guay-Paquet]

Thank you for your answers.

Indeed, "setResponsePage(getPage());" will also result in a stateful page.

I did the following to workaround the issue for now since the panel 
containing the stateless link appears on all pages of my site:

Page page = getPage();
if (page.isStateless())
// Creates a new stateless page instance
setResponsePage(page.getClass());
else
setResponsePage(page);

Martin, is WICKET-4046 
 the issue you 
mentioned for this?


On 14/09/2011 3:50 AM, Martin Grigorov wrote:

Indeed this change was reverted after RC7.
Now only "setResponsePage(new StatelessPage());" is automatically
promoted to stateful.

We tried to make it more general but apparently it was wrong...

On Wed, Sep 14, 2011 at 9:06 AM, Mike Mander  wrote:

Am 13.09.2011 23:59, schrieb Bertrand Guay-Paquet:

This is fixed in trunk. The fix will be available in 1.5.1

Martin wrote to me in a former post

This is fixed in trunk. The fix will be available in 1.5.1

Maybe we should try it again with 1.5.1

-
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: java.util.ConcurrentModificationException in Component.internalPrepareForRender

[Thomas Götz]

Actually not that easy, as there are 8 feedbacks in 
getRequestCycle().getMetaData(FEEDBACK_LIST) (Component, line 2188). But I 
noticed that one of them (which causes the exception) is a border (extends 
Border implements IFeedback) …

I will try what I can do to isolate this further.

   -Tom


On 14.09.2011, 16:48 Martin Grigorov wrote:

> Can you reproduce it with a quickstart ?
> 
> On Wed, Sep 14, 2011 at 5:44 PM, Thomas Götz  wrote:
>> Hi,
>> 
>> I am currently migrating an application to Wicket 1.5.0 (from Wicket 1.4.17) 
>> and experience the following error:
>> 
>> ERROR - DefaultExceptionMapper - Unexpected error occurred
>> java.util.ConcurrentModificationException
>>at 
>> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
>>at java.util.AbstractList$Itr.next(AbstractList.java:343)
>>at 
>> org.apache.wicket.Component.internalPrepareForRender(Component.java:2191)
>>at org.apache.wicket.Page.internalPrepareForRender(Page.java:280)
>>at org.apache.wicket.Component.render(Component.java:2265)
>>at org.apache.wicket.Page.renderPage(Page.java:1035)
>>at 
>> org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:105)
>>at 
>> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:224)
>>at 
>> org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:147)
>>at 
>> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:719)
>>at 
>> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:63)
>>at 
>> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:210)
>>at 
>> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:253)
>>at 
>> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
>>at 
>> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
>>at 
>> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
>>at 
>> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
>>at 
>> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>>at 
>> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>>at 
>> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>>at 
>> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
>>at 
>> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>at org.mortbay.jetty.Server.handle(Server.java:326)
>>at 
>> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>>at 
>> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
>>at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>>at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>>at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>>at 
>> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
>>at 
>> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
>> 
>> 
>> 
>> The error always occurs when requesting the first page after having started 
>> Jetty. Anyone has seen this already?!
>> 
>> Cheers,
>>   -Tom
>> 
>> 
>> -
>> 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
> 


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

Re: java.util.ConcurrentModificationException in Component.internalPrepareForRender

[Martin Grigorov]

Can you reproduce it with a quickstart ?

On Wed, Sep 14, 2011 at 5:44 PM, Thomas Götz  wrote:
> Hi,
>
> I am currently migrating an application to Wicket 1.5.0 (from Wicket 1.4.17) 
> and experience the following error:
>
> ERROR - DefaultExceptionMapper     - Unexpected error occurred
> java.util.ConcurrentModificationException
>        at 
> java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
>        at java.util.AbstractList$Itr.next(AbstractList.java:343)
>        at 
> org.apache.wicket.Component.internalPrepareForRender(Component.java:2191)
>        at org.apache.wicket.Page.internalPrepareForRender(Page.java:280)
>        at org.apache.wicket.Component.render(Component.java:2265)
>        at org.apache.wicket.Page.renderPage(Page.java:1035)
>        at 
> org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:105)
>        at 
> org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:224)
>        at 
> org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:147)
>        at 
> org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:719)
>        at 
> org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:63)
>        at 
> org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:210)
>        at 
> org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:253)
>        at 
> org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
>        at 
> org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
>        at 
> org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
>        at 
> org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
>        at 
> org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>        at 
> org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>        at 
> org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
>        at 
> org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
>        at 
> org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>        at org.mortbay.jetty.Server.handle(Server.java:326)
>        at 
> org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>        at 
> org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
>        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>        at 
> org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
>        at 
> org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
>
>
>
> The error always occurs when requesting the first page after having started 
> Jetty. Anyone has seen this already?!
>
> Cheers,
>   -Tom
>
>
> -
> 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

java.util.ConcurrentModificationException in Component.internalPrepareForRender

[Thomas Götz]

Hi,

I am currently migrating an application to Wicket 1.5.0 (from Wicket 1.4.17) 
and experience the following error:

ERROR - DefaultExceptionMapper - Unexpected error occurred
java.util.ConcurrentModificationException
at 
java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at 
org.apache.wicket.Component.internalPrepareForRender(Component.java:2191)
at org.apache.wicket.Page.internalPrepareForRender(Page.java:280)
at org.apache.wicket.Component.render(Component.java:2265)
at org.apache.wicket.Page.renderPage(Page.java:1035)
at 
org.apache.wicket.request.handler.render.WebPageRenderer.renderPage(WebPageRenderer.java:105)
at 
org.apache.wicket.request.handler.render.WebPageRenderer.respond(WebPageRenderer.java:224)
at 
org.apache.wicket.request.handler.RenderPageRequestHandler.respond(RenderPageRequestHandler.java:147)
at 
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(RequestCycle.java:719)
at 
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerStack.java:63)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCycle.java:210)
at 
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:253)
at 
org.apache.wicket.protocol.http.WicketFilter.processRequest(WicketFilter.java:162)
at 
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:218)
at 
org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1157)
at 
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:388)
at 
org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at 
org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at 
org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:440)
at 
org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at 
org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at 
org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:926)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at 
org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at 
org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)



The error always occurs when requesting the first page after having started 
Jetty. Anyone has seen this already?!

Cheers,
   -Tom


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

Re: Successor to StyleSheetReference in 1.5

[Ian Marshall]

Thanks Martin.

I shall try

  CssResourceReference rrefCSS = new CssResourceReference(
   ResourcesLocator.class, "style.css");
  ResourceLink rlnkCSS =
   new ResourceLink("stylesheet", rrefCSS);
  add(rlnkCSS);

in order to keep my HTML mark-up unchanged. If this does not work, I shall
look into overriding my page's renderHead(...) method (and removing the
relevant part of my HTML mark-up?) as shown in the /Migration guide/.

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Successor-to-StyleSheetReference-in-1-5-tp3812796p3812963.html
Sent from the Users forum mailing list archive at Nabble.com.

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

Re: Successor to StyleSheetReference in 1.5

[Martin Grigorov]

https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-RemovedHeaderContributorandfriends.

On Wed, Sep 14, 2011 at 4:19 PM, Martin Grigorov  wrote:
> https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-HeaderContribution
>
> On Wed, Sep 14, 2011 at 4:14 PM, Ian Marshall  
> wrote:
>> Hello there,
>>
>> Most of my web pages descend from my class PageBase, which itself descends
>> from WebPage.
>>
>> In 1.4, these pages accessed my CSS file (in the same folder as my file
>> ResourcesLocator.java) by using the code given below.
>>
>> I have looked, but cannot see how to do this in 1.5 (where
>> StyleSheetReference disappears).
>>
>> I would appreciate any help.
>>
>> Regards,
>>
>> Ian
>>
>>
>> HTML
>> 
>>  ...
>>  
>>    
>>      > href="style.css"/>
>>      ...
>>    
>>    ...
>>  
>>
>>
>> Java (in a PageBase constructor)
>> 
>>  add(new StyleSheetReference("stylesheet", ResourcesLocator.class,
>> "style.css"));
>>
>> --
>> View this message in context: 
>> http://apache-wicket.1842946.n4.nabble.com/Successor-to-StyleSheetReference-in-1-5-tp3812796p3812796.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> 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
>



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

Re: Successor to StyleSheetReference in 1.5

[Martin Grigorov]

https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+1.5#MigrationtoWicket1.5-HeaderContribution

On Wed, Sep 14, 2011 at 4:14 PM, Ian Marshall  wrote:
> Hello there,
>
> Most of my web pages descend from my class PageBase, which itself descends
> from WebPage.
>
> In 1.4, these pages accessed my CSS file (in the same folder as my file
> ResourcesLocator.java) by using the code given below.
>
> I have looked, but cannot see how to do this in 1.5 (where
> StyleSheetReference disappears).
>
> I would appreciate any help.
>
> Regards,
>
> Ian
>
>
> HTML
> 
>  ...
>  
>    
>       href="style.css"/>
>      ...
>    
>    ...
>  
>
>
> Java (in a PageBase constructor)
> 
>  add(new StyleSheetReference("stylesheet", ResourcesLocator.class,
> "style.css"));
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/Successor-to-StyleSheetReference-in-1-5-tp3812796p3812796.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> 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

Successor to StyleSheetReference in 1.5

[Ian Marshall]

Hello there,

Most of my web pages descend from my class PageBase, which itself descends
from WebPage.

In 1.4, these pages accessed my CSS file (in the same folder as my file
ResourcesLocator.java) by using the code given below.

I have looked, but cannot see how to do this in 1.5 (where
StyleSheetReference disappears).

I would appreciate any help.

Regards,

Ian


HTML

  ...
  

  
  ...

...
  


Java (in a PageBase constructor)

  add(new StyleSheetReference("stylesheet", ResourcesLocator.class,
"style.css"));

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Successor-to-StyleSheetReference-in-1-5-tp3812796p3812796.html
Sent from the Users forum mailing list archive at Nabble.com.

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

Wicket 1.5: AjaxRequestTarget.appendJavaScript() - multiple javascript evaluations

[armandoxxx]

Hi guys 

I have a question about how to avoid multiple evaluations of same
javascripts in AjaxRequestTarget.appendJavaScript().
I have a lots of components that append javascript to AjaxRequestTarget.
Some of these javascript strings are same and some are different. So what
I'm trying to figure out is how to avoid adding the same javascript to
AjaxRequestTarget.
Another thing I'm trying to figure out is how to add these strings in
appropriate order.

use case: 
- ajax button is clicked
- an event is created (AjaxRequestTarget is set as parameter) and send to
components
- Component A gets an event .. adds itself to AjaxRequestTarget and appends
some JS ("resizeLayout()");
- Component B gets an event .. adds itself to AjaxRequestTarget and appends
some JS ("resizeLayout()", "initScrollbar('ComponentB')");
- Component C gets an event .. adds itself to AjaxRequestTarget and appends
some JS ("resizeLayout()", "initScrollbar('ComponentC')");


Kind regards
Armando

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Wicket-1-5-AjaxRequestTarget-appendJavaScript-multiple-javascript-evaluations-tp3812785p3812785.html
Sent from the Users forum mailing list archive at Nabble.com.

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

Re: Getting Error for custom PageExpiredErrorPage

[Peter Karich]

 Hi Andrea,

sorry, I forgot to mention that I tried it with 1.4.18

I'm using mount(new MixedParamUrlCodingStrategy("slide",
ChooseJetslideOrJetwick.class, new String[]{}));
because I'm using the same strategy for the page where this problem
occurs (the page which has the path urltrends:urls:9:urlLink in my example)

and yes, issue 3992 really sounds like my issue. Thanks for the pointer!
Do you know a workaround?

Regards,
Peter.

> Hi,
>
> which version are you using? Are mounting an UrlCodingStrategy class?
> Maybe your problem is related with this issue
>
> https://issues.apache.org/jira/browse/WICKET-3992
>>   Hi,
>>
>> I'm getting this error in the logs:
>> ERROR org.apache.wicket.RequestCycle - unable to find component with
>> path urltrends:urls:9:urlLink on stateless page [Page class =
>> de.jetwick.ui.slide.ChooseJetslideOrJetwick, id = 0, version = 0] it
>> could be that the component is inside a repeater make your component
>> return false in getStatelessHint()
>>
>> Here is how I set the custom page in my init method:
>> getApplicationSettings().setPageExpiredErrorPage(ChooseJetslideOrJetwick.class);
>>
>>
>> Why has wicket a problem when there is a session timeout on a stateful
>> page and then 'redirecting' to my expired page? How should I implement
>> my custom PageExpiredErrorPage ... I only have 2 BookmarkablePageLink:s
>> in it!?
>>
>> I wasn't able to reproduce this message when browsing on my site
>> jetsli.de/tweets ... probably because it is only a google bot request
>> ** ?
>> How can I fix this?
>>
>> Regards,
>> Peter.
>>
>> **
>> http://apache-wicket.1842946.n4.nabble.com/Page-expired-stateless-page-td1891032.html
>>
>>
>> -
>> 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
>
>


-- 
http://jetsli.de news reader for geeks


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

Re: Getting Error for custom PageExpiredErrorPage

[Andrea Del Bene]

Hi,

which version are you using? Are mounting an UrlCodingStrategy class? 
Maybe your problem is related with this issue


https://issues.apache.org/jira/browse/WICKET-3992

  Hi,

I'm getting this error in the logs:
ERROR org.apache.wicket.RequestCycle - unable to find component with
path urltrends:urls:9:urlLink on stateless page [Page class =
de.jetwick.ui.slide.ChooseJetslideOrJetwick, id = 0, version = 0] it
could be that the component is inside a repeater make your component
return false in getStatelessHint()

Here is how I set the custom page in my init method:
getApplicationSettings().setPageExpiredErrorPage(ChooseJetslideOrJetwick.class);

Why has wicket a problem when there is a session timeout on a stateful
page and then 'redirecting' to my expired page? How should I implement
my custom PageExpiredErrorPage ... I only have 2 BookmarkablePageLink:s
in it!?

I wasn't able to reproduce this message when browsing on my site
jetsli.de/tweets ... probably because it is only a google bot request ** ?
How can I fix this?

Regards,
Peter.

**
http://apache-wicket.1842946.n4.nabble.com/Page-expired-stateless-page-td1891032.html

-
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: how to get HttpServletRequest in wicket 1.5

[Martin Grigorov]

Ah, yes.
A child class which overrides the method and is "protected" will
complain that visibility is reduced ...
Have to wait for Wicket.next.

On Wed, Sep 14, 2011 at 2:30 PM, Peter Ertl  wrote:
> @Martin:
>
> yeah, switching from protected to public should at most yield a warning in an 
> overloaded class. Igor didn't like it. Maybe my English confused him and he 
> thought about going from public to protected?!
>
> Would be great if we could change this in 1.5.
>
> What you think?
>
>
>
> Am 14.09.2011 um 13:17 schrieb Martin Grigorov:
>
>> On Wed, Sep 14, 2011 at 2:07 PM, Peter Ertl  wrote:
>>>
>>> Am 14.09.2011 um 09:32 schrieb nhsoft.yhw:
>>>
 inputStream = 
 packageResource.getCacheableResourceStream().getInputStream();
>>>
>>> I think this needs some clarification...
>>>
>>> PackageResource has these methods for getting a stream:
>>>
>>>  (1)  protected IResourceStream getResourceStream()
>>>
>>> and
>>>
>>>  (2) public IResourceStream getCacheableResourceStream()
>>>
>>> the intention is:
>>>
>>> -  (1) locates the default resource without taking any client preferences 
>>> into account.
>>>
>>> -  (2) is there to get a client-specific resoure stream that is supposed to 
>>> be immutable for the lifetime of the application and should be cached.
>>>
>>> the sooner (1) locates the resource stream based on
>>>
>>> - anchor class
>>> - name
>>> - locale
>>> - style
>>> - variation
>>>
>>> as specified in the constructor(!) of PackageResource. So for example when 
>>> using CssResourceReference (which is a descendant of 
>>> PackageResourceReference) like that in your page:
>>>
>>>  private static final PackageResourceReference CSS = new 
>>> CssResourceReference(MyPage.class, "mycss", Locale.ENGLISH, "style1", 
>>> "variation1");
>>>
>>> these parameters will be applied to PackageResource when resolving the 
>>> reference and yield:
>>>
>>> - anchor class = MyPage.class
>>> - name = "mycss"
>>> - locale = Locale.ENGLISH
>>> - style = "style1"
>>> - variation = "variation1"
>>>
>>> and getResourceStream (1) will locate the resource based on the above 
>>> criteria.
>>>
>>> In contrary getCacheableResourceStream (2) will override the values for 
>>> locale and style with the values of the current session.
>>>
>>> - anchor class = MyPage.class
>>> - name = "mycss"
>>> - Session.getLocale() if not empty, otherwise Locale.ENGLISH
>>> - Session.getStyle() if not empty, otherwise "style1"
>>> - variation = "variation1"
>>>
>>> So (1) returns the default stream and (2) returns the stream fitting the 
>>> client's preferences.
>>>
>>> Unfortunately I realized it too late that (1) which was 'public' in 1.4 is 
>>> now 'protected' in 1.5. It's too late to change this without breaking the 
>>> API. This can change in 1.6 to 'public' again unless things change 
>>> completely (don't think so :-)
>> I think 'protected' -> 'public' is not a problem.
>> The opposite ('public' -> 'protected') is not allowed in 1.5.x.
>>>
>>> So In case you need to access (1) but miss the 'public' I can suggest the 
>>> following workaround / kludge.
>>>
>>> public class MyPackageResource extends PackageResource
>>> {
>>>        public MyPackageResource(Class scope, String name, Locale locale, 
>>> String style,
>>>                String variation)
>>>        {
>>>                super(scope, name, locale, style, variation);
>>>        }
>>>
>>>        // change access to public here
>>>        public IResourceStream getResourceStream()
>>>        {
>>>                return super.getResourceStream();
>>>        }
>>> }
>>>
>>> If you only need to open a stream of a package located file use this 
>>> instead - no need for PackageResource in that case at all:
>>>
>>>  InputStream is = MyPage.class.getResourceAsStream("mycss.css")
>>>
>>>
>>> Cheers
>>> Peter
>>> -
>>> 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
>>
>
>
> -
> 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

Re: how to get HttpServletRequest in wicket 1.5

[Peter Ertl]

@Martin:

yeah, switching from protected to public should at most yield a warning in an 
overloaded class. Igor didn't like it. Maybe my English confused him and he 
thought about going from public to protected?!

Would be great if we could change this in 1.5.

What you think?



Am 14.09.2011 um 13:17 schrieb Martin Grigorov:

> On Wed, Sep 14, 2011 at 2:07 PM, Peter Ertl  wrote:
>> 
>> Am 14.09.2011 um 09:32 schrieb nhsoft.yhw:
>> 
>>> inputStream = packageResource.getCacheableResourceStream().getInputStream();
>> 
>> I think this needs some clarification...
>> 
>> PackageResource has these methods for getting a stream:
>> 
>>  (1)  protected IResourceStream getResourceStream()
>> 
>> and
>> 
>>  (2) public IResourceStream getCacheableResourceStream()
>> 
>> the intention is:
>> 
>> -  (1) locates the default resource without taking any client preferences 
>> into account.
>> 
>> -  (2) is there to get a client-specific resoure stream that is supposed to 
>> be immutable for the lifetime of the application and should be cached.
>> 
>> the sooner (1) locates the resource stream based on
>> 
>> - anchor class
>> - name
>> - locale
>> - style
>> - variation
>> 
>> as specified in the constructor(!) of PackageResource. So for example when 
>> using CssResourceReference (which is a descendant of 
>> PackageResourceReference) like that in your page:
>> 
>>  private static final PackageResourceReference CSS = new 
>> CssResourceReference(MyPage.class, "mycss", Locale.ENGLISH, "style1", 
>> "variation1");
>> 
>> these parameters will be applied to PackageResource when resolving the 
>> reference and yield:
>> 
>> - anchor class = MyPage.class
>> - name = "mycss"
>> - locale = Locale.ENGLISH
>> - style = "style1"
>> - variation = "variation1"
>> 
>> and getResourceStream (1) will locate the resource based on the above 
>> criteria.
>> 
>> In contrary getCacheableResourceStream (2) will override the values for 
>> locale and style with the values of the current session.
>> 
>> - anchor class = MyPage.class
>> - name = "mycss"
>> - Session.getLocale() if not empty, otherwise Locale.ENGLISH
>> - Session.getStyle() if not empty, otherwise "style1"
>> - variation = "variation1"
>> 
>> So (1) returns the default stream and (2) returns the stream fitting the 
>> client's preferences.
>> 
>> Unfortunately I realized it too late that (1) which was 'public' in 1.4 is 
>> now 'protected' in 1.5. It's too late to change this without breaking the 
>> API. This can change in 1.6 to 'public' again unless things change 
>> completely (don't think so :-)
> I think 'protected' -> 'public' is not a problem.
> The opposite ('public' -> 'protected') is not allowed in 1.5.x.
>> 
>> So In case you need to access (1) but miss the 'public' I can suggest the 
>> following workaround / kludge.
>> 
>> public class MyPackageResource extends PackageResource
>> {
>>public MyPackageResource(Class scope, String name, Locale locale, 
>> String style,
>>String variation)
>>{
>>super(scope, name, locale, style, variation);
>>}
>> 
>>// change access to public here
>>public IResourceStream getResourceStream()
>>{
>>return super.getResourceStream();
>>}
>> }
>> 
>> If you only need to open a stream of a package located file use this instead 
>> - no need for PackageResource in that case at all:
>> 
>>  InputStream is = MyPage.class.getResourceAsStream("mycss.css")
>> 
>> 
>> Cheers
>> Peter
>> -
>> 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
> 


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

Re: how to get HttpServletRequest in wicket 1.5

[Martin Grigorov]

On Wed, Sep 14, 2011 at 2:07 PM, Peter Ertl  wrote:
>
> Am 14.09.2011 um 09:32 schrieb nhsoft.yhw:
>
>> inputStream = packageResource.getCacheableResourceStream().getInputStream();
>
> I think this needs some clarification...
>
> PackageResource has these methods for getting a stream:
>
>  (1)  protected IResourceStream getResourceStream()
>
> and
>
>  (2) public IResourceStream getCacheableResourceStream()
>
> the intention is:
>
> -  (1) locates the default resource without taking any client preferences 
> into account.
>
> -  (2) is there to get a client-specific resoure stream that is supposed to 
> be immutable for the lifetime of the application and should be cached.
>
> the sooner (1) locates the resource stream based on
>
> - anchor class
> - name
> - locale
> - style
> - variation
>
> as specified in the constructor(!) of PackageResource. So for example when 
> using CssResourceReference (which is a descendant of 
> PackageResourceReference) like that in your page:
>
>  private static final PackageResourceReference CSS = new 
> CssResourceReference(MyPage.class, "mycss", Locale.ENGLISH, "style1", 
> "variation1");
>
> these parameters will be applied to PackageResource when resolving the 
> reference and yield:
>
> - anchor class = MyPage.class
> - name = "mycss"
> - locale = Locale.ENGLISH
> - style = "style1"
> - variation = "variation1"
>
> and getResourceStream (1) will locate the resource based on the above 
> criteria.
>
> In contrary getCacheableResourceStream (2) will override the values for 
> locale and style with the values of the current session.
>
> - anchor class = MyPage.class
> - name = "mycss"
> - Session.getLocale() if not empty, otherwise Locale.ENGLISH
> - Session.getStyle() if not empty, otherwise "style1"
> - variation = "variation1"
>
> So (1) returns the default stream and (2) returns the stream fitting the 
> client's preferences.
>
> Unfortunately I realized it too late that (1) which was 'public' in 1.4 is 
> now 'protected' in 1.5. It's too late to change this without breaking the 
> API. This can change in 1.6 to 'public' again unless things change completely 
> (don't think so :-)
I think 'protected' -> 'public' is not a problem.
The opposite ('public' -> 'protected') is not allowed in 1.5.x.
>
> So In case you need to access (1) but miss the 'public' I can suggest the 
> following workaround / kludge.
>
> public class MyPackageResource extends PackageResource
> {
>        public MyPackageResource(Class scope, String name, Locale locale, 
> String style,
>                String variation)
>        {
>                super(scope, name, locale, style, variation);
>        }
>
>        // change access to public here
>        public IResourceStream getResourceStream()
>        {
>                return super.getResourceStream();
>        }
> }
>
> If you only need to open a stream of a package located file use this instead 
> - no need for PackageResource in that case at all:
>
>  InputStream is = MyPage.class.getResourceAsStream("mycss.css")
>
>
> Cheers
> Peter
> -
> 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

Re: how to get HttpServletRequest in wicket 1.5

[Peter Ertl]

Am 14.09.2011 um 09:32 schrieb nhsoft.yhw:

> inputStream = packageResource.getCacheableResourceStream().getInputStream();

I think this needs some clarification...

PackageResource has these methods for getting a stream:

 (1)  protected IResourceStream getResourceStream()

and 

 (2) public IResourceStream getCacheableResourceStream()

the intention is:

-  (1) locates the default resource without taking any client preferences into 
account.

-  (2) is there to get a client-specific resoure stream that is supposed to be 
immutable for the lifetime of the application and should be cached.

the sooner (1) locates the resource stream based on

- anchor class
- name
- locale
- style
- variation

as specified in the constructor(!) of PackageResource. So for example when 
using CssResourceReference (which is a descendant of PackageResourceReference) 
like that in your page:

  private static final PackageResourceReference CSS = new 
CssResourceReference(MyPage.class, "mycss", Locale.ENGLISH, "style1", 
"variation1");

these parameters will be applied to PackageResource when resolving the 
reference and yield:

- anchor class = MyPage.class
- name = "mycss"
- locale = Locale.ENGLISH
- style = "style1"
- variation = "variation1"

and getResourceStream (1) will locate the resource based on the above criteria.

In contrary getCacheableResourceStream (2) will override the values for locale 
and style with the values of the current session.

- anchor class = MyPage.class
- name = "mycss"
- Session.getLocale() if not empty, otherwise Locale.ENGLISH
- Session.getStyle() if not empty, otherwise "style1"
- variation = "variation1"

So (1) returns the default stream and (2) returns the stream fitting the 
client's preferences.

Unfortunately I realized it too late that (1) which was 'public' in 1.4 is now 
'protected' in 1.5. It's too late to change this without breaking the API. This 
can change in 1.6 to 'public' again unless things change completely (don't 
think so :-)

So In case you need to access (1) but miss the 'public' I can suggest the 
following workaround / kludge.

public class MyPackageResource extends PackageResource
{
public MyPackageResource(Class scope, String name, Locale locale, 
String style,
String variation)
{
super(scope, name, locale, style, variation);
}

// change access to public here
public IResourceStream getResourceStream()
{
return super.getResourceStream();
}
}

If you only need to open a stream of a package located file use this instead - 
no need for PackageResource in that case at all:

  InputStream is = MyPage.class.getResourceAsStream("mycss.css")


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

RE: how to get HttpServletRequest in wicket 1.5

[Hielke Hoeve]

Roger, thanks for the clarification.

Hielke

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org] 
Sent: woensdag 14 september 2011 9:54
To: users@wicket.apache.org
Subject: Re: how to get HttpServletRequest in wicket 1.5

java.lang.Object org.apache.wicket.request.Response.getContainerResponse()
javax.servlet.http.HttpServletResponse
org.apache.wicket.protocol.http.servlet.ServletWebResponse.getContainerResponse()

JDK1.5+ covariant return type

On Wed, Sep 14, 2011 at 10:24 AM, Hielke Hoeve  wrote:
> Why was the return type of getContainerRequest() altered to Object? 
> Everyone is now casting the result to HttpServletRequest anyway. So 
> changing the api kind of defeats the purpose :)
>
> Hielke
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: donderdag 8 september 2011 11:36
> To: users@wicket.apache.org
> Subject: Re: how to get HttpServletRequest in wicket 1.5
>
> HttpServletRequest servletReq = (HttpServletRequest) 
> getRequest().getContainerRequest();
>
> On Thu, Sep 8, 2011 at 12:26 PM, nhsoft.yhw  wrote:
>> in wicket 1.4.x, the code like :
>>
>> HttpServletRequest request =
>> getWebRequestCycle().getWebRequest().getHttpServletRequest();
>>
>> but i don't know how to get HttpServletRequest  in wicket 1.5
>>
>>
>> -
>> http://www.517wm.com
>> 外卖订餐分享工具
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/how-to-get-HttpServletRequ
>> e st-in-wicket-1-5-tp3798272p3798272.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> 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
>
>



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

Re: how to get HttpServletRequest in wicket 1.5

[Martin Grigorov]

java.lang.Object org.apache.wicket.request.Response.getContainerResponse()
javax.servlet.http.HttpServletResponse
org.apache.wicket.protocol.http.servlet.ServletWebResponse.getContainerResponse()

JDK1.5+ covariant return type

On Wed, Sep 14, 2011 at 10:24 AM, Hielke Hoeve  wrote:
> Why was the return type of getContainerRequest() altered to Object? Everyone 
> is now casting the result to HttpServletRequest anyway. So changing the api 
> kind of defeats the purpose :)
>
> Hielke
>
> -Original Message-
> From: Martin Grigorov [mailto:mgrigo...@apache.org]
> Sent: donderdag 8 september 2011 11:36
> To: users@wicket.apache.org
> Subject: Re: how to get HttpServletRequest in wicket 1.5
>
> HttpServletRequest servletReq = (HttpServletRequest) 
> getRequest().getContainerRequest();
>
> On Thu, Sep 8, 2011 at 12:26 PM, nhsoft.yhw  wrote:
>> in wicket 1.4.x, the code like :
>>
>> HttpServletRequest request =
>> getWebRequestCycle().getWebRequest().getHttpServletRequest();
>>
>> but i don't know how to get HttpServletRequest  in wicket 1.5
>>
>>
>> -
>> http://www.517wm.com
>> 外卖订餐分享工具
>> --
>> View this message in context:
>> http://apache-wicket.1842946.n4.nabble.com/how-to-get-HttpServletReque
>> st-in-wicket-1-5-tp3798272p3798272.html
>> Sent from the Users forum mailing list archive at Nabble.com.
>>
>> -
>> 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
>
>



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

Re: stateless page + click on stateless link = stateful page

[Martin Grigorov]

Indeed this change was reverted after RC7.
Now only "setResponsePage(new StatelessPage());" is automatically
promoted to stateful.

We tried to make it more general but apparently it was wrong...

On Wed, Sep 14, 2011 at 9:06 AM, Mike Mander  wrote:
> Am 13.09.2011 23:59, schrieb Bertrand Guay-Paquet:
>>
>> This is fixed in trunk. The fix will be available in 1.5.1
>
> Martin wrote to me in a former post
>> This is fixed in trunk. The fix will be available in 1.5.1
> Maybe we should try it again with 1.5.1
>
> -
> 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

Getting Error for custom PageExpiredErrorPage

[Peter Karich]

 Hi,

I'm getting this error in the logs:
ERROR org.apache.wicket.RequestCycle - unable to find component with
path urltrends:urls:9:urlLink on stateless page [Page class =
de.jetwick.ui.slide.ChooseJetslideOrJetwick, id = 0, version = 0] it
could be that the component is inside a repeater make your component
return false in getStatelessHint()

Here is how I set the custom page in my init method:
getApplicationSettings().setPageExpiredErrorPage(ChooseJetslideOrJetwick.class);

Why has wicket a problem when there is a session timeout on a stateful
page and then 'redirecting' to my expired page? How should I implement
my custom PageExpiredErrorPage ... I only have 2 BookmarkablePageLink:s
in it!?

I wasn't able to reproduce this message when browsing on my site
jetsli.de/tweets ... probably because it is only a google bot request ** ?
How can I fix this?

Regards,
Peter.

**
http://apache-wicket.1842946.n4.nabble.com/Page-expired-stateless-page-td1891032.html

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

Re: how to get HttpServletRequest in wicket 1.5

[nhsoft.yhw]

nhsoft.yhw wrote:
> 
> Q7. 
> 
> how to get inputstream from ResourceReference object, here is code for
> wicket 1.4.x 
> inputStream =
> reference.getResource().getResourceStream().getInputStream(); 
> 
> but IResource interface has no getResourceStream() method in wicket 1.5.0 
> 

My solution ：

PackageResource packageResource = (PackageResource)reference.getResource(); 
inputStream = packageResource.getCacheableResourceStream().getInputStream();

The above method is mainly to the PackageResource resources saved to the
database, so next time read from the database and display


-
http://www.517wm.com
外卖订餐分享工具
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/how-to-get-HttpServletRequest-in-wicket-1-5-tp3798272p3812014.html
Sent from the Users forum mailing list archive at Nabble.com.

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

RE: how to get HttpServletRequest in wicket 1.5

[Hielke Hoeve]

Why was the return type of getContainerRequest() altered to Object? Everyone is 
now casting the result to HttpServletRequest anyway. So changing the api kind 
of defeats the purpose :)

Hielke

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org] 
Sent: donderdag 8 september 2011 11:36
To: users@wicket.apache.org
Subject: Re: how to get HttpServletRequest in wicket 1.5

HttpServletRequest servletReq = (HttpServletRequest) 
getRequest().getContainerRequest();

On Thu, Sep 8, 2011 at 12:26 PM, nhsoft.yhw  wrote:
> in wicket 1.4.x, the code like :
>
> HttpServletRequest request =
> getWebRequestCycle().getWebRequest().getHttpServletRequest();
>
> but i don't know how to get HttpServletRequest  in wicket 1.5
>
>
> -
> http://www.517wm.com
> 外卖订餐分享工具
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/how-to-get-HttpServletReque
> st-in-wicket-1-5-tp3798272p3798272.html
> Sent from the Users forum mailing list archive at Nabble.com.
>
> -
> 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