Re: Using relative path with HeaderContributor

[Juha Alatalo]

So now things are actually working as they should. Forget this thread, I 
am an idiot.


Thanks and keep up the good work.

- Juha

Juha Alatalo wrote:
Now browser does never find my css-file. What is the "trick" to make 
things work again?


James Carman wrote:

This is not a bug.  The $up$ stuff was put in there to "trick" the
browser into not trying to automatically resolve the ".." for you.
This is necessary for resources.

On Mon, Jun 16, 2008 at 7:02 AM, Juha Alatalo
<[EMAIL PROTECTED]> wrote:

Hi,

We started to use 1.3.X because
https://issues.apache.org/jira/browse/WICKET-1667 will be probably fixed
soon in 1.3.X.

There seems to be some changes in
public static String resourceKey(final String path, final Locale locale,
final String style) in SharedResources.
We have been using following reference to a css-file

public static final CompressedResourceReference MES_CSS = new
CompressedResourceReference(MesFunc.class, 
"../../../somePath/main.css");


public MeasurementDataPage()
{
   super();
   add(HeaderContributor.forCss( MES_CSS ));
}

In 1.3.3 source looked like this:
href="resources/syncrontech.paroc.mes.common.MesFunc/../../../syncrontech/paroc/mes/themes/main.css" 


/>

Now in 1.3.X it looks like this:
href="resources/syncrontech.paroc.mes.common.MesFunc/$up$/$up$/$up$/syncrontech/paroc/mes/themes/main.css" 


/>

Is this a bug or do I have to move all my css files to a such 
location where

.. is not needed?

- Juha



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Using relative path with HeaderContributor

[Juha Alatalo]

Now browser does never find my css-file. What is the "trick" to make 
things work again?


James Carman wrote:

This is not a bug.  The $up$ stuff was put in there to "trick" the
browser into not trying to automatically resolve the ".." for you.
This is necessary for resources.

On Mon, Jun 16, 2008 at 7:02 AM, Juha Alatalo
<[EMAIL PROTECTED]> wrote:

Hi,

We started to use 1.3.X because
https://issues.apache.org/jira/browse/WICKET-1667 will be probably fixed
soon in 1.3.X.

There seems to be some changes in
public static String resourceKey(final String path, final Locale locale,
final String style) in SharedResources.
We have been using following reference to a css-file

public static final CompressedResourceReference MES_CSS = new
CompressedResourceReference(MesFunc.class, "../../../somePath/main.css");

public MeasurementDataPage()
{
   super();
   add(HeaderContributor.forCss( MES_CSS ));
}

In 1.3.3 source looked like this:


Now in 1.3.X it looks like this:


Is this a bug or do I have to move all my css files to a such location where
.. is not needed?

- Juha



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Using relative path with HeaderContributor

[Juha Alatalo]

Hi,

We started to use 1.3.X because 
https://issues.apache.org/jira/browse/WICKET-1667 will be probably fixed 
soon in 1.3.X.


There seems to be some changes in
public static String resourceKey(final String path, final Locale locale, 
final String style) in SharedResources.

We have been using following reference to a css-file

public static final CompressedResourceReference MES_CSS = new 
CompressedResourceReference(MesFunc.class, "../../../somePath/main.css");


public MeasurementDataPage()
{
super();
add(HeaderContributor.forCss( MES_CSS ));
}

In 1.3.3 source looked like this:
href="resources/syncrontech.paroc.mes.common.MesFunc/../../../syncrontech/paroc/mes/themes/main.css" 
/>


Now in 1.3.X it looks like this:
href="resources/syncrontech.paroc.mes.common.MesFunc/$up$/$up$/$up$/syncrontech/paroc/mes/themes/main.css" 
/>


Is this a bug or do I have to move all my css files to a such location 
where .. is not needed?


- Juha



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Localizer cache with 150.000+ entries causing OutOfMemory

[Juha Alatalo]

Hi,

we have been using this patched version now in a production environment 
few days. Seems to be working nicely. Memory problems disappeared.


- Juha

Igor Vaynberg wrote:

if someone can confirm that the patch works in a production env i will
be happy to commit it. i just havent had the time to test it myself
yet.

-igor

On Tue, Jun 10, 2008 at 7:09 AM, Juha Alatalo
<[EMAIL PROTECTED]> wrote:

Hi All,

