Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)

[Sven Meier]

Martin's explanation fits the reported stacktrace nicely.

We should definitely change getSessionEntry() as proposed. I don't see 
an advantage in using an HttpSessionListener though.


@Paul: What is broken now?

Sven

On 09/28/2013 12:15 AM, Paul Bors wrote:

I take that back, the new implementation breaks the session timeout.

~ Thank you,
   Paul Bors

-Original Message-
From: Paul Bors [mailto:p...@bors.ws]
Sent: Friday, September 27, 2013 5:51 PM
To: users@wicket.apache.org
Cc: d...@wicket.apache.org
Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 
and v4)

I tested with the proposed 
o.a.w.p.PageStoreManager.PersistentRequestAdapter#getSessionEntry() new 
implementation and it's working fine in GlassFish v3.1.2.2

I'll withdraw my GLASSFISH-20828 bug.

Should I open a new Wicket ticket instead?

I do think the second suggestion of using HttpSessionListener instead is 
cleaner.

~ Thank you,
   Paul Bors

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Friday, September 27, 2013 4:09 PM
To: users@wicket.apache.org
Cc: d...@wicket.apache.org
Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 
and v4)

Reading your ticket against GF I think GF behaves correctly. But I wonder why 
Tomcat/Jetty don't do this.

So here is what happens:

org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry
looks like :
private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = 
(SessionEntry)getSessionAttribute(getAttributeName());
  if (entry == null && create)
{
bind();
  entry = new SessionEntry(applicationName, getSessionId()); } if (entry != 
null)  { synchronized (entry) { setSessionAttribute(getAttributeName(), entry); 
 } } return entry; }

I think the correct code should be:

private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = 
(SessionEntry)getSessionAttribute(getAttributeName());
  if (entry == null && create)
{
bind();
  entry = new SessionEntry(applicationName, getSessionId()); 
setSessionAttribute(getAttributeName(), entry);  } return entry; } I.e. set the 
SessionEntry as an attribute in the http session only when it is created.

Because with the current code we call
"setSessionAttribute(getAttributeName(), entry);" even with already existing 
entries and this leads to notifications to HttpSessionBindingListener - new value is 
bound, old value is removed.

I guess Tomcat and Jetty optimize this by doing identity check.

Another solution would be SessionEntry to implement HttpSessionListener instead 
and check the sessionId of the unbound session against its own one and clean 
the data store if they are equal.





On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors  wrote:


Created https://java.net/jira/browse/GLASSFISH-20828
"HttpSessionBindingListener.valueUnbound() is always called right
after
valueBound() with a null HttpSessionBindingEvent.getValue()"

Let's see what becomes of this...



-
~ Thank you,
 p...@bors.ws
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-excep
tions-in-Wicket-6-10-0-tp4661502p4661582.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




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

RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)

[Paul Bors]

I take that back, the new implementation breaks the session timeout.

~ Thank you,
  Paul Bors

-Original Message-
From: Paul Bors [mailto:p...@bors.ws] 
Sent: Friday, September 27, 2013 5:51 PM
To: users@wicket.apache.org
Cc: d...@wicket.apache.org
Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 
and v4)

I tested with the proposed 
o.a.w.p.PageStoreManager.PersistentRequestAdapter#getSessionEntry() new 
implementation and it's working fine in GlassFish v3.1.2.2

I'll withdraw my GLASSFISH-20828 bug.

Should I open a new Wicket ticket instead?

I do think the second suggestion of using HttpSessionListener instead is 
cleaner.

~ Thank you,
  Paul Bors

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Friday, September 27, 2013 4:09 PM
To: users@wicket.apache.org
Cc: d...@wicket.apache.org
Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 
and v4)

Reading your ticket against GF I think GF behaves correctly. But I wonder why 
Tomcat/Jetty don't do this.

So here is what happens:

org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry
looks like :
private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = 
(SessionEntry)getSessionAttribute(getAttributeName());
 if (entry == null && create)
{
bind();
 entry = new SessionEntry(applicationName, getSessionId()); } if (entry != 
null)  { synchronized (entry) { setSessionAttribute(getAttributeName(), entry); 
 } } return entry; }

I think the correct code should be:

private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = 
(SessionEntry)getSessionAttribute(getAttributeName());
 if (entry == null && create)
{
bind();
 entry = new SessionEntry(applicationName, getSessionId()); 
setSessionAttribute(getAttributeName(), entry);  } return entry; } I.e. set the 
SessionEntry as an attribute in the http session only when it is created.

Because with the current code we call
"setSessionAttribute(getAttributeName(), entry);" even with already existing 
entries and this leads to notifications to HttpSessionBindingListener - new 
value is bound, old value is removed.

I guess Tomcat and Jetty optimize this by doing identity check.

Another solution would be SessionEntry to implement HttpSessionListener instead 
and check the sessionId of the unbound session against its own one and clean 
the data store if they are equal.





On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors  wrote:

> Created https://java.net/jira/browse/GLASSFISH-20828
> "HttpSessionBindingListener.valueUnbound() is always called right 
> after
> valueBound() with a null HttpSessionBindingEvent.getValue()"
>
> Let's see what becomes of this...
>
>
>
> -
> ~ Thank you,
> p...@bors.ws
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-excep
> tions-in-Wicket-6-10-0-tp4661502p4661582.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: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)

[Paul Bors]

I tested with the proposed 
o.a.w.p.PageStoreManager.PersistentRequestAdapter#getSessionEntry() new 
implementation and it's working fine in GlassFish v3.1.2.2

I'll withdraw my GLASSFISH-20828 bug.

Should I open a new Wicket ticket instead?

I do think the second suggestion of using HttpSessionListener instead is 
cleaner.

~ Thank you,
  Paul Bors

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org] 
Sent: Friday, September 27, 2013 4:09 PM
To: users@wicket.apache.org
Cc: d...@wicket.apache.org
Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 
and v4)

Reading your ticket against GF I think GF behaves correctly. But I wonder why 
Tomcat/Jetty don't do this.

So here is what happens:

org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry
looks like :
private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = 
(SessionEntry)getSessionAttribute(getAttributeName());
 if (entry == null && create)
{
bind();
 entry = new SessionEntry(applicationName, getSessionId()); } if (entry != 
null)  { synchronized (entry) { setSessionAttribute(getAttributeName(), entry); 
 } } return entry; }

I think the correct code should be:

private SessionEntry getSessionEntry(boolean create) { SessionEntry entry = 
(SessionEntry)getSessionAttribute(getAttributeName());
 if (entry == null && create)
{
bind();
 entry = new SessionEntry(applicationName, getSessionId()); 
setSessionAttribute(getAttributeName(), entry);  } return entry; } I.e. set the 
SessionEntry as an attribute in the http session only when it is created.

Because with the current code we call
"setSessionAttribute(getAttributeName(), entry);" even with already existing 
entries and this leads to notifications to HttpSessionBindingListener - new 
value is bound, old value is removed.

I guess Tomcat and Jetty optimize this by doing identity check.

Another solution would be SessionEntry to implement HttpSessionListener instead 
and check the sessionId of the unbound session against its own one and clean 
the data store if they are equal.





On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors  wrote:

