DateTextField Problem

[Seçil Aydın]

I am using DateTextField and DatePicker components for getting date value of
the user but
I have a problem with the component.The problem is when user enters
99.99. to the text field and clicks on submit button it gives an
error(invalid date) -its ok till now- but when user wants to change the time
date converted to "07.06.10007" so user can not easily reach a valid date.
Is there any solution to this?
With my best regards.


Here is my code:
tEndDate = new DateTextField("endDate", new Model(),  new
StyleDateConverter("S-", true))
{

private static final long serialVersionUID = 1L;

@Override
public Locale getLocale()
{
return new Locale("tr");
}
};

DatePicker  dPicker = new DatePicker();
dPicker.setShowOnFieldClick(true);
tEndDate.add(new DatePicker());

-
Wicket-Java
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/DateTextField-Problem-tp4288137p4288137.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: Model problem with my own component

[Wayne W]

thanks Sven

On Wed, Jan 11, 2012 at 6:46 PM, Sven Meier  wrote:
> Hi,
>
>
>> add(new ProductImage("image", getDefaultModel());
>
> this line is causing the null product.
>
>
>> I thought when setting the default model all the children are visited and
>> model updated.?
>
> No, not at all. Either you have to do that by yourself or you have to give
> ProductImage a more intelligent model:
>
>     add(new ProductImage("image", new AbstractReadOnlyModel() {
>          public Product getObject() {
>              return getDefaultModel().getObject();
>          }
>     });
>
> Hope this helps
> Sven
>
> Am 11.01.2012 08:01, schrieb Wayne W:
>>
>> Hello,
>>
>> I cannot get my component model to update correctly when being set. I
>> have list of products and when I click on the name via ajax I update a
>> Product panel to display the info. In that panel I have my component
>> that displays the image of the product. sudo code:
>>
>> ProductPanel(id, IModel  model) {
>>   super(id, new CompoundPropertyModel(model));
>>
>>   add(new Label("name");
>>   add(new ProductImage("image", getDefaultModel());
>> }
>>
>> ProductImage extends Image {
>>   ProductImage(id, IModel  model) {
>>     super( id, model);
>>
>>    Product p = getDefaultModelObject();
>>    // p always null
>>
>> }
>>
>>
>> AjaxLink() {
>>   onclick(target) {
>>     productPanel.setDefaultModel(getModel());
>>     target.add(productPanel);
>> }}
>>
>>
>> When I click on the link the name is updated and displayed correctly.
>> However in the ProductImage component the product is always null. I
>> thought when setting the default model all the children are visited
>> and model updated.? I;ve tried debugging but get cannot figure it out.
>>
>> Any ideas?
>>
>> -
>> 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
>

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

RE: Javascript resources and jsessionid

[Chris Colman]

I just checked with 1.5.x and for stateless pages all bookmarkable page
links do not incur the jsessionid suffix for a non cookie client. Once
an Ajax link is added to the page however the jsessionid suffix appears
on all links which makes sense as the page is no longer stateless once
Ajax gets involved.

To summarize:

I guess there's two completely separate issues surrounding jsessionid:

1. A jsessionid is added to package resource links, most of which are
static  don't need session info for them to be rendered. For a new
session in a browser with cookies enabled this causes a 'double load' of
every package resource. If the user revisits the site after their
session has expired then another download of the package resources will
occur (because they have a different jsessionid suffix)

Possible solution: Wicket always renders stateless resources without any
jsessionid regardless of whether the page is stateful or stateless. When
servicing a request for a resource without a jsessionid Wicket does not
attempt to establish a session which avoids creating a Session on every
stateless resource request.

2. To improve SEO search engine crawlers should see only stateless pages
so that the jsessionid never appears in any links. Wicket seems to work
well in this regard already. The tricky part is to create stateless
pages in the first place ;)


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

Intermittent issue of data overwriting between browser tabs in a multi window session with forms

[T A]

Hi,

I am relatively new to Wicket and working on maintenance of a 1.3.7 Wicket 
application.

The application is a CMS and there is a very intermittent issue, but serious 
issue, that I am trying to reproduce and diagnose. It appears that updates to 
content in one application window is overwriting content in another 
applilcation window.


I would be very thankful for any words of wisdom from the community as far as 
any leads on what to investigate.


My best guess of the use case from talking to users is as follows

1-Login to the application.

2-Click on a link on the application homepage that take you to versioned 
content. The URL of this content is set via HybridUrlCodingStrategy, like this


mount(new HybridUrlCodingStrategy("/content/Edit", ContentEdit.class, true));


3-Start to edit the content by "unlocking it" and when done, save content, and 
(most likely) release the lock.


4-From clicking a link in an email , open another URL of the application, that 
is also set via HybridUrlCodingStrategy, but without the last parameter for 
redirectOnBookmarkableRequest

mount(new HybridUrlCodingStrategy("/memo", MarkMemoRead.class));

5-In this second browser window, the application takes the the URL that was 
pasted in and redirects to another URL to edit a different piece of versioned 
content. This other URL is the same as mounted in step 2 above, so it is also a 
HybridUrlCodingStrategy. The way it redirects is like

    setResponsePage(getPageClass(), getParams());
    setRedirect(true);


6-"Unlock" the content in the second browser window, makes changes and save, 
and (most likely) "unlock" it.


7-Return to the first content, either by refreshing the first window, or even 
by logging out and going back to it. The first content has been overwritten by 
the content from the second browser window.

Both content windows have forms and do use Ajax to make updates on save.


I have not yet been able to reproduce the error myself.

My thinking from looking at the code and the past issues in the user forum is 
that there is some issue with the second browser window not getting it's own 
PageMap, but instead getting the first page's, or something to that effect. I 
can't understand why it happens very intermittently.

I have seen there are/were known issues with multiple window, page maps, and 
sessions in the 1.3 stream, so I am inclined to think this issue is in that 
realm.


I also see that the application code is not explicitly setting the method  
setAutomaticMultiWindowSupport anywhere, but I think it must be defaulting to 
true, otherwise the issue would happen more than rarely considering how much 
use the application gets without incident.

Really appreciate any advice from those with more experience with wicket.

Ted

RE: Javascript resources and jsessionid

[Chris Colman]

As it turns out WicketFilter isn't responsible for directly creating a
session but some code it calls indirectly in BufferedResponseMapper
attempts to locate a sessionId which for some reason, creates a session
if there is none yet:

protected boolean hasBufferedResponse(Url url)
{
String sessionId = getSessionId();
boolean hasResponse = false;
if (Strings.isEmpty(sessionId) == false)
{
hasResponse =
WebApplication.get().hasBufferedResponse(sessionId, url);
}
return hasResponse;
}

It looks like getSessionId() will always cause a session to be created
if none previously existed. Is this necessary or could it just return
empty string if no current session exists? 

>I just had a look at the 1.5 WicketFilter source code and it appears
not
>to be creating or finding a Wicket Session at all - which is a good
sign
>- although maybe it's created somewhere else now.
>
>>The only problem is that each package resource request creates a new
>>Wicket Session in WicketFilter.
>>This may be light or heavy operation, depends on the actual Session
>impl.
>>
>>And in WicketFilter we do not know whether this is a request to a
>>package resource or to any other IResource impl which may need the
>>session. We have this info later.
>>
>>On Wed, Jan 11, 2012 at 2:15 PM, Chris Colman
>> wrote:
A use case:
Imagine that the management of the session in a cookie is disabled
in
the web server config, so jsessionid is always encoded in the url.
If resources don't have the jsessionid in their url then a new
temporary Wicket and http sessions will be created and discarded for
each request.
>>>
>>> In the use case where jsessionid is to be used instead of cookies
>there
>>> is no need for jsessionid to be present in every url generated in a
>page
>>> render. It is only required in urls that will lead to another page
so
>>> that the session id is transitive from one page to another as the
>user
>>> clicks links.
>>>
>>> Urls that are 'dead ends' and will never lead to other pages being
>>> opened don't need this transitive feature and so don't need to carry
>a
>>> jsessionid.
>>>
>>> I can't ever see a need for encodeURL to be called on a package
>resource
>>> URL - it doesn't lead to another page so there is no need to send
>this
>>> 'session DNA' along with URLs to package resources. It should only
>ever
>>> be needed in URLs that can take the user to another page on the
site.
>>>
>>> There's two approaches to avoid sending these jsessionid's along
with
>>> package resource URLs:
>>>
>>> 1. Wicket framework does some smarts and doesn't encode links to
>package
>>> resources.
>>>
>>> 2. Wicket users override newWebResponse and return WebResponse
>instances
>>> that override encodeURL to avoid calling super.encodeURL(url) for
>>> package resource URLs but do it for links to pages on the site.
>>> Obviously this class would have to analyze the URL and get funky
with
>a
>>> lot of nastiness to get it right.
>>>
>>> In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment
on
>>> 19/8/2010 seems to suggest that approach 1. was taken and that it
was
>>> working in 1.5 but that was 16 months ago ;)
>>>
>>>
-
>>> 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


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

RE: Javascript resources and jsessionid

[Chris Colman]

I just had a look at the 1.5 WicketFilter source code and it appears not
to be creating or finding a Wicket Session at all - which is a good sign
- although maybe it's created somewhere else now.

>The only problem is that each package resource request creates a new
>Wicket Session in WicketFilter.
>This may be light or heavy operation, depends on the actual Session
impl.
>
>And in WicketFilter we do not know whether this is a request to a
>package resource or to any other IResource impl which may need the
>session. We have this info later.
>
>On Wed, Jan 11, 2012 at 2:15 PM, Chris Colman
> wrote:
>>>A use case:
>>>Imagine that the management of the session in a cookie is disabled in
>>>the web server config, so jsessionid is always encoded in the url.
>>>If resources don't have the jsessionid in their url then a new
>>>temporary Wicket and http sessions will be created and discarded for
>>>each request.
>>
>> In the use case where jsessionid is to be used instead of cookies
there
>> is no need for jsessionid to be present in every url generated in a
page
>> render. It is only required in urls that will lead to another page so
>> that the session id is transitive from one page to another as the
user
>> clicks links.
>>
>> Urls that are 'dead ends' and will never lead to other pages being
>> opened don't need this transitive feature and so don't need to carry
a
>> jsessionid.
>>
>> I can't ever see a need for encodeURL to be called on a package
resource
>> URL - it doesn't lead to another page so there is no need to send
this
>> 'session DNA' along with URLs to package resources. It should only
ever
>> be needed in URLs that can take the user to another page on the site.
>>
>> There's two approaches to avoid sending these jsessionid's along with
>> package resource URLs:
>>
>> 1. Wicket framework does some smarts and doesn't encode links to
package
>> resources.
>>
>> 2. Wicket users override newWebResponse and return WebResponse
instances
>> that override encodeURL to avoid calling super.encodeURL(url) for
>> package resource URLs but do it for links to pages on the site.
>> Obviously this class would have to analyze the URL and get funky with
a
>> lot of nastiness to get it right.
>>
>> In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment on
>> 19/8/2010 seems to suggest that approach 1. was taken and that it was
>> working in 1.5 but that was 16 months ago ;)
>>
>> -
>> 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: Is it possible to set the session?

[Serban Balamaci]

You need two requests because in the first one you don't have yet have any
session attached to the request you make to the server. And the server
response will just be to attach JSESSIONID cookie and tell the browser to
repeat the first request with the JSESSION cookie attached(you can redirect
to the same page or another). So now this new request has the sessionid you
require.

In 1.4 I think you can throw a RedirectToUrlException but take a look at
what/how it does it because I see it extends
AbstractRestartResponseException and if you set the cookie before you throw
it, I'm pretty sure it will reset the addCookie method from the response, so
you may have to override it. 

Again firebug will show you if the cookie was set or not.



-
http://balamaci.wordpress.com 
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-tp4281720p4285767.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: Is it possible to set the session?

[cosmindumy]

Hi again,
Thanks for your replay and for your time to write the code.
But I didn't understand why to do a redirect from iframe page. Which is
"/page_to_redirect_after_set_session"? I don't want any redirect from my
iframe page. And where should I put that code? In constructor?
And secondary, I use wicket1.4.8 and there is no method
"scheduleRequestHandlerAfterCurrent". What can I use instead?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-tp4281720p4285622.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: Regarding Stack Overflow exception

[smsmaddy]

I have tried with 1.5.2 and tried by migrating few classes and tested the
small feature which was part of  stack overflow message error...And now, the
fix is working fine locally
I have to upgrade complete application to 1.5.2 and update you the results
sooner

Thanks for the support :)

-
//Maddy
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Regarding-Stack-Overflow-exception-tp4203930p4285581.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: Is it possible to set the session?

[Serban Balamaci]

Hi Cosmin,
What have you tried? 
Sending 1. .../frame_page;jsessionid=123 or 2.
.../frame_page?jsessionid=123.
The first option may work while the second it's normal not to have any
impact on the session but can be used to get the sessionid as a parameter.

The 1. option if it works, is not really fullproof, as from my experience if
the user already has a JSESSIONID cookie, the value in the cookie takes
precedence so the user will come in the frame page with an old sessionid,
but it's simplest.

And since you say that we cannot set cookies for the frame, I'm thinking the
solution is to set the sessionid cookie "manually" by adding it to the
response from the frame. Since this first request will not have a session
created, we need to force the browser to reload the page/redirect to another
page after we set the session cookie, and the new request will have the
required session with it:

So I'm saying in your frame page page you do something like

FramePage extends WebPage {
...

getRequestCycle().scheduleRequestHandlerAfterCurrent(new
RedirectRequestHandler("/page_to_redirect_after_set_session") {
@Override
public void respond(IRequestCycle requestCycle) {

WebResponse response =
(WebResponse)requestCycle.getResponse();
String sessionId =
getRequest().getQueryParameters().getParameterValue("sessionId").toString();
Cookie cookie = new Cookie("JSESSIONID", sessionId);
cookie.setMaxAge(-1);

response.addCookie(cookie);
super.respond(requestCycle);
}
});
}

Take care that if you decide on throwing RestartResponseException instead it
does a restart of the old response so your addCookie command will be lost.

Firebug is a great tool that helps you in this, as you will need to look on
the response for Set-Cookie with JSESSIONID response from the frame page.


PS: Yes, I'm from Romania.

-
http://balamaci.wordpress.com 
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-tp4281720p4285390.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: Javascript resources and jsessionid

[Chris Colman]

I can see things like DynamicWebResource might need a session as what it
streams out could depend on session state but most instances of things
like images, .css, .js, etc., are static.

Perhaps some kind of convention could be used in the URL so that the
WicketFilter could quickly and easily tell by looking at the resource
URL which ones are static (no session required) and which are dynamic
(session required).

Certainly most of the IResources in our sites appear to be all static.
 
>The only problem is that each package resource request creates a new
>Wicket Session in WicketFilter.
>This may be light or heavy operation, depends on the actual Session
impl.
>
>And in WicketFilter we do not know whether this is a request to a
>package resource or to any other IResource impl which may need the
>session. We have this info later.
>
>On Wed, Jan 11, 2012 at 2:15 PM, Chris Colman
> wrote:
>>>A use case:
>>>Imagine that the management of the session in a cookie is disabled in
>>>the web server config, so jsessionid is always encoded in the url.
>>>If resources don't have the jsessionid in their url then a new
>>>temporary Wicket and http sessions will be created and discarded for
>>>each request.
>>
>> In the use case where jsessionid is to be used instead of cookies
there
>> is no need for jsessionid to be present in every url generated in a
page
>> render. It is only required in urls that will lead to another page so
>> that the session id is transitive from one page to another as the
user
>> clicks links.
>>
>> Urls that are 'dead ends' and will never lead to other pages being
>> opened don't need this transitive feature and so don't need to carry
a
>> jsessionid.
>>
>> I can't ever see a need for encodeURL to be called on a package
resource
>> URL - it doesn't lead to another page so there is no need to send
this
>> 'session DNA' along with URLs to package resources. It should only
ever
>> be needed in URLs that can take the user to another page on the site.
>>
>> There's two approaches to avoid sending these jsessionid's along with
>> package resource URLs:
>>
>> 1. Wicket framework does some smarts and doesn't encode links to
package
>> resources.
>>
>> 2. Wicket users override newWebResponse and return WebResponse
instances
>> that override encodeURL to avoid calling super.encodeURL(url) for
>> package resource URLs but do it for links to pages on the site.
>> Obviously this class would have to analyze the URL and get funky with
a
>> lot of nastiness to get it right.
>>
>> In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment on
>> 19/8/2010 seems to suggest that approach 1. was taken and that it was
>> working in 1.5 but that was 16 months ago ;)
>>
>> -
>> 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: Is it possible to set the session?