I run our profiling tests (version 1.3.3) using Application.java and
Localizer.java patched by Stefan. Patch seems to be solving our memory
problems.

Is this patch coming to 1.3.4 and do you have any idea when 1.3.4 will be
released?

Best Regards
- Juha


Stefan Fußenegger wrote:

Hi Daniel,

I didn't put the patch into production yet, but I am quite confident, that
it will help. As you can see in the example I attached to the JIRA issue
(just attached a new version), the unpatched Localizer had 200 entries in
his cache, the patched Localizer only four - which is a Good Thing (tm),
as
there are only 4 different cached values!

Regards, Stefan



Daniel Frisk wrote:

So the patch did help?

I too have observed this problem but it was at the moment less of a
 problem than other heap eaters, now this is next in line. We have  added a
script which automatically restarts the server when repeated  OOME occurs
and are down to a couple of times per week without the  patch. But still,
who wouldn't want to see months of uptime...

// Daniel
jalbum.net


On 2008-06-10, at 11:29, Stefan Fußenegger wrote:


Hi Igor,

Thanks for your quick reply and the patch, sorry for not searching the
mailinglist only but not JIRA.

Your patch was for 1.4, I applied it to 1.3.3, created a quickstart
including JUnit test and attached it to the JIRA issue. Hope this  fix
gets
into the next maintenance release. I am to lazy to create a properly
 patched
jar and a MVN repo for my team right now ;)

Regards, Stefan



igor.vaynberg wrote:

try applying this patch and see if it helps

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

-igor

On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
<[EMAIL PROTECTED]> wrote:

I am just analysing a heap dump (god bless the
-XX:+HeapDumpOnOutOfMemoryError flag) of a recent application  cache
due
to
an OutOfMemoryError ("GC overhead limit exceeded" to be precise).
 Using
jhat, the "175456 instances of class
org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry"
 immediately
got
my attention. While looking through the 107 instance of
ConcurrentHashMap, I
found one *really* big one: Localizer.cache has a hash table  length
of
262144, each of its 32 segments with about 5300 entries, where a  hash
key
is
a string, sometimes longer than 500 charactes, similar to (see
Localizer.getCacheKey(String,Component)):

fooTitle.bar-
org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-
org.apache.wicket.markup.html.panel.Fragment:track-
org.apache.wicket.markup.html.list.ListItem:14-
my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-
org.apache.wicket.markup.html.list.ListItem:0-
my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-
my.company.boxes.BodyBox:2-
org.apache.wicket.markup.repeater.RepeatingView:body-
my.company.layout.Border:border-my.company.pages.music.FoobarPage:
43-de-null

Those numbers pretty much convinced me: The localizer cache has  blown
away
my application.

Looking at this hash keys, I suspect the following problem: those
 strings
are constructed from the "position" of a localized String on a page,
which
is quite a bad thing if you use nested list views or repeating  views
to
construct your page. For instance, I have a panel with a long
 (pageable)
list of entries, might be > 5000 entries which might appear on
 various
positions in a repeating view I use as a container for most of my
 pages.
Let's say there are 5 possible positions, this would cause 2500
 thousand
cached entries, each with a key of 300+ characters plus some more
characters
for the cached message - feel free to do the maths. From a quick
 estimate
I'd say: No wonder, this has blown away my app.

As a quick fix, I'd suggest to regularly clear the localizer  cache,
use a
more sophisticated cache (that expires old entries once in a  while!!)
or
to
disable the cache completely. However, don't try to overwrite
Localizer.newCache() and clear the cache regularly: clearCache()  will
replace your cache with a ConcurrentHashMap (not using
Localizer.newCache()). However, quite unlikely, that this will  happen
as
newCache() is private anyway ;) I am going to add some code to  clear
the
cache regularly.

Best regards, Stefan

PS: I'll also create a JIRA issue, but I am really short on time
 right
now.

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:

http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMem

Re: Localizer cache with 150.000+ entries causing OutOfMemory

[Juha Alatalo]

We are now using patched version of 1.3.X in a production environment 
and usage of memory seems to be much more stable.


Is there still some bug in PageWindowManager? Seems that size of 
idToWindowIndices increases every time WebPage is opened in a browser.


I run jmeter test during last night. It was simulating 50 users which 
opens a page once in a 0 - 60 seconds. Jprofiler was showing as many