> Created https://java.net/jira/browse/GLASSFISH-20828
> "HttpSessionBindingListener.valueUnbound() is always called right 
> after
> valueBound() with a null HttpSessionBindingEvent.getValue()"
>
> Let's see what becomes of this...
>
>
>
> -
> ~ Thank you,
> p...@bors.ws
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-excep
> tions-in-Wicket-6-10-0-tp4661502p4661582.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: wicket + autowired annotation

[miguel]

If you are using _only_ spring and no wicket you _still_ can't do the "new
ClsDb()" method and have the @Autowired fields populated. You're question
isn't really specific to wicket anymore in that situation.


On Fri, Sep 27, 2013 at 12:32 PM, dan123 [via Apache Wicket] <
ml-node+s1842946n4661583...@n4.nabble.com> wrote:

> Thanks to everybody for help.
>
> Paul Bors wrote
> As far as I can tell you the Spring native annotations work within the
> implementation of a bean you already injected in your wicket component.
> First crate a service for yourself and inject it where needed in Wicket
> via
> @SpringBean. Then inside your service feel free to inject other Spring
> dependencies via Spring's native annotations.
>
>
> It works.
> But I thought, that I can set something (something like a scanning all
> classes) in web.xml or springContext.xml file to scan for all @Autowired
> annotations and it will be autowired in all classes. So why I have to use
> "@SpringBean ClsDb clsDb;" in my HomePage.class and then I can use
> @Autowired in CldDb class. Why I cannon use only "new ClsDb();"? There is
> no way how to autowired all beans?
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
>
> http://apache-wicket.1842946.n4.nabble.com/wicket-autowired-annotation-tp4661529p4661583.html
>  To unsubscribe from wicket + autowired annotation, click 
> here
> .
> NAML
>




--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/wicket-autowired-annotation-tp4661529p4661586.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: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)

[Martin Grigorov]

Reading your ticket against GF I think GF behaves correctly. But I wonder
why Tomcat/Jetty don't do this.

So here is what happens:

org.apache.wicket.page.PageStoreManager.PersistentRequestAdapter#getSessionEntry
looks like :
private SessionEntry getSessionEntry(boolean create)
{
SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName());
 if (entry == null && create)
{
bind();
 entry = new SessionEntry(applicationName, getSessionId());
}
if (entry != null)
 {
synchronized (entry)
{
setSessionAttribute(getAttributeName(), entry);
 }
}
return entry;
}

I think the correct code should be:

private SessionEntry getSessionEntry(boolean create)
{
SessionEntry entry = (SessionEntry)getSessionAttribute(getAttributeName());
 if (entry == null && create)
{
bind();
 entry = new SessionEntry(applicationName, getSessionId());
setSessionAttribute(getAttributeName(), entry);
 }
return entry;
}
I.e. set the SessionEntry as an attribute in the http session only when it
is created.

Because with the current code we call
"setSessionAttribute(getAttributeName(), entry);" even with already
existing entries and this leads to notifications
to HttpSessionBindingListener - new value is bound, old value is removed.

I guess Tomcat and Jetty optimize this by doing identity check.

Another solution would be SessionEntry to implement HttpSessionListener
instead and check the sessionId of the unbound session against its own one
and clean the data store if they are equal.





On Fri, Sep 27, 2013 at 9:20 PM, Paul Bors  wrote:

> Created https://java.net/jira/browse/GLASSFISH-20828
> "HttpSessionBindingListener.valueUnbound() is always called right after
> valueBound() with a null HttpSessionBindingEvent.getValue()"
>
> Let's see what becomes of this...
>
>
>
> -
> ~ Thank you,
> p...@bors.ws
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions-in-Wicket-6-10-0-tp4661502p4661582.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 + autowired annotation

[dan123]

Thanks to everybody for help.


Paul Bors wrote
> As far as I can tell you the Spring native annotations work within the
> implementation of a bean you already injected in your wicket component.
> First crate a service for yourself and inject it where needed in Wicket
> via
> @SpringBean. Then inside your service feel free to inject other Spring
> dependencies via Spring's native annotations.


It works.
But I thought, that I can set something (something like a scanning all
classes) in web.xml or springContext.xml file to scan for all @Autowired
annotations and it will be autowired in all classes. So why I have to use
"@SpringBean ClsDb clsDb;" in my HomePage.class and then I can use
@Autowired in CldDb class. Why I cannon use only "new ClsDb();"? There is no
way how to autowired all beans?



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/wicket-autowired-annotation-tp4661529p4661583.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: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)

[Paul Bors]

Created https://java.net/jira/browse/GLASSFISH-20828
"HttpSessionBindingListener.valueUnbound() is always called right after
valueBound() with a null HttpSessionBindingEvent.getValue()"

Let's see what becomes of this...



-
~ Thank you,
p...@bors.ws
--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions-in-Wicket-6-10-0-tp4661502p4661582.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 turn off email delivery without unsubscribe?

[Paul Bors]

See http://wicket.apache.org/help/email.html and follow the Unsubscribe
link.

>From then on, log in to Nabble with your account to read the list content.

~ Thank you,
  Paul Bors

-Original Message-
From: Ben Stover [mailto:bxsto...@yahoo.co.uk] 
Sent: Friday, September 27, 2013 2:54 PM
To: Wicket Users
Subject: How to turn off email delivery without unsubscribe?

I don't want to receive email delivery from this mailing-list any more.
Instead I want to read posting through nabble forum at

http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

How can I turn off email delivery but keep my permission to post emails by
email?

Ben






-
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

How to turn off email delivery without unsubscribe?

[Ben Stover]

I don't want to receive email delivery from this mailing-list any more.
Instead I want to read posting through nabble forum at

http://apache-wicket.1842946.n4.nabble.com/Users-forum-f1842947.html

How can I turn off email delivery but keep my permission to post emails by 
email?

Ben






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

Re: Translation of wicket properties files

[Martin Grigorov]

Hi,

See
http://stackoverflow.com/questions/7768997/software-for-managing-java-lang-properties-files-for-translation


On Fri, Sep 27, 2013 at 7:42 PM, Filipe Roque <
filipe.ro...@premium-minds.com> wrote:

> Hi, are there any tools to review and translate all the messages in the
>   *.properties.xml wicket files that we have created ?
>
> I am thinking something as Poedit for *.po files.
>
> flip
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

RE: wicket + autowired annotation

[Paul Bors]

Read section 17.2 "Integrating Wicket with Spring" starting on page 176 of
the Free Wicket Guide:
http://wicket.apache.org/learn/books/freeguide.html

As far as I can tell you the Spring native annotations work within the
implementation of a bean you already injected in your wicket component.
First crate a service for yourself and inject it where needed in Wicket via
@SpringBean. Then inside your service feel free to inject other Spring
dependencies via Spring's native annotations.

~ Thank you,
  Paul Bors

-Original Message-
From: miguel [mailto:mig...@thedeanda.com] 
Sent: Friday, September 27, 2013 12:41 PM
To: users@wicket.apache.org
Subject: Re: wicket + autowired annotation

I forgot to also mention...

I've noticed that @Autowired does NOT work whereas @Inject does. Also,
@Value annotations don't work either.



--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/wicket-autowired-annotation-tp466
1529p4661575.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

Translation of wicket properties files

[Filipe Roque]

Hi, are there any tools to review and translate all the messages in the 
  *.properties.xml wicket files that we have created ?