[cosmindumy]

This was the first solution. I tried to give the session id as a parameter to
the iframe. I tought it's enough and the framework will do the rest. It
didn't work.
 You said that I have to "return from that page a response with a JSESSIONID
header equal to the value of the session." . 
Can you explain a little bit more detailed? Maybe a sketch of code. Where
should this be done? Do I have to override a method? I didn't understand
how. 
Thanks. 
By the way, are you from Romania? 

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-tp4281720p4285272.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: Javascript resources and jsessionid

[Martin Grigorov]

The only problem is that each package resource request creates a new
Wicket Session in WicketFilter.
This may be light or heavy operation, depends on the actual Session impl.

And in WicketFilter we do not know whether this is a request to a
package resource or to any other IResource impl which may need the
session. We have this info later.

On Wed, Jan 11, 2012 at 2:15 PM, Chris Colman
 wrote:
>>A use case:
>>Imagine that the management of the session in a cookie is disabled in
>>the web server config, so jsessionid is always encoded in the url.
>>If resources don't have the jsessionid in their url then a new
>>temporary Wicket and http sessions will be created and discarded for
>>each request.
>
> In the use case where jsessionid is to be used instead of cookies there
> is no need for jsessionid to be present in every url generated in a page
> render. It is only required in urls that will lead to another page so
> that the session id is transitive from one page to another as the user
> clicks links.
>
> Urls that are 'dead ends' and will never lead to other pages being
> opened don't need this transitive feature and so don't need to carry a
> jsessionid.
>
> I can't ever see a need for encodeURL to be called on a package resource
> URL - it doesn't lead to another page so there is no need to send this
> 'session DNA' along with URLs to package resources. It should only ever
> be needed in URLs that can take the user to another page on the site.
>
> There's two approaches to avoid sending these jsessionid's along with
> package resource URLs:
>
> 1. Wicket framework does some smarts and doesn't encode links to package
> resources.
>
> 2. Wicket users override newWebResponse and return WebResponse instances
> that override encodeURL to avoid calling super.encodeURL(url) for
> package resource URLs but do it for links to pages on the site.
> Obviously this class would have to analyze the URL and get funky with a
> lot of nastiness to get it right.
>
> In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment on
> 19/8/2010 seems to suggest that approach 1. was taken and that it was
> working in 1.5 but that was 16 months ago ;)
>
> -
> 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: Javascript resources and jsessionid

