[jira] [Created] (WICKET-5261) After deserialize of a page CDI injection should take place
Daniel Zwicker created WICKET-5261: -- Summary: After deserialize of a page CDI injection should take place Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- 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-5262) Lifecycle of CDI object bound to wicket Page
Daniel Zwicker created WICKET-5262: -- Summary: Lifecycle of CDI object bound to wicket Page Key: WICKET-5262 URL: https://issues.apache.org/jira/browse/WICKET-5262 Project: Wicket Issue Type: Bug Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker The wicket-cdi module injects object only on IBehaviorInstantiationListener.onInstantiation and IComponentInstantiationListener.onInstantiation. After this injection pass wicket-cdi does not manage the injected objects anymore. It relies on the normal wicket state management. So the lifecycle of any injected object is bound to the page (even if this page is serialized and the stored instance is no longer a cdi object). I think only the cdi implementation should manage these object. As a consequence wicket-cdi should inject object before every request is processed. -- 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-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697766#comment-13697766 ] Daniel Zwicker commented on WICKET-5261: CDI permit transient fields or have i missed something. But these must be injected after restoring the object. After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- 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] [Comment Edited] (WICKET-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697766#comment-13697766 ] Daniel Zwicker edited comment on WICKET-5261 at 7/2/13 1:21 PM: CDI permit transient fields as defined in 3.8. of the JSR-299. But these must be injected after restoring the object. was (Author: shadowdz): CDI permit transient fields or have i missed something. But these must be injected after restoring the object. After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- 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-5262) Lifecycle of CDI object bound to wicket Page
[ https://issues.apache.org/jira/browse/WICKET-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697790#comment-13697790 ] Daniel Zwicker commented on WICKET-5262: Ok, i have read the JSR-299 which designate to inject client proxies to handle the state of the objects transparently. In the debugger in can see that the injection points are just the plain objects. No proxies. But i use the @Dependant scope. So i think this issue can be closed and the real problem is https://issues.apache.org/jira/browse/WICKET-5261. Lifecycle of CDI object bound to wicket Page Key: WICKET-5262 URL: https://issues.apache.org/jira/browse/WICKET-5262 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg The wicket-cdi module injects object only on IBehaviorInstantiationListener.onInstantiation and IComponentInstantiationListener.onInstantiation. After this injection pass wicket-cdi does not manage the injected objects anymore. It relies on the normal wicket state management. So the lifecycle of any injected object is bound to the page (even if this page is serialized and the stored instance is no longer a cdi object). I think only the cdi implementation should manage these object. As a consequence wicket-cdi should inject object before every request is processed. -- 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-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697793#comment-13697793 ] Daniel Zwicker commented on WICKET-5261: Ok. The problem is indeed with transient injection points and @Dependand scoped beans which are not proxies and must not be Serializable. So these injection points are null after deserialization. After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- 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] [Comment Edited] (WICKET-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697793#comment-13697793 ] Daniel Zwicker edited comment on WICKET-5261 at 7/2/13 1:55 PM: Ok. The problem is indeed with transient injection points and @Dependent scoped beans which are not proxies and must not be Serializable. So these injection points are null after deserialization. was (Author: shadowdz): Ok. The problem is indeed with transient injection points and @Dependand scoped beans which are not proxies and must not be Serializable. So these injection points are null after deserialization. After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- 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] [Comment Edited] (WICKET-5262) Lifecycle of CDI object bound to wicket Page
[ https://issues.apache.org/jira/browse/WICKET-5262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697790#comment-13697790 ] Daniel Zwicker edited comment on WICKET-5262 at 7/2/13 1:56 PM: Ok, i have read the JSR-299 which designate to inject client proxies to handle the state of the objects transparently. In the debugger in can see that the injection points are just the plain objects. No proxies. But i use the @Dependent scope. So i think this issue can be closed and the real problem is https://issues.apache.org/jira/browse/WICKET-5261 as we are using transinet @Dependent scoped beans. was (Author: shadowdz): Ok, i have read the JSR-299 which designate to inject client proxies to handle the state of the objects transparently. In the debugger in can see that the injection points are just the plain objects. No proxies. But i use the @Dependant scope. So i think this issue can be closed and the real problem is https://issues.apache.org/jira/browse/WICKET-5261. Lifecycle of CDI object bound to wicket Page Key: WICKET-5262 URL: https://issues.apache.org/jira/browse/WICKET-5262 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg The wicket-cdi module injects object only on IBehaviorInstantiationListener.onInstantiation and IComponentInstantiationListener.onInstantiation. After this injection pass wicket-cdi does not manage the injected objects anymore. It relies on the normal wicket state management. So the lifecycle of any injected object is bound to the page (even if this page is serialized and the stored instance is no longer a cdi object). I think only the cdi implementation should manage these object. As a consequence wicket-cdi should inject object before every request is processed. -- 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-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697880#comment-13697880 ] Daniel Zwicker commented on WICKET-5261: i have just implement a workaround replacing the Serializer used by wicket with one delegating to the original one and call CdiContainer.getNonContextualManager().inject(); for all children of the page and Behavior recursively. Works. I'm just asking my self about the implications for replication and performance. Are Pages replicated across the cluster? After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- 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-5261) After deserialize of a page CDI injection should take place
[ https://issues.apache.org/jira/browse/WICKET-5261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13697882#comment-13697882 ] Daniel Zwicker commented on WICKET-5261: Why have you marked this one as resolved? A workaround is not resolved and transient CDI-Beans are permitted. Any CDI container handle these passivations. So wicket-cdi should handle this too. If there are transient fields in a passivated bean they will be injected again after restoring. After deserialize of a page CDI injection should take place --- Key: WICKET-5261 URL: https://issues.apache.org/jira/browse/WICKET-5261 Project: Wicket Issue Type: Bug Components: wicket-cdi Affects Versions: 6.8.0, 6.9.0 Reporter: Daniel Zwicker Assignee: Igor Vaynberg If a page or behavior or what ever has some fields which are injected by cdi and these object are not Serializable so they are market as transient they will be null after deserialization. This is ok. But now the CDI injection should be kicked in an inject new object. BTW the injection should take place every time a new request is processed. If the injection occurs e.g before every rendering this bug should be obsolete. I will fill a bug for this 'request handled injection' too. -- 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-5254) Create a possibility to disable increasing of getter/setter, field visibility in PropertyResolver
[ https://issues.apache.org/jira/browse/WICKET-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13696305#comment-13696305 ] Daniel Zwicker commented on WICKET-5254: @Martin Grigorov: To your 2. point. Yes, somebody will recognize that the app is broken (or perhaps even not). But the question is when will somebody find this misbehavior? And the misbehavior will happen not near by the usage of the PropertyModel. And than somebody has to track this bug bag to the place PropertyModel is used. And than he MUST know that the PropertyModel or even worse a CompoundPropertyModel some Panels and a Page Object away will break the immutable object. Even if it is documented. I don't want to insult somebody. But in my opinion wicket is just wrong here and make some assumption that every object should be writable. As i have mentioned in the original ticket https://issues.apache.org/jira/browse/WICKET-5252. This ticket is just a workaround for me. The cause is to increase the visibility at all. Wicket doesn't know the contract of the object! But you are right. The dev should know. So he should have the responsibility to change the object to have some public steer or fields. Or to change the used bean or model at all. But this decision should not be done by a framework. Create a possibility to disable increasing of getter/setter, field visibility in PropertyResolver -- Key: WICKET-5254 URL: https://issues.apache.org/jira/browse/WICKET-5254 Project: Wicket Issue Type: New Feature Reporter: Daniel Zwicker Priority: Minor PropertyResolver make it possible to access private fields and setter. This can break the contract of the beans . I know this is documented. But especially in larger teams not every body knows why a bean is immutable or don't think about it even if they know. It would be nice if there is a possibility to enable some kind of exception if the visibility of a property was increased. Additional i think a good idea would be to log some warnings in debug mode in these situations. -- 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-5254) Create a possibility to disable increasing of getter/setter, field visibility in PropertyResolver
[ https://issues.apache.org/jira/browse/WICKET-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13696314#comment-13696314 ] Daniel Zwicker commented on WICKET-5254: BTW: This comment is nice // We do not look for a public FIELD because // that is not good programming with beans patterns when lookup the getter in line 500 of PropertyResolver. But when there is no setter using the field is ok? Create a possibility to disable increasing of getter/setter, field visibility in PropertyResolver -- Key: WICKET-5254 URL: https://issues.apache.org/jira/browse/WICKET-5254 Project: Wicket Issue Type: New Feature Reporter: Daniel Zwicker Priority: Minor PropertyResolver make it possible to access private fields and setter. This can break the contract of the beans . I know this is documented. But especially in larger teams not every body knows why a bean is immutable or don't think about it even if they know. It would be nice if there is a possibility to enable some kind of exception if the visibility of a property was increased. Additional i think a good idea would be to log some warnings in debug mode in these situations. -- 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-5254) Create a possibility to disable increasing of getter/setter, filed visibility in PropertyResolver
Daniel Zwicker created WICKET-5254: -- Summary: Create a possibility to disable increasing of getter/setter, filed visibility in PropertyResolver Key: WICKET-5254 URL: https://issues.apache.org/jira/browse/WICKET-5254 Project: Wicket Issue Type: New Feature Reporter: Daniel Zwicker Priority: Minor PropertyResolver make it possible to access private fields and setter. This can break the contract of the beans . I know this is documented. But especially in larger teams not every body knows why a bean is immutable or don't think about it even if they know. It would be nice if there is a possibility to enable some kind of exception if the visibility of a property was increased. Additional i think a good idea would be to log some warnings in debug mode in these situations. -- 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] [Updated] (WICKET-5254) Create a possibility to disable increasing of getter/setter, field visibility in PropertyResolver
[ https://issues.apache.org/jira/browse/WICKET-5254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Zwicker updated WICKET-5254: --- Summary: Create a possibility to disable increasing of getter/setter, field visibility in PropertyResolver (was: Create a possibility to disable increasing of getter/setter, filed visibility in PropertyResolver ) Create a possibility to disable increasing of getter/setter, field visibility in PropertyResolver -- Key: WICKET-5254 URL: https://issues.apache.org/jira/browse/WICKET-5254 Project: Wicket Issue Type: New Feature Reporter: Daniel Zwicker Priority: Minor PropertyResolver make it possible to access private fields and setter. This can break the contract of the beans . I know this is documented. But especially in larger teams not every body knows why a bean is immutable or don't think about it even if they know. It would be nice if there is a possibility to enable some kind of exception if the visibility of a property was increased. Additional i think a good idea would be to log some warnings in debug mode in these situations. -- 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-5252) PropertyResolver breaks immutable objects by calling setAccessible
Daniel Zwicker created WICKET-5252: -- Summary: PropertyResolver breaks immutable objects by calling setAccessible Key: WICKET-5252 URL: https://issues.apache.org/jira/browse/WICKET-5252 Project: Wicket Issue Type: Bug Affects Versions: 6.8.0 Reporter: Daniel Zwicker If a Bean only have private fields and no setter this object is immutable. The decision to implement such an object has a bunch of implications. e.g. it is thread safe, you can take snapshots of these object to store a version history and so on. Now your use of reflection breaks this isolation silently. I believe if somebody want set the values of the object he should implement a setter or provide a public field. -- 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-5252) PropertyResolver breaks immutable objects by calling setAccessible
[ https://issues.apache.org/jira/browse/WICKET-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693816#comment-13693816 ] Daniel Zwicker commented on WICKET-5252: I know that wicket doesn't know how to use my object. But i would expect an exception in the case that wicket want to set a property and this property is not accessible. So i get aware of this situation and can think about the solution. But just accessing this private field should not be the decision of wicket. As -you are right- can't know how to use my objects. PropertyResolver breaks immutable objects by calling setAccessible -- Key: WICKET-5252 URL: https://issues.apache.org/jira/browse/WICKET-5252 Project: Wicket Issue Type: Bug Affects Versions: 6.8.0 Reporter: Daniel Zwicker If a Bean only have private fields and no setter this object is immutable. The decision to implement such an object has a bunch of implications. e.g. it is thread safe, you can take snapshots of these object to store a version history and so on. Now your use of reflection breaks this isolation silently. I believe if somebody want set the values of the object he should implement a setter or provide a public field. -- 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-5252) PropertyResolver breaks immutable objects by calling setAccessible
[ https://issues.apache.org/jira/browse/WICKET-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13693829#comment-13693829 ] Daniel Zwicker commented on WICKET-5252: Hm. Ok. I will tell my team to refactor all places the PropertyModel is used. But i believe this i a huge problem. Every tutorial for wicket told you to use this PropertyModel! And there is no remark about this behavior! Perhaps you understand the problem with this more when i told you what happen in our project. We have these immutable object. Everybody in the backend team knows these object. Now in the Frontendteam used new AjaxCheckBox(marker). So. I have told him the cause of our bug and he directly respond args immutable.. Sorry. Perhaps a solution would be a configuration switch to configure PropertyResolver to throw exceptions in these cases. So everybody can pay attention to this. PropertyResolver breaks immutable objects by calling setAccessible -- Key: WICKET-5252 URL: https://issues.apache.org/jira/browse/WICKET-5252 Project: Wicket Issue Type: Bug Affects Versions: 6.8.0 Reporter: Daniel Zwicker If a Bean only have private fields and no setter this object is immutable. The decision to implement such an object has a bunch of implications. e.g. it is thread safe, you can take snapshots of these object to store a version history and so on. Now your use of reflection breaks this isolation silently. I believe if somebody want set the values of the object he should implement a setter or provide a public field. -- 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] [Closed] (WICKET-5252) PropertyResolver breaks immutable objects by calling setAccessible
[ https://issues.apache.org/jira/browse/WICKET-5252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Zwicker closed WICKET-5252. -- PropertyResolver breaks immutable objects by calling setAccessible -- Key: WICKET-5252 URL: https://issues.apache.org/jira/browse/WICKET-5252 Project: Wicket Issue Type: Bug Affects Versions: 6.8.0 Reporter: Daniel Zwicker If a Bean only have private fields and no setter this object is immutable. The decision to implement such an object has a bunch of implications. e.g. it is thread safe, you can take snapshots of these object to store a version history and so on. Now your use of reflection breaks this isolation silently. I believe if somebody want set the values of the object he should implement a setter or provide a public field. -- 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-5100) Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks
[ https://issues.apache.org/jira/browse/WICKET-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13607398#comment-13607398 ] Daniel Zwicker commented on WICKET-5100: Yes, i know this method. But CdiConfiguration has a assertion for the BeanManager and in the CdiConfiguration.configure(Application) the BeanManager is checked again! So this method is useless. And you have to call CdiConfiguration.configure(Application) to register all the listeners for injection points. Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks Key: WICKET-5100 URL: https://issues.apache.org/jira/browse/WICKET-5100 Project: Wicket Issue Type: Wish Components: wicket-cdi Reporter: Daniel Zwicker Assignee: Igor Vaynberg We are using mockito for out unit tests. Mockito has introduced @InjectMocks for injections mocks in CDI-Beans. I have tried to setup the wicket-cdi to use the 'mockito-injection' but ended up with copy the classes to rewrite just some lines. (just replace the INonContextualManager and omit the BeanManager). Perhaps the cdi-module can be refactored to use some kind of factory to replace the INonContextualManager. -- 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-5100) Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks
[ https://issues.apache.org/jira/browse/WICKET-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13607439#comment-13607439 ] Daniel Zwicker commented on WICKET-5100: It is possible to mock the BeanManager. Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks Key: WICKET-5100 URL: https://issues.apache.org/jira/browse/WICKET-5100 Project: Wicket Issue Type: Wish Components: wicket-cdi Reporter: Daniel Zwicker Assignee: Igor Vaynberg We are using mockito for out unit tests. Mockito has introduced @InjectMocks for injections mocks in CDI-Beans. I have tried to setup the wicket-cdi to use the 'mockito-injection' but ended up with copy the classes to rewrite just some lines. (just replace the INonContextualManager and omit the BeanManager). Perhaps the cdi-module can be refactored to use some kind of factory to replace the INonContextualManager. -- 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-5100) Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks
[ https://issues.apache.org/jira/browse/WICKET-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13607454#comment-13607454 ] Daniel Zwicker commented on WICKET-5100: but there is a warning from SeamConversationContextFactory which is called inside the CdiContainer constructor even if ConversationPropagation.NONE is configured. Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks Key: WICKET-5100 URL: https://issues.apache.org/jira/browse/WICKET-5100 Project: Wicket Issue Type: Wish Components: wicket-cdi Reporter: Daniel Zwicker Assignee: Igor Vaynberg We are using mockito for out unit tests. Mockito has introduced @InjectMocks for injections mocks in CDI-Beans. I have tried to setup the wicket-cdi to use the 'mockito-injection' but ended up with copy the classes to rewrite just some lines. (just replace the INonContextualManager and omit the BeanManager). Perhaps the cdi-module can be refactored to use some kind of factory to replace the INonContextualManager. -- 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-5100) Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks
[ https://issues.apache.org/jira/browse/WICKET-5100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13607455#comment-13607455 ] Daniel Zwicker commented on WICKET-5100: it is not possible to deactivate DetachEventEmitter which will result in: java.lang.NullPointerException at org.apache.wicket.cdi.DetachEventEmitter.onDetach(DetachEventEmitter.java:73) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:105) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:101) at org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:120) at org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:144) at org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:100) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:105) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:101) at org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:120) at org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:144) at org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:100) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:105) at org.apache.wicket.request.cycle.RequestCycleListenerCollection$3.notify(RequestCycleListenerCollection.java:101) at org.apache.wicket.util.listener.ListenerCollection$1.notify(ListenerCollection.java:120) at org.apache.wicket.util.listener.ListenerCollection.reversedNotify(ListenerCollection.java:144) at org.apache.wicket.util.listener.ListenerCollection.reversedNotifyIgnoringExceptions(ListenerCollection.java:113) at org.apache.wicket.request.cycle.RequestCycleListenerCollection.onDetach(RequestCycleListenerCollection.java:100) at org.apache.wicket.request.cycle.RequestCycle.onDetach(RequestCycle.java:619) at org.apache.wicket.request.cycle.RequestCycle.detach(RequestCycle.java:568) at org.apache.wicket.request.cycle.RequestCycle.processRequestAndDetach(RequestCycle.java:286) at org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:643) at org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:572) at org.apache.wicket.util.tester.BaseWicketTester.processRequest(BaseWicketTester.java:544) at org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:1186) at org.apache.wicket.util.tester.BaseWicketTester.startPage(BaseWicketTester.java:1159) at com.in2experience.rom.webapp.customer.CustomerSelectionIntegrationTest.testBasicRender(CustomerSelectionIntegrationTest.java:57) at com.in2experience.rom.webapp.customer.CustomerSelectionIntegrationTest.testBasicRenderEN(CustomerSelectionIntegrationTest.java:53) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
[jira] [Created] (WICKET-5100) Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks
Daniel Zwicker created WICKET-5100: -- Summary: Make it possible to replace the INonContextualManager in wicket-cdi for mock frameworks Key: WICKET-5100 URL: https://issues.apache.org/jira/browse/WICKET-5100 Project: Wicket Issue Type: Wish Components: wicket-cdi Reporter: Daniel Zwicker We are using mockito for out unit tests. Mockito has introduced @InjectMocks for injections mocks in CDI-Beans. I have tried to setup the wicket-cdi to use the 'mockito-injection' but ended up with copy the classes to rewrite just some lines. (just replace the INonContextualManager and omit the BeanManager). Perhaps the cdi-module can be refactored to use some kind of factory to replace the INonContextualManager. -- 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-4594) Do not use the parsed PageParameters when re-creating an expired page
[ https://issues.apache.org/jira/browse/WICKET-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13421591#comment-13421591 ] Daniel Zwicker commented on WICKET-4594: @Martin: 1) If this is true, why I am able to overwrite Behavior.getStatelessHint(final Component component)? This shouldn't be possible. 2) Clicking a link on a expired page will create a new empty PageParameter and will not create a new page if this page requieres path parameter. This is the problem i came along after updating to beta3! Do not use the parsed PageParameters when re-creating an expired page - Key: WICKET-4594 URL: https://issues.apache.org/jira/browse/WICKET-4594 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.5.7 Reporter: Martin Grigorov Assignee: Martin Grigorov Fix For: 6.0.0-beta3, 1.5.8 Attachments: WICKET-4594.patch.diff, WICKET-4594_bug.zip, example.tar.gz WICKET-4014 and WICKET-4290 provided functionality to re-create an expired page if there is a mount path in the current request's url. There is a minor problem with that because the page parameters are passed to the freshly created page. I.e. parameters for a callback behavior are now set as page construction parameters. Since the execution of the behavior is ignored for the recreated page these parameters should be ignored too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4594) Do not use the parsed PageParameters when re-creating an expired page
[ https://issues.apache.org/jira/browse/WICKET-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13420820#comment-13420820 ] Daniel Zwicker commented on WICKET-4594: Ok, I will try the onEvent version. But I have one question about stateless AjaxEventBehaviors. I don't understand why they send a pageId? They are stateless and shouldn't send a padeId? If the pageId is null the parsed PageParameters will reach the page constructer. Do not use the parsed PageParameters when re-creating an expired page - Key: WICKET-4594 URL: https://issues.apache.org/jira/browse/WICKET-4594 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.5.7 Reporter: Martin Grigorov Assignee: Martin Grigorov Fix For: 6.0.0-beta3, 1.5.8 Attachments: WICKET-4594.patch.diff, example.tar.gz WICKET-4014 and WICKET-4290 provided functionality to re-create an expired page if there is a mount path in the current request's url. There is a minor problem with that because the page parameters are passed to the freshly created page. I.e. parameters for a callback behavior are now set as page construction parameters. Since the execution of the behavior is ignored for the recreated page these parameters should be ignored too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (WICKET-4594) Do not use the parsed PageParameters when re-creating an expired page
[ https://issues.apache.org/jira/browse/WICKET-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Zwicker updated WICKET-4594: --- Attachment: example.tar.gz Do not use the parsed PageParameters when re-creating an expired page - Key: WICKET-4594 URL: https://issues.apache.org/jira/browse/WICKET-4594 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.5.7 Reporter: Martin Grigorov Assignee: Martin Grigorov Fix For: 6.0.0-beta3, 1.5.8 Attachments: WICKET-4594.patch.diff, example.tar.gz WICKET-4014 and WICKET-4290 provided functionality to re-create an expired page if there is a mount path in the current request's url. There is a minor problem with that because the page parameters are passed to the freshly created page. I.e. parameters for a callback behavior are now set as page construction parameters. Since the execution of the behavior is ignored for the recreated page these parameters should be ignored too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4594) Do not use the parsed PageParameters when re-creating an expired page
[ https://issues.apache.org/jira/browse/WICKET-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13419959#comment-13419959 ] Daniel Zwicker commented on WICKET-4594: @Martin: I have attached a smale example Do not use the parsed PageParameters when re-creating an expired page - Key: WICKET-4594 URL: https://issues.apache.org/jira/browse/WICKET-4594 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.5.7 Reporter: Martin Grigorov Assignee: Martin Grigorov Fix For: 6.0.0-beta3, 1.5.8 Attachments: WICKET-4594.patch.diff, example.tar.gz WICKET-4014 and WICKET-4290 provided functionality to re-create an expired page if there is a mount path in the current request's url. There is a minor problem with that because the page parameters are passed to the freshly created page. I.e. parameters for a callback behavior are now set as page construction parameters. Since the execution of the behavior is ignored for the recreated page these parameters should be ignored too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (WICKET-4594) Do not use the parsed PageParameters when re-creating an expired page
[ https://issues.apache.org/jira/browse/WICKET-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13419959#comment-13419959 ] Daniel Zwicker edited comment on WICKET-4594 at 7/21/12 10:12 PM: -- @Martin: I have attached a smale example. The refresh button on second page should work and refresh just the page. But it will miss and redirect to index. was (Author: shadowdz): @Martin: I have attached a smale example Do not use the parsed PageParameters when re-creating an expired page - Key: WICKET-4594 URL: https://issues.apache.org/jira/browse/WICKET-4594 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.5.7 Reporter: Martin Grigorov Assignee: Martin Grigorov Fix For: 6.0.0-beta3, 1.5.8 Attachments: WICKET-4594.patch.diff, example.tar.gz WICKET-4014 and WICKET-4290 provided functionality to re-create an expired page if there is a mount path in the current request's url. There is a minor problem with that because the page parameters are passed to the freshly created page. I.e. parameters for a callback behavior are now set as page construction parameters. Since the execution of the behavior is ignored for the recreated page these parameters should be ignored too. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (WICKET-4594) Do not use the parsed PageParameters when re-creating an expired page
[
https://issues.apache.org/jira/browse/WICKET-4594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13416742#comment-13416742
]
Daniel Zwicker commented on WICKET-4594:
Hi,
this feature make it impossible to use AJAX calls on stateless pages if the
AJAX call uses ExtraParameters for restoring the page state.
For example:
protected void updateAjaxAttributes(final AjaxRequestAttributes
attributes) {
super.updateAjaxAttributes(attributes);
attributes.getExtraParameters().put(customerId,
customer.getId());
}
This will produce the correct PageParameters but they will be just ignored by
your fix.
Perhaps I have just missed something?
I have attached a fix which works for me.
Kindest regards,
Daniel
Do not use the parsed PageParameters when re-creating an expired page
-
Key: WICKET-4594
URL: https://issues.apache.org/jira/browse/WICKET-4594
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.5.7
Reporter: Martin Grigorov
Assignee: Martin Grigorov
Fix For: 6.0.0-beta3, 1.5.8
Attachments: WICKET-4594.patch.diff
WICKET-4014 and WICKET-4290 provided functionality to re-create an expired
page if there is a mount path in the current request's url.
There is a minor problem with that because the page parameters are passed to
the freshly created page. I.e. parameters for a callback behavior are now set
as page construction parameters.
Since the execution of the behavior is ignored for the recreated page these
parameters should be ignored too.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