IntHashMap$Entry instances as there were samples in jmeter.

- Juha



Igor Vaynberg wrote:

if someone can confirm that the patch works in a production env i will
be happy to commit it. i just havent had the time to test it myself
yet.

-igor

On Tue, Jun 10, 2008 at 7:09 AM, Juha Alatalo
<[EMAIL PROTECTED]> wrote:

Hi All,

I run our profiling tests (version 1.3.3) using Application.java and
Localizer.java patched by Stefan. Patch seems to be solving our memory
problems.

Is this patch coming to 1.3.4 and do you have any idea when 1.3.4 will be
released?

Best Regards
- Juha


Stefan Fußenegger wrote:

Hi Daniel,

I didn't put the patch into production yet, but I am quite confident, that
it will help. As you can see in the example I attached to the JIRA issue
(just attached a new version), the unpatched Localizer had 200 entries in
his cache, the patched Localizer only four - which is a Good Thing (tm),
as
there are only 4 different cached values!

Regards, Stefan



Daniel Frisk wrote:

So the patch did help?

I too have observed this problem but it was at the moment less of a
 problem than other heap eaters, now this is next in line. We have  added a
script which automatically restarts the server when repeated  OOME occurs
and are down to a couple of times per week without the  patch. But still,
who wouldn't want to see months of uptime...

// Daniel
jalbum.net


On 2008-06-10, at 11:29, Stefan Fußenegger wrote:


Hi Igor,

Thanks for your quick reply and the patch, sorry for not searching the
mailinglist only but not JIRA.

Your patch was for 1.4, I applied it to 1.3.3, created a quickstart
including JUnit test and attached it to the JIRA issue. Hope this  fix
gets
into the next maintenance release. I am to lazy to create a properly
 patched
jar and a MVN repo for my team right now ;)

Regards, Stefan



igor.vaynberg wrote:

try applying this patch and see if it helps

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

-igor

On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
<[EMAIL PROTECTED]> wrote:

I am just analysing a heap dump (god bless the
-XX:+HeapDumpOnOutOfMemoryError flag) of a recent application  cache
due
to
an OutOfMemoryError ("GC overhead limit exceeded" to be precise).
 Using
jhat, the "175456 instances of class
org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry"
 immediately
got
my attention. While looking through the 107 instance of
ConcurrentHashMap, I
found one *really* big one: Localizer.cache has a hash table  length
of
262144, each of its 32 segments with about 5300 entries, where a  hash
key
is
a string, sometimes longer than 500 charactes, similar to (see
Localizer.getCacheKey(String,Component)):

fooTitle.bar-
org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink-
org.apache.wicket.markup.html.panel.Fragment:track-
org.apache.wicket.markup.html.list.ListItem:14-
my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos-
org.apache.wicket.markup.html.list.ListItem:0-
my.company.BarListPanel$1:bars-my.company.FooListPanel:panel-
my.company.boxes.BodyBox:2-
org.apache.wicket.markup.repeater.RepeatingView:body-
my.company.layout.Border:border-my.company.pages.music.FoobarPage:
43-de-null

Those numbers pretty much convinced me: The localizer cache has  blown
away
my application.

Looking at this hash keys, I suspect the following problem: those
 strings
are constructed from the "position" of a localized String on a page,
which
is quite a bad thing if you use nested list views or repeating  views
to
construct your page. For instance, I have a panel with a long
 (pageable)
list of entries, might be > 5000 entries which might appear on
 various
positions in a repeating view I use as a container for most of my
 pages.
Let's say there are 5 possible positions, this would cause 2500
 thousand
cached entries, each with a key of 300+ characters plus some more
characters
for the cached message - feel free to do the maths. From a quick
 estimate
I'd say: No wonder, this has blown away my app.

As a quick fix, I'd suggest to regularly clear the localizer  cache,
use a
more sophisticated cache (that expires old entries once in a  while!!)
or
to
disable the cache completely. However, don't try to overwrite
Localizer.newCache() and clear the cache regularly: clearCache()  will
replace your cache with a ConcurrentHashMap (not using
Localizer.newCache()). However, quite unlikely, that this will  happen
as
newCache() is private anyway ;) I am going to add some code to  clear
the
cache regularly.

Bes

Re: Localizer cache with 150.000+ entries causing OutOfMemory

[Juha Alatalo]

Hi All,

