[jira] [Created] (WICKET-5506) DefaultPropertyResolver should resolve the Property according to the getter first
Vincent MATHON created WICKET-5506: -- Summary: DefaultPropertyResolver should resolve the Property according to the getter first Key: WICKET-5506 URL: https://issues.apache.org/jira/browse/WICKET-5506 Project: Wicket Issue Type: Bug Components: wicket-bean-validation Affects Versions: 6.13.0 Environment: Reporter: Vincent MATHON Assignee: Igor Vaynberg Priority: Minor A domain model model2 may extend a domain model model1 and have JSR303 annotations on one or more getter to override constraints. In such a case, DefaultPropertyResolver cannot detect the right domain model implementation since direct property analysis is done first. Indeed, with the current implementation, if a property is declared in model1 and the getter is overriden in model2, model1 is systematically affected as the property class owner although model2 is the actual implementation associated with the Wicket model. As a consequence, some constraints validations may never been thrown. Swapping direct property analysis and getter analysis solves this problem. Workaround: providing my own property resolver. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (WICKET-5505) DefaultPropertyResolver does not respect JavaBean conventions
Vincent MATHON created WICKET-5505:
--
Summary: DefaultPropertyResolver does not respect JavaBean
conventions
Key: WICKET-5505
URL: https://issues.apache.org/jira/browse/WICKET-5505
Project: Wicket
Issue Type: Bug
Components: wicket-bean-validation
Affects Versions: 6.13.0
Reporter: Vincent MATHON
Assignee: Igor Vaynberg
Priority: Minor
The property name code should handle the isPropertyName pattern
if(getterName.startsWith("get")) {
name = getterName.substring(3, 4).toLowerCase() +
getterName.substring(4);
} else {
name = getterName.substring(2, 3).toLowerCase() +
getterName.substring(3);
}
Workaround: providing my own property resolver.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Updated] (WICKET-5086) FormTester throws an exception when a Palette component is added to a Form associated with a compound property model
[ https://issues.apache.org/jira/browse/WICKET-5086?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent MATHON updated WICKET-5086: --- Attachment: wicket-palette-test.zip A quick start showing the issue. > FormTester throws an exception when a Palette component is added to a Form > associated with a compound property model > > > Key: WICKET-5086 > URL: https://issues.apache.org/jira/browse/WICKET-5086 > Project: Wicket > Issue Type: Bug > Components: wicket >Affects Versions: 6.6.0 > Environment: Windows 7, JDK 1.6_31 >Reporter: Vincent MATHON > Attachments: wicket-palette-test.zip > > > FormTester throws an exception when a Palette component is added to a Form > associated with a compound property model: > org.apache.wicket.WicketRuntimeException: No get method defined for class ... > expression: choices > It worked fine in Wicket 6.5.0, and works fine if the form is not associated > with a compound property model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (WICKET-5086) FormTester throws an exception when a Palette component is added to a Form associated with a compound property model
Vincent MATHON created WICKET-5086: -- Summary: FormTester throws an exception when a Palette component is added to a Form associated with a compound property model Key: WICKET-5086 URL: https://issues.apache.org/jira/browse/WICKET-5086 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 6.6.0 Environment: Windows 7, JDK 1.6_31 Reporter: Vincent MATHON FormTester throws an exception when a Palette component is added to a Form associated with a compound property model: org.apache.wicket.WicketRuntimeException: No get method defined for class ... expression: choices It worked fine in Wicket 6.5.0, and works fine if the form is not associated with a compound property model. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WICKET-3345) Side effect induced by WICKET-2279 fix
[ https://issues.apache.org/jira/browse/WICKET-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983110#action_12983110 ] Vincent MATHON commented on WICKET-3345: No problem, I have a work around, although it's a hack. I tried to build a simpler test case from wicket example but I failed. I am not surprised, Javascript anomaly are sometimes difficult to reproduce, that's why I tried to suggest to implement an optional setting to satisfy all cases... Sincerly Vincent MATHON > Side effect induced by WICKET-2279 fix > -- > > Key: WICKET-3345 > URL: https://issues.apache.org/jira/browse/WICKET-3345 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.12 > Environment: IE8, windows7, Linux redhat >Reporter: Vincent MATHON >Priority: Minor > > This issue is directly related to > https://issues.apache.org/jira/browse/WICKET-2279. > After a migration of Wicket-extension from 1.4.9 to 1.4.12, the suggestions > of some auto-complete fields in my application pages vanish after a few > milliseconds. > I don't understand exactly what happens since my pages are quite complexe but > I solve my issue by replacing wicket-autocomplete.js version 1.4.12 with > version 1.4.9 (I do > a hack in my application's wicket shared resources repository). Note that > except this javascript file I use version 1.4.12 code (for Wicket, > wicket-extension and so on). > Thus, as https://issues.apache.org/jira/browse/WICKET-2279 solves a bug but > introduces also a new one, the piece of code involved should only be > activable through an optional setting. > Vincent MATHON -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-3345) Side effect induced by WICKET-2279 fix
[ https://issues.apache.org/jira/browse/WICKET-3345?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12983088#action_12983088 ] Vincent MATHON commented on WICKET-3345: No it works also for me. As I mentioned, my pages are very complexe, I need time to extract a simpler test case, unfortunately I don't have so much time for the moment... > Side effect induced by WICKET-2279 fix > -- > > Key: WICKET-3345 > URL: https://issues.apache.org/jira/browse/WICKET-3345 > Project: Wicket > Issue Type: Bug > Components: wicket-extensions >Affects Versions: 1.4.12 > Environment: IE8, windows7, Linux redhat >Reporter: Vincent MATHON >Priority: Minor > > This issue is directly related to > https://issues.apache.org/jira/browse/WICKET-2279. > After a migration of Wicket-extension from 1.4.9 to 1.4.12, the suggestions > of some auto-complete fields in my application pages vanish after a few > milliseconds. > I don't understand exactly what happens since my pages are quite complexe but > I solve my issue by replacing wicket-autocomplete.js version 1.4.12 with > version 1.4.9 (I do > a hack in my application's wicket shared resources repository). Note that > except this javascript file I use version 1.4.12 code (for Wicket, > wicket-extension and so on). > Thus, as https://issues.apache.org/jira/browse/WICKET-2279 solves a bug but > introduces also a new one, the piece of code involved should only be > activable through an optional setting. > Vincent MATHON -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-3345) Side effect induced by WICKET-2279 fix
Side effect induced by WICKET-2279 fix -- Key: WICKET-3345 URL: https://issues.apache.org/jira/browse/WICKET-3345 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4.12 Environment: IE8, windows7, Linux redhat Reporter: Vincent MATHON Priority: Minor This issue is directly related to https://issues.apache.org/jira/browse/WICKET-2279. After a migration of Wicket-extension from 1.4.9 to 1.4.12, the suggestions of some auto-complete fields in my application pages vanish after a few milliseconds. I don't understand exactly what happens since my pages are quite complexe but I solve my issue by replacing wicket-autocomplete.js version 1.4.12 with version 1.4.9 (I do a hack in my application's wicket shared resources repository). Note that except this javascript file I use version 1.4.12 code (for Wicket, wicket-extension and so on). Thus, as https://issues.apache.org/jira/browse/WICKET-2279 solves a bug but introduces also a new one, the piece of code involved should only be activable through an optional setting. Vincent MATHON -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Reopened: (WICKET-2514) Encoding issue with wicket Ajax POST form processing
[
https://issues.apache.org/jira/browse/WICKET-2514?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vincent MATHON reopened WICKET-2514:
Sorry but I stil reproduce this anomaly with Wicket 1.4.9, IE6, 7, 8 and FF3.
The workaround in wicket-ajax.js still work like a charm
(t.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded;charset=UTF-8"); instead of
t.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");in the
doPost method). It is just a bit annoying to maintain myself a patched copy of
wicket-ajax.js each time I upgrade Wicket version.
> Encoding issue with wicket Ajax POST form processing
> -
>
> Key: WICKET-2514
> URL: https://issues.apache.org/jira/browse/WICKET-2514
> Project: Wicket
> Issue Type: Bug
>Affects Versions: 1.3.4
> Environment: IE6, FF3
>Reporter: Vincent MATHON
>Assignee: Igor Vaynberg
>
> Ajax submitted forms via POST are not encoded properly when wicket
> applications are configured for a charset different from UTF-8.
> (I mean for instance
> getMarkupSettings().setDefaultMarkupEncoding("ISO-8859-1");
> getRequestCycleSettings().setResponseRequestEncoding("ISO-8859-1");)
> This bug is clearly related to old wicket mailing-list posts:
> http://mail-archives.apache.org/mod_mbox/wicket-users/200804.mbox/%3cdf3d7452-0ac0-4cf7-8164-87e9371d8...@signicat.com%3e
> http://www.nabble.com/BUG-on-wicket-ajax.js-on-Ajax-behaviour-in-IE7to20915921.html#a20915921
> Changing t.setRequestHeader("Content-Type",
> "application/x-www-form-urlencoded"); with
> t.setRequestHeader("Content-Type",
> "application/x-www-form-urlencoded;charset=UTF-8"); in wicket-ajax.js solves
> the problem without adding any specific web server configuration setting
> (like URIEncoding="UTF-8" for TOMCAT). This is the best solution if one not
> wants to sacrify web application portability. More, it seems that Ajax form
> processing should always be encoded in UTF-8 (see WicketFilter implementation
> switch in case of ajax request), so specifiying charset in the javascript
> should not be a problem.
> The javascript code for Ajax POST processing is identical in wicket 1.4.1 so
> this bug should also appear in this version.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2740) DynamicWizardModel: setActiveStep is called twice
DynamicWizardModel: setActiveStep is called twice - Key: WICKET-2740 URL: https://issues.apache.org/jira/browse/WICKET-2740 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.3.4 Reporter: Vincent MATHON DynamicWizardModel constructor calls setActiveStep(startStep); Thus, the Initial step onInit method is called where as the form is not already created. When calling Wizard init() method, there is a call to DynamicWizardModel reset() method that leads to a second Initial step onInit method call. This time, the form is created but I have exceptions since I have already added the components of my first step on the first call to onInit. Removing the call to setActiveStep(startStep); in the DynamicWizardModel constructor solves the bug (note that the activeStep is correctly initialized by the reset method call). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2514) Encoding issue with wicket Ajax POST form processing
Encoding issue with wicket Ajax POST form processing
-
Key: WICKET-2514
URL: https://issues.apache.org/jira/browse/WICKET-2514
Project: Wicket
Issue Type: Bug
Affects Versions: 1.3.4
Environment: IE6, FF3
Reporter: Vincent MATHON
Ajax submitted forms via POST are not encoded properly when wicket applications
are configured for a charset different from UTF-8.
(I mean for instance
getMarkupSettings().setDefaultMarkupEncoding("ISO-8859-1");
getRequestCycleSettings().setResponseRequestEncoding("ISO-8859-1");)
This bug is clearly related to old wicket mailing-list posts:
http://mail-archives.apache.org/mod_mbox/wicket-users/200804.mbox/%3cdf3d7452-0ac0-4cf7-8164-87e9371d8...@signicat.com%3e
http://www.nabble.com/BUG-on-wicket-ajax.js-on-Ajax-behaviour-in-IE7to20915921.html#a20915921
Changing t.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded"); with t.setRequestHeader("Content-Type",
"application/x-www-form-urlencoded;charset=UTF-8"); in wicket-ajax.js solves
the problem without adding any specific web server configuration setting (like
URIEncoding="UTF-8" for TOMCAT). This is the best solution if one not wants to
sacrify web application portability. More, it seems that Ajax form processing
should always be encoded in UTF-8 (see WicketFilter implementation switch in
case of ajax request), so specifiying charset in the javascript should not be a
problem.
The javascript code for Ajax POST processing is identical in wicket 1.4.1 so
this bug should also appear in this version.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1013) spring component injection leads to deserialization error (or page expiration)
[ https://issues.apache.org/jira/browse/WICKET-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12700692#action_12700692 ] Vincent MATHON commented on WICKET-1013: It depends on your configuration. In my case I use a skinny war packaging with an EAR containing a WAR for the web application and JARs for EJB3 services. With this configuration I have to ensure that service classes are loaded by the same classloader for a correct processing of Wicket serialization. I described how to achieve this with JBoss 4.2.1, unfortunately I don' know how to do this with Weblogic. However, if you don't want to modify your server configuration, you can retrieve your services directly from the Spring application context when needed (not as a class field to avoid serialization issues). > spring component injection leads to deserialization error (or page > expiration) > --- > > Key: WICKET-1013 > URL: https://issues.apache.org/jira/browse/WICKET-1013 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.0-beta2 > Environment: windows 2000/ Linux Jboss 4.05 EJB3 or POJO >Reporter: Vincent MATHON >Assignee: Igor Vaynberg > Fix For: 1.3.0-beta4 > > Attachments: TestBackButton-light.zip > > > I made several tests on spring component injection and obtained the following > results. > The test is simply a main page accessing a target page through a link. > 1/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is itself a Spring proxy (a POJO proxy > or an EJB3 proxy). > a) The link is a PageLink ==> This configuration leads to a > deserialization error or a page expiration error whatever Serialization > scheme I use (wicket new one or Java serialization). > b) The link is a BookMarkablePageLink ==> it works. > 2/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is a concrete POJO. > a) The link is a PageLink ==> This configuration leads to a page > expiration error if I use the Java Serialization scheme or alternatively a > page expiration error or a serialization error with the wicket serialization > scheme. > b) The link is a BookMarkablePageLink ==> it works. > 3/ A spring component is accessed through a service locator when needed (so > it's not a class field) > It works for both PageLink and BookMarkablePageLink > Thus, the spring injection can only be used in pages accessed through a > BookMarkablePageLink , for other kind of links one must use a service > locator to avoid proxy serialization. > I suspect that this is not the expected behaviour. > Vincent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2197) BaseWicketTester should not hardcode UTF-8 in isComponentOnAjaxResponse
BaseWicketTester should not hardcode UTF-8 in isComponentOnAjaxResponse
---
Key: WICKET-2197
URL: https://issues.apache.org/jira/browse/WICKET-2197
Project: Wicket
Issue Type: Bug
Affects Versions: 1.3.4
Reporter: Vincent MATHON
UTF-8 encoding should not be hard coded in
BaseWicketTester.isComponentOnAjaxResponse:
boolean isAjaxResponse = ajaxResponse.startsWith("");
Moreover, it is very hard to work around this limitation due to a poor design
of BaseWicketTester, Result and so on.
regards
Vincent
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1630) memory leak with IE 6
[ https://issues.apache.org/jira/browse/WICKET-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent MATHON updated WICKET-1630: --- Attachment: AmdmDatePicker.java AmdmDatePicker is a behavior providing similar features compared to DatePicker. It is a melting pot of DatePicker and AbtractCalendar that I provide "as is". This implementation does not use yuiloader in order to correct the IE 6 memory leak. With this implementation: - All css, gif and js files must be in the AmdmDatePicker directory. - I have withdrawn joda-time reference in getDatePattern since I do not need it in my project. - appendNavigationConfiguration method should be enhanced to support full localization. of the calendar navigation. I hope this helps Vincent MATHON > memory leak with IE 6 > - > > Key: WICKET-1630 > URL: https://issues.apache.org/jira/browse/WICKET-1630 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.3.3 > Environment: IE 6.0-2800-1106 >Reporter: Vincent MATHON > Attachments: AmdmDatePicker.java > > > I used Drip (http://www.outofhanwell.com/ieleak/index.php?title=Main_Page) to > test the latest wicket date example (I suppose it is the 1.3.3 version) and > I found several memory leaks with with IE 6. I reproduce the same behaviour > with my own project using wicket-date-time 1.3.1. > sincerly, > Vincent MATHON -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1630) memory leak with IE 6
[ https://issues.apache.org/jira/browse/WICKET-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597190#action_12597190 ] Vincent MATHON commented on WICKET-1630: I am trying to "merge" AbstractCalendar and DatePicker in order to have the most from each other. I still have bugs with this new DatePicker that does not use yuiloader, however, I have no more memory leak with IE 6. So, the leak is due to yuiloader. Sincerly Vincent MATHON > memory leak with IE 6 > - > > Key: WICKET-1630 > URL: https://issues.apache.org/jira/browse/WICKET-1630 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.3.3 > Environment: IE 6.0-2800-1106 >Reporter: Vincent MATHON > > I used Drip (http://www.outofhanwell.com/ieleak/index.php?title=Main_Page) to > test the latest wicket date example (I suppose it is the 1.3.3 version) and > I found several memory leaks with with IE 6. I reproduce the same behaviour > with my own project using wicket-date-time 1.3.1. > sincerly, > Vincent MATHON -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1630) memory leak with IE 6
[ https://issues.apache.org/jira/browse/WICKET-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597093#action_12597093 ] Vincent MATHON commented on WICKET-1630: I mean they still appear in the IE DOM tree after garbage collection (at least according to Drip documentation). I can reach them on page unload but setting there reference to null has no effects. I note that ids like yui__dyn* are loaded dynamically with yuiloader. Is it possible to avoid this ? AbstractCalendar does not use yuiloader, have you an example showing how to use it to create a pop up? Where is the class CalendarPopup referenced in AbstractCalendar javadoc? CalendarPopup seems to do the job according to its name isn't it ?. Sincerly Vincent MATHON > memory leak with IE 6 > - > > Key: WICKET-1630 > URL: https://issues.apache.org/jira/browse/WICKET-1630 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.3.3 > Environment: IE 6.0-2800-1106 >Reporter: Vincent MATHON > > I used Drip (http://www.outofhanwell.com/ieleak/index.php?title=Main_Page) to > test the latest wicket date example (I suppose it is the 1.3.3 version) and > I found several memory leaks with with IE 6. I reproduce the same behaviour > with my own project using wicket-date-time 1.3.1. > sincerly, > Vincent MATHON -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1630) memory leak with IE 6
[ https://issues.apache.org/jira/browse/WICKET-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597072#action_12597072 ] Vincent MATHON commented on WICKET-1630: Not sure. This only means that these resources are not released. One can imagine to release them manually on unload, that could be done in wicket code. > memory leak with IE 6 > - > > Key: WICKET-1630 > URL: https://issues.apache.org/jira/browse/WICKET-1630 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.3.3 > Environment: IE 6.0-2800-1106 >Reporter: Vincent MATHON > > I used Drip (http://www.outofhanwell.com/ieleak/index.php?title=Main_Page) to > test the latest wicket date example (I suppose it is the 1.3.3 version) and > I found several memory leaks with with IE 6. I reproduce the same behaviour > with my own project using wicket-date-time 1.3.1. > sincerly, > Vincent MATHON -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1630) memory leak with IE 6
[ https://issues.apache.org/jira/browse/WICKET-1630?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12597050#action_12597050 ] Vincent MATHON commented on WICKET-1630: Here are the relevant DOM nodes that are not released. As it is mostly heavy resources (js files, css files) the leak cannot be neglected. You can observe this leak easily by reloading the wicket Date example (http://www.wicketstuff.org/wicket13/dates/) and looking at IE memory increase. It is about 2 MO each time. I observe the leak only with IE 6, not with IE 7 or Firefox 2.x. I didn't find a workaround yet. Sincerly Vincent MATHON > memory leak with IE 6 > - > > Key: WICKET-1630 > URL: https://issues.apache.org/jira/browse/WICKET-1630 > Project: Wicket > Issue Type: Bug > Components: wicket-datetime >Affects Versions: 1.3.3 > Environment: IE 6.0-2800-1106 >Reporter: Vincent MATHON > > I used Drip (http://www.outofhanwell.com/ieleak/index.php?title=Main_Page) to > test the latest wicket date example (I suppose it is the 1.3.3 version) and > I found several memory leaks with with IE 6. I reproduce the same behaviour > with my own project using wicket-date-time 1.3.1. > sincerly, > Vincent MATHON -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1630) memory leak with IE 6
memory leak with IE 6 - Key: WICKET-1630 URL: https://issues.apache.org/jira/browse/WICKET-1630 Project: Wicket Issue Type: Bug Components: wicket-datetime Affects Versions: 1.3.3 Environment: IE 6.0-2800-1106 Reporter: Vincent MATHON I used Drip (http://www.outofhanwell.com/ieleak/index.php?title=Main_Page) to test the latest wicket date example (I suppose it is the 1.3.3 version) and I found several memory leaks with with IE 6. I reproduce the same behaviour with my own project using wicket-date-time 1.3.1. sincerly, Vincent MATHON -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1013) spring component injection leads to deserialization error (or page expiration)
[ https://issues.apache.org/jira/browse/WICKET-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532586 ] Vincent MATHON commented on WICKET-1013: I agree, although I still not understand why the Wicket Serialization scheme does not need special JBoss configuration to work (at least for pages that do not contain proxy as class field). regards Vincent > spring component injection leads to deserialization error (or page > expiration) > --- > > Key: WICKET-1013 > URL: https://issues.apache.org/jira/browse/WICKET-1013 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.0-beta2 > Environment: windows 2000/ Linux Jboss 4.05 EJB3 or POJO >Reporter: Vincent MATHON >Assignee: Igor Vaynberg > Fix For: 1.3.0-beta4 > > Attachments: TestBackButton-light.zip > > > I made several tests on spring component injection and obtained the following > results. > The test is simply a main page accessing a target page through a link. > 1/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is itself a Spring proxy (a POJO proxy > or an EJB3 proxy). > a) The link is a PageLink ==> This configuration leads to a > deserialization error or a page expiration error whatever Serialization > scheme I use (wicket new one or Java serialization). > b) The link is a BookMarkablePageLink ==> it works. > 2/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is a concrete POJO. > a) The link is a PageLink ==> This configuration leads to a page > expiration error if I use the Java Serialization scheme or alternatively a > page expiration error or a serialization error with the wicket serialization > scheme. > b) The link is a BookMarkablePageLink ==> it works. > 3/ A spring component is accessed through a service locator when needed (so > it's not a class field) > It works for both PageLink and BookMarkablePageLink > Thus, the spring injection can only be used in pages accessed through a > BookMarkablePageLink , for other kind of links one must use a service > locator to avoid proxy serialization. > I suspect that this is not the expected behaviour. > Vincent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1013) spring component injection leads to deserialization error (or page expiration)
[ https://issues.apache.org/jira/browse/WICKET-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12532411 ] Vincent MATHON commented on WICKET-1013: I have found another workaround that works only with Java Serialization. If you change to true true in the jboss-service.xml file of the jbossweb-tomcat55.sar it works fine il all cases. That means that you must use JBoss unified class loader in place of an isolated class loader for web applications when using skinny WAR packaging. Thus, all classes are loaded by the JBoss unified class loader which seems indeed more coherent. Finally, I don't know if it's a Wicket bug nor if it's possible to programmatically deal with such problem in Wicket code... regards Vincent > spring component injection leads to deserialization error (or page > expiration) > --- > > Key: WICKET-1013 > URL: https://issues.apache.org/jira/browse/WICKET-1013 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.0-beta2 > Environment: windows 2000/ Linux Jboss 4.05 EJB3 or POJO >Reporter: Vincent MATHON > Attachments: TestBackButton-light.zip > > > I made several tests on spring component injection and obtained the following > results. > The test is simply a main page accessing a target page through a link. > 1/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is itself a Spring proxy (a POJO proxy > or an EJB3 proxy). > a) The link is a PageLink ==> This configuration leads to a > deserialization error or a page expiration error whatever Serialization > scheme I use (wicket new one or Java serialization). > b) The link is a BookMarkablePageLink ==> it works. > 2/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is a concrete POJO. > a) The link is a PageLink ==> This configuration leads to a page > expiration error if I use the Java Serialization scheme or alternatively a > page expiration error or a serialization error with the wicket serialization > scheme. > b) The link is a BookMarkablePageLink ==> it works. > 3/ A spring component is accessed through a service locator when needed (so > it's not a class field) > It works for both PageLink and BookMarkablePageLink > Thus, the spring injection can only be used in pages accessed through a > BookMarkablePageLink , for other kind of links one must use a service > locator to avoid proxy serialization. > I suspect that this is not the expected behaviour. > Vincent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1013) spring component injection leads to deserialization error (or page expiration)
[ https://issues.apache.org/jira/browse/WICKET-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531430 ] Vincent MATHON commented on WICKET-1013: A/ Wicket Serialization: 2007-10-01 09:41:24,604 ERROR [org.apache.wicket.RequestCycle] java.lang.reflect.InvocationTargetException java.lang.RuntimeException: java.lang.reflect.InvocationTargetException at org.apache.wicket.util.io.ClassStreamHandler.invokeReadMethod(ClassStreamHandler.java:504) at org.apache.wicket.util.io.WicketObjectInputStream.readObjectOverride(WicketObjectInputStream.java:96) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:342) at org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java:396) at org.apache.wicket.protocol.http.FilePageStore.readPage(FilePageStore.java:541) at org.apache.wicket.protocol.http.FilePageStore.getPage(FilePageStore.java:455) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore$SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:192) at org.apache.wicket.Session.getPage(Session.java:725) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:427) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1090) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1176) at org.apache.wicket.RequestCycle.request(RequestCycle.java:499) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:257) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:127) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178) at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175) at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105) at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527) at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112) at java.lang.Thread.run(Thread.java:595) Caused by: java.lang.reflect.InvocationTargetException 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 org.apache.wicket.util.io.ClassStreamHandler.invokeReadMethod(ClassStreamHandler.java:492) ... 33 more Caused by: org.apache.wicket.util.io.WicketSerializeableException: Error reading field: outsideWARServiceEJB3 for object class: class com.amdm.testbackbutton.application.presentation.OutsideWARServiceEJB3Page NOTE: if you feel Wicket is at fault with this exception, please report to the mailing list. You can switch to JDK based serialization by calling: org.apache.wicket.util.lang.Objects.setObjectStreamFactory(new IObjectStreamFactory.DefaultObjectStreamFactory()) e.g. in the init method of your application at org.apache.wicket.util.io.ClassStreamHandler.readFields(ClassStreamHandler.java:427) at org.apache.wicket.util.io.WicketObjectInputStream.defaultReadObject(WicketObjectInputStream.java:164) at org.apache.wicket.protocol.http.FilePageStore$PageSerializer.deserializePage(FilePageStore.jav
[jira] Commented: (WICKET-1013) spring component injection leads to deserialization error (or page expiration)
[ https://issues.apache.org/jira/browse/WICKET-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531220 ] Vincent MATHON commented on WICKET-1013: I don't know why but it does. Pages serialize correctly (at least silently). One must wait page deserialization from Wicket second level cache to see a problem. Concerning the serialization Scheme, it appears that Wicket mechanism using Java Serialization becomes unable to deserialize even the simplest dummy page when skinny war packaging is used. However, Wicket serialization scheme is able to deserialize pages that do not have proxy field. I read a post where you have written that Wicket serialization scheme does not handle all cases like proxy. Thus I suspect that something in this code solve the skinny WAR problem but one still observe the proxy serialization limitations. Vincent > spring component injection leads to deserialization error (or page > expiration) > --- > > Key: WICKET-1013 > URL: https://issues.apache.org/jira/browse/WICKET-1013 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.0-beta2 > Environment: windows 2000/ Linux Jboss 4.05 EJB3 or POJO >Reporter: Vincent MATHON > Attachments: TestBackButton-light.zip > > > I made several tests on spring component injection and obtained the following > results. > The test is simply a main page accessing a target page through a link. > 1/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is itself a Spring proxy (a POJO proxy > or an EJB3 proxy). > a) The link is a PageLink ==> This configuration leads to a > deserialization error or a page expiration error whatever Serialization > scheme I use (wicket new one or Java serialization). > b) The link is a BookMarkablePageLink ==> it works. > 2/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is a concrete POJO. > a) The link is a PageLink ==> This configuration leads to a page > expiration error if I use the Java Serialization scheme or alternatively a > page expiration error or a serialization error with the wicket serialization > scheme. > b) The link is a BookMarkablePageLink ==> it works. > 3/ A spring component is accessed through a service locator when needed (so > it's not a class field) > It works for both PageLink and BookMarkablePageLink > Thus, the spring injection can only be used in pages accessed through a > BookMarkablePageLink , for other kind of links one must use a service > locator to avoid proxy serialization. > I suspect that this is not the expected behaviour. > Vincent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1013) spring component injection leads to deserialization error (or page expiration)
[ https://issues.apache.org/jira/browse/WICKET-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531049 ] Vincent MATHON commented on WICKET-1013: I found an interesting behaviour. Configuration: A/ - default Java Serialization Scheme. - Skinny war The 7 tests I made lead to alternatively PageExpiration or Serialization problem when I play with back and forward button of the Navigator (Important, I use IE6, with Firefox 2.0.0.7 I have no problem because meta tags in HTML seem to have no effect on its cache when no POST is send to the server, thus, wicket never deserializes pages in such case, so no bug...). B/ - Wicket Serialization Scheme - Skinny war The DummyPage and the ServiceLocatorPage work fine, the 5 others (with services injected as page field) I still have problems. Thus the servicelocator is another workaround. I hope this helps Vincent > spring component injection leads to deserialization error (or page > expiration) > --- > > Key: WICKET-1013 > URL: https://issues.apache.org/jira/browse/WICKET-1013 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.0-beta2 > Environment: windows 2000/ Linux Jboss 4.05 EJB3 or POJO >Reporter: Vincent MATHON > Attachments: TestBackButton-light.zip > > > I made several tests on spring component injection and obtained the following > results. > The test is simply a main page accessing a target page through a link. > 1/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is itself a Spring proxy (a POJO proxy > or an EJB3 proxy). > a) The link is a PageLink ==> This configuration leads to a > deserialization error or a page expiration error whatever Serialization > scheme I use (wicket new one or Java serialization). > b) The link is a BookMarkablePageLink ==> it works. > 2/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is a concrete POJO. > a) The link is a PageLink ==> This configuration leads to a page > expiration error if I use the Java Serialization scheme or alternatively a > page expiration error or a serialization error with the wicket serialization > scheme. > b) The link is a BookMarkablePageLink ==> it works. > 3/ A spring component is accessed through a service locator when needed (so > it's not a class field) > It works for both PageLink and BookMarkablePageLink > Thus, the spring injection can only be used in pages accessed through a > BookMarkablePageLink , for other kind of links one must use a service > locator to avoid proxy serialization. > I suspect that this is not the expected behaviour. > Vincent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1013) spring component injection leads to deserialization error (or page expiration)
[ https://issues.apache.org/jira/browse/WICKET-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12531007 ] Vincent MATHON commented on WICKET-1013: Just to provide further details. We use - JBoss 4.05 default configuration with EJB3 support (via jems deployer) (for instance Isolated = false callByValue = false in the ear-deployer configuration file) - JDK 1.5.0_11 - Tests have been done on a Windows 2000 computer. - Workarounds at that time: 1/ Packaging using fat WAR scheme: works for simple prototypes, becomes tricky with real world application. 2/ Deploying the war and EJB on different servers. Both workarounds lead to a more complexe release process. Help would be appreciated to find another solution. Thanks a lot, Vincent > spring component injection leads to deserialization error (or page > expiration) > --- > > Key: WICKET-1013 > URL: https://issues.apache.org/jira/browse/WICKET-1013 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.0-beta2 > Environment: windows 2000/ Linux Jboss 4.05 EJB3 or POJO >Reporter: Vincent MATHON > Attachments: TestBackButton-light.zip > > > I made several tests on spring component injection and obtained the following > results. > The test is simply a main page accessing a target page through a link. > 1/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is itself a Spring proxy (a POJO proxy > or an EJB3 proxy). > a) The link is a PageLink ==> This configuration leads to a > deserialization error or a page expiration error whatever Serialization > scheme I use (wicket new one or Java serialization). > b) The link is a BookMarkablePageLink ==> it works. > 2/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is a concrete POJO. > a) The link is a PageLink ==> This configuration leads to a page > expiration error if I use the Java Serialization scheme or alternatively a > page expiration error or a serialization error with the wicket serialization > scheme. > b) The link is a BookMarkablePageLink ==> it works. > 3/ A spring component is accessed through a service locator when needed (so > it's not a class field) > It works for both PageLink and BookMarkablePageLink > Thus, the spring injection can only be used in pages accessed through a > BookMarkablePageLink , for other kind of links one must use a service > locator to avoid proxy serialization. > I suspect that this is not the expected behaviour. > Vincent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-1013) spring component injection leads to deserialization error (or page expiration)
[ https://issues.apache.org/jira/browse/WICKET-1013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent MATHON updated WICKET-1013: --- Attachment: TestBackButton-light.zip I send a zip file of tests I realize. Unzip the file (it is an eclipse project). This project can be built with maven2. Note: I identify the bug. This is due to the packaging of the ear that follow the Skinny WAR scheme (see http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html). That means that the WAR contains no dependencies, but these dependencies are referenced through its manifest file. All the cases I have tested in this prototype leads to serialization problems with skinny war packaging . When I package it using fat war default scheme all is right. For us, revert to fat war build is very problematic in term of organization (skinny war deployment allow to specify all commons dependencies of all our projects in a single parent pom file). > spring component injection leads to deserialization error (or page > expiration) > --- > > Key: WICKET-1013 > URL: https://issues.apache.org/jira/browse/WICKET-1013 > Project: Wicket > Issue Type: Bug >Affects Versions: 1.3.0-beta2 > Environment: windows 2000/ Linux Jboss 4.05 EJB3 or POJO >Reporter: Vincent MATHON > Attachments: TestBackButton-light.zip > > > I made several tests on spring component injection and obtained the following > results. > The test is simply a main page accessing a target page through a link. > 1/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is itself a Spring proxy (a POJO proxy > or an EJB3 proxy). > a) The link is a PageLink ==> This configuration leads to a > deserialization error or a page expiration error whatever Serialization > scheme I use (wicket new one or Java serialization). > b) The link is a BookMarkablePageLink ==> it works. > 2/ A spring component is injected in the target page as a class field using > jdk 1.5 annotation and this component is a concrete POJO. > a) The link is a PageLink ==> This configuration leads to a page > expiration error if I use the Java Serialization scheme or alternatively a > page expiration error or a serialization error with the wicket serialization > scheme. > b) The link is a BookMarkablePageLink ==> it works. > 3/ A spring component is accessed through a service locator when needed (so > it's not a class field) > It works for both PageLink and BookMarkablePageLink > Thus, the spring injection can only be used in pages accessed through a > BookMarkablePageLink , for other kind of links one must use a service > locator to avoid proxy serialization. > I suspect that this is not the expected behaviour. > Vincent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-1013) spring component injection leads to deserialization error (or page expiration)
spring component injection leads to deserialization error (or page expiration) --- Key: WICKET-1013 URL: https://issues.apache.org/jira/browse/WICKET-1013 Project: Wicket Issue Type: Bug Affects Versions: 1.3.0-beta2 Environment: windows 2000/ Linux Jboss 4.05 EJB3 or POJO Reporter: Vincent MATHON I made several tests on spring component injection and obtained the following results. The test is simply a main page accessing a target page through a link. 1/ A spring component is injected in the target page as a class field using jdk 1.5 annotation and this component is itself a Spring proxy (a POJO proxy or an EJB3 proxy). a) The link is a PageLink ==> This configuration leads to a deserialization error or a page expiration error whatever Serialization scheme I use (wicket new one or Java serialization). b) The link is a BookMarkablePageLink ==> it works. 2/ A spring component is injected in the target page as a class field using jdk 1.5 annotation and this component is a concrete POJO. a) The link is a PageLink ==> This configuration leads to a page expiration error if I use the Java Serialization scheme or alternatively a page expiration error or a serialization error with the wicket serialization scheme. b) The link is a BookMarkablePageLink ==> it works. 3/ A spring component is accessed through a service locator when needed (so it's not a class field) It works for both PageLink and BookMarkablePageLink Thus, the spring injection can only be used in pages accessed through a BookMarkablePageLink , for other kind of links one must use a service locator to avoid proxy serialization. I suspect that this is not the expected behaviour. Vincent -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