[Chris Colman]

>A use case:
>Imagine that the management of the session in a cookie is disabled in
>the web server config, so jsessionid is always encoded in the url.
>If resources don't have the jsessionid in their url then a new
>temporary Wicket and http sessions will be created and discarded for
>each request.

In the use case where jsessionid is to be used instead of cookies there
is no need for jsessionid to be present in every url generated in a page
render. It is only required in urls that will lead to another page so
that the session id is transitive from one page to another as the user
clicks links.

Urls that are 'dead ends' and will never lead to other pages being
opened don't need this transitive feature and so don't need to carry a
jsessionid.

I can't ever see a need for encodeURL to be called on a package resource
URL - it doesn't lead to another page so there is no need to send this
'session DNA' along with URLs to package resources. It should only ever
be needed in URLs that can take the user to another page on the site. 
 
There's two approaches to avoid sending these jsessionid's along with
package resource URLs:

1. Wicket framework does some smarts and doesn't encode links to package
resources.

2. Wicket users override newWebResponse and return WebResponse instances
that override encodeURL to avoid calling super.encodeURL(url) for
package resource URLs but do it for links to pages on the site.
Obviously this class would have to analyze the URL and get funky with a
lot of nastiness to get it right.

In http://issues.apache.org/jira/browse/WICKET-2999 Igor's comment on
19/8/2010 seems to suggest that approach 1. was taken and that it was
working in 1.5 but that was 16 months ago ;)

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