I am thinking something as Poedit for *.po files.

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

Re: wicket + autowired annotation

[miguel]

I forgot to also mention...

I've noticed that @Autowired does NOT work whereas @Inject does. Also,
@Value annotations don't work either.



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/wicket-autowired-annotation-tp4661529p4661575.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: Bunch of Page Expired exceptions in Wicket 6.10.0 (GlassFish v3 and v4)

[Paul Bors]

The closest I came to finding any ticket in GF's queue was:
https://java.net/jira/browse/GLASSFISH-4373 "Remove http session attributes 
only after invoking HttpSessionListener.sessionDestroyed()"

Which was closed with some defensive comment about how GF does obey the servlet 
specs and ...


Now that I knew what to look for I observed the following strange behavior in 
GlassFish v3.

Each time GF is calling o.a.w.p.PageStoreManager.SessionEntry#valueUnbound it's 
calling it in pairs of valueBound() immediate fallowed by valueUnbound() with 
one exception, the HttpSessionBindingEvent#getName() is null for the call to 
valueUnbound().

It's actually always null until the Object is really unbound from the session 
which I tested on Session#invalidateNow() and session timeout.

This is definitely a GF bug, but I am wondering if it's worth the effort to put 
in a condition for the null check on the HttpSessionBindingEvent#getName() 
whenever the valueUnbound() is called inside the default 
PageStoreManager.SessionEntry?

Otherwise I'll just register my own PageStoreManager to go with this fix. It 
might make it easier for me if I could extend just the private SessionEntry, 
but that'll really be a nice to have at this point.

~ Thank you,
  Paul Bors

-Original Message-
From: Paul Bors [mailto:p...@bors.ws] 
Sent: Friday, September 27, 2013 11:04 AM
To: users@wicket.apache.org
Subject: RE: Bunch of Page Expired exceptions in Wicket 6.10.0

I so knew it! It also affects GlassFish v3.1.2.2 which I am using.

Thanks again guys, I'll look into it from my end and see what GF team has to 
say about it.
In the mid time, I'll go back to Wicket 6.10.0 and just register my own 
PageStoreManager.

~ Thank you,
  Paul Bors

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Friday, September 27, 2013 10:09 AM
To: users@wicket.apache.org
Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0

I created a simple app and tested it on these 3 servers + Jetty 8.1.13.
The app shows that SessionEntry#valueUnbound is called only for Glassfish 4.0.
Reading HttpSessionBindingListener's javadoc:

* Causes an object to be notified when it is bound to
 * or unbound from a session. The object is notified
 * by an {@link HttpSessionBindingEvent} object. This may be as a result
 * of a servlet programmer explicitly unbinding an attribute from a session,
 * due to a session being invalidated, or due to a session timing out.

for me this is a bug in GF.

I didn't bother to search in their issue trackers. Usually their servers are 
very slow.
Additionally they do not bother to respond/comment. They just close the ticket 
at some point...

I don't like GF and I will not try to help them.


On Fri, Sep 27, 2013 at 3:43 PM, Sven Meier  wrote:

> Do you have a reference? Do we have to do something about it?
>
> Regards
> Sven
>
>
> On 09/27/2013 10:24 AM, Martin Grigorov wrote:
>
>> It is the buggy Glassfish.
>> Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine.
>> But Glassfish 4.0 (build 89)
>> calls
>> org.apache.wicket.page.**PageStoreManager.SessionEntry#**valueUnbound
>> for
>> any attribute added to the session.
>>
>>
>> On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier  wrote:
>>
>>  Hi,
>>>
>>>
>>>  With this change any kind of attribute added to the http session 
>>> causes

>>> total removal
>>>
>>> a HttpSessionBindingListener listens to removal of itself only. Any 
>>> other session attribute is irrelevant.
>>>
>>> It seems an existing sessionEntry is replaced with a new one:
>>>
>>> org.apache.wicket.page.PageStoreManager$SessionEntry.
>>> valueUnbound(PageStoreManager.java:307)
>>>at
>>> ...
>>>
>>> org.apache.wicket.page.RequestAdapter.setSessionAttribute(**
>>> RequestAdapter.java:89)
>>>at
>>> org.apache.wicket.page.PageStoreManager$
>>> PersistentRequestAdapter.**
>>> getSessionEntry(PageStoreManager.java:378)
>>>
>>>
>>>
>>> The question is why the request adapter does not find the existing 
>>> sessionEntry although it is already there (and then replaced afterwards).
>>>
>>> A quickstart would help to narrow down the problem.
>>>
>>> Sven
>>>
>>>
>>>
>>> On 09/26/2013 11:46 PM, Paul Bors wrote:
>>>
>>>  By rolling back to Wicket 6.9.0 I can confirm that the 
>>> PageStoreManager
 works and I do see my page store content via DiskStoreBrowserPage.

 For a bit more environmental details, I was running my tests on top 
 of GlassFish 3.1.2.2

 Thanks for the heads up Martin!
 For now I'll stick to 6.9.x :)

 ~ Thank you,
 Paul Bors

 -Original Message-
 From: Martin Grigorov [mailto:mgrigo...@apache.org]
 Sent: Thursday, September 26, 2013 5:01 PM
 To: users@wicket.apache.org
 Cc: Sven Meier
 Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0

 The problem seems to be caused by
 http://issues.apache

RE: Bunch of Page Expired exceptions in Wicket 6.10.0

[Paul Bors]

I so knew it! It also affects GlassFish v3.1.2.2 which I am using.

Thanks again guys, I'll look into it from my end and see what GF team has to 
say about it.
In the mid time, I'll go back to Wicket 6.10.0 and just register my own 
PageStoreManager.

~ Thank you,
  Paul Bors

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org] 
Sent: Friday, September 27, 2013 10:09 AM
To: users@wicket.apache.org
Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0

I created a simple app and tested it on these 3 servers + Jetty 8.1.13.
The app shows that SessionEntry#valueUnbound is called only for Glassfish 4.0.
Reading HttpSessionBindingListener's javadoc:

* Causes an object to be notified when it is bound to
 * or unbound from a session. The object is notified
 * by an {@link HttpSessionBindingEvent} object. This may be as a result
 * of a servlet programmer explicitly unbinding an attribute from a session,
 * due to a session being invalidated, or due to a session timing out.

for me this is a bug in GF.

I didn't bother to search in their issue trackers. Usually their servers are 
very slow.
Additionally they do not bother to respond/comment. They just close the ticket 
at some point...

I don't like GF and I will not try to help them.


On Fri, Sep 27, 2013 at 3:43 PM, Sven Meier  wrote:

> Do you have a reference? Do we have to do something about it?
>
> Regards
> Sven
>
>
> On 09/27/2013 10:24 AM, Martin Grigorov wrote:
>
>> It is the buggy Glassfish.
>> Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine.
>> But Glassfish 4.0 (build 89)
>> calls 
>> org.apache.wicket.page.**PageStoreManager.SessionEntry#**valueUnbound
>> for
>> any attribute added to the session.
>>
>>
>> On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier  wrote:
>>
>>  Hi,
>>>
>>>
>>>  With this change any kind of attribute added to the http session 
>>> causes

