[jira] Created: (WICKET-2671) Enclosure causes Nullpointer exception
Enclosure causes Nullpointer exception
--
Key: WICKET-2671
URL: https://issues.apache.org/jira/browse/WICKET-2671
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.5
Reporter: Sven Rienstra
Priority: Critical
There is a bug in DirectChildTagIterator which causes a Nullpointer exception
with the following stack trace:
Caused by: java.lang.NullPointerException
at
org.apache.wicket.markup.html.internal.DirectChildTagIterator.findNext(DirectChildTagIterator.java:115)
at
org.apache.wicket.markup.html.internal.DirectChildTagIterator.next(DirectChildTagIterator.java:85)
at
org.apache.wicket.markup.html.internal.Enclosure.ensureAllChildrenPresent(Enclosure.java:236)
at
org.apache.wicket.markup.html.internal.Enclosure.onComponentTagBody(Enclosure.java:169)
at org.apache.wicket.Component.renderComponent(Component.java:2619)
... 106 more
The problem is in this code fragment:
while (markupStream.hasMore())
{
final MarkupElement cursor = markupStream.next();
if (cursor.closes(parent))
markupStream.hasMore() checks if the currentindex is available to retrieve,
while markupStream.next() doesn't retrieve the currentindex, but tries to
retrieve the currentindex + 1 element. The right function to get the current
element is markupStream.get().
To fix this, i should be this:
while (markupStream.hasMore())
{
final MarkupElement cursor = markupStream.get();
markupStream.next();
if (cursor.closes(parent))
The best fix is imo to make next() in MarkupStream a void method, it will
prevent this in the future.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (WICKET-2672) FormComponent doesn't properly handle array model types
FormComponent doesn't properly handle array model types --- Key: WICKET-2672 URL: https://issues.apache.org/jira/browse/WICKET-2672 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.5 Reporter: Marat Radchenko Attachments: FormComponentTest.java FormComponent doesn't properly handle array model types. Testcase attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (WICKET-2672) FormComponent doesn't properly handle array model types
[ https://issues.apache.org/jira/browse/WICKET-2672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Marat Radchenko updated WICKET-2672: Attachment: FormComponentTest.java FormComponent doesn't properly handle array model types --- Key: WICKET-2672 URL: https://issues.apache.org/jira/browse/WICKET-2672 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4.5 Reporter: Marat Radchenko Attachments: FormComponentTest.java FormComponent doesn't properly handle array model types. Testcase attached. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-2665) When adding two buttons to a form and enabling and disabling them alternatively we get the org.apache.wicket.WicketRuntimeException: Submit Button ... is not enabled
[
https://issues.apache.org/jira/browse/WICKET-2665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799393#action_12799393
]
Igor Vaynberg commented on WICKET-2665:
---
please provide a quickstart
When adding two buttons to a form and enabling and disabling them
alternatively we get the org.apache.wicket.WicketRuntimeException: Submit
Button ... is not enabled
--
Key: WICKET-2665
URL: https://issues.apache.org/jira/browse/WICKET-2665
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4.4, 1.4.5
Environment: Wicket 1.4.5 portlet
Deployed on Liferay 5.2.3 (using JBoss 4.2.3 on windows X)
Reporter: Brevard Swart
Original Estimate: 24h
Remaining Estimate: 24h
If you look at the JIRA WICKET-2570 fix it adds the following lines:
+ if
(!component.isEnabledInHierarchy())
+ {
+ throw new
WicketRuntimeException(Submit Button +
+
submittingComponent.getInputName() + (path= +
+
component.getPageRelativePath() + ) is not enabled);
+ }
This fix above breaks our code if I go back to version 1.4.3 this goes away.
If you have a scenario where you have added two ajax buttons on a form
disabling them using org.apache.wicket.Component.setEnabled, alternating and
enabling one while disabling the other. Then once you have clicked on the
button (say Button Y) a second time you get the error:
org.apache.wicket.WicketRuntimeException: Submit Button X ... is not enabled
I have a wicket form inside a wick panel that is inside another wicket panel
(if I do a complete re-render on the root panel after each click the error
will not occur). The order in which the buttons have been added to the form
determine which button onclick will fail. This failure will occur when Submit
Button Y is clicked a second time it will complain that Submit Button X is
not enabled. We have tried disabling these buttons in either the
onBeforeRender of the buttons or the form but both fail.
Current button states:
Button Y - isEnabled = true
Button Y - isEnabledInHierarchy = true
Button X - isEnabled = false
Button X - isEnabledInHierarchy = false
Submit Button Y clicked!
Current button states:
Button Y - isEnabled = false
Button Y - isEnabledInHierarchy = false
Button X - isEnabled = true
Button X- isEnabledInHierarchy = true
Submit Button X clicked:
Current button states:
Button Y - isEnabled = true
Button Y - isEnabledInHierarchy = true
Button X - isEnabled = false
Button X- isEnabledInHierarchy = false
Submit Button Y clicked!
ERROR
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1866) MarkupContainer already follows the contract of Iterable; it should implement it.
[
https://issues.apache.org/jira/browse/WICKET-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799588#action_12799588
]
David Shepherdson commented on WICKET-1866:
---
From the perspective of a caller of the API, I don't see that there would be
any problem with changing the signature of the existing iterator() method to
make it compatible with the Iterable interface; looking at the code for
MarkupContainer, it already actually returns an IteratorComponent, and if
the signature was changed to
public IteratorComponent iterator()
...then anybody's existing code that does something like
Iterator? extends Component children = container.iterator();
...would still work, because Component satisfies the ? extends Component
specifier.
Is your concern about subclasses of MarkupContainer that override iterator()
using the same signature? In other words, something like
public class MyContainer extends MarkupContainer {
@Override
public Iterator? extends Component iterator() {
return ...;
}
}
...would no longer be valid if the signature of MarkupContainer's iterator()
was changed, since ? extends Component is incompatible with Component at the
superclass level.
It would be nice to be able to use the 'modern'-style for loops with
MarkupContainers, and it's not like it would be a lot of effort to add the
'implements IterableComponent' and change the signature of iterator(), but I
can see where you're coming from if you're worried about breaking anybody's
legacy subclasses of MarkupContainer.
Is this something that might be reconsidered for the next major release (since
small API changes on major releases are not unheard of)?
MarkupContainer already follows the contract of Iterable; it should implement
it.
-
Key: WICKET-1866
URL: https://issues.apache.org/jira/browse/WICKET-1866
Project: Wicket
Issue Type: Bug
Components: wicket
Affects Versions: 1.4-M3
Reporter: Maarten Billemont
Assignee: Igor Vaynberg
To support the enhanced for syntax and several other features of the
language; MarkupContainers should implement the Iterable interface whose
contract it already follows.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WICKET-1866) MarkupContainer already follows the contract of Iterable; it should implement it.
[ https://issues.apache.org/jira/browse/WICKET-1866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12799620#action_12799620 ] Igor Vaynberg commented on WICKET-1866: --- what is the usecase for this? the preferred way to iterate components is to use the visitors, iterating children directly is a pretty rare usecase. we may consider it for 1.5, but i would like to know the usecase first... MarkupContainer already follows the contract of Iterable; it should implement it. - Key: WICKET-1866 URL: https://issues.apache.org/jira/browse/WICKET-1866 Project: Wicket Issue Type: Bug Components: wicket Affects Versions: 1.4-M3 Reporter: Maarten Billemont Assignee: Igor Vaynberg To support the enhanced for syntax and several other features of the language; MarkupContainers should implement the Iterable interface whose contract it already follows. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