RE: Is it possible to set the session?

[Chris Colman]

I had the exact same 'can I SET the session' requirement today. I
thought of dealing with search engine crawlers and their stateless view
of the site by assigning the same session instance to each request from
a given crawler to avoid creating a new session for every request they
made.

Well I achieve one session per search engine now but it relies on
jsessionid which I'm trying to avoid using when a search engine is
crawling the site. (jsessionid will still work for uses who have cookies
turned off).

>-Original Message-
>From: cosmindumy [mailto:cosmind...@yahoo.com]
>Sent: Wednesday, 11 January 2012 10:35 PM
>To: users@wicket.apache.org
>Subject: RE: Is it possible to set the session?
>
>
>Did you wan to get or set the session? Your subject said 'set' but the
>body asked about 'get'.
>
>It would be awesome  if I could set the session with a given one. But
it is
>an option to get the session by id, as I have some informations on the
>session and I want to access them.
>The problem is that if I block third party cookies the iframe I open
>creates
>a new session.
>
>--
>View this message in context: http://apache-
>wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-
>tp4281720p4285130.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: Is it possible to set the session?

[Serban Balamaci]

Hello,

Maybe pass the sessionid in the url like a query parameter to the page you
open in an iframe and then read the url parameter and return from that page
a response with a JSESSIONID header equal to the value of the session.
Subsequent requests to the page in the iframe will have this sessionid. 