I run our profiling tests (version 1.3.3) using Application.java and 
Localizer.java patched by Stefan. Patch seems to be solving our memory 
problems.


Is this patch coming to 1.3.4 and do you have any idea when 1.3.4 will 
be released?


Best Regards
- Juha


Stefan Fußenegger wrote:

Hi Daniel,

I didn't put the patch into production yet, but I am quite confident, that
it will help. As you can see in the example I attached to the JIRA issue
(just attached a new version), the unpatched Localizer had 200 entries in
his cache, the patched Localizer only four - which is a Good Thing (tm), as
there are only 4 different cached values!

Regards, Stefan



Daniel Frisk wrote:

So the patch did help?

I too have observed this problem but it was at the moment less of a  
problem than other heap eaters, now this is next in line. We have  
added a script which automatically restarts the server when repeated  
OOME occurs and are down to a couple of times per week without the  
patch. But still, who wouldn't want to see months of uptime...


// Daniel
jalbum.net


On 2008-06-10, at 11:29, Stefan Fußenegger wrote:


Hi Igor,

Thanks for your quick reply and the patch, sorry for not searching the
mailinglist only but not JIRA.

Your patch was for 1.4, I applied it to 1.3.3, created a quickstart
including JUnit test and attached it to the JIRA issue. Hope this  
fix gets
into the next maintenance release. I am to lazy to create a properly  
patched

jar and a MVN repo for my team right now ;)

Regards, Stefan



igor.vaynberg wrote:

try applying this patch and see if it helps

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

-igor

On Mon, Jun 9, 2008 at 8:11 AM, Stefan Fußenegger
<[EMAIL PROTECTED]> wrote:

I am just analysing a heap dump (god bless the
-XX:+HeapDumpOnOutOfMemoryError flag) of a recent application  
cache due

to
an OutOfMemoryError ("GC overhead limit exceeded" to be precise).  
Using

jhat, the "175456 instances of class
org.apache.wicket.util.concurrent.ConcurrentHashMap$Entry"  
immediately

got
my attention. While looking through the 107 instance of
ConcurrentHashMap, I
found one *really* big one: Localizer.cache has a hash table  
length of
262144, each of its 32 segments with about 5300 entries, where a  
hash key

is
a string, sometimes longer than 500 charactes, similar to (see
Localizer.getCacheKey(String,Component)):

fooTitle.bar- 
org.apache.wicket.markup.html.link.BookmarkablePageLink:fooLink- 
org.apache.wicket.markup.html.panel.Fragment:track- 
org.apache.wicket.markup.html.list.ListItem:14- 
my.company.FooListPanel$1:fooList-my.company.FooListPanel:foos- 
org.apache.wicket.markup.html.list.ListItem:0- 
my.company.BarListPanel$1:bars-my.company.FooListPanel:panel- 
my.company.boxes.BodyBox:2- 
org.apache.wicket.markup.repeater.RepeatingView:body- 
my.company.layout.Border:border-my.company.pages.music.FoobarPage: 
43-de-null


Those numbers pretty much convinced me: The localizer cache has  
blown

away
my application.

Looking at this hash keys, I suspect the following problem: those  
strings

are constructed from the "position" of a localized String on a page,
which
is quite a bad thing if you use nested list views or repeating  
views to
construct your page. For instance, I have a panel with a long  
(pageable)
list of entries, might be > 5000 entries which might appear on  
various
positions in a repeating view I use as a container for most of my  
pages.
Let's say there are 5 possible positions, this would cause 2500  
thousand

cached entries, each with a key of 300+ characters plus some more
characters
for the cached message - feel free to do the maths. From a quick  
estimate

I'd say: No wonder, this has blown away my app.

As a quick fix, I'd suggest to regularly clear the localizer  
cache, use a
more sophisticated cache (that expires old entries once in a  
while!!) or

to
disable the cache completely. However, don't try to overwrite
Localizer.newCache() and clear the cache regularly: clearCache()  
will

replace your cache with a ConcurrentHashMap (not using
Localizer.newCache()). However, quite unlikely, that this will  
happen as
newCache() is private anyway ;) I am going to add some code to  
clear the

cache regularly.

Best regards, Stefan

PS: I'll also create a JIRA issue, but I am really short on time  
right

now.

-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Localizer-cache-with-150.000%2B-entries-causing-OutOfMemory-tp17734931p17734931.html
Sent from the Wicket - User mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