>>> total removal
>>>
>>> a HttpSessionBindingListener listens to removal of itself only. Any 
>>> other session attribute is irrelevant.
>>>
>>> It seems an existing sessionEntry is replaced with a new one:
>>>
>>> org.apache.wicket.page.PageStoreManager$SessionEntry.
>>> valueUnbound(PageStoreManager.java:307)
>>>at
>>> ...
>>>
>>> org.apache.wicket.page.RequestAdapter.setSessionAttribute(**
>>> RequestAdapter.java:89)
>>>at
>>> org.apache.wicket.page.PageStoreManager$
>>> PersistentRequestAdapter.**
>>> getSessionEntry(PageStoreManager.java:378)
>>>
>>>
>>>
>>> The question is why the request adapter does not find the existing 
>>> sessionEntry although it is already there (and then replaced afterwards).
>>>
>>> A quickstart would help to narrow down the problem.
>>>
>>> Sven
>>>
>>>
>>>
>>> On 09/26/2013 11:46 PM, Paul Bors wrote:
>>>
>>>  By rolling back to Wicket 6.9.0 I can confirm that the 
>>> PageStoreManager
 works and I do see my page store content via DiskStoreBrowserPage.

 For a bit more environmental details, I was running my tests on top 
 of GlassFish 3.1.2.2

 Thanks for the heads up Martin!
 For now I'll stick to 6.9.x :)

 ~ Thank you,
 Paul Bors

 -Original Message-
 From: Martin Grigorov [mailto:mgrigo...@apache.org]
 Sent: Thursday, September 26, 2013 5:01 PM
 To: users@wicket.apache.org
 Cc: Sven Meier
 Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0

 The problem seems to be caused by
 http://issues.apache.org/jira/browse/WICKET-5164
 
 >

 With this change any kind of attribute added to the http session 
 causes total removal of all data from the disk store.
 This looks quite serious.

 @Sven: can you take a look.


 On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors  wrote:

   Hey Martin,

>
>
> So I put in my breakpoint and it looks like that my page store is 
> always empty, is always being invalidated by two repeated stack 
> traces that come in the following order:
>
>
>
> http-thread-pool-5311(1)@8339 daemon, prio=5, in group 
> 'grizzly-kernel',
> status: 'RUNNING'
>
> at
> org.apache.wicket.pageStore.DefaultPageStore.**
> removePageData(DefaultPag
> eStore.java:109)
>
> at
> org.apache.wicket.pageStore.DefaultPageStore.unbind(**
> DefaultPageStore.j
> ava:161)
>
> at
> org.apache.wicket.page.PageStoreManager$SessionEntry.
> valueUnbound(Page
> StoreManager.java:307)
>
> at
> org.apache.catalina.session.StandardSession.setAttribute(
> StandardSessi
> on.java:1738)
>
> 

RE: Bunch of Page Expired exceptions in Wicket 6.10.0

[Paul Bors]

No, I mean TabbedPanel or the Ajax equivalent.
http://www.wicket-library.com/wicket-examples/compref/wicket/bookmarkable/or
g.apache.wicket.examples.compref.TabbedPanelPage;jsessionid=1D5D59D85C73C7FA
E205D7C7C0154C5A?0

However, this is simply reproducible via any access to a page from the disk
store since it's always empty such as submitting a form twice in a row or
using the back button in the browser.

~ Thank you,
  Paul Bors


-Original Message-
From: miguel [mailto:mig...@thedeanda.com] 
Sent: Friday, September 27, 2013 2:20 AM
To: users@wicket.apache.org
Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0

by tabs do you mean browser tabs?

if you have 2 tabs:

http://localhost:8080/Foo

and

http://localhost:8081/Bar

then reloading each tab will often invalidate the previous tab. the session
cookie is overwritten.



--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Bunch-of-Page-Expired-exceptions-
in-Wicket-6-10-0-tp4661502p4661540.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: Bunch of Page Expired exceptions in Wicket 6.10.0

[Martin Grigorov]

I created a simple app and tested it on these 3 servers + Jetty 8.1.13.
The app shows that SessionEntry#valueUnbound is called only for Glassfish
4.0.
Reading HttpSessionBindingListener's javadoc:

* Causes an object to be notified when it is bound to
 * or unbound from a session. The object is notified
 * by an {@link HttpSessionBindingEvent} object. This may be as a result
 * of a servlet programmer explicitly unbinding an attribute from a session,
 * due to a session being invalidated, or due to a session timing out.

for me this is a bug in GF.

I didn't bother to search in their issue trackers. Usually their servers
are very slow.
Additionally they do not bother to respond/comment. They just close the
ticket at some point...

I don't like GF and I will not try to help them.


On Fri, Sep 27, 2013 at 3:43 PM, Sven Meier  wrote:

> Do you have a reference? Do we have to do something about it?
>
> Regards
> Sven
>
>
> On 09/27/2013 10:24 AM, Martin Grigorov wrote:
>
>> It is the buggy Glassfish.
>> Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine.
>> But Glassfish 4.0 (build 89)
>> calls org.apache.wicket.page.**PageStoreManager.SessionEntry#**valueUnbound
>> for
>> any attribute added to the session.
>>
>>
>> On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier  wrote:
>>
>>  Hi,
>>>
>>>
>>>  With this change any kind of attribute added to the http session causes

>>> total removal
>>>
>>> a HttpSessionBindingListener listens to removal of itself only. Any other
>>> session attribute is irrelevant.
>>>
>>> It seems an existing sessionEntry is replaced with a new one:
>>>
>>> org.apache.wicket.page.PageStoreManager$SessionEntry.
>>> valueUnbound(PageStoreManager.java:307)
>>>at
>>> ...
>>>
>>> org.apache.wicket.page.RequestAdapter.setSessionAttribute(**
>>> RequestAdapter.java:89)
>>>at
>>> org.apache.wicket.page.PageStoreManager$
>>> PersistentRequestAdapter.**
>>> getSessionEntry(PageStoreManager.java:378)
>>>
>>>
>>>
>>> The question is why the request adapter does not find the existing
>>> sessionEntry although it is already there (and then replaced afterwards).
>>>
>>> A quickstart would help to narrow down the problem.
>>>
>>> Sven
>>>
>>>
>>>
>>> On 09/26/2013 11:46 PM, Paul Bors wrote:
>>>
>>>  By rolling back to Wicket 6.9.0 I can confirm that the PageStoreManager
 works and I do see my page store content via DiskStoreBrowserPage.

 For a bit more environmental details, I was running my tests on top of
 GlassFish 3.1.2.2

 Thanks for the heads up Martin!
 For now I'll stick to 6.9.x :)

 ~ Thank you,
 Paul Bors

 -Original Message-
 From: Martin Grigorov [mailto:mgrigo...@apache.org]
 Sent: Thursday, September 26, 2013 5:01 PM
 To: users@wicket.apache.org
 Cc: Sven Meier
 Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0

 The problem seems to be caused by
 http://issues.apache.org/jira/browse/WICKET-5164
 
 >

 With this change any kind of attribute added to the http session causes
 total removal of all data from the disk store.
 This looks quite serious.

 @Sven: can you take a look.


 On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors  wrote:

   Hey Martin,

