[jira] Commented: (WICKET-3146) Make form inside ModalWindow work without form outside ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-3146?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12932521#action_12932521 ] Matej Knopp commented on WICKET-3146: - This will break if you put any form components into modal window and have the modal window inside a form. If you use form in modal window you always have to put modal window in another form. Wicket will realize this and replace all form tags inside model window with div. The form tag in modal window markup has to be there because when the modal window is shown it is taken out of DOM hierarchy and put as toplevel element. > Make form inside ModalWindow work without form outside ModalWindow > -- > > Key: WICKET-3146 > URL: https://issues.apache.org/jira/browse/WICKET-3146 > Project: Wicket > Issue Type: Improvement > Components: wicket-extensions >Affects Versions: 1.4.10 >Reporter: Frank Klein Koerkamp > Attachments: fix_form_in_modalwindow.diff > > Original Estimate: 0.02h > Remaining Estimate: 0.02h > > Currently is needed to have an Form outside an ModalWindow if you want to use > a Form inside a ModalWindow. > This is not needed when the form tag is not necessary in the ModalWindow > generation javascript js. > Will apply a patch -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in alternate fashion
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12801938#action_12801938 ] Matej Knopp commented on WICKET-2111: - Just keep in mind one thing. We need to remember the markup id after it's rendered. For "standard" markup Id we only need one integer (4 bytes, not a reference). Otherwise it costs lot of state for ajax heavy apps. > Ability to generate markup ids in alternate fashion > --- > > Key: WICKET-2111 > URL: https://issues.apache.org/jira/browse/WICKET-2111 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.3.5, 1.3.6, 1.4-RC3 >Reporter: Berry van Halderen > Fix For: 1.5-M1 > > Attachments: patch, wicket-2111.patch > > > In the attempts to setup integrated testing one particular piece of wicket > code isn't quite extendible enough for our needs, which is the generation of > markup ids by the wicket session class. The ability to extend this > functionality is not limited to the particular use case, I'd like to propose > a small change. > The issue is the following; when a Component has no explicit markup-id set, > the markup id is generated by the Session which has an internal counter and > uses an increment of this to generate a mark-id. The flaw IMHO is that a > Component requests the Session to generate an id, without passing it any > context. Especially the most logical context, i.e. "please session, generate > a markup id for _ME_" is missing. Therefore I'd propose that the > Session.getMarkupId() is passes the Component object for which the markup id > is to be generated. > By default, the operation should remain as is and the Session object falls > back to the default getMarkupId() without parameters, which is already > overrideable. But now you can override the getMarkupId() and generate more > useful markup ids. > In our case, we are able to generate markup ids which contain part of the > hierarchy and in this manner generate stable Ids, namely those which do not > change after several requests. This particular usage may just work for our > case (one page application, no back-button support, etc), but the fundamental > overrideable method to generate more useful IDs is more widely applicable, > hence this change request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2570) Form submitting component is not checked for being enabled during submit
Form submitting component is not checked for being enabled during submit Key: WICKET-2570 URL: https://issues.apache.org/jira/browse/WICKET-2570 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.3 Reporter: Matej Knopp Assignee: Matej Knopp Fix For: 1.4.4 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2432) Sending Ajax datas from Form with MultiPart(true) causing 302 - Moved Temporarily
[ https://issues.apache.org/jira/browse/WICKET-2432?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12758724#action_12758724 ] Matej Knopp commented on WICKET-2432: - Seems to work for me but I only tested it in jetty. Do you get the loop also when running with jetty or is it just those containers? > Sending Ajax datas from Form with MultiPart(true) causing 302 - Moved > Temporarily > - > > Key: WICKET-2432 > URL: https://issues.apache.org/jira/browse/WICKET-2432 > Project: Wicket > Issue Type: Bug > Components: site >Affects Versions: 1.4.1 > Environment: Firefox 3.5.2 >Reporter: Major Peter > Attachments: quickstart.zip > > Original Estimate: 3h > Remaining Estimate: 3h > > When I set the MultiPart to true, then when I try to send the Form via a > Button, I'm getting always an 302 - Moved Temporarily, that's why my code > can't process the Forms datas. > For more details, see: > http://osdir.com/ml/users-wicket.apache.org/2009-08/msg00836.html > Downgrading from 14.1 to 1.4.0 solves the issue. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2460) CLONE -Flash/ExternalInterface does not work in IE if movie is fetched via Wicket/Ajax
CLONE -Flash/ExternalInterface does not work in IE if movie is fetched via
Wicket/Ajax
--
Key: WICKET-2460
URL: https://issues.apache.org/jira/browse/WICKET-2460
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.1
Environment: IE6/7 FlashCS4/AS3
Reporter: Matej Knopp
Assignee: Matej Knopp
Priority: Critical
Fix For: 1.4.2
If Flash movie CS4/AS3 is added with Wicket/Ajax then AS3/ExternalInterface.call
does not return any value event it calls JavaScript functions, also
ExternalInterface.objectID is null.
Suggestion is that wicket-ajax.js:268 (1.4.1) breaks IE+Flash/ExternalInterface:
// place all newly created elements before the old element
while(tempParent.childNodes.length > 0) {
var tempElement = tempParent.childNodes[0];
>> tempParent.removeChild(tempElement); <
parent.insertBefore(tempElement, element);
tempElement = null;
}
This "removeChild" breaks Flash/ExternalInterface in IE. If "removeChild" is
removed then everything works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-2457) Flash/ExternalInterface does not work in IE if movie is fetched via Wicket/Ajax
[
https://issues.apache.org/jira/browse/WICKET-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp closed WICKET-2457.
---
> Flash/ExternalInterface does not work in IE if movie is fetched via
> Wicket/Ajax
> ---
>
> Key: WICKET-2457
> URL: https://issues.apache.org/jira/browse/WICKET-2457
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.1
> Environment: IE6/7 FlashCS4/AS3
>Reporter: Heikki Uotinen
>Assignee: Matej Knopp
>Priority: Critical
> Fix For: 1.4.2
>
> Attachments: noname.zip
>
>
> If Flash movie CS4/AS3 is added with Wicket/Ajax then
> AS3/ExternalInterface.call
> does not return any value event it calls JavaScript functions, also
> ExternalInterface.objectID is null.
> Suggestion is that wicket-ajax.js:268 (1.4.1) breaks
> IE+Flash/ExternalInterface:
> // place all newly created elements before the old element
> while(tempParent.childNodes.length > 0) {
> var tempElement = tempParent.childNodes[0];
> >> tempParent.removeChild(tempElement); <
> parent.insertBefore(tempElement, element);
> tempElement = null;
> }
> This "removeChild" breaks Flash/ExternalInterface in IE. If "removeChild" is
> removed then everything works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2457) Flash/ExternalInterface does not work in IE if movie is fetched via Wicket/Ajax
[
https://issues.apache.org/jira/browse/WICKET-2457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-2457.
-
Resolution: Fixed
Fix Version/s: 1.4.2
> Flash/ExternalInterface does not work in IE if movie is fetched via
> Wicket/Ajax
> ---
>
> Key: WICKET-2457
> URL: https://issues.apache.org/jira/browse/WICKET-2457
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4.1
> Environment: IE6/7 FlashCS4/AS3
>Reporter: Heikki Uotinen
>Assignee: Matej Knopp
>Priority: Critical
> Fix For: 1.4.2
>
> Attachments: noname.zip
>
>
> If Flash movie CS4/AS3 is added with Wicket/Ajax then
> AS3/ExternalInterface.call
> does not return any value event it calls JavaScript functions, also
> ExternalInterface.objectID is null.
> Suggestion is that wicket-ajax.js:268 (1.4.1) breaks
> IE+Flash/ExternalInterface:
> // place all newly created elements before the old element
> while(tempParent.childNodes.length > 0) {
> var tempElement = tempParent.childNodes[0];
> >> tempParent.removeChild(tempElement); <
> parent.insertBefore(tempElement, element);
> tempElement = null;
> }
> This "removeChild" breaks Flash/ExternalInterface in IE. If "removeChild" is
> removed then everything works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Deleted: (WICKET-2460) CLONE -Flash/ExternalInterface does not work in IE if movie is fetched via Wicket/Ajax
[
https://issues.apache.org/jira/browse/WICKET-2460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp deleted WICKET-2460:
> CLONE -Flash/ExternalInterface does not work in IE if movie is fetched via
> Wicket/Ajax
> --
>
> Key: WICKET-2460
> URL: https://issues.apache.org/jira/browse/WICKET-2460
> Project: Wicket
> Issue Type: Bug
> Environment: IE6/7 FlashCS4/AS3
>Reporter: Matej Knopp
>Assignee: Matej Knopp
>Priority: Critical
>
> If Flash movie CS4/AS3 is added with Wicket/Ajax then
> AS3/ExternalInterface.call
> does not return any value event it calls JavaScript functions, also
> ExternalInterface.objectID is null.
> Suggestion is that wicket-ajax.js:268 (1.4.1) breaks
> IE+Flash/ExternalInterface:
> // place all newly created elements before the old element
> while(tempParent.childNodes.length > 0) {
> var tempElement = tempParent.childNodes[0];
> >> tempParent.removeChild(tempElement); <
> parent.insertBefore(tempElement, element);
> tempElement = null;
> }
> This "removeChild" breaks Flash/ExternalInterface in IE. If "removeChild" is
> removed then everything works fine.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2437) Ajax requests are called serially using only one channel (Channel busy - postponing...)
[ https://issues.apache.org/jira/browse/WICKET-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748408#action_12748408 ] Matej Knopp commented on WICKET-2437: - There is no way to process parallel requests for a single page without locking. Pages are not thread safe. > Ajax requests are called serially using only one channel (Channel busy - > postponing...) > --- > > Key: WICKET-2437 > URL: https://issues.apache.org/jira/browse/WICKET-2437 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.4.0 >Reporter: Rodrigo De Castro >Assignee: Matej Knopp > > I have several lazy load panel that load DynamicImageResource objects. They > are always loaded in serial mode. These are the debug messages: > INFO: Initiating Ajax GET request on > ../?wicket:interface=:3:tabpanel:panel:app_graph_panel:1:graph::IBehaviorListener:0:1&random=0.7774967316771 > INFO: Invoking pre-call handler(s)... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Received ajax response (2665 characters) > After checking the code, it seems that every Ajax code in Wicket does not > specify the channel when calling wicketAjaxGet. By doing that, all the > requests end up in the default queue, being executed serially. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2437) Ajax requests are called serially using only one channel (Channel busy - postponing...)
[ https://issues.apache.org/jira/browse/WICKET-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12748293#action_12748293 ] Matej Knopp commented on WICKET-2437: - It does not matter if the requests on client are fired in parallel because we are locking on the pagemap so they will be serialized on server. They have to be. So the only "benefit" of parallel request is that the execution order will be non-deterministic. > Ajax requests are called serially using only one channel (Channel busy - > postponing...) > --- > > Key: WICKET-2437 > URL: https://issues.apache.org/jira/browse/WICKET-2437 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.4.0 >Reporter: Rodrigo De Castro >Assignee: Matej Knopp > > I have several lazy load panel that load DynamicImageResource objects. They > are always loaded in serial mode. These are the debug messages: > INFO: Initiating Ajax GET request on > ../?wicket:interface=:3:tabpanel:panel:app_graph_panel:1:graph::IBehaviorListener:0:1&random=0.7774967316771 > INFO: Invoking pre-call handler(s)... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Channel busy - postponing... > INFO: Received ajax response (2665 characters) > After checking the code, it seems that every Ajax code in Wicket does not > specify the channel when calling wicketAjaxGet. By doing that, all the > requests end up in the default queue, being executed serially. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2214) Form tag in ModalWindow html code causes nested html forms when ModalWindow is used with panel that contain forms
[ https://issues.apache.org/jira/browse/WICKET-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738433#action_12738433 ] Matej Knopp commented on WICKET-2214: - If you have form inside your modal window the modal window itself needs to be placed in another form. > Form tag in ModalWindow html code causes nested html forms when ModalWindow > is used with panel that contain forms > - > > Key: WICKET-2214 > URL: https://issues.apache.org/jira/browse/WICKET-2214 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.5, 1.3.6, 1.4-RC2 >Reporter: Jor >Assignee: Matej Knopp > Attachments: modal.js.patch > > > There is an extra form tag in modal window html code (modal.js -> > Wicket.Window.getMarkup function), it causes problems when ModalWindow is > used with panel that contain forms. > I haven't found any use for that form tag as it cannot be referenced from > java code (it has no wicket id) and it only causes problems by creating > nested form tags (outter form from modal html with no wicket id and inner > form from panel with wicket id) that some browsers cant handle and its > againts W3C html specification. > I had to replace it with div tag to get my panel working. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1600) Wicket tree improvement
[ https://issues.apache.org/jira/browse/WICKET-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12735745#action_12735745 ] Matej Knopp commented on WICKET-1600: - But we only update portions that have actually changed (even though we need to send entire rows). The problem is that there is lot of generated markup for each row. Only way around here would be to send tree data and build the markup on client. But that would mean you can't put wicket components in nodes. Also the swing TreeModel is not very nice interface but it does it's job. It's much better now in wicket then it was since i was able to get rid of TreeNode - so now any object can be a node. And for simple implementation all you need is to implement 5 simple methods if you want to build it from scratch. Tracking changes is bit more difficult but if you look like TreeModelListener it does look pretty sane. Even though probably more complex as it need to be for our needs. However we need to be able to track changes to model to be able to do partial updates. Partial updates are the key point of wicket's AbstractTree. For 1.5 it would be nice to get rid of the swing classes simplifying the model, but only if we can build an adapter so that swing tree model can still be used. > Wicket tree improvement > --- > > Key: WICKET-1600 > URL: https://issues.apache.org/jira/browse/WICKET-1600 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-M1 >Reporter: Sven Meier >Assignee: Matej Knopp >Priority: Minor > Fix For: 1.5-M1 > > Attachments: tree.diff > > > I see the following issues with Wicket's tree implementation that should be > solved: > AbstractTree and its subclasses were written with the Swing JTree API in > mind. This is not a bad thing per se, but the JTree abstractions are not very > well suited for a web application. Matej recently removed some of these > dependencies, but there's still a lot of code that uses TreeNode, > TreeModelEvent and such. > AbstractTree holds a TreeModel in its model, attaching a listener to it. This > is an unusual approach for a Wicket component: > - It implies that changes in the TreeModel are automatically propagated to > the user interface. This is not always the case, as in an ajax request the > AbstractTree has to be explicitely notified to update itself. > - It requires the AbstractTree to monitor the model for a replaced TreeModel. > Most importantly the TreeModel API is complicated and ambiguous (just see the > javadoc of TreeModelEvent and TreeModelListener) which makes life harder > especially for those who want to use AbstractTree with their own TreeModel > implementation (which is difficult enough). Although not directly visible in > the API, an implementor has to privide the parent of a node - see > AbstractTree#getParentNode(). Tree listeners and events are an annoyance > which doesn't match Wicket's elegance. > Currently many components in the AbstractTree hierarchy hold a reference to > real nodes of the TreeModel (e.g. junctionLink). TreeState seems like a > foreign concept to Wicket, holding references to nodes too. To support > detachment AbstractTree tests wether a node implements IDetachable, > effectively duplicating functionality that is normally provider by Component > and its model out of the box. > The nodes are currently used to identify state (e.g. the parent) in the tree. > To add a node, the nodes have to implement equals() and hashCode() to be > correctly identified in the tree state. This might be unacceptable, e.g. if > entities (business objects) are used as nodes, probably loaded from a > database. > Therefore I propose to refactor AbstractTree and subclasses as follows: > A new interface INodeProvider (similar to IDataProvider) defines a concise > API to define a tree of nodes. The method #model(Object) gives an implementor > the possibility to wrap nodes in a suitable model, e.g. a detachable one. The > provided model can handle #equal() and #hashcode() for identification of > nodes in the tree. > References to nodes are always indirect through the model, never to the real > node object. > Handling of node parents is completely managed inside AbstractTree, no need > for an ExtendedTreeModel. > The model of an AbstractTree is used for node selection, similar to > AbstractChoices. > Listeners are replaced with notification methods on AbstractTree. No need for > tree paths on changes. > Expansion state is held in the AbstracTree#TreeItems (instead of former > ITreeState) - similar to component visibility. > The attached patch tries to achieve all this (or at least show how a solution > could look like), additionally: > - AbstractTree now utilizes AbstractRepeater and > #setOu
[jira] Commented: (WICKET-2384) OutOfMemoryError occur for memory leak on FeedbackPanel & FeedbackMessages
[
https://issues.apache.org/jira/browse/WICKET-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733722#action_12733722
]
Matej Knopp commented on WICKET-2384:
-
I've committed a fix, can you check if it helps your problem?
> OutOfMemoryError occur for memory leak on FeedbackPanel & FeedbackMessages
> --
>
> Key: WICKET-2384
> URL: https://issues.apache.org/jira/browse/WICKET-2384
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.6, 1.4-RC7
> Environment: reproduceable on wicket-1.4-rc7(current newest) and
> wicket-1.3.6(current newest release of 1.3 series). tested on Windows XP and
> Mac OS X
>Reporter: Tsutomu YANO
>Priority: Critical
> Attachments: wickettestapp.tar.gz
>
>
> When I uses component.info() method to display a message, my program stopped
> by OutOfMemoryError or StackOverflowError.
> I create a sample application to show this problem. Open attached tar.gz
> file(including a maven project) and run.
> check 'submit continuously' checkbox and click 'register' button.
> The program will display current session size continuously on console. the
> size will be increased, and finally program will be
> stopped with OutOfMemoryError or StackOverflowError.
> But if you changes only one line, this program will not be stopped.
> ---original code---
> private SubmitLink insertLink = new SubmitLink("insertLink") {
> public void onSubmit() {
> info("message");
> setResponsePage(new Test(testFormBean));
> Session session = Session.get();
> long size = session.getSizeInBytes();
> LOGGER.info("SESSION SIZE: {}", size);
> }
> };
> -
> ---changed--
> private SubmitLink insertLink = new SubmitLink("insertLink") {
> public void onSubmit() {
> Session.get().info("message"); //CHANGED!!!
> setResponsePage(new Test(testFormBean));
> Session session = Session.get();
> long size = session.getSizeInBytes();
> LOGGER.info("SESSION SIZE: {}", size);
> }
> };
>
>so component's info() method is the reason of this problem. If you
> commented out 'info()' line, this program never crashed.
>We found out the reason of this problem in a static inner class
> 'MessageListView' in FeedbackPanel.
> MessageListView uses annonimous inner class of Model (named ad
> 'replacementModel'), and it imports a FeedbackMessage object from
> enclosing instance. FeedbackPanel holds this annonimous inner class and the
> annonimous inner class holds a FeedbackMessage.
> When we use component's info() method, the component is assigned into
> FeedbackMessage object as a 'reporter' object. so, all of
> FeedbackMessage objects have a component instance inside of himself as
> 'reporter' (only one exception: if you use Session.get().info()
> method instead of component's info() method, 'reporter' object become null).
> All already-displayed FeedbackMessages will be purged at 'detach' time from
> Session object. But FeedbackPanel holds FeedbackMessages.
> So when page is serialized, all FeedbackMessages, all 'reporter' components
> is serialized. This is the reason of this problem.
> We can solve this problem if we do not hold FeedbackMessage instance in the
> annnonimous inner class.
> change the code of FeedbackPanel as bellow (this code is based on
> FeedbackPanel class of wicket 1.4-rc7, line 70):
> original code -
> @Override
> protected void populateItem(final ListItem listItem)
> {
> final FeedbackMessage message = listItem.getModelObject();
> message.markRendered();
> final IModel replacementModel = new Model()
> {
> private static final long serialVersionUID = 1L;
> /**
> * Returns feedbackPanel + the message level, eg
> 'feedbackPanelERROR'. This is used
> * as the class of the li / span elements.
> *
> * @see org.apache.wicket.model.IModel#getObject()
> */
> @Override
> public String getObject()
> {
> return getCSSClass(message);
> }
> };
> final Component label = newMessageDisplayComponent("message", message);
> final AttributeModifier levelModifier = new AttributeModifier("class",
> replacementModel);
> label.add(levelModifier);
> listItem.add(levelModifier);
> listItem.add(label);
> }
>
> fixed code
> @Override
> protected void populateItem(final ListItem listItem)
> {
> //FIXED message must not be 'final'. It must not be used in inner class.
> //If message could be used in inn
[jira] Commented: (WICKET-2384) OutOfMemoryError occur for memory leak on FeedbackPanel & FeedbackMessages
[
https://issues.apache.org/jira/browse/WICKET-2384?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733713#action_12733713
]
Matej Knopp commented on WICKET-2384:
-
Problem is that we keep reference to FeedbackMessage in component inside
MessageListView item. The feedback message references previous page - that
causes the problem, because the previous page is serialized together with
current (and the page before, etc).
Simply removing components from MessageListView should fix the problem.
class MessageListView
{
...
@Override
protected void onDetach()
{
removeAll();
super.onDetach();
}
}
> OutOfMemoryError occur for memory leak on FeedbackPanel & FeedbackMessages
> --
>
> Key: WICKET-2384
> URL: https://issues.apache.org/jira/browse/WICKET-2384
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.6, 1.4-RC7
> Environment: reproduceable on wicket-1.4-rc7(current newest) and
> wicket-1.3.6(current newest release of 1.3 series). tested on Windows XP and
> Mac OS X
>Reporter: Tsutomu YANO
>Priority: Critical
> Attachments: wickettestapp.tar.gz
>
>
> When I uses component.info() method to display a message, my program stopped
> by OutOfMemoryError or StackOverflowError.
> I create a sample application to show this problem. Open attached tar.gz
> file(including a maven project) and run.
> check 'submit continuously' checkbox and click 'register' button.
> The program will display current session size continuously on console. the
> size will be increased, and finally program will be
> stopped with OutOfMemoryError or StackOverflowError.
> But if you changes only one line, this program will not be stopped.
> ---original code---
> private SubmitLink insertLink = new SubmitLink("insertLink") {
> public void onSubmit() {
> info("message");
> setResponsePage(new Test(testFormBean));
> Session session = Session.get();
> long size = session.getSizeInBytes();
> LOGGER.info("SESSION SIZE: {}", size);
> }
> };
> -
> ---changed--
> private SubmitLink insertLink = new SubmitLink("insertLink") {
> public void onSubmit() {
> Session.get().info("message"); //CHANGED!!!
> setResponsePage(new Test(testFormBean));
> Session session = Session.get();
> long size = session.getSizeInBytes();
> LOGGER.info("SESSION SIZE: {}", size);
> }
> };
>
>so component's info() method is the reason of this problem. If you
> commented out 'info()' line, this program never crashed.
>We found out the reason of this problem in a static inner class
> 'MessageListView' in FeedbackPanel.
> MessageListView uses annonimous inner class of Model (named ad
> 'replacementModel'), and it imports a FeedbackMessage object from
> enclosing instance. FeedbackPanel holds this annonimous inner class and the
> annonimous inner class holds a FeedbackMessage.
> When we use component's info() method, the component is assigned into
> FeedbackMessage object as a 'reporter' object. so, all of
> FeedbackMessage objects have a component instance inside of himself as
> 'reporter' (only one exception: if you use Session.get().info()
> method instead of component's info() method, 'reporter' object become null).
> All already-displayed FeedbackMessages will be purged at 'detach' time from
> Session object. But FeedbackPanel holds FeedbackMessages.
> So when page is serialized, all FeedbackMessages, all 'reporter' components
> is serialized. This is the reason of this problem.
> We can solve this problem if we do not hold FeedbackMessage instance in the
> annnonimous inner class.
> change the code of FeedbackPanel as bellow (this code is based on
> FeedbackPanel class of wicket 1.4-rc7, line 70):
> original code -
> @Override
> protected void populateItem(final ListItem listItem)
> {
> final FeedbackMessage message = listItem.getModelObject();
> message.markRendered();
> final IModel replacementModel = new Model()
> {
> private static final long serialVersionUID = 1L;
> /**
> * Returns feedbackPanel + the message level, eg
> 'feedbackPanelERROR'. This is used
> * as the class of the li / span elements.
> *
> * @see org.apache.wicket.model.IModel#getObject()
> */
> @Override
> public String getObject()
> {
> return getCSSClass(message);
> }
> };
> final Component label = newMessageDisplayComponent("message", message);
> final AttributeModifier levelMo
[jira] Commented: (WICKET-2383) Add Button#onError
[ https://issues.apache.org/jira/browse/WICKET-2383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12733395#action_12733395 ] Matej Knopp commented on WICKET-2383: - right now if validation fails only form#onerror is called. This would be called if validation fails. If error() is called inside onsubmit on error wouldn't be called. I think the semantics should be close to ajaxsubmitlinkk#onerror > Add Button#onError > -- > > Key: WICKET-2383 > URL: https://issues.apache.org/jira/browse/WICKET-2383 > Project: Wicket > Issue Type: New Feature >Reporter: Matej Knopp > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2383) Add Button#onError
Add Button#onError -- Key: WICKET-2383 URL: https://issues.apache.org/jira/browse/WICKET-2383 Project: Wicket Issue Type: New Feature Reporter: Matej Knopp -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-2382) Stateless problems
[ https://issues.apache.org/jira/browse/WICKET-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp closed WICKET-2382. --- > Stateless problems > -- > > Key: WICKET-2382 > URL: https://issues.apache.org/jira/browse/WICKET-2382 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Matej Knopp > Fix For: 1.4.1 > > > onBeforeRender is invoked twice when BookmarkableListenerInterface is used > and target component is not added in constructor. > FeedbackPanel loads the messages too soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2382) Stateless problems
[ https://issues.apache.org/jira/browse/WICKET-2382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-2382. - Resolution: Fixed > Stateless problems > -- > > Key: WICKET-2382 > URL: https://issues.apache.org/jira/browse/WICKET-2382 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.4.0 >Reporter: Matej Knopp > Fix For: 1.4.1 > > > onBeforeRender is invoked twice when BookmarkableListenerInterface is used > and target component is not added in constructor. > FeedbackPanel loads the messages too soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2382) Stateless problems
Stateless problems -- Key: WICKET-2382 URL: https://issues.apache.org/jira/browse/WICKET-2382 Project: Wicket Issue Type: Bug Affects Versions: 1.4.0 Reporter: Matej Knopp Fix For: 1.4.1 onBeforeRender is invoked twice when BookmarkableListenerInterface is used and target component is not added in constructor. FeedbackPanel loads the messages too soon. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2268) NullPointerException NPE in DiskPageStore after Session Timeout
[ https://issues.apache.org/jira/browse/WICKET-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729735#action_12729735 ] Matej Knopp commented on WICKET-2268: - committed the fix to 1.3 as well > NullPointerException NPE in DiskPageStore after Session Timeout > --- > > Key: WICKET-2268 > URL: https://issues.apache.org/jira/browse/WICKET-2268 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC2 > Environment: JDK 1.6, Netbeans 6.5 with GlassFish >Reporter: bernard >Assignee: Matej Knopp >Priority: Critical > Fix For: 1.3.7, 1.4-RC6 > > Attachments: ExpiryCrash.zip, session-expire-patch-1.4-rc4.txt > > > A NullPointerException is thrown on an attempt to sumit a login form after > session timeout. > Wicket version 1.4 RC2 > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.getSessionEntry(DiskPageStore.java:661) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.containsPage(DiskPageStore.java:1255) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.containsPage(SecondLevelCacheSessionStore.java:268) > at org.apache.wicket.Session.getPage(Session.java:660) > at > org.apache.wicket.request.target.coding.HybridUrlCodingStrategy.decode(HybridUrlCodingStrategy.java:211) > at > org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:490) > at > org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:184) > at g1.base.MemberApplication$2.resolve(MemberApplication.java:327) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1246) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:498) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:444) > at > org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:159) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:738) > Please refer to the attached testcase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-2268) NullPointerException NPE in DiskPageStore after Session Timeout
[ https://issues.apache.org/jira/browse/WICKET-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp closed WICKET-2268. --- Resolution: Fixed Fix Version/s: 1.3.7 > NullPointerException NPE in DiskPageStore after Session Timeout > --- > > Key: WICKET-2268 > URL: https://issues.apache.org/jira/browse/WICKET-2268 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC2 > Environment: JDK 1.6, Netbeans 6.5 with GlassFish >Reporter: bernard >Assignee: Matej Knopp >Priority: Critical > Fix For: 1.3.7, 1.4-RC6 > > Attachments: ExpiryCrash.zip, session-expire-patch-1.4-rc4.txt > > > A NullPointerException is thrown on an attempt to sumit a login form after > session timeout. > Wicket version 1.4 RC2 > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.getSessionEntry(DiskPageStore.java:661) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.containsPage(DiskPageStore.java:1255) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.containsPage(SecondLevelCacheSessionStore.java:268) > at org.apache.wicket.Session.getPage(Session.java:660) > at > org.apache.wicket.request.target.coding.HybridUrlCodingStrategy.decode(HybridUrlCodingStrategy.java:211) > at > org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:490) > at > org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:184) > at g1.base.MemberApplication$2.resolve(MemberApplication.java:327) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1246) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:498) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:444) > at > org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:159) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:738) > Please refer to the attached testcase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2268) NullPointerException NPE in DiskPageStore after Session Timeout
[ https://issues.apache.org/jira/browse/WICKET-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12727657#action_12727657 ] Matej Knopp commented on WICKET-2268: - Just tried the testcase again works as expected. After clicking sign-in button i get session expiration, no exception. > NullPointerException NPE in DiskPageStore after Session Timeout > --- > > Key: WICKET-2268 > URL: https://issues.apache.org/jira/browse/WICKET-2268 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC2 > Environment: JDK 1.6, Netbeans 6.5 with GlassFish >Reporter: bernard >Assignee: Matej Knopp >Priority: Critical > Fix For: 1.4-RC6 > > Attachments: ExpiryCrash.zip, session-expire-patch-1.4-rc4.txt > > > A NullPointerException is thrown on an attempt to sumit a login form after > session timeout. > Wicket version 1.4 RC2 > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.getSessionEntry(DiskPageStore.java:661) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.containsPage(DiskPageStore.java:1255) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.containsPage(SecondLevelCacheSessionStore.java:268) > at org.apache.wicket.Session.getPage(Session.java:660) > at > org.apache.wicket.request.target.coding.HybridUrlCodingStrategy.decode(HybridUrlCodingStrategy.java:211) > at > org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:490) > at > org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:184) > at g1.base.MemberApplication$2.resolve(MemberApplication.java:327) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1246) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:498) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:444) > at > org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:159) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:738) > Please refer to the attached testcase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1815) Problem rendering not visible Form with OutputMarkupPlaceholderTag
[ https://issues.apache.org/jira/browse/WICKET-1815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12726208#action_12726208 ] Matej Knopp commented on WICKET-1815: - This is fixed in 1.4. Has the fix not been backported to 1.3 branch? > Problem rendering not visible Form with OutputMarkupPlaceholderTag > -- > > Key: WICKET-1815 > URL: https://issues.apache.org/jira/browse/WICKET-1815 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.3 > Environment: Nothing special, i guess. >Reporter: German Morales >Assignee: Matej Knopp >Priority: Minor > > Hi all, > We had suffered an strange behavior, which i would like to share for comments. > We have a Panel (loaded with ajax) with many Forms inside (because each needs > different models). > Some of these Forms are only visible under certain conditions, so we > overwrote isVisible with the condition. > Also, the Panel can be updated, so the Forms have > setOutputMarkupPlaceholderTag(true) to make them visible later. > That triggered a problem in the rendering of the ajax response. > After some investigation, the problem seems to be: > -When a Form is visible, Form#onComponentTag replaces the tag "form" by "div" > (because it's nor the Root form of the page), this works ok. > -When a Form is invisible, Form#onComponentTag is never called. Instead, > Component#render builds the response by itself, using > markupStream.getTag().getName(), which answers the tag "form". > -Then, the ajax response has a mix of "div" and "form". Apparently, all goes > ok until the first "form" is found, then the parsing goes somehow crazy and > this first "form" gets lost from the DOM, and the next forms and divs get > inserted outside (one level in DOM) the main component being replaced by the > ajax call. > We have found no way to fix it in the Form class itself. Component uses > markupStream.getTag() (which answers "form"). That is, it does not ask the > component for the tag to answer, but instead trusts in the HTML side. And we > can't change our html to say "div", because Form also checks (when visible) > that the tag says "form" (checkComponentTag(tag, "form")). > The solution was to put the missbehaving forms inside Panels, which do not > suffer this problem, and then make the panels visible/invisible (also with > OutputMarkupPlaceholderTag). > We have it running now, but we wanted to know if there was some better > solution, or perpahs something should be fixed to prevent future problems, > for example: > -inform somehow if a form is being set as invisible with > setOutputMarkupPlaceholderTag(true)? > -let Component ask itself for the tag to output in case of invisible + > setOutputMarkupPlaceholderTag(true), instead of just putting what the markup > says... then Form could say "no, i want a div here". > -other? > Thanks in advance, > German -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2345) ModalWindow.setResizable(false) does not work after 1.4-rc4
[ https://issues.apache.org/jira/browse/WICKET-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-2345. - Resolution: Fixed Fix Version/s: 1.4-RC6 > ModalWindow.setResizable(false) does not work after 1.4-rc4 > --- > > Key: WICKET-2345 > URL: https://issues.apache.org/jira/browse/WICKET-2345 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4-RC4 > Environment: Windows Vista 64-bit, Tomcat 6.0.18, JDK 16u14 >Reporter: Marcin Palka >Assignee: Matej Knopp >Priority: Minor > Fix For: 1.4-RC6 > > Attachments: ModalWindow.java.patch, quickstart.zip > > > I haven't been able to make a fixed size modal window since I migrated my > application to Wicket 1.4-rc5. The same problem exists while using Wicket > 1.4-rc4. On the other hand everything works just fine with the 1.4rc-2. I > will attach a quickstart that allows to reproduce the problem. > It's looks like that there were some modification made to the ModalWindow > component between rc2 and rc4 because my application crashes when switching > between those two versions. It crashes with an exception as follows: > java.lang.NoSuchMethodError: > nl.stuq.SelectModalWindow.setInitialWidth(I)Lorg/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow. > > A clean and build makes the trick to make it work again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-2345) ModalWindow.setResizable(false) does not work after 1.4-rc4
[ https://issues.apache.org/jira/browse/WICKET-2345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp reassigned WICKET-2345: --- Assignee: Matej Knopp > ModalWindow.setResizable(false) does not work after 1.4-rc4 > --- > > Key: WICKET-2345 > URL: https://issues.apache.org/jira/browse/WICKET-2345 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4-RC4 > Environment: Windows Vista 64-bit, Tomcat 6.0.18, JDK 16u14 >Reporter: Marcin Palka >Assignee: Matej Knopp >Priority: Minor > Attachments: ModalWindow.java.patch, quickstart.zip > > > I haven't been able to make a fixed size modal window since I migrated my > application to Wicket 1.4-rc5. The same problem exists while using Wicket > 1.4-rc4. On the other hand everything works just fine with the 1.4rc-2. I > will attach a quickstart that allows to reproduce the problem. > It's looks like that there were some modification made to the ModalWindow > component between rc2 and rc4 because my application crashes when switching > between those two versions. It crashes with an exception as follows: > java.lang.NoSuchMethodError: > nl.stuq.SelectModalWindow.setInitialWidth(I)Lorg/apache/wicket/extensions/ajax/markup/html/modal/ModalWindow. > > A clean and build makes the trick to make it work again. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2327) URLs created with urlFor(RequestListenerInterface) on a bookmarkable page try to instantiate a new page after the page expired
[ https://issues.apache.org/jira/browse/WICKET-2327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12720322#action_12720322 ] Matej Knopp commented on WICKET-2327: - I think we should be more explicit about this. We should have two methods, one generate url with ListenerInterfaceRequestTarget, another one generate url with BookmrakbleListenerRequestTarget. > URLs created with urlFor(RequestListenerInterface) on a bookmarkable page try > to instantiate a new page after the page expired > -- > > Key: WICKET-2327 > URL: https://issues.apache.org/jira/browse/WICKET-2327 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC4 >Reporter: Ralf Ebert > Fix For: 1.4-RC6 > > Attachments: mvn2327.zip > > > When a component on a bookmarkable page uses urlFor to generate a URL to > receive events, such an url is generated: > http://localhost:8080/?wicket:bookmarkablePage=:somepkg.SomePage&wicket:interface=:12:bla::ISomeEventListener:: > If the given page expires and the URL is opened, Wicket tries to create a new > page instead of throwing a PageExpiredException. This is incorrect in my > opinion, because the URLs intention is to call a listener interface. In my > understanding this cannot happen after the state of the page is lost, so a > PageExpiredException should be thrown in this case (or a "non-bookmarkable" > URL should be generated). > Stack trace: > at > org.apache.wicket.session.DefaultPageFactory.createPage(DefaultPageFactory.java:212) > at > org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:89) > at > org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:306) > at > org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:321) > at > org.apache.wicket.request.target.component.BookmarkableListenerInterfaceRequestTarget.processEvents(BookmarkableListenerInterfaceRequestTarget.java:126) > at > org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:92) > at > org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1240) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1319) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1418) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:544) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:456) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:289) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2127) Javascript function Wicket.replaceAll is unbearably slow
[ https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-2127. - Resolution: Fixed > Javascript function Wicket.replaceAll is unbearably slow > > > Key: WICKET-2127 > URL: https://issues.apache.org/jira/browse/WICKET-2127 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC2 > Environment: Firefox 3.0.5, Opera 9.2 (windows) >Reporter: Sean Patrick Floyd >Assignee: Matej Knopp > Fix For: 1.4-RC6 > > Attachments: wicketReplaceAll.js > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > I use AbstractAjaxTimerBehavior to update many different components on my > pages periodically. > After a while, the browser occupies 50% or more of the system resources. > I used the javascript profiler in firebug and found that Wicket.replaceAll is > responsible for 60+ percent of javascript processing time. > The problem is that sequential string processing is used instead of much > faster regular expressions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-2127) Javascript function Wicket.replaceAll is unbearably slow
[ https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp closed WICKET-2127. --- > Javascript function Wicket.replaceAll is unbearably slow > > > Key: WICKET-2127 > URL: https://issues.apache.org/jira/browse/WICKET-2127 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC2 > Environment: Firefox 3.0.5, Opera 9.2 (windows) >Reporter: Sean Patrick Floyd >Assignee: Matej Knopp > Fix For: 1.4-RC6 > > Attachments: wicketReplaceAll.js > > Original Estimate: 0.5h > Remaining Estimate: 0.5h > > I use AbstractAjaxTimerBehavior to update many different components on my > pages periodically. > After a while, the browser occupies 50% or more of the system resources. > I used the javascript profiler in firebug and found that Wicket.replaceAll is > responsible for 60+ percent of javascript processing time. > The problem is that sequential string processing is used instead of much > faster regular expressions -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2268) NullPointerException NPE in DiskPageStore after Session Timeout
[ https://issues.apache.org/jira/browse/WICKET-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12718210#action_12718210 ] Matej Knopp commented on WICKET-2268: - What makes you think it's not? > NullPointerException NPE in DiskPageStore after Session Timeout > --- > > Key: WICKET-2268 > URL: https://issues.apache.org/jira/browse/WICKET-2268 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC2 > Environment: JDK 1.6, Netbeans 6.5 with GlassFish >Reporter: bernard >Assignee: Matej Knopp >Priority: Critical > Fix For: 1.4-RC6 > > Attachments: ExpiryCrash.zip, session-expire-patch-1.4-rc4.txt > > > A NullPointerException is thrown on an attempt to sumit a login form after > session timeout. > Wicket version 1.4 RC2 > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.getSessionEntry(DiskPageStore.java:661) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.containsPage(DiskPageStore.java:1255) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.containsPage(SecondLevelCacheSessionStore.java:268) > at org.apache.wicket.Session.getPage(Session.java:660) > at > org.apache.wicket.request.target.coding.HybridUrlCodingStrategy.decode(HybridUrlCodingStrategy.java:211) > at > org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:490) > at > org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:184) > at g1.base.MemberApplication$2.resolve(MemberApplication.java:327) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1246) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:498) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:444) > at > org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:159) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:738) > Please refer to the attached testcase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2268) NullPointerException NPE in DiskPageStore after Session Timeout
[ https://issues.apache.org/jira/browse/WICKET-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-2268. - Resolution: Fixed Fix Version/s: 1.4-RC6 > NullPointerException NPE in DiskPageStore after Session Timeout > --- > > Key: WICKET-2268 > URL: https://issues.apache.org/jira/browse/WICKET-2268 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC2 > Environment: JDK 1.6, Netbeans 6.5 with GlassFish >Reporter: bernard >Assignee: Matej Knopp >Priority: Critical > Fix For: 1.4-RC6 > > Attachments: ExpiryCrash.zip, session-expire-patch-1.4-rc4.txt > > > A NullPointerException is thrown on an attempt to sumit a login form after > session timeout. > Wicket version 1.4 RC2 > java.lang.NullPointerException > at > java.util.concurrent.ConcurrentHashMap.get(ConcurrentHashMap.java:768) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.getSessionEntry(DiskPageStore.java:661) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.containsPage(DiskPageStore.java:1255) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.containsPage(SecondLevelCacheSessionStore.java:268) > at org.apache.wicket.Session.getPage(Session.java:660) > at > org.apache.wicket.request.target.coding.HybridUrlCodingStrategy.decode(HybridUrlCodingStrategy.java:211) > at > org.apache.wicket.protocol.http.request.WebRequestCodingStrategy.targetForRequest(WebRequestCodingStrategy.java:490) > at > org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:184) > at g1.base.MemberApplication$2.resolve(MemberApplication.java:327) > at org.apache.wicket.RequestCycle.step(RequestCycle.java:1246) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1366) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:498) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:444) > at > org.apache.wicket.protocol.http.WicketServlet.doPost(WicketServlet.java:159) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:738) > Please refer to the attached testcase. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1922) AbstractTree - setting root to null causes NullPointerException
[
https://issues.apache.org/jira/browse/WICKET-1922?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-1922.
-
Resolution: Fixed
Fix Version/s: 1.4-RC5
1.3.7
> AbstractTree - setting root to null causes NullPointerException
> ---
>
> Key: WICKET-1922
> URL: https://issues.apache.org/jira/browse/WICKET-1922
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.5
> Environment: JDK 1.6.0_01
>Reporter: Vlastimil
>Assignee: Matej Knopp
> Fix For: 1.3.7, 1.4-RC5
>
>
> I have TreeTable with some nodes, perform some filtering of them and update
> tree model. If result of filtering is nothing (empty Tree) I set
> setRoot(null) on the tree model. This send treeStructureChanged event to all
> listeners (to my TreeTable) with parameter TreeModelEvent which is
> constructed with null TreePath parameter. This cause NullPointerException in
> AbstractTree (implements TreeModelListener).
> I propose this fix:
> org.apache.wicket.markup.html.tree.AbstractTree
> /**
>* @see
> javax.swing.event.TreeModelListener#treeStructureChanged(javax.swing.event.TreeModelEvent)
>*/
> public final void treeStructureChanged(TreeModelEvent e)
> {
> // empty root
> if(e.getTreePath() == null) {
> invalidateAll();
> }
> else {
> // get the parent node of changed nodes
> TreeNode node =
> (TreeNode)e.getTreePath().getLastPathComponent();
> // has the tree root changed?
> if (e.getTreePath().getPathCount() == 1 &&
> node.equals(rootItem.getModelObject()))
> {
> invalidateAll();
> }
> else
> {
> invalidateNodeWithChildren(node);
> }
> }
> }
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1837) DiskPageStore: 32k directory entries.
[ https://issues.apache.org/jira/browse/WICKET-1837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-1837. - Resolution: Fixed > DiskPageStore: 32k directory entries. > - > > Key: WICKET-1837 > URL: https://issues.apache.org/jira/browse/WICKET-1837 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.4-M3 > Environment: Caucho Resin 3.2 >Reporter: uwe schaefer >Assignee: Matej Knopp > Fix For: 1.4-RC5 > > Attachments: sessionId_deep_path_revisited.patch > > > When using JMeter to battletest a Wicket-App, i saw 31999 directories created > (one per session) in the tmp dir to store the pagemaps. > This is a problem because the underlying filesystem might (and does in my > case) prevent wicket from creating more directory entries than that. > i appended a very very simple patch to address this by creating > /ab/cd/ef instead of /abcdef for pagemap storage. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1623) LinkTree with IndicatingAjaxLink leaks
[ https://issues.apache.org/jira/browse/WICKET-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-1623. - Resolution: Fixed Fix Version/s: 1.3.6 > LinkTree with IndicatingAjaxLink leaks
[jira] Commented: (WICKET-1933) Issue appears to not be fixed
[ https://issues.apache.org/jira/browse/WICKET-1933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12715754#action_12715754 ] Matej Knopp commented on WICKET-1933: - According to WICKET-2207 comments //: should work fine for IE6. At least noone complained... Does ://0 work with all other browsers as well? > Issue appears to not be fixed > - > > Key: WICKET-1933 > URL: https://issues.apache.org/jira/browse/WICKET-1933 > Project: Wicket > Issue Type: Sub-task > Components: wicket-extensions >Affects Versions: 1.4-M3 >Reporter: Steve Lowery >Assignee: Matej Knopp > > The fix describes changing the iframe src attribute to '://0'. The code was > changed to '//:'. This does not fix the issue in IE6, at least for us. In > version 1.4M3, it is now line 1124 in modal.js. I changed it to ://0 and the > issue went away. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2099) NullPointerException after jetty restart with persistent sessions
[
https://issues.apache.org/jira/browse/WICKET-2099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-2099.
-
Resolution: Fixed
Applied to trunk.
> NullPointerException after jetty restart with persistent sessions
> -
>
> Key: WICKET-2099
> URL: https://issues.apache.org/jira/browse/WICKET-2099
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
>Reporter: Adriano dos Santos Fernandes
>Assignee: Matej Knopp
>
> I start Jetty with a savePeriod (HashSessionManager) of 4 seconds. When I
> restart it, a NPE is logged each 4s. After some (not all) page loads, the
> exception stop.
> Since NPE is never a feature, I suggest to apply that patch. Or something
> else more appropriate, if you understand the problem better.
> Index:
> wicket/src/main/java/org/apache/wicket/protocol/http/pagestore/DiskPageStore.java
> ===
> ---
> wicket/src/main/java/org/apache/wicket/protocol/http/pagestore/DiskPageStore.java
> (revisão 740670)
> +++
> wicket/src/main/java/org/apache/wicket/protocol/http/pagestore/DiskPageStore.java
> (cópia de trabalho)
> @@ -1165,7 +1165,7 @@
> else if (page instanceof SerializedPageWithSession)
> {
> SerializedPageWithSession serialized =
> (SerializedPageWithSession)page;
> - if (serialized.page.get() ==
> SerializedPageWithSession.NO_PAGE)
> + if (serialized.page != null && serialized.page.get() ==
> SerializedPageWithSession.NO_PAGE)
> {
> // stripped page, need to restore it first
> result =
> restoreStrippedSerializedPage(serialized);
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1826) Forms + ModalWindow + AjaxSubmitLink + FormComponent#isInputNullable
[ https://issues.apache.org/jira/browse/WICKET-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12703622#action_12703622 ] Matej Knopp commented on WICKET-1826: - If you have form in modal window make sure that the modal window is placed in another form. Also you need to use latest wicket version for it to work properly. > Forms + ModalWindow + AjaxSubmitLink + FormComponent#isInputNullable > > > Key: WICKET-1826 > URL: https://issues.apache.org/jira/browse/WICKET-1826 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.3.3 >Reporter: German Morales >Assignee: Matej Knopp >Priority: Minor > Attachments: modalwindowform.jar, modalwindowform.jar > > > Submiting a form which is inside a ModalWindow, wicket javascript sends only > the information for the modal window's form, but not for the root form of the > page (because ModalWindow hangs its own div at body level). > On Wicket server side, the form processing is done for the root form, which > calls inputChanged for all the components in the page, but the javascript > side didn't send the information for them, and then some of them go wrong. > That happens to FormComponents which have isInputNullable in true. > More description and proposed solutions in the (to be) attached quickstart > project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2207) Modal Window created with a page creator don't open on IE8 and direct to an invalid adress
[
https://issues.apache.org/jira/browse/WICKET-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-2207.
-
Resolution: Fixed
Fix Version/s: 1.4-RC3
1.3.6
> Modal Window created with a page creator don't open on IE8 and direct to an
> invalid adress
> --
>
> Key: WICKET-2207
> URL: https://issues.apache.org/jira/browse/WICKET-2207
> Project: Wicket
> Issue Type: Bug
> Components: wicket-examples
>Affects Versions: 1.4-RC1
> Environment: IE8 on Windows Vista
>Reporter: Daniel Chipan
>Assignee: Matej Knopp
>Priority: Critical
> Fix For: 1.3.6, 1.4-RC3
>
> Attachments: modal-ie8.patch
>
>
> When the content of a modal window is set using a page creator as shown
> below, the modal window is not displayed and you are redirected to an invalid
> page with the adress "http:///";.
> Code :
> chooseLgWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new PopupChooseLg(Layout.this,
> chooseLgWindow);
> }
> });
> The modal is called through an AjaxLink.
> The problem occurs on IE 8.0.6001.18702 installed on Vista 32 bits. No
> problems on Firefox 3 and IE7.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2130) Pages stored in Session.touchedPages aren't detached when part of ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-2130. - Resolution: Fixed > Pages stored in Session.touchedPages aren't detached when part of ModalWindow > - > > Key: WICKET-2130 > URL: https://issues.apache.org/jira/browse/WICKET-2130 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.5, 1.4-RC2 >Reporter: Martijn Dashorst > Fix For: 1.3.6, 1.4-RC3 > > Attachments: wicket-2130.tgz > > > Creating a ModalWindow with a Page causes the newly constructed page not to > be detached. > The page is stored in Session.touchedPages, but that list isn't properly > processed at the end of the request for detaching. > I'll try to create a testcase for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2130) Pages stored in Session.touchedPages aren't detached when part of ModalWindow
[ https://issues.apache.org/jira/browse/WICKET-2130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702921#action_12702921 ] Matej Knopp commented on WICKET-2130: - I think your fix is correct. We have to detach the page there. It's better to detach some pages twice than to have pages not detached at all. > Pages stored in Session.touchedPages aren't detached when part of ModalWindow > - > > Key: WICKET-2130 > URL: https://issues.apache.org/jira/browse/WICKET-2130 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.5, 1.4-RC2 >Reporter: Martijn Dashorst > Fix For: 1.3.6, 1.4-RC3 > > Attachments: wicket-2130.tgz > > > Creating a ModalWindow with a Page causes the newly constructed page not to > be detached. > The page is stored in Session.touchedPages, but that list isn't properly > processed at the end of the request for detaching. > I'll try to create a testcase for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1856) AbstractTree XHTML Strict validation
[
https://issues.apache.org/jira/browse/WICKET-1856?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12702899#action_12702899
]
Matej Knopp commented on WICKET-1856:
-
I don't really remember why it gets the tag from stream but I know there was a
good reason to do it because it used to output only a div. IIRC there were some
problems in IE with replacing the elements afterwards. What exactly is the
validation problem? Is it because the element is empty? We could fix it by
rendering or something like that if the tag name is table.
> AbstractTree XHTML Strict validation
>
>
> Key: WICKET-1856
> URL: https://issues.apache.org/jira/browse/WICKET-1856
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Affects Versions: 1.4-M2
>Reporter: Kaspar Fischer
>Assignee: Matej Knopp
>Priority: Trivial
>
> [Notice: Adapted from http://markmail.org/message/afuxccwazkzwc7bz ]
> I have a rootless BaseTree and see it output
> class="wicket-tree-content" id="tree1f_1">...
> which according to http://validator.w3.org is invalid strict XHTML. Looking
> at the
> comment in the code, AbstractTree.onRender(),
> // is this root and tree is in rootless mode?
> if (this == rootItem && isRootLess() == true)
> {
> // yes, write empty div with id
> // this is necessary for createElement js to
> work correctly
> String tagName =
> ((ComponentTag)markupStream.get()).getName();
> getResponse().write(
> "<" + tagName + "
> style=\"display:none\" id=\"" + getMarkupId() + "\"> tagName + ">");
> markupStream.skipComponent();
> }
> it appears from the comment that the indention was to output a div and not a
> table. With
> a div, we would get valid markup:
> class="wicket-tree-content" id="tree1f_1">...
> Is there a particular reason to fetch the tagName from the markupStream
> instead of just hardcoding
> it to "div"?
> Thanks,
> Kaspar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2207) Modal Window created with a page creator don't open on IE8 and direct to an invalid adress
[
https://issues.apache.org/jira/browse/WICKET-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701671#action_12701671
]
Matej Knopp commented on WICKET-2207:
-
Committed to trunk. If someone can confirm that it works across
browser/http/htts i will commit it to 1.3
> Modal Window created with a page creator don't open on IE8 and direct to an
> invalid adress
> --
>
> Key: WICKET-2207
> URL: https://issues.apache.org/jira/browse/WICKET-2207
> Project: Wicket
> Issue Type: Bug
> Components: wicket-examples
>Affects Versions: 1.4-RC1
> Environment: IE8 on Windows Vista
>Reporter: Daniel Chipan
>Assignee: Matej Knopp
>Priority: Critical
> Attachments: modal-ie8.patch
>
>
> When the content of a modal window is set using a page creator as shown
> below, the modal window is not displayed and you are redirected to an invalid
> page with the adress "http:///";.
> Code :
> chooseLgWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new PopupChooseLg(Layout.this,
> chooseLgWindow);
> }
> });
> The modal is called through an AjaxLink.
> The problem occurs on IE 8.0.6001.18702 installed on Vista 32 bits. No
> problems on Firefox 3 and IE7.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2207) Modal Window created with a page creator don't open on IE8 and direct to an invalid adress
[
https://issues.apache.org/jira/browse/WICKET-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701669#action_12701669
]
Matej Knopp commented on WICKET-2207:
-
I don't mind applying this (with minor change - query IE6 using
Wicket.Browser.isIeLessThan7) - if someone can confirm that it works correctly
in IE6,7,8 with both http and https
> Modal Window created with a page creator don't open on IE8 and direct to an
> invalid adress
> --
>
> Key: WICKET-2207
> URL: https://issues.apache.org/jira/browse/WICKET-2207
> Project: Wicket
> Issue Type: Bug
> Components: wicket-examples
>Affects Versions: 1.4-RC1
> Environment: IE8 on Windows Vista
>Reporter: Daniel Chipan
>Assignee: Matej Knopp
>Priority: Critical
> Attachments: modal-ie8.patch
>
>
> When the content of a modal window is set using a page creator as shown
> below, the modal window is not displayed and you are redirected to an invalid
> page with the adress "http:///";.
> Code :
> chooseLgWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new PopupChooseLg(Layout.this,
> chooseLgWindow);
> }
> });
> The modal is called through an AjaxLink.
> The problem occurs on IE 8.0.6001.18702 installed on Vista 32 bits. No
> problems on Firefox 3 and IE7.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2207) Modal Window created with a page creator don't open on IE8 and direct to an invalid adress
[
https://issues.apache.org/jira/browse/WICKET-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12701109#action_12701109
]
Matej Knopp commented on WICKET-2207:
-
Have you tested it both with http and https?
I do seem to remember there being issues with about:blank and https, especially
on IE6
> Modal Window created with a page creator don't open on IE8 and direct to an
> invalid adress
> --
>
> Key: WICKET-2207
> URL: https://issues.apache.org/jira/browse/WICKET-2207
> Project: Wicket
> Issue Type: Bug
> Components: wicket-examples
>Affects Versions: 1.4-RC1
> Environment: IE8 on Windows Vista
>Reporter: Daniel Chipan
>Assignee: Matej Knopp
>Priority: Critical
>
> When the content of a modal window is set using a page creator as shown
> below, the modal window is not displayed and you are redirected to an invalid
> page with the adress "http:///";.
> Code :
> chooseLgWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new PopupChooseLg(Layout.this,
> chooseLgWindow);
> }
> });
> The modal is called through an AjaxLink.
> The problem occurs on IE 8.0.6001.18702 installed on Vista 32 bits. No
> problems on Firefox 3 and IE7.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2207) Modal Window created with a page creator don't open on IE8 and direct to an invalid adress
[
https://issues.apache.org/jira/browse/WICKET-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699754#action_12699754
]
Matej Knopp commented on WICKET-2207:
-
As far as I remember javascript:void(0) is broken in certain versions of IE6 so
it's too risky. Serving blank page might be the solution - we could have it
served as resource.
> Modal Window created with a page creator don't open on IE8 and direct to an
> invalid adress
> --
>
> Key: WICKET-2207
> URL: https://issues.apache.org/jira/browse/WICKET-2207
> Project: Wicket
> Issue Type: Bug
> Components: wicket-examples
>Affects Versions: 1.4-RC1
> Environment: IE8 on Windows Vista
>Reporter: Daniel Chipan
>Assignee: Matej Knopp
>Priority: Critical
>
> When the content of a modal window is set using a page creator as shown
> below, the modal window is not displayed and you are redirected to an invalid
> page with the adress "http:///";.
> Code :
> chooseLgWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new PopupChooseLg(Layout.this,
> chooseLgWindow);
> }
> });
> The modal is called through an AjaxLink.
> The problem occurs on IE 8.0.6001.18702 installed on Vista 32 bits. No
> problems on Firefox 3 and IE7.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2207) Modal Window created with a page creator don't open on IE8 and direct to an invalid adress
[
https://issues.apache.org/jira/browse/WICKET-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699727#action_12699727
]
Matej Knopp commented on WICKET-2207:
-
Problem here is that we have to create empty iframe. So we set src to //: to
prevent IE from complaining about security on https pages. This works for IE6,
and 7, but for some reason it completely confuses IE8. If anyone knows a way to
create empty iframe in IE that doesn't make it complain on https pages and
works on IE8, please share.
> Modal Window created with a page creator don't open on IE8 and direct to an
> invalid adress
> --
>
> Key: WICKET-2207
> URL: https://issues.apache.org/jira/browse/WICKET-2207
> Project: Wicket
> Issue Type: Bug
> Components: wicket-examples
>Affects Versions: 1.4-RC1
> Environment: IE8 on Windows Vista
>Reporter: Daniel Chipan
>Assignee: Matej Knopp
>Priority: Critical
>
> When the content of a modal window is set using a page creator as shown
> below, the modal window is not displayed and you are redirected to an invalid
> page with the adress "http:///";.
> Code :
> chooseLgWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new PopupChooseLg(Layout.this,
> chooseLgWindow);
> }
> });
> The modal is called through an AjaxLink.
> The problem occurs on IE 8.0.6001.18702 installed on Vista 32 bits. No
> problems on Firefox 3 and IE7.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-2207) Modal Window created with a page creator don't open on IE8 and direct to an invalid adress
[
https://issues.apache.org/jira/browse/WICKET-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp reassigned WICKET-2207:
---
Assignee: Matej Knopp
> Modal Window created with a page creator don't open on IE8 and direct to an
> invalid adress
> --
>
> Key: WICKET-2207
> URL: https://issues.apache.org/jira/browse/WICKET-2207
> Project: Wicket
> Issue Type: Bug
> Components: wicket-examples
>Affects Versions: 1.4-RC1
> Environment: IE8 on Windows Vista
>Reporter: Daniel Chipan
>Assignee: Matej Knopp
>Priority: Critical
>
> When the content of a modal window is set using a page creator as shown
> below, the modal window is not displayed and you are redirected to an invalid
> page with the adress "http:///";.
> Code :
> chooseLgWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new PopupChooseLg(Layout.this,
> chooseLgWindow);
> }
> });
> The modal is called through an AjaxLink.
> The problem occurs on IE 8.0.6001.18702 installed on Vista 32 bits. No
> problems on Firefox 3 and IE7.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2195) DefaultObjectStreamFactory needs Application during deserialization
[ https://issues.apache.org/jira/browse/WICKET-2195?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-2195. - Resolution: Fixed > DefaultObjectStreamFactory needs Application during deserialization > --- > > Key: WICKET-2195 > URL: https://issues.apache.org/jira/browse/WICKET-2195 > Project: Wicket > Issue Type: Bug >Reporter: Matej Knopp >Assignee: Matej Knopp > Fix For: 1.4-RC3 > > > During session replication deserialization is likely to happen outside > request thread -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2195) DefaultObjectStreamFactory needs Application during deserialization
DefaultObjectStreamFactory needs Application during deserialization --- Key: WICKET-2195 URL: https://issues.apache.org/jira/browse/WICKET-2195 Project: Wicket Issue Type: Bug Reporter: Matej Knopp Assignee: Matej Knopp Fix For: 1.4-RC3 During session replication deserialization is likely to happen outside request thread -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1967) ModalWindow doesn't work in Internet Explorer 6 and Internet Explorer 7
[
https://issues.apache.org/jira/browse/WICKET-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12693906#action_12693906
]
Matej Knopp commented on WICKET-1967:
-
-Dmaven.test.skip=true
> ModalWindow doesn't work in Internet Explorer 6 and Internet Explorer 7
> ---
>
> Key: WICKET-1967
> URL: https://issues.apache.org/jira/browse/WICKET-1967
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.5
> Environment: Internet Explorer 6 and Internet Explorer 7
>Reporter: Lars Sonchocky-Helldorf
>Assignee: Matej Knopp
>Priority: Critical
> Attachments: Revision_745450_test_results.txt,
> unable_to_get_1.3.6-SNAPSHOT, WICKET-1967 Ajax Debug Window Output not
> working version 1.3.5.txt, WICKET-1967 Ajax Debug Window Output working
> version.txt
>
>
> While the ModalWindow Example of
> http://www.wicket-library.com/wicket-examples/ajax/modal-window.0 works for
> me in Internet Explorer 6 and Internet Explorer 7 I can't get the following
> code to work in IE locally:
> {code:title=HomePage.java}
> public class HomePage extends BaseLayoutPage {
> private static final long serialVersionUID = 1L;
> public HomePage() {
> /*
> * modal window test
> */
> final ModalWindow modalWindow;
> modalWindow = new ModalWindow("modalWindow");
> add(modalWindow);
> modalWindow.setPageMapName("modal-1");
> modalWindow.setCookieName("modal-1");
> modalWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new ExampleModalContentPage(modalWindow);
> //return PageUtils.newModalSubFormPage(ExampleModalSubFormPage.class,
> exampleModel, DienstleistungenDetailPage.this, modal1);
> }
> });
> modalWindow.setWindowClosedCallback(new
> ModalWindow.WindowClosedCallback() {
> public void onClose(AjaxRequestTarget target) {
> // target.addComponent(result);
> }
> });
> modalWindow.setCloseButtonCallback(new ModalWindow.CloseButtonCallback() {
> public boolean onCloseButtonClicked(AjaxRequestTarget target) {
> return true;
> }
> });
> add(new AjaxLink("showModalWindow") {
> @Override
> public void onClick(AjaxRequestTarget target) {
> modalWindow.show(target);
> }
> });
> }
> }
> {code}
> {code:title=HomePage.html}
> "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd";>
> http://wicket.apache.org";>
> Adminclient content="text/html; charset=UTF-8">
>
>
>
>
> Show modal dialog with a page
>
>
>
>
> {code}
> {code:title=ExampleModalContentPage.java}
> //$URL: $
> //$Id: $
> package de.synergie.bgb.admin.example;
> import org.apache.wicket.ajax.AjaxRequestTarget;
> import org.apache.wicket.ajax.markup.html.AjaxLink;
> import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
> import org.apache.wicket.markup.html.WebPage;
> /**
> *
> */
> public class ExampleModalContentPage extends WebPage {
> /**
>*
>* @param window
>*/
> public ExampleModalContentPage(final ModalWindow window) {
> add(new AjaxLink("closeOK") {
> private static final long serialVersionUID = 1L;
> @Override
> public void onClick(AjaxRequestTarget target) {
> window.close(target);
> }
> });
> add(new AjaxLink("closeCancel") {
> private static final long serialVersionUID = 1L;
> @Override
> public void onClick(AjaxRequestTarget target) {
> window.close(target);
> }
> });
> }
> }
> {code}
> {code:title=ExampleModalContentPage.html}
>
>
> This is modal window
>
> body {
> font-family: verdana, sans-serif;
> font-size: 82%;
> background-color: white;
> }
>
>
>
> Modal WINDOW content.
>
> Close this window with result "OK"
> Close this window with result
> "Cancel"
>
>
>
> {code}
> All I get in IE inside Ajax-Debug is:
> {code}
> INFO: focus set on wicketDebugLink
> INFO: focus removed from wicketDebugLink
> INFO: focus set on showModalWindow8
> INFO: Using ActiveX transport
> INFO:
> INFO: Initiating Ajax GET request on
> ?wicket:interface=:1:showModalWindow::IBehaviorListener:0:&random=0.5070443492328245
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (1910 characters)
> INFO:
> encoding="wicket1" >
> INFO: Response parsed. Now invoking steps...
> ERROR: Exception evaluating javascript: [object Error]
> INFO: Response processed successfully.
> INFO: Invoking post-call handler(s)...
> INFO: Calling focus on showModalWindow8
> INFO: focus removed from showModalWindow8
> INFO: focus set on showModa
[jira] Issue Comment Edited: (WICKET-2111) Ability to generate markup ids in alternate fashion
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689207#action_12689207 ] Matej Knopp edited comment on WICKET-2111 at 3/25/09 12:35 PM: --- Guys, before you throw around ideas like IMarkupId and markup ids as strings please consider that the Component itself has been profiled a lot and there is very good reason why the internals look as they do (even though the code is not pretty). In one project (rather ajax heavy) storing component data as Object and having used only int slot for markup id has reduced the memory consumed by wicket components by 30-40% on certain pages. If you have lot of ajax enabled components a string field for markup id is a *huge* waste of memory. was (Author: knopp): Guys, before you throw around ideas like IMarkupId and markup ids as strings please consider that the Component itself has been profiled a lot and there is very good why the internals look as they do (even though the code is not pretty). In one project (rather ajax heavy) storing component data as Object and having used only int slot for markup id has reduced the memory consumed by wicket components by 30-40% on certain pages. If you have lot of ajax enabled components a string field for markup id is a *huge* waste of memory. > Ability to generate markup ids in alternate fashion > --- > > Key: WICKET-2111 > URL: https://issues.apache.org/jira/browse/WICKET-2111 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.3.5, 1.3.6, 1.4-RC3 >Reporter: Berry van Halderen > Fix For: 1.3.6, 1.4-RC3 > > Attachments: patch, wicket-2111.patch > > > In the attempts to setup integrated testing one particular piece of wicket > code isn't quite extendible enough for our needs, which is the generation of > markup ids by the wicket session class. The ability to extend this > functionality is not limited to the particular use case, I'd like to propose > a small change. > The issue is the following; when a Component has no explicit markup-id set, > the markup id is generated by the Session which has an internal counter and > uses an increment of this to generate a mark-id. The flaw IMHO is that a > Component requests the Session to generate an id, without passing it any > context. Especially the most logical context, i.e. "please session, generate > a markup id for _ME_" is missing. Therefore I'd propose that the > Session.getMarkupId() is passes the Component object for which the markup id > is to be generated. > By default, the operation should remain as is and the Session object falls > back to the default getMarkupId() without parameters, which is already > overrideable. But now you can override the getMarkupId() and generate more > useful markup ids. > In our case, we are able to generate markup ids which contain part of the > hierarchy and in this manner generate stable Ids, namely those which do not > change after several requests. This particular usage may just work for our > case (one page application, no back-button support, etc), but the fundamental > overrideable method to generate more useful IDs is more widely applicable, > hence this change request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in alternate fashion
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689207#action_12689207 ] Matej Knopp commented on WICKET-2111: - Guys, before you throw around ideas like IMarkupId and markup ids as strings please consider that the Component itself has been profiled a lot and there is very good why the internals look as they do (even though the code is not pretty). In one project (rather ajax heavy) storing component data as Object and having used only int slot for markup id has reduced the memory consumed by wicket components by 30-40% on certain pages. If you have lot of ajax enabled components a string field for markup id is a *huge* waste of memory. > Ability to generate markup ids in alternate fashion > --- > > Key: WICKET-2111 > URL: https://issues.apache.org/jira/browse/WICKET-2111 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.3.5, 1.3.6, 1.4-RC3 >Reporter: Berry van Halderen > Fix For: 1.3.6, 1.4-RC3 > > Attachments: patch, wicket-2111.patch > > > In the attempts to setup integrated testing one particular piece of wicket > code isn't quite extendible enough for our needs, which is the generation of > markup ids by the wicket session class. The ability to extend this > functionality is not limited to the particular use case, I'd like to propose > a small change. > The issue is the following; when a Component has no explicit markup-id set, > the markup id is generated by the Session which has an internal counter and > uses an increment of this to generate a mark-id. The flaw IMHO is that a > Component requests the Session to generate an id, without passing it any > context. Especially the most logical context, i.e. "please session, generate > a markup id for _ME_" is missing. Therefore I'd propose that the > Session.getMarkupId() is passes the Component object for which the markup id > is to be generated. > By default, the operation should remain as is and the Session object falls > back to the default getMarkupId() without parameters, which is already > overrideable. But now you can override the getMarkupId() and generate more > useful markup ids. > In our case, we are able to generate markup ids which contain part of the > hierarchy and in this manner generate stable Ids, namely those which do not > change after several requests. This particular usage may just work for our > case (one page application, no back-button support, etc), but the fundamental > overrideable method to generate more useful IDs is more widely applicable, > hence this change request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2111) Ability to generate markup ids in alternate fashion
[ https://issues.apache.org/jira/browse/WICKET-2111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12689205#action_12689205 ] Matej Knopp commented on WICKET-2111: - There is good reason why markup id is stored as integer by default! In 99.99% cases the integer is only thing necessary to get component's markup id. There is no reason to store it as string. We did that and the runtime penalty was really noticeable. In case someone wants to override it, we store it as metadata. Thus we don't need String slot for markup id. > Ability to generate markup ids in alternate fashion > --- > > Key: WICKET-2111 > URL: https://issues.apache.org/jira/browse/WICKET-2111 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.3.5, 1.3.6, 1.4-RC3 >Reporter: Berry van Halderen > Fix For: 1.3.6, 1.4-RC3 > > Attachments: patch, wicket-2111.patch > > > In the attempts to setup integrated testing one particular piece of wicket > code isn't quite extendible enough for our needs, which is the generation of > markup ids by the wicket session class. The ability to extend this > functionality is not limited to the particular use case, I'd like to propose > a small change. > The issue is the following; when a Component has no explicit markup-id set, > the markup id is generated by the Session which has an internal counter and > uses an increment of this to generate a mark-id. The flaw IMHO is that a > Component requests the Session to generate an id, without passing it any > context. Especially the most logical context, i.e. "please session, generate > a markup id for _ME_" is missing. Therefore I'd propose that the > Session.getMarkupId() is passes the Component object for which the markup id > is to be generated. > By default, the operation should remain as is and the Session object falls > back to the default getMarkupId() without parameters, which is already > overrideable. But now you can override the getMarkupId() and generate more > useful markup ids. > In our case, we are able to generate markup ids which contain part of the > hierarchy and in this manner generate stable Ids, namely those which do not > change after several requests. This particular usage may just work for our > case (one page application, no back-button support, etc), but the fundamental > overrideable method to generate more useful IDs is more widely applicable, > hence this change request. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679120#action_12679120
]
knopp edited comment on WICKET-2127 at 3/5/09 2:34 AM:
-
This one
var replaceAll = function(str, from, to) {
eval(
'var regex = /' + from.replace( /\W/g ,'\\$&' ) + '/g ;'
);
return str.replace(regex,to);
}
looks good to me. I will apply it to 1.4 and if no one complains after some
time I will probably also add it to 1.3.
was (Author: knopp):
This one
var replaceAll = function(str, from, to) {
eval(
'var regex = /' + from.replace( /\W/g ,'\\$&' ) + '/g ;'
);
return str.replace(regex,to);
}
looks good to me. I will apply it to 1.4 and if no one complains after same
time I will probably also add it to 1.3.
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12679120#action_12679120
]
Matej Knopp commented on WICKET-2127:
-
This one
var replaceAll = function(str, from, to) {
eval(
'var regex = /' + from.replace( /\W/g ,'\\$&' ) + '/g ;'
);
return str.replace(regex,to);
}
looks good to me. I will apply it to 1.4 and if no one complains after same
time I will probably also add it to 1.3.
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-2138) SecondLevelCache + DiskPageStore Serialization issue with Anonymous inner classes
[
https://issues.apache.org/jira/browse/WICKET-2138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp reassigned WICKET-2138:
---
Assignee: Johan Compagner (was: Matej Knopp)
> SecondLevelCache + DiskPageStore Serialization issue with Anonymous inner
> classes
> -
>
> Key: WICKET-2138
> URL: https://issues.apache.org/jira/browse/WICKET-2138
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Solaris/JDK6u10 Jetty clustered session store.
>Reporter: Victor Igumnov
>Assignee: Johan Compagner
>
> It seems like declaring an anonymous inner class will hold on to the previous
> page which will break serialization with secondlevelcache in a clustered
> environment.
> ---
> I have run into an odd issue with serialization which throws a stackoverflow
> exception. Here is the cause:
> Passing an LDM model as-is to a page, it will stackoverflow on the receiving
> page, if that page is refreshed twice or a form has been submitted.
> Here is an example...
> setResponsePage(new EditBlogPage(new LoadableDetachableModel() {
> private static final long serialVersionUID = 1L;
> @Override
> protected Blog load() {
> // just an example
> return new Blog();
> }
> }));
> However, if I subclass the LDM and pass it like so, it will work just fine.
> public class FakeLDM extends LoadableDetachableModel {
> private static final long serialVersionUID = 1L;
> @Override
> protected Blog load() {
> return new Blog();
> }
> }
> setResponsePage(new EditBlogPage(new FakeLDM()));
> One last thing, If I construct the LDM inside the receiving page. It will
> work fine as well.
> This seems to only happen with the SecondLevelCache, any ideas?
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-2051) OutOfMemoryError while serializing page
[ https://issues.apache.org/jira/browse/WICKET-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp reassigned WICKET-2051: --- Assignee: Johan Compagner (was: Matej Knopp) > OutOfMemoryError while serializing page > --- > > Key: WICKET-2051 > URL: https://issues.apache.org/jira/browse/WICKET-2051 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC1 >Reporter: Yosi >Assignee: Johan Compagner > > getting OutOfMemoryError while serializing page. > * I have a page containing a ModalWindow showing a Page. > * When closing the modal I get the following exception (see below). > * Objects.setObjectStreamFactory(new WicketObjectStreamFactory()) seem to fix > the problem. > * (using SimpleSynchronousFilePageStore() instead of DiskPageStore also fixes > the problem). > And also some questions: > * why do we need WicketObjectStreamFactory? > * is it ok to use it? > * why isn't it the default? > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Arrays.java:2786) > at > java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133) > at > org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1107) > at > org.apache.wicket.protocol.http.pagestore.AbstractPageStore$PageSerializer.getPageReplacementObject(AbstractPageStore.java:281) > at org.apache.wicket.Page.writeReplace(Page.java:1320) > at sun.reflect.GeneratedMethodAccessor186.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamClass.java:1032) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1107) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) > at > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) > at > org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:119) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322) > at > org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1097) > at > org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:199) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327) > at org.apache.wicket.Session.requestDetached(Session.java:1390) > at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1385) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:498) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:444) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (WICKET-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676725#action_12676725
]
knopp edited comment on WICKET-2127 at 2/25/09 10:15 AM:
---
You replacement function is broken. It needs to escape more characters. I added
some.
var replaceAll = function(str, from, to) {
eval(
'var regex = /'
+ from.replace( /[\(\)\[\]\{\}\$\^\.\?\*\+\\\/\|]/g ,'\\$&' )
+ '/g ;'
);
return str.replace(regex,to);
}
I don't mind replacing the current function with this but at this point I'm not
sure it escapes all necessary characters.
was (Author: knopp):
You replacement function is broken. It needs to escape more characters. I
added some.
var replaceAll = function(str, from, to) {
eval(
'var regex = /'
+ from.replace( /[\(\)\[\]\{\}\$\^\.\?\*\+\\\/]/g ,'\\$&' )
+ '/g ;'
);
return str.replace(regex,to);
}
I don't mind replacing the current function with this but at this point I'm not
sure it escapes all necessary characters.
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2127) Javascript function Wicket.replaceAll is unbearably slow
[
https://issues.apache.org/jira/browse/WICKET-2127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12676725#action_12676725
]
Matej Knopp commented on WICKET-2127:
-
You replacement function is broken. It needs to escape more characters. I added
some.
var replaceAll = function(str, from, to) {
eval(
'var regex = /'
+ from.replace( /[\(\)\[\]\{\}\$\^\.\?\*\+\\\/]/g ,'\\$&' )
+ '/g ;'
);
return str.replace(regex,to);
}
I don't mind replacing the current function with this but at this point I'm not
sure it escapes all necessary characters.
> Javascript function Wicket.replaceAll is unbearably slow
>
>
> Key: WICKET-2127
> URL: https://issues.apache.org/jira/browse/WICKET-2127
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-RC2
> Environment: Firefox 3.0.5, Opera 9.2 (windows)
>Reporter: Sean Patrick Floyd
>Assignee: Matej Knopp
> Fix For: 1.4-RC3
>
> Attachments: wicketReplaceAll.js
>
> Original Estimate: 0.5h
> Remaining Estimate: 0.5h
>
> I use AbstractAjaxTimerBehavior to update many different components on my
> pages periodically.
> After a while, the browser occupies 50% or more of the system resources.
> I used the javascript profiler in firebug and found that Wicket.replaceAll is
> responsible for 60+ percent of javascript processing time.
> The problem is that sequential string processing is used instead of much
> faster regular expressions
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2061) interceptContinuationURL with umlauts not encoded
[
https://issues.apache.org/jira/browse/WICKET-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12675120#action_12675120
]
Matej Knopp commented on WICKET-2061:
-
Juergen, the unit tests are broken on Mac. Obviously the default encoding of
java file is not the same as you used (RequestEncodingTest). Can you escape the
accented characters in strings?
> interceptContinuationURL with umlauts not encoded
> -
>
> Key: WICKET-2061
> URL: https://issues.apache.org/jira/browse/WICKET-2061
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.5, 1.3.6, 1.4-RC1
>Reporter: Sven Meier
>Assignee: Juergen Donnerstag
> Fix For: 1.4-RC3
>
> Attachments: encodingtest.zip
>
>
> This is my second try to fix Wicket's encoding of redirects to intercepted
> URLs.
> Instead of reopening WICKET-2007, I decided to create this new issue and make
> a clean start.
> When Wicket redirects to an intercept page, it stores the original URL in
> PageMap#interceptContinuationURL.
> // The intercept continuation URL should be saved exactly as the
> // original request specified.
> ...
> interceptContinuationURL = "/" +
> cycle.getRequest().getURL();
> Note that comment and code are not in sync:
> Instead of saving *exactly* the original request, a new URL is generated.
> ServletWebRequest#getURL() includes special characters non-encoded. Thus on a
> later continuation, the redirect to the original URL fails in case of special
> characters (umlauts in our case).
> We're now using a subclass of ServletWebRequest, which utilizes the
> requestURI:
> public String getURL()
> {
> // servletPath is de-encoded, so use requestURI minus
> contextPath instead
> // String url = getServletPath();
> String url = httpServletRequest.getRequestURI().substring(
> httpServletRequest.getContextPath().length());
> final String pathInfo = getHttpServletRequest().getPathInfo();
> ...
> }
> I cannot say if this solution has unwanted side effects though.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-2095) error in modal.js wrong use of typeof
[ https://issues.apache.org/jira/browse/WICKET-2095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-2095. - Resolution: Fixed Fix Version/s: 1.4-RC3 1.3.6 Applied to 1.3 branch and trunk > error in modal.js wrong use of typeof > - > > Key: WICKET-2095 > URL: https://issues.apache.org/jira/browse/WICKET-2095 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.5 > Environment: javascript language error so any enviroment >Reporter: C.C.H. Weinberg >Assignee: Matej Knopp > Fix For: 1.3.6, 1.4-RC3 > > Attachments: typeof_error_v1.patch > > > error in javascript code > line 780: > if (typeof(this.oldParent != "undefined")) -> if (typeof(this.oldParent) != > "undefined") -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1861) Inevitable UnknownSizeException with HTTPS
[
https://issues.apache.org/jira/browse/WICKET-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12671894#action_12671894
]
Matej Knopp commented on WICKET-1861:
-
Can't we omit the check if no maxSize is set?
> Inevitable UnknownSizeException with HTTPS
> --
>
> Key: WICKET-1861
> URL: https://issues.apache.org/jira/browse/WICKET-1861
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-M3
> Environment: Caucho Resin 3.2 behind apache2
>Reporter: uwe schaefer
>Assignee: Juergen Donnerstag
> Fix For: 1.4-RC2
>
>
> When using a FileUploadField in a HTTPS environment, the request always
> returns a request-size of -1.
> In that case, FileUploadBase rejects to process the reuqest, no matter what
> (or if) a maxSize is defined:
> org.apache.wicket.util.upload.FileUploadBase:236 (wicket 1.4m3)
> if (requestSize == -1) {
> throw new UnknownSizeException( "the request was rejected because its size
> is unknown");
> }
> this makes it impossible to use fileUploads with HTTPS in this environment at
> all.
> I think, this _sanity check_ should not be done if either HTTPS is used, or
> the developer does not care (expressed by not setting any maxSize).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1967) ModalWindow doesn't work in Internet Explorer 6 and Internet Explorer 7
[
https://issues.apache.org/jira/browse/WICKET-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669583#action_12669583
]
Matej Knopp commented on WICKET-1967:
-
Should be fixed in 1.3 branch and trunk. Can you please test it and confirm?
> ModalWindow doesn't work in Internet Explorer 6 and Internet Explorer 7
> ---
>
> Key: WICKET-1967
> URL: https://issues.apache.org/jira/browse/WICKET-1967
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.5
> Environment: Internet Explorer 6 and Internet Explorer 7
>Reporter: Lars Sonchocky-Helldorf
>Assignee: Matej Knopp
>Priority: Critical
> Attachments: WICKET-1967 Ajax Debug Window Output not working
> version 1.3.5.txt, WICKET-1967 Ajax Debug Window Output working version.txt
>
>
> While the ModalWindow Example of
> http://www.wicket-library.com/wicket-examples/ajax/modal-window.0 works for
> me in Internet Explorer 6 and Internet Explorer 7 I can't get the following
> code to work in IE locally:
> {code:title=HomePage.java}
> public class HomePage extends BaseLayoutPage {
> private static final long serialVersionUID = 1L;
> public HomePage() {
> /*
> * modal window test
> */
> final ModalWindow modalWindow;
> modalWindow = new ModalWindow("modalWindow");
> add(modalWindow);
> modalWindow.setPageMapName("modal-1");
> modalWindow.setCookieName("modal-1");
> modalWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new ExampleModalContentPage(modalWindow);
> //return PageUtils.newModalSubFormPage(ExampleModalSubFormPage.class,
> exampleModel, DienstleistungenDetailPage.this, modal1);
> }
> });
> modalWindow.setWindowClosedCallback(new
> ModalWindow.WindowClosedCallback() {
> public void onClose(AjaxRequestTarget target) {
> // target.addComponent(result);
> }
> });
> modalWindow.setCloseButtonCallback(new ModalWindow.CloseButtonCallback() {
> public boolean onCloseButtonClicked(AjaxRequestTarget target) {
> return true;
> }
> });
> add(new AjaxLink("showModalWindow") {
> @Override
> public void onClick(AjaxRequestTarget target) {
> modalWindow.show(target);
> }
> });
> }
> }
> {code}
> {code:title=HomePage.html}
> "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd";>
> http://wicket.apache.org";>
> Adminclient content="text/html; charset=UTF-8">
>
>
>
>
> Show modal dialog with a page
>
>
>
>
> {code}
> {code:title=ExampleModalContentPage.java}
> //$URL: $
> //$Id: $
> package de.synergie.bgb.admin.example;
> import org.apache.wicket.ajax.AjaxRequestTarget;
> import org.apache.wicket.ajax.markup.html.AjaxLink;
> import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
> import org.apache.wicket.markup.html.WebPage;
> /**
> *
> */
> public class ExampleModalContentPage extends WebPage {
> /**
>*
>* @param window
>*/
> public ExampleModalContentPage(final ModalWindow window) {
> add(new AjaxLink("closeOK") {
> private static final long serialVersionUID = 1L;
> @Override
> public void onClick(AjaxRequestTarget target) {
> window.close(target);
> }
> });
> add(new AjaxLink("closeCancel") {
> private static final long serialVersionUID = 1L;
> @Override
> public void onClick(AjaxRequestTarget target) {
> window.close(target);
> }
> });
> }
> }
> {code}
> {code:title=ExampleModalContentPage.html}
>
>
> This is modal window
>
> body {
> font-family: verdana, sans-serif;
> font-size: 82%;
> background-color: white;
> }
>
>
>
> Modal WINDOW content.
>
> Close this window with result "OK"
> Close this window with result
> "Cancel"
>
>
>
> {code}
> All I get in IE inside Ajax-Debug is:
> {code}
> INFO: focus set on wicketDebugLink
> INFO: focus removed from wicketDebugLink
> INFO: focus set on showModalWindow8
> INFO: Using ActiveX transport
> INFO:
> INFO: Initiating Ajax GET request on
> ?wicket:interface=:1:showModalWindow::IBehaviorListener:0:&random=0.5070443492328245
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (1910 characters)
> INFO:
> encoding="wicket1" >
> INFO: Response parsed. Now invoking steps...
> ERROR: Exception evaluating javascript: [object Error]
> INFO: Response processed successfully.
> INFO: Invoking post-call handler(s)...
> INFO: Calling focus on showModalWindow8
> INFO: focus removed from showModalWindow8
> INFO: focus set on showModalWindow8
> INFO:
[jira] Commented: (WICKET-1967) ModalWindow doesn't work in Internet Explorer 6 and Internet Explorer 7
[
https://issues.apache.org/jira/browse/WICKET-1967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12669477#action_12669477
]
Matej Knopp commented on WICKET-1967:
-
I don't see anything wrong with the code. What is in your base page?
> ModalWindow doesn't work in Internet Explorer 6 and Internet Explorer 7
> ---
>
> Key: WICKET-1967
> URL: https://issues.apache.org/jira/browse/WICKET-1967
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.5
> Environment: Internet Explorer 6 and Internet Explorer 7
>Reporter: Lars Sonchocky-Helldorf
>Assignee: Matej Knopp
>Priority: Critical
> Attachments: WICKET-1967 Ajax Debug Window Output not working
> version 1.3.5.txt, WICKET-1967 Ajax Debug Window Output working version.txt
>
>
> While the ModalWindow Example of
> http://www.wicket-library.com/wicket-examples/ajax/modal-window.0 works for
> me in Internet Explorer 6 and Internet Explorer 7 I can't get the following
> code to work in IE locally:
> {code:title=HomePage.java}
> public class HomePage extends BaseLayoutPage {
> private static final long serialVersionUID = 1L;
> public HomePage() {
> /*
> * modal window test
> */
> final ModalWindow modalWindow;
> modalWindow = new ModalWindow("modalWindow");
> add(modalWindow);
> modalWindow.setPageMapName("modal-1");
> modalWindow.setCookieName("modal-1");
> modalWindow.setPageCreator(new ModalWindow.PageCreator() {
> public Page createPage() {
> return new ExampleModalContentPage(modalWindow);
> //return PageUtils.newModalSubFormPage(ExampleModalSubFormPage.class,
> exampleModel, DienstleistungenDetailPage.this, modal1);
> }
> });
> modalWindow.setWindowClosedCallback(new
> ModalWindow.WindowClosedCallback() {
> public void onClose(AjaxRequestTarget target) {
> // target.addComponent(result);
> }
> });
> modalWindow.setCloseButtonCallback(new ModalWindow.CloseButtonCallback() {
> public boolean onCloseButtonClicked(AjaxRequestTarget target) {
> return true;
> }
> });
> add(new AjaxLink("showModalWindow") {
> @Override
> public void onClick(AjaxRequestTarget target) {
> modalWindow.show(target);
> }
> });
> }
> }
> {code}
> {code:title=HomePage.html}
> "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd";>
> http://wicket.apache.org";>
> Adminclient content="text/html; charset=UTF-8">
>
>
>
>
> Show modal dialog with a page
>
>
>
>
> {code}
> {code:title=ExampleModalContentPage.java}
> //$URL: $
> //$Id: $
> package de.synergie.bgb.admin.example;
> import org.apache.wicket.ajax.AjaxRequestTarget;
> import org.apache.wicket.ajax.markup.html.AjaxLink;
> import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
> import org.apache.wicket.markup.html.WebPage;
> /**
> *
> */
> public class ExampleModalContentPage extends WebPage {
> /**
>*
>* @param window
>*/
> public ExampleModalContentPage(final ModalWindow window) {
> add(new AjaxLink("closeOK") {
> private static final long serialVersionUID = 1L;
> @Override
> public void onClick(AjaxRequestTarget target) {
> window.close(target);
> }
> });
> add(new AjaxLink("closeCancel") {
> private static final long serialVersionUID = 1L;
> @Override
> public void onClick(AjaxRequestTarget target) {
> window.close(target);
> }
> });
> }
> }
> {code}
> {code:title=ExampleModalContentPage.html}
>
>
> This is modal window
>
> body {
> font-family: verdana, sans-serif;
> font-size: 82%;
> background-color: white;
> }
>
>
>
> Modal WINDOW content.
>
> Close this window with result "OK"
> Close this window with result
> "Cancel"
>
>
>
> {code}
> All I get in IE inside Ajax-Debug is:
> {code}
> INFO: focus set on wicketDebugLink
> INFO: focus removed from wicketDebugLink
> INFO: focus set on showModalWindow8
> INFO: Using ActiveX transport
> INFO:
> INFO: Initiating Ajax GET request on
> ?wicket:interface=:1:showModalWindow::IBehaviorListener:0:&random=0.5070443492328245
> INFO: Invoking pre-call handler(s)...
> INFO: Received ajax response (1910 characters)
> INFO:
> encoding="wicket1" >
> INFO: Response parsed. Now invoking steps...
> ERROR: Exception evaluating javascript: [object Error]
> INFO: Response processed successfully.
> INFO: Invoking post-call handler(s)...
> INFO: Calling focus on showModalWindow8
> INFO: focus removed from showModalWindow8
> INFO: focus set on showModalWindow8
> INFO: focus r
[jira] Closed: (WICKET-2053) Can't close modal panel inside modal page.
[
https://issues.apache.org/jira/browse/WICKET-2053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp closed WICKET-2053.
---
Resolution: Won't Fix
Panel modal window inside iframe modal window is not supported.
> Can't close modal panel inside modal page.
> --
>
> Key: WICKET-2053
> URL: https://issues.apache.org/jira/browse/WICKET-2053
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 1.3.5, 1.4-RC1
>Reporter: Yosi
>Assignee: Matej Knopp
>
> I have ModalWindow showing a page containing anothor (child) ModalWindow
> showing a panel.
> When trying to close the inner panel ModalWindow wicket is trying to close
> the parent ModalWindow (page).
> I found the error in modal.js:
> ---
> Wicket.Window.close = function() {
>
> var win;
> try {
> win = window.parent.Wicket.Window;
> } catch (ignore) {
> }
>
> if (typeof(win) != "undefined" && typeof(win.current) != "undefined") {
> // we can't call close directly, because it will delete our
> window,
> // so we will schedule it as timeout for parent's window
> window.parent.setTimeout(function() {
> win.current.close();
> }, 0);
> }
> }
> the following code seem to fix it:
> ---
> Wicket.Window.close = function() {
> var win;
> try {
> win = window.parent.Wicket.Window;
> } catch (ignore) {
> }
> if (typeof(win) == "undefined" || typeof(win.current) == "undefined") {
> try {
> win = window.Wicket.Window;
> } catch (ignore) {
> }
> }
> if (typeof(win) != "undefined" && typeof(win.current) != "undefined") {
> if (win.current.content.tagName.toLowerCase() == 'iframe') {
> var innerWin =
> win.current.content.contentWindow.Wicket.Window;
> if (innerWin && innerWin.current) {
> win = innerWin;
> }
> }
> var close = function(w) {
> w.setTimeout(function() {
> win.current.close();
> }, 0);
> };
> try {
> close(window.parent);
> } catch (ignore) {
> close(window);
> }
> }
> };
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-2054) error submmiting a form inside a ModalWindow
[
https://issues.apache.org/jira/browse/WICKET-2054?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp closed WICKET-2054.
---
Resolution: Invalid
If you have form in modal window with panel you need to use AjaxButton to
submit. Next time please ask such questions on mailing list, this is not what
JIRA is for.
> error submmiting a form inside a ModalWindow
>
>
> Key: WICKET-2054
> URL: https://issues.apache.org/jira/browse/WICKET-2054
> Project: Wicket
> Issue Type: Bug
> Components: wicket-extensions
>Affects Versions: 1.3.5, 1.4-RC1
>Reporter: Yosi
>Assignee: Matej Knopp
>
> * I have a ModalWindow showing a panel.
> * The panel contains a .
> * I can't seem to submit the form inside the ModalWindow.
> * I found the problem in modal.js:
> Wicket.Window.getMarkup = function() {} seem to and a tag
> wrapping the panel.
> * Removing the tag (see below) seems to fix the problem.
> * Why is this needed anyway??
> My fixed Wicket.Window.getMarkup:
> ---
> Wicket.Window.getMarkup = function(idWindow, idClassElement, idCaption,
> idContent, idTop, idTopLeft, idTopRight, idLeft, idRight, idBottomLeft,
> idBottomRight, idBottom, idCaptionText, isFrame) {
> var s =
> " style=\"top: 10px; left: 10px; width: 100px;\">" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> " (Wicket.Browser.isSafari()) { event.ignore = true; } else {
> Wicket.stopEvent(event); } \">" +
> "" +
> "" +
> " class=\"w_captionText\">" +
> "" +
> "" +
> "" +
> "";
> if (isFrame) {
> s +=
> " allowtransparency=\"false\" style=\"height: 200px\">" +
> "";
> } else {
> s +=
> "";
> }
> s +=
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "" +
> "";
> return s;
> };
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2051) OutOfMemoryError while serializing page
[ https://issues.apache.org/jira/browse/WICKET-2051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12667706#action_12667706 ] Matej Knopp commented on WICKET-2051: - WicketObjectStreamFactory is experimental and shouldn't really be used. SimpleSynchronousFilePageStore is not meant to be used in production. What is your VM heap size? And what components are on page? It might be that you have non-transient references to big objects in your page that cause OOM during serialization. > OutOfMemoryError while serializing page > --- > > Key: WICKET-2051 > URL: https://issues.apache.org/jira/browse/WICKET-2051 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC1 >Reporter: Yosi >Assignee: Matej Knopp > > getting OutOfMemoryError while serializing page. > * I have a page containing a ModalWindow showing a Page. > * When closing the modal I get the following exception (see below). > * Objects.setObjectStreamFactory(new WicketObjectStreamFactory()) seem to fix > the problem. > * (using SimpleSynchronousFilePageStore() instead of DiskPageStore also fixes > the problem). > And also some questions: > * why do we need WicketObjectStreamFactory? > * is it ok to use it? > * why isn't it the default? > java.lang.OutOfMemoryError: Java heap space > at java.util.Arrays.copyOf(Arrays.java:2786) > at > java.io.ByteArrayOutputStream.toByteArray(ByteArrayOutputStream.java:133) > at > org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1107) > at > org.apache.wicket.protocol.http.pagestore.AbstractPageStore$PageSerializer.getPageReplacementObject(AbstractPageStore.java:281) > at org.apache.wicket.Page.writeReplace(Page.java:1320) > at sun.reflect.GeneratedMethodAccessor186.invoke(Unknown Source) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > java.io.ObjectStreamClass.invokeWriteReplace(ObjectStreamClass.java:1032) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1107) > at > java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1509) > at > java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1474) > at > java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1392) > at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1150) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:326) > at > org.apache.wicket.util.io.IObjectStreamFactory$DefaultObjectStreamFactory$2.writeObjectOverride(IObjectStreamFactory.java:119) > at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:322) > at > org.apache.wicket.util.lang.Objects.objectToByteArray(Objects.java:1097) > at > org.apache.wicket.protocol.http.pagestore.AbstractPageStore.serializePage(AbstractPageStore.java:199) > at > org.apache.wicket.protocol.http.pagestore.DiskPageStore.storePage(DiskPageStore.java:814) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.put(SecondLevelCacheSessionStore.java:327) > at org.apache.wicket.Session.requestDetached(Session.java:1390) > at org.apache.wicket.RequestCycle.detach(RequestCycle.java:1113) > at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1385) > at org.apache.wicket.RequestCycle.request(RequestCycle.java:498) > at > org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:444) > at > org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:282) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.springframework.orm.hibernate3.support.OpenSessionInViewFilter.doFilterInternal(OpenSessionInViewFilter.java:198) > at > org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:76) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1089) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:365) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1707) Wicket.replaceOuterHtmlIE() (wicket-ajax.js) has very low performance.
[
https://issues.apache.org/jira/browse/WICKET-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12665424#action_12665424
]
Matej Knopp commented on WICKET-1707:
-
What you can do is to redefine Wicket.replaceOuterHtml so that it uses jquery
instead.
i.e. put somewhere in your page
Wicket.replaceOuterHtml = function(element, text) { ... your jquery
implementation ... };
> Wicket.replaceOuterHtmlIE() (wicket-ajax.js) has very low performance.
> --
>
> Key: WICKET-1707
> URL: https://issues.apache.org/jira/browse/WICKET-1707
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
> Environment: IE 7.0
>Reporter: Bartosz Owczarek
>Assignee: Matej Knopp
>
> Hi.
> Firstly I'd like to say that I'm using wicket framework in my company in
> 'e-commerce' system for Business Users. Its main functionality is ordering
> items available in stores by business users. Items are displayed in a
> customized table (we're using DataView component for it). This table is a
> little bit complicated from DOM point of view. Some columns contain images,
> input components, and different css styles for each row or even column (that
> are added dynamically in javacode using AttributeModifier). There's about 22
> columns in table.
> Moreover table is paginable and number of items per page can be change by
> filter on the web page (default is 50). Paging table is done by our
> customized paging navigator that uses AjaxEventBeahvior. In other words table
> is refreshed using build-in ajax provided with wicket. Whati is more only
> tag with its content is refreshed by ajax request (not whole ).
> After implementation I've done some testing so here are results...
> Table is refreshed very quickly in FireFox 3 by wicket-ajax.js after
> receiving response but there is a huge performance bottleneck with refreshing
> it in IE 7.0.I profiled whole wicket-ajax.js in order to find this
> bottleneck. It appears that replacing outer html in IE takes about 4 seconds
> (druing which IE freezes). It's not acceptable. I found that
> Wicket.replaceOuterHtmlIE() method takes around 3.7seconds! That's when only
> 50 items in table are displayed!. If we change items per page to greater
> number then it takes much more time. When I commented body of this function,
> IE doesn't freeze and performance is very good, but content that comes with
> ajax response is not refreshed in browser, which is obvious.
> Then I tried to use jQuery(..).replaceWith() function in
> Wicket.replaceOuterHtmlIE() whereas rest of its body was commented. It is
> faster than default Wicket.replaceOuterHtmlIE() implementation. It takes
> about 1.7 second to render response in browser but of course it doesn't do
> all things as default Wicket.replaceOuterHtmlIE() implementation does (i.e.
> default implementation runs embedded javascripts in
[jira] Assigned: (WICKET-2022) wicket fails on WebLogic 9.2 clustered
[ https://issues.apache.org/jira/browse/WICKET-2022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp reassigned WICKET-2022: --- Assignee: Matej Knopp > wicket fails on WebLogic 9.2 clustered > -- > > Key: WICKET-2022 > URL: https://issues.apache.org/jira/browse/WICKET-2022 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC1 > Environment: Weblogic 9.2 > Spring 2.5.5 > JDK 1.5.0.17 >Reporter: Martin Bednar >Assignee: Matej Knopp > > I have problems with deploying wicket (wicket-1.4m1) application on WebLogic > 9.2 server cluster (2 nodes). > Application use spring 2.5.5 for service layer and is configured: > web.xml: > > > wicket.call-centre > > org.apache.wicket.protocol.http.WicketFilter > > applicationFactoryClassName > > org.apache.wicket.spring.SpringWebApplicationFactory > > > applicationBean > wicketApplication > > > wicket.configuration > deployment > > > > wicket.call-centre > /* > > > > org.springframework.web.context.ContextLoaderListener > > > contextConfigLocation > classpath:applicationContext.xml > > weblogic.xml: > > replicated_if_clustered > > If application deploys on nonclustered environment everything is ok. On > cluster I got these errors: > <[ACTIVE] ExecuteThread: '0' for queue: > 'weblogic.kernel.Default (self-tuning)'> <> <> <> <1231941794006> > weblogic.cluster.replication.ReplicationManager.create(Lweblogic.rmi.spi.HostID;ILweblogic.cluster.replication.ROID;Lweblogic.cluster.replication.Replicatable;) > java.lang.ExceptionInInitializerError. > java.lang.ExceptionInInitializerError > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > sun.reflect.UnsafeFieldAccessorFactory.newFieldAccessor(UnsafeFieldAccessorFactory.java:25) > at > sun.reflect.ReflectionFactory.newFieldAccessor(ReflectionFactory.java:122) > at java.lang.reflect.Field.acquireFieldAccessor(Field.java:917) > at java.lang.reflect.Field.getFieldAccessor(Field.java:898) > at java.lang.reflect.Field.getLong(Field.java:527) > at > java.io.ObjectStreamClass.getDeclaredSUID(ObjectStreamClass.java:1586) > at java.io.ObjectStreamClass.access$700(ObjectStreamClass.java:52) > at java.io.ObjectStreamClass$2.run(ObjectStreamClass.java:408) > at java.io.ObjectStreamClass.(ObjectStreamClass.java:400) > at java.io.ObjectStreamClass.lookup0(ObjectStreamClass.java:297) > at java.io.ObjectStreamClass.lookup(ObjectStreamClass.java) > at java.io.ObjectStreamClass.initNonProxy(ObjectStreamClass.java:531) > at > java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1552) > at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1466) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1699) > at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) > at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) > at > org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.readObject(SecondLevelCacheSessionStore.java:412) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > java.io.ObjectStreamClass.invokeReadObject(ObjectStreamClass.java:946) > at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1809) > at > java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) > org.apache.wicket.WicketRuntimeException: There is no application attached to > current thread [ACTIVE] ExecuteThread: '0' for queue: > 'weblogic.kernel.Default (self-tuning)' > at org.apache.wicket.Application.get(Application.java:177) > at org.apache.wicket.Component.getApplication(Component.java:1282) > at org.apache.wicket.Component.(Component.java:894) > at org.apache.wicket.MarkupContainer.(MarkupContainer.java:105) > at org.apache.wicket.Page.(Page.java:236) > at > org.apache.wicket.protocol.http.pagestore.SerializedPagesCache$SerializedPageWithSession$1.(SerializedPagesCache.java:206) > at > org.apache.wicket.protocol.http.pagestore.SerializedPagesCache$SerializedPageWithSession.(SerializedPagesCache.java:205) > at sun.misc.Unsafe.ensureClassInitialized(Native Method) > at > sun.r
[jira] Commented: (WICKET-2021) When a form is not valid, the textfields become with "raw input" and can't change its model on subsequent requests
[ https://issues.apache.org/jira/browse/WICKET-2021?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12664375#action_12664375 ] Matej Knopp commented on WICKET-2021: - Also you can call clearInput on form - that will clear input on all form components within the form > When a form is not valid, the textfields become with "raw input" and can't > change its model on subsequent requests > -- > > Key: WICKET-2021 > URL: https://issues.apache.org/jira/browse/WICKET-2021 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.4-RC1 >Reporter: Adriano dos Santos Fernandes >Assignee: Igor Vaynberg > Fix For: 1.5-M1 > > Attachments: formvalidationtest.tar.gz, patch.diff > > > Quickstart attached. To reproduce: > 1) Open the homepage > 2) Enter something on the second field and click submit > 3) An error is displayed - the first field is required > 4) Click changeModel (that doesn't submit the form) > 5) The labels update, but the textfields doesn't > Also attached a patch that seems to fix the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1981) LinkTree generates markup which breaks xhtml transitional validation
[ https://issues.apache.org/jira/browse/WICKET-1981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12657070#action_12657070 ] Matej Knopp commented on WICKET-1981: - Does LinkTree really generate the ? Isn't the tree component attached to a span in your markup file? > LinkTree generates markup which breaks xhtml transitional validation > > > Key: WICKET-1981 > URL: https://issues.apache.org/jira/browse/WICKET-1981 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.4, 1.3.5, 1.4-M1, 1.4-M2, 1.4-M3, 1.4-RC1 > Environment: Java 5.0, OSX, Macbook Pro >Reporter: Ross McDonald >Assignee: Matej Knopp > > The markup produced by LinkTree breaks xhtml transitional validation. > > > ... > ... > The span should be replaced with a div. > In addition, the icon images produced by the component are lacking an 'alt' > attribute, which also breaks accessibility. > src="../resources/org.apache.wicket.markup.html.tree.LabelIconPanel/res/item.gif"/> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (WICKET-1653) Invalid argument in wicket-ajax.js (line 606) causes not loading ajax lazy load panel in IE
[ https://issues.apache.org/jira/browse/WICKET-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp closed WICKET-1653. --- Resolution: Fixed > Invalid argument in wicket-ajax.js (line 606) causes not loading ajax lazy > load panel in IE > --- > > Key: WICKET-1653 > URL: https://issues.apache.org/jira/browse/WICKET-1653 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.3 > Environment: IE6.0.2900.2180 on xp >Reporter: Per Newgro >Assignee: Matej Knopp >Priority: Critical > > see description at > http://www.nabble.com/javascript-error-in-internet-explorer-td16732896.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1932) IE7 doesn't evaluate inline javascript without element id
[ https://issues.apache.org/jira/browse/WICKET-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647623#action_12647623 ] Matej Knopp commented on WICKET-1932: - I see. Unfortunately this assumes that the first line of javascript is "invalid". We should check if the javascript starts with > Key: WICKET-1932 > URL: https://issues.apache.org/jira/browse/WICKET-1932 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.5 >Reporter: Frank van Lankvelt >Assignee: Matej Knopp > Attachments: ie7eval.tar.gz > > > The javascript as generated by the JavascriptUtils, is not evaluated by the > IE7 eval(). An AJAX response with javascript, but no element id, does not > lead to execution in Wicket.Head.Contributor.prototype.processScript. > Prepending the SCRIPT_CONTENT_PREFIX with "//" seems to fix the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1932) IE7 doesn't evaluate inline javascript without element id
[ https://issues.apache.org/jira/browse/WICKET-1932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12647131#action_12647131 ] Matej Knopp commented on WICKET-1932: - Mind elaborating a bit on this? > IE7 doesn't evaluate inline javascript without element id > - > > Key: WICKET-1932 > URL: https://issues.apache.org/jira/browse/WICKET-1932 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.5 >Reporter: Frank van Lankvelt >Assignee: Matej Knopp > > The javascript as generated by the JavascriptUtils, is not evaluated by the > IE7 eval(). An AJAX response with javascript, but no element id, does not > lead to execution in Wicket.Head.Contributor.prototype.processScript. > Prepending the SCRIPT_CONTENT_PREFIX with "//" seems to fix the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1653) Invalid argument in wicket-ajax.js (line 606) causes not loading ajax lazy load panel in IE
[ https://issues.apache.org/jira/browse/WICKET-1653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp updated WICKET-1653: Priority: Critical (was: Major) I bumped up the priority. I'll look at it as soon as I get XP working in vmware (which will be as soon as my new RAM arrives. Which can take a while unfortunately). > Invalid argument in wicket-ajax.js (line 606) causes not loading ajax lazy > load panel in IE > --- > > Key: WICKET-1653 > URL: https://issues.apache.org/jira/browse/WICKET-1653 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.3 > Environment: IE6.0.2900.2180 on xp >Reporter: Per Newgro >Assignee: Matej Knopp >Priority: Critical > > see description at > http://www.nabble.com/javascript-error-in-internet-explorer-td16732896.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1862) Please consider backing out changes to Component that merged dissimilar objects into an Object[]
[ https://issues.apache.org/jira/browse/WICKET-1862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12637999#action_12637999 ] Matej Knopp commented on WICKET-1862: - As weird as the code might look like, we really had a good reason for making it the way it is. I was profiing it a lot when making that change and with the application i was working on (fairly regular wicket application) the improvement was 30-40%. Also I really don't see the difficulty of debugging. You can use debugger expression or look at the data object to see what is stored in there. > Please consider backing out changes to Component that merged dissimilar > objects into an Object[] > > > Key: WICKET-1862 > URL: https://issues.apache.org/jira/browse/WICKET-1862 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.4 >Reporter: Willis Blackburn >Priority: Minor > > In Wicket 1.2, the members of the Component class were pretty straightforward. > But in 1.3, three fields, including the model, have been merged into a single > Object[], and there are new methods called data_get, data_set, data_length, > data_add, data_remove, and data_insert, to deal with the array. > I cannot determine from the source code why this was done, but it does not > seem like a change for the better. The Component class is now very > confusing, and the change has also made working with any Component subclass > (in other words, practically every Wicket class!) in the debugger more > difficult. I think that when three fields that used to be accessed in a > simple and straightforward manner are replaced by 160 lines of code, there > needs to be some very compelling reason. > Maybe the motivation was to reduce the memory footprint of a Component > instance that does not have any model, behaviors, or metadata, or maybe one > that just has one of the three? If so, is that really so compelling? Is the > memory footprint that large? Are users suffering from problems that have > been addressed by this solution? In the context of the memory usage of a > typical webapp, saving something like 8 bytes per Component instance does not > seem like that much. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1845) WicketRuntimeException when using wicket-auth-roles in a frameset
[
https://issues.apache.org/jira/browse/WICKET-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12634570#action_12634570
]
Matej Knopp commented on WICKET-1845:
-
You have to call getSession().bind() in your frameset page constructor.
(because the page as well as the header page is stateless so it doesn't bind
the session. But you have to ensure that all pages come from same session
anyway)
> WicketRuntimeException when using wicket-auth-roles in a frameset
> -
>
> Key: WICKET-1845
> URL: https://issues.apache.org/jira/browse/WICKET-1845
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-auth-roles
>Affects Versions: 1.3.4
> Environment: Windows XP, WebSphere 6.1
>Reporter: Steve Hiller
>Assignee: Matej Knopp
>Priority: Minor
> Attachments: myproject.zip, pom.xml, stacktrace.txt
>
>
> Hi All,
> I seem to have a very strange exception when using wicket-auth-roles in a
> frameset.
> Let me try and sketch out the setup:
> 1) Application home page is called FramesetPage.java
> -- it extends org.apache.wicket.markup.html.WebPage
> -- corresponding HTML contains simple frameset with 2 rows
> 2) Top row of frameset contains TopFramePage.java
> -- it extends org.apache.wicket.markup.html.WebPage
> -- corresponding HTML contains only an image component as follows:
>-- add(new Image("bannerImage", "logo.png"));
> 3) Bottom row of frameset contains BottomFramePage.java
> -- it extends org.apache.wicket.markup.html.WebPage
> -- it requires authentication/authorization using wicket-auth-roles (as
> is, straight out of the jar)
> -- if not already authenticated/authorized then redirected to
> MySignInPage.java
> -- it extends
> org.apache.wicket.authentication.pages.SignInPage
> -- corresponding HTML contains standard wicket:id="signInPanel"/> tag
>
> Here's the strange part: After completing the 'Username' and 'Password'
> fields of the
> signInPanel then the exception displayed in the attached stack trace is
> thrown. Further, if I replace the image
> component in TopFramePage with some CSS that loads the same image then no
> exception is thrown.
> Any thoughts on what is causing this problem?
> Thanks,
> Steve
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1845) WicketRuntimeException when using wicket-auth-roles in a frameset
[
https://issues.apache.org/jira/browse/WICKET-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-1845.
-
Resolution: Fixed
> WicketRuntimeException when using wicket-auth-roles in a frameset
> -
>
> Key: WICKET-1845
> URL: https://issues.apache.org/jira/browse/WICKET-1845
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-auth-roles
>Affects Versions: 1.3.4
> Environment: Windows XP, WebSphere 6.1
>Reporter: Steve Hiller
>Assignee: Matej Knopp
>Priority: Minor
> Attachments: myproject.zip, pom.xml, stacktrace.txt
>
>
> Hi All,
> I seem to have a very strange exception when using wicket-auth-roles in a
> frameset.
> Let me try and sketch out the setup:
> 1) Application home page is called FramesetPage.java
> -- it extends org.apache.wicket.markup.html.WebPage
> -- corresponding HTML contains simple frameset with 2 rows
> 2) Top row of frameset contains TopFramePage.java
> -- it extends org.apache.wicket.markup.html.WebPage
> -- corresponding HTML contains only an image component as follows:
>-- add(new Image("bannerImage", "logo.png"));
> 3) Bottom row of frameset contains BottomFramePage.java
> -- it extends org.apache.wicket.markup.html.WebPage
> -- it requires authentication/authorization using wicket-auth-roles (as
> is, straight out of the jar)
> -- if not already authenticated/authorized then redirected to
> MySignInPage.java
> -- it extends
> org.apache.wicket.authentication.pages.SignInPage
> -- corresponding HTML contains standard wicket:id="signInPanel"/> tag
>
> Here's the strange part: After completing the 'Username' and 'Password'
> fields of the
> signInPanel then the exception displayed in the attached stack trace is
> thrown. Further, if I replace the image
> component in TopFramePage with some CSS that loads the same image then no
> exception is thrown.
> Any thoughts on what is causing this problem?
> Thanks,
> Steve
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1845) WicketRuntimeException when using wicket-auth-roles in a frameset
[
https://issues.apache.org/jira/browse/WICKET-1845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp reassigned WICKET-1845:
---
Assignee: Matej Knopp (was: Igor Vaynberg)
> WicketRuntimeException when using wicket-auth-roles in a frameset
> -
>
> Key: WICKET-1845
> URL: https://issues.apache.org/jira/browse/WICKET-1845
> Project: Wicket
> Issue Type: Bug
> Components: wicket, wicket-auth-roles
>Affects Versions: 1.3.4
> Environment: Windows XP, WebSphere 6.1
>Reporter: Steve Hiller
>Assignee: Matej Knopp
>Priority: Minor
> Attachments: myproject.zip, pom.xml, stacktrace.txt
>
>
> Hi All,
> I seem to have a very strange exception when using wicket-auth-roles in a
> frameset.
> Let me try and sketch out the setup:
> 1) Application home page is called FramesetPage.java
> -- it extends org.apache.wicket.markup.html.WebPage
> -- corresponding HTML contains simple frameset with 2 rows
> 2) Top row of frameset contains TopFramePage.java
> -- it extends org.apache.wicket.markup.html.WebPage
> -- corresponding HTML contains only an image component as follows:
>-- add(new Image("bannerImage", "logo.png"));
> 3) Bottom row of frameset contains BottomFramePage.java
> -- it extends org.apache.wicket.markup.html.WebPage
> -- it requires authentication/authorization using wicket-auth-roles (as
> is, straight out of the jar)
> -- if not already authenticated/authorized then redirected to
> MySignInPage.java
> -- it extends
> org.apache.wicket.authentication.pages.SignInPage
> -- corresponding HTML contains standard wicket:id="signInPanel"/> tag
>
> Here's the strange part: After completing the 'Username' and 'Password'
> fields of the
> signInPanel then the exception displayed in the attached stack trace is
> thrown. Further, if I replace the image
> component in TopFramePage with some CSS that loads the same image then no
> exception is thrown.
> Any thoughts on what is causing this problem?
> Thanks,
> Steve
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1623) LinkTree with IndicatingAjaxLink leaks
[ https://issues.apache.org/jira/browse/WICKET-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632477#action_12632477 ] Matej Knopp commented on WICKET-1623: - Committed fix for 1.3 branch and trunk > LinkTree with IndicatingAjaxLink leaks
[jira] Commented: (WICKET-1623) LinkTree with IndicatingAjaxLink leaks
[ https://issues.apache.org/jira/browse/WICKET-1623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632472#action_12632472 ] Matej Knopp commented on WICKET-1623: - I was thinking of leaking of the actual indicator. Okay, the script indeed leaks, it's because of Ajax header contribution > LinkTree with IndicatingAjaxLink leaks
[jira] Resolved: (WICKET-1502) Slow opening of ModalWindow for complex pages
[
https://issues.apache.org/jira/browse/WICKET-1502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-1502.
-
Resolution: Fixed
Fix Version/s: 1.3.5
> Slow opening of ModalWindow for complex pages
> -
>
> Key: WICKET-1502
> URL: https://issues.apache.org/jira/browse/WICKET-1502
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
>Affects Versions: 1.3.2
> Environment: Firefox 2
>Reporter: Martin Grigorov
>Assignee: Matej Knopp
>Priority: Minor
> Fix For: 1.3.5
>
>
> I'm experiencing bad performance when opening a ModalWindow. Profiling it
> with Firebug I found that the hot spot is modal.js -> disableFocus() ->
> disableFocusElement() (which is recursive and iterates over all children of
> ).
> I have a (relatively) complex page with a modal window and Firebug profiler
> shows these results:
> disableFocusElement 982381.72% 1379.189ms 1379.189ms 0.14ms
> 0.014ms 768.042ms modal.js (line 1373)
> bind 9 2.9%48.908ms49.861ms5.54ms 0.098ms
> 45.192msmodal.js (line 408)
>
> As you see there are ~1 calls to disableFocusElement (i.e. there are
> ~1 sub-elements of ).
> The following patch improves the performance and still remains the
> functionality:
> Index:
> src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
> ===
> ---
> src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
> (revision 646196)
> +++
> src/main/java/org/apache/wicket/extensions/ajax/markup/html/modal/res/modal.js
> (working copy)
> @@ -1251,9 +1251,9 @@
> this.document = doc;
>
> // disable user interaction
> - this.hideSelectBoxes();
> - this.disableTabs();
> - this.disableFocus();
> + setTimeout(function() {this.hideSelectBoxes()}.bind(this),
> 300);
> + setTimeout(function() {this.disableTabs()}.bind(this), 400);
> + setTimeout(function() {this.disableFocus()}.bind(this), 1000);
> },
> Note: calling "setTimeout(function() {this.disableFocus()}.bind(this),
> *500*);" didn't help in my case. It needs to be bigger.
> The user experience is good and I don't see any drawbacks of this
> modification.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1368) ModalWindow causes display of JavaScript message "Reloading this page will cause modal window to disappear" when calling setResponsePage() in AjaxButton.onSubmit after M
[ https://issues.apache.org/jira/browse/WICKET-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-1368. - Resolution: Invalid Set the Wicket.Window.unloadConfirmation = false; javascript flag somewhere on your page > ModalWindow causes display of JavaScript message "Reloading this page will > cause modal window to disappear" when calling setResponsePage() in > AjaxButton.onSubmit after ModalWindow.close(target) > - > > Key: WICKET-1368 > URL: https://issues.apache.org/jira/browse/WICKET-1368 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.1 > Environment: Windows Vista, JDK 1.6, Firefox 2 and Internet Explorer 7 >Reporter: Bernd Mrohs >Assignee: Matej Knopp >Priority: Minor > > A ModalWindow is used to display a form. This form is submitted using an > AjaxButton. In the onSubmit method, the form fields are processed, and then > close(target) of the ModalWindow is called to close it. After the close, > setResponsePage(someother.class) is called to redirect the user. This > setResponsePage() leads to a JavaScript message "Reloading this page will > cause modal window to disappear", and the ModalWindow is not closes. This > happens with Firefox 2 and Internet Explorer 7. If setResponsePage() is not > called, the ModalWindow closes perfectly. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1426) URL creation in wicket-ajax.js -> Wicket.Ajax.Call.doGet produces broken URLs for Gecko
[
https://issues.apache.org/jira/browse/WICKET-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632468#action_12632468
]
Matej Knopp commented on WICKET-1426:
-
I removed the workaround code from Wicket because it was causing problems with
absolute URLs. I can't reproduce the problem on Firefox (test both 2 and 3)
with latest trunk
> URL creation in wicket-ajax.js -> Wicket.Ajax.Call.doGet produces broken URLs
> for Gecko
> ---
>
> Key: WICKET-1426
> URL: https://issues.apache.org/jira/browse/WICKET-1426
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Firefox 2
>Reporter: Martin Grigorov
>Assignee: Matej Knopp
>
> With r628015 (Wicket 1.3.2) creation of full URL for Gecko browsers creates
> broken URLs when there is a slash ('/') in the http parameter values.
> For example when a page with this URL is loaded:
> http://localhost/app?key=value/
> wicketAjaxGet will issue a query with this content:
> http://localhost/app?key=value/../?wicket:interface=:
> By RFC2396 the query part of URL could be:
> query = *uric
> uric = reserved | unreserved | escaped
> reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
> "$" | ","
> unreserved= alphanum | mark
> So '/' is allowed.
> Here is a quick patch:
> --- wicket-ajax.js (revision 637425)
> +++ wicket-ajax.js (working copy)
> @@ -823,6 +823,10 @@
> if (t != null) {
> if (Wicket.Browser.isGecko()) {
> var href = document.location.href;
> + var lastIndexOfQuestionMark =
> href.lastIndexOf('?');
> + if (lastIndexOfQuestionMark > -1) {
> + href = href.substring(0,
> lastIndexOfQuestionMark);
> + }
> var lastIndexOf =
> href.lastIndexOf('/');
> if (lastIndexOf > 0)
> {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1426) URL creation in wicket-ajax.js -> Wicket.Ajax.Call.doGet produces broken URLs for Gecko
[
https://issues.apache.org/jira/browse/WICKET-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-1426.
-
Resolution: Cannot Reproduce
Please reopen if still valid
> URL creation in wicket-ajax.js -> Wicket.Ajax.Call.doGet produces broken URLs
> for Gecko
> ---
>
> Key: WICKET-1426
> URL: https://issues.apache.org/jira/browse/WICKET-1426
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.2
> Environment: Firefox 2
>Reporter: Martin Grigorov
>Assignee: Matej Knopp
>
> With r628015 (Wicket 1.3.2) creation of full URL for Gecko browsers creates
> broken URLs when there is a slash ('/') in the http parameter values.
> For example when a page with this URL is loaded:
> http://localhost/app?key=value/
> wicketAjaxGet will issue a query with this content:
> http://localhost/app?key=value/../?wicket:interface=:
> By RFC2396 the query part of URL could be:
> query = *uric
> uric = reserved | unreserved | escaped
> reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
> "$" | ","
> unreserved= alphanum | mark
> So '/' is allowed.
> Here is a quick patch:
> --- wicket-ajax.js (revision 637425)
> +++ wicket-ajax.js (working copy)
> @@ -823,6 +823,10 @@
> if (t != null) {
> if (Wicket.Browser.isGecko()) {
> var href = document.location.href;
> + var lastIndexOfQuestionMark =
> href.lastIndexOf('?');
> + if (lastIndexOfQuestionMark > -1) {
> + href = href.substring(0,
> lastIndexOfQuestionMark);
> + }
> var lastIndexOf =
> href.lastIndexOf('/');
> if (lastIndexOf > 0)
> {
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1707) Wicket.replaceOuterHtmlIE() (wicket-ajax.js) has very low performance.
[ https://issues.apache.org/jira/browse/WICKET-1707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632450#action_12632450 ] Matej Knopp commented on WICKET-1707: - I would have to see some code. Is there any additional (3rd party) javascript on the page? > Wicket.replaceOuterHtmlIE() (wicket-ajax.js) has very low performance. > -- > > Key: WICKET-1707 > URL: https://issues.apache.org/jira/browse/WICKET-1707 > Project: Wicket > Issue Type: Improvement > Components: wicket > Environment: IE 7.0 >Reporter: Bartosz Owczarek >Assignee: Matej Knopp > > Hi. > Firstly I'd like to say that I'm using wicket framework in my company in > 'e-commerce' system for Business Users. Its main functionality is ordering > items available in stores by business users. Items are displayed in a > customized table (we're using DataView component for it). This table is a > little bit complicated from DOM point of view. Some columns contain images, > input components, and different css styles for each row or even column (that > are added dynamically in javacode using AttributeModifier). There's about 22 > columns in table. > Moreover table is paginable and number of items per page can be change by > filter on the web page (default is 50). Paging table is done by our > customized paging navigator that uses AjaxEventBeahvior. In other words table > is refreshed using build-in ajax provided with wicket. Whati is more only > tag with its content is refreshed by ajax request (not whole ). > After implementation I've done some testing so here are results... > Table is refreshed very quickly in FireFox 3 by wicket-ajax.js after > receiving response but there is a huge performance bottleneck with refreshing > it in IE 7.0.I profiled whole wicket-ajax.js in order to find this > bottleneck. It appears that replacing outer html in IE takes about 4 seconds > (druing which IE freezes). It's not acceptable. I found that > Wicket.replaceOuterHtmlIE() method takes around 3.7seconds! That's when only > 50 items in table are displayed!. If we change items per page to greater > number then it takes much more time. When I commented body of this function, > IE doesn't freeze and performance is very good, but content that comes with > ajax response is not refreshed in browser, which is obvious. > Then I tried to use jQuery(..).replaceWith() function in > Wicket.replaceOuterHtmlIE() whereas rest of its body was commented. It is > faster than default Wicket.replaceOuterHtmlIE() implementation. It takes > about 1.7 second to render response in browser but of course it doesn't do > all things as default Wicket.replaceOuterHtmlIE() implementation does (i.e. > default implementation runs embedded javascripts in
[jira] Resolved: (WICKET-1286) HybridUrlCodingStrategy should throw an error for paths with trailing /
[ https://issues.apache.org/jira/browse/WICKET-1286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-1286. - Resolution: Fixed > HybridUrlCodingStrategy should throw an error for paths with trailing / > --- > > Key: WICKET-1286 > URL: https://issues.apache.org/jira/browse/WICKET-1286 > Project: Wicket > Issue Type: Improvement >Affects Versions: 1.3.0-final >Reporter: Ryan McKinley >Assignee: Matej Knopp >Priority: Trivial > Attachments: WICKET-1286-HybridUrlCodingStrategy.patch > > > Registering a path with trailing / causes the HybridUrlCodingStrategy to > redirect to an invalid page -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1343) HybridUrlCodingStrategy and StatelessForm ( or StatelessLink ) results in invalid parameter encoding
[ https://issues.apache.org/jira/browse/WICKET-1343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-1343. - Resolution: Fixed > HybridUrlCodingStrategy and StatelessForm ( or StatelessLink ) results in > invalid parameter encoding > > > Key: WICKET-1343 > URL: https://issues.apache.org/jira/browse/WICKET-1343 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.1 >Reporter: demir kiracoglu >Assignee: Matej Knopp > Fix For: 1.5-M1 > > > I put a header component on one of my pages which contains a statelessform ( > or stateless link ) . I mounted the page with a HybridUrlCodingStrategy . > When you request the page like this > http://localhost:9696/mountpath/param1/param1value, > stateless form attaches another parameter which shows the forms IFormListener > target. The new url is like this : > http://localhost:9696/mountpath/param1/param1value/wicket:interface/%3A0%3Aheader%3AloggedOutView%3AloginForm%3A%3AIFormSubmitListener%3A%3A/.0 > I haven't covered all the source code for now but i think the form changes > the page parameters object so i think HybridUrlCodingStrategy must clone > initial page parameters before putting it to page metadata. But not sure that > this will cause any other problems -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-918) allow for pluggable javascript compression algorithms
[
https://issues.apache.org/jira/browse/WICKET-918?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp updated WICKET-918:
---
Fix Version/s: (was: 1.4-M4)
1.5-M1
> allow for pluggable javascript compression algorithms
> -
>
> Key: WICKET-918
> URL: https://issues.apache.org/jira/browse/WICKET-918
> Project: Wicket
> Issue Type: Improvement
> Components: wicket
>Reporter: Ryan Sonnek
>Assignee: Matej Knopp
>Priority: Minor
> Fix For: 1.5-M1
>
>
> The current JavascripResource uses a very simple algorithm to compress
> javascript (JavascriptStripper). This should be abstracted into a pluggable
> interface so that any algorithm can be used. There are a number of popular
> javascript compression tools out there that could be integrated into wicket
> if this feature is supported.
> * dojo javascript compression tool
> * JSMin
> * YUI compression tool
> My suggestion for implementation would be to create an interface:
> {code}
> public interface JavascriptCompressor {
> public String stripCommentsAndWhitespace(String original);
> }
> {code}
> The existing JavascriptStripper would be the default implementation, but
> there would be an application setting to swap in a different implementation.
> Actually I would recommend creating a NoOp implementation as the default
> implementation.
> {code}
> public class MyApplication extends WebApplication {
> public void init() {
> getResourceSettings().setJavascriptCompressor(new
> MyFancyJavascriptCompressor());
> }
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1491) ModalWindow: unclear exception if property "Content" is not set
[
https://issues.apache.org/jira/browse/WICKET-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-1491.
-
Resolution: Fixed
There should be no exception
> ModalWindow: unclear exception if property "Content" is not set
> ---
>
> Key: WICKET-1491
> URL: https://issues.apache.org/jira/browse/WICKET-1491
> Project: Wicket
> Issue Type: Improvement
> Components: wicket-extensions
>Affects Versions: 1.3.2
>Reporter: Sergey Derugo
>Assignee: Matej Knopp
>
> 1. Create ModalWindow and don't set property *content* , for example:
> {code}
> package test.demo.webcontrols.popup;
> import org.apache.wicket.extensions.ajax.markup.html.modal.ModalWindow;
> public class DialogMessage extends ModalWindow {
> public DialogMessage(String id) {
> super(id);
> setTitle("popups.notification.header");
> //setContent(new InformationMessageContent(getContentId()));
> }
> }
> {code}
> 2. Create instance of DialogMessage and call method *show* - exception is
> thrown:
> message - WicketMessage: Error creating page for modal dialog.
> Using this exception it's impossible to understand what is wrong. Either
> exception message should be more detailed.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1399) Escaping DiskPageStore SessionFolder needed
[
https://issues.apache.org/jira/browse/WICKET-1399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-1399.
-
Resolution: Fixed
> Escaping DiskPageStore SessionFolder needed
> ---
>
> Key: WICKET-1399
> URL: https://issues.apache.org/jira/browse/WICKET-1399
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.3.1
> Environment: win xp, sun jdk 1.5.0_12, jboss-4.2.2.ga+tomcat-5.5
>Reporter: Filippo Guerzoni
>Assignee: Matej Knopp
>
> When sessionId=8y4bxNcyiScVVV6QtVp9lg**.node1 Wicket can't create the temp
> directory because the name contains invalid character (at least on windows).
> So a FileNotFoundException is thrown.
> The use case happens when tomcat is configured as (in order to work with
> apache module mod_jk)
>
> emptySessionPath="true" enableLookups="false" redirectPort="8443" />
>
> My very temp solution (to let things go) is
> private File getSessionFolder(String sessionId, boolean create)
> {
> File storeFolder = getStoreFolder();
> File sessionFolder = new File(storeFolder,
> sessionId.replace('*','_'));
> if (create && sessionFolder.exists() == false)
> {
> mkdirs(sessionFolder);
> }
> return sessionFolder;
> }
> I think that a global solution is needed to fix the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1826) Forms + ModalWindow + AjaxSubmitLink + FormComponent#isInputNullable
[ https://issues.apache.org/jira/browse/WICKET-1826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-1826. - Resolution: Invalid This shouldn't happen if you have form in your modal window. If that's the case only the form inside modal window should be processed. Also in 1.3 if you have modal window with panel with form, you should always place the modal window inside another form. If this problem still persists (in current 1.3 branch) please reopen the issue > Forms + ModalWindow + AjaxSubmitLink + FormComponent#isInputNullable > > > Key: WICKET-1826 > URL: https://issues.apache.org/jira/browse/WICKET-1826 > Project: Wicket > Issue Type: Bug > Components: wicket, wicket-extensions >Affects Versions: 1.3.3 >Reporter: German Morales >Assignee: Matej Knopp >Priority: Minor > Attachments: modalwindowform.jar > > > Submiting a form which is inside a ModalWindow, wicket javascript sends only > the information for the modal window's form, but not for the root form of the > page (because ModalWindow hangs its own div at body level). > On Wicket server side, the form processing is done for the root form, which > calls inputChanged for all the components in the page, but the javascript > side didn't send the information for them, and then some of them go wrong. > That happens to FormComponents which have isInputNullable in true. > More description and proposed solutions in the (to be) attached quickstart > project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1550) AbstractDefaultAjaxBehavior ....shows the ajax indicator even if precondition script returns false
[ https://issues.apache.org/jira/browse/WICKET-1550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-1550. - Resolution: Won't Fix Can't be fixed wicket current ajax infrastructure. Will be addressed in 1.5 > AbstractDefaultAjaxBehavior shows the ajax indicator even if precondition > script returns false > -- > > Key: WICKET-1550 > URL: https://issues.apache.org/jira/browse/WICKET-1550 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.3 >Reporter: atul singh >Assignee: Matej Knopp >Priority: Minor > Original Estimate: 0.25h > Remaining Estimate: 0.25h > > AbstractDefaultAjaxBehavior shows the ajax indicator even if precondition > script returns false. > Precondition script returns false means no call will be made actually to the > server, And hence no indicator should be shown. > How this impacts: In my particular scenario it keeps showing all the time, > though i go to the server only when a javascript function returns true -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1576) Modal Window not opening the second time
[ https://issues.apache.org/jira/browse/WICKET-1576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632457#action_12632457 ] Matej Knopp commented on WICKET-1576: - Would need source code of the project, not war to look into this. > Modal Window not opening the second time > > > Key: WICKET-1576 > URL: https://issues.apache.org/jira/browse/WICKET-1576 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.3.3 >Reporter: Marieke Vandamme >Assignee: Matej Knopp >Priority: Minor > Attachments: ModalWindowTestcase.war > > > After closing a ModalWindow and open it the second time, nothing happens. > I can refer to the mailinglist : > http://www.nabble.com/Modal-Window-not-opening-the-second-time-td16850180.html > and i attach a test case > thanks ! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WICKET-1578) MixedParamUrlCodingStrategy makes an incorrect assumption about RequestParameters.parametersMap of type String where as its String[] according to Servlet 2.3 and later
[ https://issues.apache.org/jira/browse/WICKET-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp reassigned WICKET-1578: --- Assignee: Johan Compagner (was: Matej Knopp) > MixedParamUrlCodingStrategy makes an incorrect assumption about > RequestParameters.parametersMap of type String where as its String[] > according to Servlet 2.3 and later > --- > > Key: WICKET-1578 > URL: https://issues.apache.org/jira/browse/WICKET-1578 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.3 > Environment: Windows >Reporter: Ritesh Trivedi >Assignee: Johan Compagner > Attachments: MixedParamUrlCodingStrategy.java.diff > > > MixedParamUrlCodingStrategy makes an incorrect assumption about > RequestParameters.parametersMap of type String where as its String[] > according to Servlet 2.3 and later > Look at MixedParamUrlCodingStrategy.appendParameters (line 153) its type > casting to (String) which throws ClassCastException at runtime since its of > type String[]. > Same issue for decodeParameters. > I actually have question about multivalued parameters. Will any of the URL > schemes handle these correctly? if yes - is there an example that shows how? -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1033) Allow Grace Period for AJAX Busy Indication
[ https://issues.apache.org/jira/browse/WICKET-1033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp updated WICKET-1033: Fix Version/s: (was: 1.4-M4) 1.5-M1 > Allow Grace Period for AJAX Busy Indication > --- > > Key: WICKET-1033 > URL: https://issues.apache.org/jira/browse/WICKET-1033 > Project: Wicket > Issue Type: Improvement > Components: wicket >Affects Versions: 1.3.0-beta3 >Reporter: Thomas Mäder >Assignee: Matej Knopp >Priority: Minor > Fix For: 1.5-M1 > > > The support around IAjaxIndicatorAware allows to show a busy indicator when > there is an AJAX call active; nice! However, we have a couple of pages where > we do multiple, short AJAX updates. This leads to the busy indicator > flickering in and out of existence multiple times. It would be nice if one > could specify a grace period after which the busy indicator is shown. This > would prevent the flickering and still inform the user that the app is not > hung. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-153) FormElement cookies not set when called using AJAX
[ https://issues.apache.org/jira/browse/WICKET-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp updated WICKET-153: --- Fix Version/s: (was: 1.4-M4) 1.5-M1 > FormElement cookies not set when called using AJAX > -- > > Key: WICKET-153 > URL: https://issues.apache.org/jira/browse/WICKET-153 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.2.3 >Reporter: Erik van Oosten >Assignee: Matej Knopp >Priority: Minor > Fix For: 1.5-M1 > > > I have a DropDownChoice with wantOnSelectionChangedNotifications returning > true and persistent set to true. > Unfortunately the cookie is not set when the submit is done through AJAX > (with an AjaxSubmitButton). > In addition when there is a cookie in the AJAX request, that cookie is not > used for the form component's value when it is constructed during the AJAX > call. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1746) gecko: ajax javascript reference rendering problem
[
https://issues.apache.org/jira/browse/WICKET-1746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Matej Knopp resolved WICKET-1746.
-
Resolution: Fixed
Fix Version/s: 1.4-M4
1.3.5
removed the workaround. might be a leftover or fix for some bug in ff beta
> gecko: ajax javascript reference rendering problem
> --
>
> Key: WICKET-1746
> URL: https://issues.apache.org/jira/browse/WICKET-1746
> Project: Wicket
> Issue Type: Bug
> Components: wicket
>Affects Versions: 1.4-M2
>Reporter: Jan Loose
>Assignee: Matej Knopp
> Fix For: 1.3.5, 1.4-M4
>
>
> Hi,
> i tried render the javascript as:
> public void renderHead(IHeaderResponse response) {
> response.renderJavascriptReference(contextPath + "js/test.js");
> }
> The test.js is in webapp/js/test.js (out of classpath). All works greatly in
> Opera but in FF (gecko) is there a problem in wicket-ajax.js (the code is
> form trunk version):
> 836: if (Wicket.Browser.isGecko()) {
> 837: var href = document.location.href;
> 838: var lastIndexOf = href.lastIndexOf('/');
> 839: if (lastIndexOf > 0)
> 840: {
> 841: url = href.substring(0,lastIndexOf+1) + url;
> 842:}
> 843:}
> Why is there this fix/workaround? This works only for relative path but for
> absolute is this code broken.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1563) renderOnLoadJavascript being called multiple times
[ https://issues.apache.org/jira/browse/WICKET-1563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12632447#action_12632447 ] Matej Knopp commented on WICKET-1563: - First of all - I don't see why the renderHead method should be called by page#detach. That doesn't make whole lot sense to me. Another thing is that the contribution is already filtered. If the javascript method has same body it will only be rendered once per request. > renderOnLoadJavascript being called multiple times > -- > > Key: WICKET-1563 > URL: https://issues.apache.org/jira/browse/WICKET-1563 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.3 >Reporter: Carlos Pita >Assignee: Matej Knopp > > There are at least of couple of common scenarios where this happens: > - you add the component that is a header contributor to an ajax target: > renderHead is called as part of target.respond() and latter by page.detach() > - you add the component that is a header contributor more than once to an > ajax target. Normally you can't control this, because the component in > question is added by another component indirectly, by adding some of its > ancestors. renderHead is called multiple times as part of target.respond() > and latter yet another time by page.detach() > I think there must be a check to avoid repetitions of these nature, maybe by > means of an id, the same as renderJavascript() does. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1177) partial ajax updates on repeater components
[ https://issues.apache.org/jira/browse/WICKET-1177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp updated WICKET-1177: Fix Version/s: (was: 1.4-M4) 1.5-M1 > partial ajax updates on repeater components > --- > > Key: WICKET-1177 > URL: https://issues.apache.org/jira/browse/WICKET-1177 > Project: Wicket > Issue Type: Wish > Components: wicket >Affects Versions: 1.3.0-rc2 >Reporter: Peter Ertl >Assignee: Matej Knopp > Fix For: 1.5-M1 > > > I try to explain the problem using an example: > Imagine having a guestbook page where you can add new user entries via ajax > post... > Assume we are using RefreshingView to display the user entries. Once a user > submits a new post the view should not be re-rendered in the ajax response > completely but only the new user entry. > Technically it's easy to address the view items by using e.g. > ListItem#setOutputMarkupId(true). > However, things are more complicated. > When the user clicks on the submit button a background ajax request is > created and a form submit listener is invoked. There the new guestbook post > is saved in the data model. Then you want to update the list with the new > entry using target.addComponent(..) . Also, applying a yellow fade effect to > the component would be cool as an visual indication for the user. However, > there is no way I can think of to get the proper view item(s) for the model > object (=new user entry). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WICKET-1120) Problem closing a ModalWindow when used through an IFrame
[ https://issues.apache.org/jira/browse/WICKET-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matej Knopp resolved WICKET-1120. - Resolution: Fixed Fix Version/s: 1.3.5 commited fix for 1.3 branch and trunk > Problem closing a ModalWindow when used through an IFrame > - > > Key: WICKET-1120 > URL: https://issues.apache.org/jira/browse/WICKET-1120 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 1.3.0-rc1 >Reporter: Deepak Mahavishnu >Assignee: Matej Knopp > Fix For: 1.3.5, 1.4-M4 > > > I'm doing some POC testing to find out how a wicket application could be used > through an IFrame and noticed that closing of a ModalWindow fails. > My setup: > Application A: > -a dummy html page that has an IFrame > -the contents of the IFrame is requested from Application B > http://localhost:8080/mywicketapp/app/"; width="100%" > height="500"> > Application B: > -a Wicket application that uses a ModalWindow > -deployed to tomcat: http://localhost:8080/mywicketapp/ > Problem: > The ModalWindow is not closed when OK ( or Cancel ) button is clicked when > Application B is used throug IFrame of Application A. > OK button performs the actual action (in my case deletes an item from a list) > but is not closed after the execution of the action. > Closing of the ModalWindow works normally when Application B is not used > through an IFrame. > Reproducing the problem: > You can test this by creating a html page with this source: > > > src="http://www.wicket-library.com/wicket-examples/ajax/modal-window.1"; > width="100%" height="100%"> > > > And then open "Show modal dialog with panel" and try to close the dialog. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