However using the same session could cause problems with the PageMap? Not
sure about this as it probably should be the same as opening  the
application in two browser windows.

I'd rather go for storing the information that must be shared in a cache/map
and pass around as an url parameter the key to lookup in the cache but since
I don't know the full story...

-
http://balamaci.wordpress.com 
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-tp4281720p4285158.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: Is it possible to set the session?

[cosmindumy]

Did you wan to get or set the session? Your subject said 'set' but the
body asked about 'get'.

It would be awesome  if I could set the session with a given one. But it is
an option to get the session by id, as I have some informations on the
session and I want to access them. 
The problem is that if I block third party cookies the iframe I open creates
a new session.  

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-tp4281720p4285130.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: Javascript resources and jsessionid

[Martin Grigorov]

A use case:
Imagine that the management of the session in a cookie is disabled in
the web server config, so jsessionid is always encoded in the url.
if resources don't have the jsessionid in their url then a new
temporary Wicket and http sessions will be created and discarded for
each request. And their number will be the same as the number of the
resources.

On Wed, Jan 11, 2012 at 1:09 PM, Chris Colman
 wrote:
> I just opened IE and with a new clean session went to our website and
> voila - IE sees the .js files with jsessionid as different to the ones
> without it and so there are two of every .js file required by both the
> home page and the second page I visited.
>
> I imagine if user visits a site on a regular basis but at intervals
> sufficient for the last session to expirre then they will be forced to
> download add an extra set of .js files which will get stored in the
> browser's cache, even though the .js file has not changed.
>
> A URL referencing a .js file should *never* need a jsessionid attached
> to it. It would be good if we could stop that somehow. They have version
> numbers built into their names so the browser will never end up trying
> to use a 'stale' .js file.
>
> Regards
> Chris
>
> 
>
> From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
> Sent: Wednesday, 11 January 2012 9:37 PM
> To: users@wicket.apache.org
> Subject: Javascript resources and jsessionid
>
> I realize that the servlet container is responsible for URL rewriting
> and hence adding the jsessionid but I was after an opinion:
>
> Is it right that Javascript resources get URLs rewritten to include the
> jsessionid when search engines access a website?
> (And indeed for normal users on their first visit to the site).
>
> Eg.,
>
>  src="wicket/resource/org.apache.wicket.extensions.ajax.markup.html.modal
> .ModalWindow/res/modal-ver-1326193494000.js;jsessionid=3E45F45F056AF2BCF
> CFD030B489F832A">
>
>
> I guess for search engines it doesn't matter as they won't be
> downloading the .js anyway - the jsessionid just adds extra clutter to
> the HTML - but for normal users with cookies enabled it could cause the
> .js downloaded after a new session is created to be redownloaded when
> the next page is requested because at that stage the server would have
> established that the client supports cookies and so would not render
> subsequent pages with jsessionidS suffixed to the .js references.
>
> Depending on how smart the browser's cache is it might see the jsession
> suffixed .js and the clean .js as two separate resources and do a second
> download of the .js.
>
> Hmmm, interesting.
>
> Again, this is not strictly a Wicket issue but I'd be interested to know
> what others think about this.
>
>
> Yours sincerely,
>
> Chris Colman
>
> Pagebloom Team Leader,
> Step Ahead Software
>
>
> pagebloom - your business & your website growing together
>
> Sydney:           (+61 2) 9656 1278     Canberra: (+61 2) 6100 2120
> Email: chr...@stepahead.com.au 
> Website:
> http://www.pagebloom.com http://www.pagebloom.com/>
> http://develop.stepaheadsoftware.com
> http://develop.stepaheadsoftware.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: Javascript resources and jsessionid - existing JIRA issue fixed in 1.4