>
>
> So I put in my breakpoint and it looks like that my page store is
> always empty, is always being invalidated by two repeated stack traces
> that come in the following order:
>
>
>
> http-thread-pool-5311(1)@8339 daemon, prio=5, in group
> 'grizzly-kernel',
> status: 'RUNNING'
>
> at
> org.apache.wicket.pageStore.DefaultPageStore.**
> removePageData(DefaultPag
> eStore.java:109)
>
> at
> org.apache.wicket.pageStore.DefaultPageStore.unbind(**
> DefaultPageStore.j
> ava:161)
>
> at
> org.apache.wicket.page.PageStoreManager$SessionEntry.
> valueUnbound(Page
> StoreManager.java:307)
>
> at
> org.apache.catalina.session.StandardSession.setAttribute(
> StandardSessi
> on.java:1738)
>
> at
> org.apache.catalina.session.StandardSessionFacade.**
> setAttribute(Standar
> dSessionFacade.java:178)
>
> at
> org.apache.wicket.session.HttpSessionStore.setAttribute(
> HttpSessionSto
> re.java:344)
>
> at
> org.apache.wicket.Session.setAttribute(Session.java:848)
>
> at
> org.apache.wicket.page.DefaultPageManagerContext.**
> setSessionAttribute(D
> efaultPageManagerContext

Re: Bunch of Page Expired exceptions in Wicket 6.10.0

[Sven Meier]

Do you have a reference? Do we have to do something about it?

Regards
Sven

On 09/27/2013 10:24 AM, Martin Grigorov wrote:

It is the buggy Glassfish.
Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine.
But Glassfish 4.0 (build 89)
calls org.apache.wicket.page.PageStoreManager.SessionEntry#valueUnbound for
any attribute added to the session.


On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier  wrote:


Hi,



With this change any kind of attribute added to the http session causes

total removal

a HttpSessionBindingListener listens to removal of itself only. Any other
session attribute is irrelevant.

It seems an existing sessionEntry is replaced with a new one:

org.apache.wicket.page.**PageStoreManager$SessionEntry.**
valueUnbound(PageStoreManager.**java:307)
   at
...

org.apache.wicket.page.**RequestAdapter.**setSessionAttribute(**
RequestAdapter.java:89)
   at
org.apache.wicket.page.**PageStoreManager$**PersistentRequestAdapter.**
getSessionEntry(**PageStoreManager.java:378)


The question is why the request adapter does not find the existing
sessionEntry although it is already there (and then replaced afterwards).

A quickstart would help to narrow down the problem.

Sven



On 09/26/2013 11:46 PM, Paul Bors wrote:


By rolling back to Wicket 6.9.0 I can confirm that the PageStoreManager
works and I do see my page store content via DiskStoreBrowserPage.

For a bit more environmental details, I was running my tests on top of
GlassFish 3.1.2.2

Thanks for the heads up Martin!
For now I'll stick to 6.9.x :)

~ Thank you,
Paul Bors

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Thursday, September 26, 2013 5:01 PM
To: users@wicket.apache.org
Cc: Sven Meier
Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0

The problem seems to be caused by
http://issues.apache.org/jira/**browse/WICKET-5164
With this change any kind of attribute added to the http session causes
total removal of all data from the disk store.
This looks quite serious.

@Sven: can you take a look.


On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors  wrote:

  Hey Martin,



So I put in my breakpoint and it looks like that my page store is
always empty, is always being invalidated by two repeated stack traces
that come in the following order:



http-thread-pool-5311(1)@8339 daemon, prio=5, in group
'grizzly-kernel',
status: 'RUNNING'

at
org.apache.wicket.pageStore.**DefaultPageStore.**
removePageData(DefaultPag
eStore.java:109)

at
org.apache.wicket.pageStore.**DefaultPageStore.unbind(**
DefaultPageStore.j
ava:161)

at
org.apache.wicket.page.**PageStoreManager$SessionEntry.**
valueUnbound(Page
StoreManager.java:307)

at
org.apache.catalina.session.**StandardSession.setAttribute(**
StandardSessi
on.java:1738)

at
org.apache.catalina.session.**StandardSessionFacade.**
setAttribute(Standar
dSessionFacade.java:178)

at
org.apache.wicket.session.**HttpSessionStore.setAttribute(**
HttpSessionSto
re.java:344)

at
org.apache.wicket.Session.**setAttribute(Session.java:848)

at
org.apache.wicket.page.**DefaultPageManagerContext.**
setSessionAttribute(D
efaultPageManagerContext.java:**99)

at
org.apache.wicket.page.**RequestAdapter.**setSessionAttribute(**
RequestAdapt
er.java:89)

at
org.apache.wicket.page.**PageStoreManager$**
PersistentRequestAdapter.getSe
ssionEntry(PageStoreManager.**java:378)

at
org.apache.wicket.page.**PageStoreManager$**
PersistentRequestAdapter.getPa
ge(PageStoreManager.java:349)

at
org.apache.wicket.page.**AbstractPageManager.getPage(**
AbstractPageManager
.java:107)

at
org.apache.wicket.page.**PageManagerDecorator.getPage(**
PageManagerDecorat
or.java:52)

at
org.apache.wicket.page.**PageAccessSynchronizer$2.**
getPage(PageAccessSync
hronizer.java:257)

at
org.apache.wicket.**DefaultMapperContext.**getPageInstance(**
DefaultMapperCo
ntext.java:148)

at
org.apache.wicket.core.**request.handler.PageProvider.**
getStoredPage(Page
Provider.java:296)

at
org.apache.wicket.core.**request.handler.PageProvider.**
resolvePageInstanc
e(PageProvider.java:261)

at
org.apache.wicket.core.**request.handler.PageProvider.**
getPageInstance(Pa
geProvider.java:166)

at
org.apache.wicket.core.**request.handler.**
ListenerInterfaceRequestHandle**r
.getPage(**ListenerInterfaceRequestHandle**r.java:96)

at
org.apache.wicket.core.**request.handler.**
ListenerInterfaceRequestHandle**r
.respond(**ListenerInterfaceRequestHandle**r.java:157)

at
org.apache.wicket.request.**cycle.RequestCycle$**
Handler

Re: Auto add component

[lc991]

??? I add a wicket component like Label, texfield ecc not html element. 

if i write " getResponse.write("")  " and after i add(new
Label("componentName"))


work?



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Auto-add-component-tp4661566p4661570.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: Auto add component

[Martin Grigorov]

On Fri, Sep 27, 2013 at 2:05 PM, lc991  wrote:

> could I have a mini example? I've used wicket for only 2 months
>

getResponse().write("element");


>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Auto-add-component-tp4661566p4661568.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: Auto add component

[lc991]

could I have a mini example? I've used wicket for only 2 months



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Auto-add-component-tp4661566p4661568.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: Auto add component

[Martin Grigorov]

On Fri, Sep 27, 2013 at 1:56 PM, lc991  wrote:

> hi
>
> I add a component without wicket:id in html page. is this possible?
>
yes

>
>
> bye
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Auto-add-component-tp4661566.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
>
>

Auto add component

[lc991]

hi

I add a component without wicket:id in html page. is this possible?


bye



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/Auto-add-component-tp4661566.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 + autowired annotation

[Kristian Rosenvold]

You cannot use "new" to create a spring bean in you HomePage class.
You must use @SpringBean on "ClsDb"

Kristian


2013/9/26 dan123 :
> Hi,
> I have simple project created from Quickstart, and I have deffined in
> springContext.xml bean named "dbAccess".
> When I use: *@SpringBean private DbAccess dbAccess;* in *class HomePage
> extends WebPage*.
> It works, it creates bean and in constructor "HomePage" class I can access
> to dbAccess.
>
> But when I create class with one method:
> public class ClsDb {
> @Autowired private DbAccess dbAccess;
> public void save() {
>  // ... dbAccess save something
> }
> }
>
> and in HomePage class I use "new ClsDb().save();", "dbAccess" in ClsDb is
> null.
>
> What is neccessary to do for use @Autowired in ClsDb class?
> Thanks.
>
>
>
> --
> View this message in context: 
> http://apache-wicket.1842946.n4.nabble.com/wicket-autowired-annotation-tp4661529.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: UPDATE A COMPONENT INTO DATATABLE

[Martin Grigorov]

Hi,

Please do not use CapsLock next time.


On Fri, Sep 27, 2013 at 11:13 AM, lc991  wrote:

> hi,
>
> I have a dataTable which contains label, textfield and normal property
> columns.
> I should update only labels element.
>
> When i add a label i add a panel which contains a label
> When i add a TextField i add a panel which contains a textField
>
>
What have you tried so far ?
How does it fail ?


>
>
> bye lorenzo
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/UPDATE-A-COMPONENT-INTO-DATATABLE-tp4661556.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
>
>

[ANNOUNCE] Apache Wicket 6.11.0 released!

[Martijn Dashorst]

The Apache Wicket PMC is proud to announce Apache Wicket 6.11.0!

This release marks the eleventh minor release of Wicket 6. Starting
with Wicket 6 we use semantic versioning for the future development
of Wicket, and as such no API breaks are present in this release
compared to 6.0.0.

New and noteworthy
--

* New HTML5Attributes behavior

HTML5 attribute support in Wicket continues to be improved upon. Add
the new HTML5Attributes behavior to your text fields or buttons and
Wicket will add the relevant HTML5 attributes based on the state of
your components:

 - adds "required" if your form component is required
 - adds "placeholder" for the label of your form component
 - adds "pattern" if your form component has a PatternValidator
   attached
 - adds "formnovalidate" if your button has default form processing
   set to false

* BeanValidation receives french translation

The BeanValidation project now has a french translation for
validation errors:

 - Le champ '${label}' ne doit pas être null
 - Le champ '${label}' pourrait contenir du contenu HTML dangereux

Bonne chance!

JQuery update in 6.9.0
--

As of Wicket 6.9 we ship JQuery 1.10.1. The JQuery project has
decided to remove deprecated APIs from their codebase from JQuery 1.9
and up. This means that JQuery plugins using these deprecated APIs no
longer work. See the JQuery migration guide for more information,
available from http://jquery.com/upgrade-guide/1.9/

If your application depends on these deprecated APIs you can easily
downgrade to JQuery 1.8.3-the previously provided JQuery that still
contains these APIs. Download the 1.8.3 release of jquery and add it
to your project in its application's init method:

@Override
protected void init() {
getJavaScriptLibrarySettings()
.setJQueryReference(yourJquery183ResourceReference);
}

CDI injection issue
---

In the CDI releases of Weld 2.0.1 and prior, it was assumed that
injection in anonymous inner classes was not legal and when
attempted, it resulted in an exception:

Caused by: org.jboss.weld.exceptions.DefinitionException:
WELD-70 Simple bean [EnhancedAnnotatedTypeImpl] private class
com.example.HomePage$AForm cannot be a non-static inner class

This was reported as
https://issues.apache.org/jira/browse/WICKET-5226, as it became an
issue in Glassfish 4, which ships with Weld 2.0.1 (or earlier). We
implemented a fix for this particular issue by not injecting into
anonymous inner classes.

Unfortunately this was not a bug that needed fixing on our part, but
rather in the Weld framework (see
https://issues.jboss.org/browse/WELD-1441)

Therefore we reverted the commits done for WICKET-5226 and hope that
Glassfish will upgrade their Weld implementation soon. For the whole
story read
https://issues.apache.org/jira/browse/WICKET-5264

Glassfish has fixed this in trunk according to

https://java.net/jira/browse/GLASSFISH-20619

but the fix has yet to be integrated into a release.

Using this release
--

With Apache Maven update your dependency to (and don't forget to
update any other dependencies on Wicket projects to the same version):


org.apache.wicket
wicket-core
6.11.0


Or download and build the distribution yourself, or use our
convenience binary package

 * Source: http://www.apache.org/dyn/closer.cgi/wicket/6.11.0
 * Binary: http://www.apache.org/dyn/closer.cgi/wicket/6.11.0/binaries

Upgrading from earlier versions
---

If you upgrade from 6.y.z this release is a drop in replacement. If
you come from a version prior to 6.0.0, please read our Wicket 6
migration guide found at

 * https://cwiki.apache.org/confluence/display/WICKET/Migration+to+Wicket+6.0

Have fun!

— The Wicket team

Release Notes - Wicket - Version 6.11.0

** Bug

 * [WICKET-5313] - Wrong HTML attribute used in SizeTagModifier
   (wicket-bean-validation)
 * [WICKET-5315] - PriorityHeaderItem+OnDomReadyHeaderItem has no
   priority in Ajax response
 * [WICKET-5316] - Wicket Atmosphere CouldNotLockPageException
 * [WICKET-5319] - CryptoMapper encrypts external URLs in
   ResourceReferences making the resources inaccessible
 * [WICKET-5322] - "Source code" link doesn't work at wicket-library.com
 * [WICKET-5325] - ComponentRenderer.renderComponent does not
   render markup for ListView
 * [WICKET-5329] - "Required" flag initialized too early in
   PropertyValidator
 * [WICKET-5332] - Autocomplete throws error when initialized in an
   AjaxLazyLoadPanel
 * [WICKET-5334] - KittenCaptcha example is broken in IE10
 * [WICKET-5335] - After selecting a file MultiFileUploadField does
   not render properly input field
 * [WICKET-5339] - Broadcast.EXACT does not notify Behaviors of
   target Component
 * [WICKET-5343] - AutoCompleteTextField suggestions po

UPDATE A COMPONENT INTO DATATABLE

[lc991]

hi,

I have a dataTable which contains label, textfield and normal property
columns.
I should update only labels element.

When i add a label i add a panel which contains a label
When i add a TextField i add a panel which contains a textField



bye lorenzo



--
View this message in context: 
http://apache-wicket.1842946.n4.nabble.com/UPDATE-A-COMPONENT-INTO-DATATABLE-tp4661556.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: Additional ajax request before ajax form submit

[Martin Grigorov]

Hi,


On Fri, Sep 27, 2013 at 10:41 AM, Tom Götz  wrote:

> Hi,
>
> I have the following situation:
> we use a tabpanel (8-10 tabs) to display lots of form components. On tab
> change the content of the activated tab is made visible via ajax, content
> of all other tabs is made invisible (setVisible(false)). To not lose user
> input we do a form submit when changing tabs, with
> setDefaultFormProcessing(false). All fine up to here.
>
> Now: when I submit the form, only the data of the active tab is submitted,
> because all others are invisible at that moment. So I think I need to do an
> additional ajax request


But the data of the invisible ones is already at the server.
It has been uploaded when you switched to the new tab.

I guess you want to validate all form component at the end.
But with your current approach the data is already in the models, without
validation.

One way is to render all form component and use client side tabbed panel
that doesn't use display:none to hide the inactive tabs because this way
the browser won't submit their data.

Another way is to do some custom validation on the model data in
Form#onSubmit() before saving the data in the DB.


> before submitting the form, to set all tab-content visible and after that
> submit the form. Does this sound like a good idea? How would I do that?
>
> Cheers,
>-Tom
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>

Re: Additional ajax request before ajax form submit

[Ernesto Reinaldo Barreiro]

I think that if your are using AJAXTabbedPanel only one tab will be present
at client side at any time: as far as I remember the component does an AJAX
replace when you choose tabs. One alternative would be using a tabs
components that displays all tabs on client and uses JavaScript to make
them visible/invisible.


On Fri, Sep 27, 2013 at 10:41 AM, Tom Götz  wrote:

> Hi,
>
> I have the following situation:
> we use a tabpanel (8-10 tabs) to display lots of form components. On tab
> change the content of the activated tab is made visible via ajax, content
> of all other tabs is made invisible (setVisible(false)). To not lose user
> input we do a form submit when changing tabs, with
> setDefaultFormProcessing(false). All fine up to here.
>
> Now: when I submit the form, only the data of the active tab is submitted,
> because all others are invisible at that moment. So I think I need to do an
> additional ajax request before submitting the form, to set all tab-content
> visible and after that submit the form. Does this sound like a good idea?
> How would I do that?
>
> Cheers,
>-Tom
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>


-- 
Regards - Ernesto Reinaldo Barreiro

Additional ajax request before ajax form submit

[Tom Götz]

Hi,

I have the following situation:
we use a tabpanel (8-10 tabs) to display lots of form components. On tab change 
the content of the activated tab is made visible via ajax, content of all other 
tabs is made invisible (setVisible(false)). To not lose user input we do a form 
submit when changing tabs, with setDefaultFormProcessing(false). All fine up to 
here.

Now: when I submit the form, only the data of the active tab is submitted, 
because all others are invisible at that moment. So I think I need to do an 
additional ajax request before submitting the form, to set all tab-content 
visible and after that submit the form. Does this sound like a good idea? How 
would I do that?

Cheers,
   -Tom



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

Re: Bunch of Page Expired exceptions in Wicket 6.10.0

[Martin Grigorov]

It is the buggy Glassfish.
Jetty 7.6.13 and Tomcat 7.0.45 (being voted atm) work fine.
But Glassfish 4.0 (build 89)
calls org.apache.wicket.page.PageStoreManager.SessionEntry#valueUnbound for
any attribute added to the session.


On Fri, Sep 27, 2013 at 9:41 AM, Sven Meier  wrote:

> Hi,
>
>
> >With this change any kind of attribute added to the http session causes
> total removal
>
> a HttpSessionBindingListener listens to removal of itself only. Any other
> session attribute is irrelevant.
>
> It seems an existing sessionEntry is replaced with a new one:
>
> org.apache.wicket.page.**PageStoreManager$SessionEntry.**
> valueUnbound(PageStoreManager.**java:307)
>   at
> ...
>
> org.apache.wicket.page.**RequestAdapter.**setSessionAttribute(**
> RequestAdapter.java:89)
>   at
> org.apache.wicket.page.**PageStoreManager$**PersistentRequestAdapter.**
> getSessionEntry(**PageStoreManager.java:378)
>
>
> The question is why the request adapter does not find the existing
> sessionEntry although it is already there (and then replaced afterwards).
>
> A quickstart would help to narrow down the problem.
>
> Sven
>
>
>
> On 09/26/2013 11:46 PM, Paul Bors wrote:
>
>> By rolling back to Wicket 6.9.0 I can confirm that the PageStoreManager
>> works and I do see my page store content via DiskStoreBrowserPage.
>>
>> For a bit more environmental details, I was running my tests on top of
>> GlassFish 3.1.2.2
>>
>> Thanks for the heads up Martin!
>> For now I'll stick to 6.9.x :)
>>
>> ~ Thank you,
>>Paul Bors
>>
>> -Original Message-
>> From: Martin Grigorov [mailto:mgrigo...@apache.org]
>> Sent: Thursday, September 26, 2013 5:01 PM
>> To: users@wicket.apache.org
>> Cc: Sven Meier
>> Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0
>>
>> The problem seems to be caused by
>> http://issues.apache.org/jira/**browse/WICKET-5164
>> With this change any kind of attribute added to the http session causes
>> total removal of all data from the disk store.
>> This looks quite serious.
>>
>> @Sven: can you take a look.
>>
>>
>> On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors  wrote:
>>
>>  Hey Martin,
>>>
>>>
>>>
>>> So I put in my breakpoint and it looks like that my page store is
>>> always empty, is always being invalidated by two repeated stack traces
>>> that come in the following order:
>>>
>>>
>>>
>>> http-thread-pool-5311(1)@8339 daemon, prio=5, in group
>>> 'grizzly-kernel',
>>> status: 'RUNNING'
>>>
>>>at
>>> org.apache.wicket.pageStore.**DefaultPageStore.**
>>> removePageData(DefaultPag
>>> eStore.java:109)
>>>
>>>at
>>> org.apache.wicket.pageStore.**DefaultPageStore.unbind(**
>>> DefaultPageStore.j
>>> ava:161)
>>>
>>>at
>>> org.apache.wicket.page.**PageStoreManager$SessionEntry.**
>>> valueUnbound(Page
>>> StoreManager.java:307)
>>>
>>>at
>>> org.apache.catalina.session.**StandardSession.setAttribute(**
>>> StandardSessi
>>> on.java:1738)
>>>
>>>at
>>> org.apache.catalina.session.**StandardSessionFacade.**
>>> setAttribute(Standar
>>> dSessionFacade.java:178)
>>>
>>>at
>>> org.apache.wicket.session.**HttpSessionStore.setAttribute(**
>>> HttpSessionSto
>>> re.java:344)
>>>
>>>at
>>> org.apache.wicket.Session.**setAttribute(Session.java:848)
>>>
>>>at
>>> org.apache.wicket.page.**DefaultPageManagerContext.**
>>> setSessionAttribute(D
>>> efaultPageManagerContext.java:**99)
>>>
>>>at
>>> org.apache.wicket.page.**RequestAdapter.**setSessionAttribute(**
>>> RequestAdapt
>>> er.java:89)
>>>
>>>at
>>> org.apache.wicket.page.**PageStoreManager$**
>>> PersistentRequestAdapter.getSe
>>> ssionEntry(PageStoreManager.**java:378)
>>>
>>>at
>>> org.apache.wicket.page.**PageStoreManager$**
>>> PersistentRequestAdapter.getPa
>>> ge(PageStoreManager.java:349)
>>>
>>>at
>>> org.apache.wicket.page.**AbstractPageManager.getPage(**
>>> AbstractPageManager
>>> .java:107)
>>>
>>>at
>>> org.apache.wicket.page.**PageManagerDecorator.getPage(**
>>> PageManagerDecorat
>>> or.java:52)
>>>
>>>at
>>> org.apache.wicket.page.**PageAccessSynchronizer$2.**
>>> getPage(PageAccessSync
>>> hronizer.java:257)
>>>
>>>at
>>> org.apache.wicket.**DefaultMapperContext.**getPageInstance(**
>>> DefaultMapperCo
>>> ntext.java:148)
>>>
>>>at
>>> org.apache.wicket.core.**request.handler.PageProvider.**
>>> getStoredPage(Page
>>> Provider.java:296)
>>>
>>>at
>>> org.apache.wicket.core.**request.handler.PageProvider.**
>>> resolvePageInstanc
>>> e(PageProvider.java:261)
>>>
>>>at
>>> org.apache.wicket.core.**request.handler.PageProvider.**
>>> getPageInstance(Pa
>>> geProvider.java:166)
>>>
>>>at
>

Re: Bunch of Page Expired exceptions in Wicket 6.10.0

[Sven Meier]

Hi,

>With this change any kind of attribute added to the http session 
causes total removal


a HttpSessionBindingListener listens to removal of itself only. Any 
other session attribute is irrelevant.


It seems an existing sessionEntry is replaced with a new one:

org.apache.wicket.page.PageStoreManager$SessionEntry.valueUnbound(PageStoreManager.java:307)
  at
...
org.apache.wicket.page.RequestAdapter.setSessionAttribute(RequestAdapter.java:89)
  at
org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getSessionEntry(PageStoreManager.java:378)


The question is why the request adapter does not find the existing 
sessionEntry although it is already there (and then replaced afterwards).


A quickstart would help to narrow down the problem.

Sven


On 09/26/2013 11:46 PM, Paul Bors wrote:

By rolling back to Wicket 6.9.0 I can confirm that the PageStoreManager works 
and I do see my page store content via DiskStoreBrowserPage.

For a bit more environmental details, I was running my tests on top of 
GlassFish 3.1.2.2

Thanks for the heads up Martin!
For now I'll stick to 6.9.x :)

~ Thank you,
   Paul Bors

-Original Message-
From: Martin Grigorov [mailto:mgrigo...@apache.org]
Sent: Thursday, September 26, 2013 5:01 PM
To: users@wicket.apache.org
Cc: Sven Meier
Subject: Re: Bunch of Page Expired exceptions in Wicket 6.10.0

The problem seems to be caused by
http://issues.apache.org/jira/browse/WICKET-5164
With this change any kind of attribute added to the http session causes total 
removal of all data from the disk store.
This looks quite serious.

@Sven: can you take a look.


On Thu, Sep 26, 2013 at 10:30 PM, Paul Bors  wrote:


Hey Martin,



So I put in my breakpoint and it looks like that my page store is
always empty, is always being invalidated by two repeated stack traces
that come in the following order:



http-thread-pool-5311(1)@8339 daemon, prio=5, in group
'grizzly-kernel',
status: 'RUNNING'

   at
org.apache.wicket.pageStore.DefaultPageStore.removePageData(DefaultPag
eStore.java:109)

   at
org.apache.wicket.pageStore.DefaultPageStore.unbind(DefaultPageStore.j
ava:161)

   at
org.apache.wicket.page.PageStoreManager$SessionEntry.valueUnbound(Page
StoreManager.java:307)

   at
org.apache.catalina.session.StandardSession.setAttribute(StandardSessi
on.java:1738)

   at
org.apache.catalina.session.StandardSessionFacade.setAttribute(Standar
dSessionFacade.java:178)

   at
org.apache.wicket.session.HttpSessionStore.setAttribute(HttpSessionSto
re.java:344)

   at
org.apache.wicket.Session.setAttribute(Session.java:848)

   at
org.apache.wicket.page.DefaultPageManagerContext.setSessionAttribute(D
efaultPageManagerContext.java:99)

   at
org.apache.wicket.page.RequestAdapter.setSessionAttribute(RequestAdapt
er.java:89)

   at
org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getSe
ssionEntry(PageStoreManager.java:378)

   at
org.apache.wicket.page.PageStoreManager$PersistentRequestAdapter.getPa
ge(PageStoreManager.java:349)

   at
org.apache.wicket.page.AbstractPageManager.getPage(AbstractPageManager
.java:107)

   at
org.apache.wicket.page.PageManagerDecorator.getPage(PageManagerDecorat
or.java:52)

   at
org.apache.wicket.page.PageAccessSynchronizer$2.getPage(PageAccessSync
hronizer.java:257)

   at
org.apache.wicket.DefaultMapperContext.getPageInstance(DefaultMapperCo
ntext.java:148)

   at
org.apache.wicket.core.request.handler.PageProvider.getStoredPage(Page
Provider.java:296)

   at
org.apache.wicket.core.request.handler.PageProvider.resolvePageInstanc
e(PageProvider.java:261)

   at
org.apache.wicket.core.request.handler.PageProvider.getPageInstance(Pa
geProvider.java:166)

   at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler
.getPage(ListenerInterfaceRequestHandler.java:96)

   at
org.apache.wicket.core.request.handler.ListenerInterfaceRequestHandler
.respond(ListenerInterfaceRequestHandler.java:157)

   at
org.apache.wicket.request.cycle.RequestCycle$HandlerExecutor.respond(R
equestCycle.java:861)

   at
org.apache.wicket.request.RequestHandlerStack.execute(RequestHandlerSt
ack.java:64)

   at
org.apache.wicket.request.cycle.RequestCycle.execute(RequestCycle.java
:261)

   at
org.apache.wicket.request.cycle.RequestCycle.processRequest(RequestCyc
le.java:218)

   at
org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(R
equestCycle.java:289)

   at
org.apache.wicket.protocol.http.WicketFilter.processRequestCycle(Wicke
tFilter.java:259)

   at
org.apache.wicket.pro

Re: custom markup from db

[Martin Grigorov]

Hi,

I think there shouldn't be caching involved here.
Put a breakpoint
at 
org.apache.wicket.core.util.resource.locator.caching.CachingResourceStreamLocator#locate
methods and see what happens.


On Fri, Sep 27, 2013 at 8:33 AM, miguel  wrote:

> i'm trying to be a proof-of-concept where I use wicket to use "styles" that
> are loaded from the database. I've managed to get my custom markup to load
> but it seems that its only loaded once then cached (even in dev mode). This
> is what I've tried:
>
> IResourceSettings settings = getResourceSettings();
> settings.setResourcePollFrequency(Duration.seconds(10));
> settings.getResourceFinders().add(0, new
> SkinResourceFinder());
>
> I searched for references to
> IResourceSettings.getResourcePollingFrequency()
> and found this:
>
>
> org.apache.wicket.devutils.inspector - src/main/java - wicket-devutils
> ApplicationView
> ApplicationView(String, Application)
>
> org.apache.wicket.jmx - src/main/java - wicket-jmx
> ResourceSettings
> getResourcePollFrequency()
>
> org.apache.wicket.settings.def - src/main/java - wicket-core
> ResourceSettings
> getResourcePollFrequency()
> getResourceWatcher(boolean)
>
> My guess is that getResourceWatcher(boolean) is where the polling value
> gets
> used but I assume that since polling works in dev mode for normal resource
> finder then there is something else going on. My implementation of
> IResourceFinder basically returns:
>
> return new StringResourceStream(sw.toString(), "text/html");
>
> any ideas?
>
> -m
>
>
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/custom-markup-from-db-tp4661542.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
>
>