-
--

Re: Wicket:enclosure isn't working with ajax?

[Juha Alatalo]

Ok. That's the answer I was afraid of.

- Juha

Igor Vaynberg wrote:

enclosures dont really work with ajax. you would have to update some
container that the enclosure is in

-igor


On Mon, Mar 31, 2008 at 10:22 AM, Juha Alatalo
<[EMAIL PROTECTED]> wrote:

Hi,

 is there any way to set a component, which is surrounded by
 wicket:enclosure, visible via ajax? setOutputMarkupPlaceholderTag(true);
 doesn't seem to be working when component is surrounded by wicket:enclosure.

 I made a simple example:
 http://download.syncrontech.com/public/EnclosureTest.zip

 Ajax debug:

 INFO: focus set on ajaxLinkb8
 INFO:
 INFO: Initiating Ajax GET request on
 ?wicket:interface=:3:ajaxLink::IBehaviorListener:0:&random=0.6930893807323287
 INFO: Invoking pre-call handler(s)...
 INFO: Received ajax response (160 characters)
 INFO:
 
 INFO: Response parsed. Now invoking steps...
 ERROR: Component with id [[containerb9]] a was not found while trying to
 perform markup update. Make sure you called
 component.setOutputMarkupId(true) on the component whose markup you are
 trying to update.
 INFO: Response processed successfully.
 INFO: Invoking post-call handler(s)...
 INFO: Calling focus on ajaxLinkb8
 INFO: focus removed from ajaxLinkb8

 Should this example be working == Should I create a JIRA issue?

 - Juha

 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Wicket:enclosure isn't working with ajax?

[Juha Alatalo]

Hi,

is there any way to set a component, which is surrounded by 
wicket:enclosure, visible via ajax? setOutputMarkupPlaceholderTag(true); 
doesn't seem to be working when component is surrounded by wicket:enclosure.


I made a simple example:
http://download.syncrontech.com/public/EnclosureTest.zip

Ajax debug:

INFO: focus set on ajaxLinkb8
INFO:
INFO: Initiating Ajax GET request on 
?wicket:interface=:3:ajaxLink::IBehaviorListener:0:&random=0.6930893807323287

INFO: Invoking pre-call handler(s)...
INFO: Received ajax response (160 characters)
INFO:
id="containerb9" >

INFO: Response parsed. Now invoking steps...
ERROR: Component with id [[containerb9]] a was not found while trying to 
perform markup update. Make sure you called 
component.setOutputMarkupId(true) on the component whose markup you are 
trying to update.

INFO: Response processed successfully.
INFO: Invoking post-call handler(s)...
INFO: Calling focus on ajaxLinkb8
INFO: focus removed from ajaxLinkb8

Should this example be working == Should I create a JIRA issue?

- Juha

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release 1.4 with only generics and stop support for 1.3

[Juha Alatalo]

[x] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3

- Juha

Martijn Dashorst wrote:

This thread is for voting only. Use the [discuss] thread for voicing
your opinion or asking questions. This makes counting the votes much
easier.

The discussion on our development list makes it clear that a lot of
folks are anxious for generified models. Most users if not all wish us
to release a quick release which is 1.3 + generics. The consequence is
that the core team will stop to support 1.3, and that everybody that
wishes updates will have to migrate to 1.4, and upgrade to Java 5.

Everybody is invited to vote! Please use

[ ] +1, Wicket 1.4 is 1.3 + generics, drop support for 1.3
[ ] -1, I need a supported version running on Java 1.4

Let your voices be heard!

Martijn


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Adding javascript in html

[Juha Alatalo]

Hi,

we just started using version 1.3.2 and noticed that references to 
js-files without wicket:id doesn't work any more. They were working in 
1.3.1.


code:

src="/syncrontech/common/gate/component/GateConfirm.js">



log:
192.168.2.155 - st [13/Mar/2008:09:29:03 +] "GET 
/wicket//syncrontech/common/gate/component/GateConfirm.js? HTTP/1.1" 404 
1123


I know that we can (and probably should) start using for example 
CompressedResourceReference


new CompressedResourceReference(GateConfirmPanel.class, "GateConfirm.js");
+
add(HeaderContributor.forJavaScript(GATE_CONFIRM_JS));

However is this a bug in 1.3.2?

- Juha


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]