[Chris Colman]

I noticed this is an existing JIRA issue that was apparently fixed in
1.4 but I'm seeing the double package resources in the cache using an up
to date 1.5-SNAPSHOT.

Existing JIRA issue:
https://issues.apache.org/jira/browse/WICKET-2999


>I just opened IE and with a new clean session went to our website and
>voila - IE sees the .js files with jsessionid as different to the ones
>without it and so there are two of every .js file required by both the
>home page and the second page I visited.
>
>I imagine if user visits a site on a regular basis but at intervals
>sufficient for the last session to expirre then they will be forced to
>download add an extra set of .js files which will get stored in the
>browser's cache, even though the .js file has not changed.
>
>A URL referencing a .js file should *never* need a jsessionid attached
>to it. It would be good if we could stop that somehow. They have
version
>numbers built into their names so the browser will never end up trying
>to use a 'stale' .js file.
>
>Regards
>Chris
>
>
>
>From: Chris Colman [mailto:chr...@stepaheadsoftware.com]
>Sent: Wednesday, 11 January 2012 9:37 PM
>To: users@wicket.apache.org
>Subject: Javascript resources and jsessionid
>
>I realize that the servlet container is responsible for URL rewriting
>and hence adding the jsessionid but I was after an opinion:
>
>Is it right that Javascript resources get URLs rewritten to include the
>jsessionid when search engines access a website?
>(And indeed for normal users on their first visit to the site).
>
>Eg.,
>
>src="wicket/resource/org.apache.wicket.extensions.ajax.markup.html.moda
l
>.ModalWindow/res/modal-ver-1326193494000.js;jsessionid=3E45F45F056AF2BC
F
>CFD030B489F832A">
>
>
>I guess for search engines it doesn't matter as they won't be
>downloading the .js anyway - the jsessionid just adds extra clutter to
>the HTML - but for normal users with cookies enabled it could cause the
>.js downloaded after a new session is created to be redownloaded when
>the next page is requested because at that stage the server would have
>established that the client supports cookies and so would not render
>subsequent pages with jsessionidS suffixed to the .js references.
>
>Depending on how smart the browser's cache is it might see the jsession
>suffixed .js and the clean .js as two separate resources and do a
second
>download of the .js.
>
>Hmmm, interesting.
>
>Again, this is not strictly a Wicket issue but I'd be interested to
know
>what others think about this.
>
>
>Yours sincerely,
>
>Chris Colman
>
>Pagebloom Team Leader,
>Step Ahead Software
>
>
>pagebloom - your business & your website growing together
>
>Sydney:   (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120
>Email: chr...@stepahead.com.au 
>Website:
>http://www.pagebloom.com http://www.pagebloom.com/>
>http://develop.stepaheadsoftware.com
>http://develop.stepaheadsoftware.com/>
>
>

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

RE: Javascript resources and jsessionid

[Chris Colman]

I just opened IE and with a new clean session went to our website and
voila - IE sees the .js files with jsessionid as different to the ones
without it and so there are two of every .js file required by both the
home page and the second page I visited.
 
I imagine if user visits a site on a regular basis but at intervals
sufficient for the last session to expirre then they will be forced to
download add an extra set of .js files which will get stored in the
browser's cache, even though the .js file has not changed.
 
A URL referencing a .js file should *never* need a jsessionid attached
to it. It would be good if we could stop that somehow. They have version
numbers built into their names so the browser will never end up trying
to use a 'stale' .js file.
 
Regards
Chris
 


From: Chris Colman [mailto:chr...@stepaheadsoftware.com] 
Sent: Wednesday, 11 January 2012 9:37 PM
To: users@wicket.apache.org
Subject: Javascript resources and jsessionid
 
I realize that the servlet container is responsible for URL rewriting
and hence adding the jsessionid but I was after an opinion:
 
Is it right that Javascript resources get URLs rewritten to include the
jsessionid when search engines access a website?
(And indeed for normal users on their first visit to the site).
 
Eg.,
 

 
 
I guess for search engines it doesn't matter as they won't be
downloading the .js anyway - the jsessionid just adds extra clutter to
the HTML - but for normal users with cookies enabled it could cause the
.js downloaded after a new session is created to be redownloaded when
the next page is requested because at that stage the server would have
established that the client supports cookies and so would not render
subsequent pages with jsessionidS suffixed to the .js references.
 
Depending on how smart the browser's cache is it might see the jsession
suffixed .js and the clean .js as two separate resources and do a second
download of the .js.
 
Hmmm, interesting.
 
Again, this is not strictly a Wicket issue but I'd be interested to know
what others think about this.
 
 
Yours sincerely,
 
Chris Colman
 
Pagebloom Team Leader,
Step Ahead Software


pagebloom - your business & your website growing together
 
Sydney:   (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 
Email: chr...@stepahead.com.au  
Website:
http://www.pagebloom.com http://www.pagebloom.com/> 
http://develop.stepaheadsoftware.com
http://develop.stepaheadsoftware.com/> 
 
 

RE: Is it possible to set the session?

[Chris Colman]

Did you wan to get or set the session? Your subject said 'set' but the
body asked about 'get'.

>Hi,
>It would be enough for me if I could get session by id. Is there a
>possibility?
>
>--
>View this message in context: http://apache-
>wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-
>tp4281720p4284724.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

Javascript resources and jsessionid

[Chris Colman]

I realize that the servlet container is responsible for URL rewriting
and hence adding the jsessionid but I was after an opinion:
 
Is it right that Javascript resources get URLs rewritten to include the
jsessionid when search engines access a website?
(And indeed for normal users on their first visit to the site).
 
Eg.,
 

 
 
I guess for search engines it doesn't matter as they won't be
downloading the .js anyway - the jsessionid just adds extra clutter to
the HTML - but for normal users with cookies enabled it could cause the
.js downloaded after a new session is created to be redownloaded when
the next page is requested because at that stage the server would have
established that the client supports cookies and so would not render
subsequent pages with jsessionidS suffixed to the .js references.
 
Depending on how smart the browser's cache is it might see the jsession
suffixed .js and the clean .js as two separate resources and do a second
download of the .js.
 
Hmmm, interesting.
 
Again, this is not strictly a Wicket issue but I'd be interested to know
what others think about this.
 
 
Yours sincerely,
 
Chris Colman
 
Pagebloom Team Leader,
Step Ahead Software

 
pagebloom - your business & your website growing together
 
Sydney: (+61 2) 9656 1278 Canberra: (+61 2) 6100 2120 
Email: chr...@stepahead.com.au  
Website:
http://www.pagebloom.com http://www.pagebloom.com/> 
http://develop.stepaheadsoftware.com
http://develop.stepaheadsoftware.com/> 
 
 

Re: Is it possible to set the session?

[cosmindumy]

Hi,
It would be enough for me if I could get session by id. Is there a
possibility?

--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Is-it-possible-to-set-the-session-tp4281720p4284724.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