You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wink.apache.org by "Mike Rheinheimer (JIRA)" <ji...@apache.org> on 2009/06/26 20:05:47 UTC
[jira] Created: (WINK-10) unnecessary constructor validation on
subresource
unnecessary constructor validation on subresource
-------------------------------------------------
Key: WINK-10
URL: https://issues.apache.org/jira/browse/WINK-10
Project: Wink
Issue Type: Bug
Reporter: Mike Rheinheimer
Attachments: patch.txt
Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724687#action_12724687 ]
Mike Rheinheimer commented on WINK-10:
--------------------------------------
Also, I'm not tied to the fix suggested by fixcandidate_01 patch. Please review and critique or change if needed -- or send comments and ideas my way.
Also, FYI, I had a two test failures and two test errors in common, but they were unrelated to this patch. The failures were due to the position of the namespace declarations in some XML being checked in an assert. I did not check on the errors, but it looked like NPEs coming from a missing application validator object?? Anyway, this fix patch didn't cause those. :)
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Reporter: Mike Rheinheimer
> Attachments: patch.txt, patch_fixcandidate_01.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Nick Gallardo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Gallardo reassigned WINK-10:
---------------------------------
Assignee: Nick Gallardo
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Reporter: Mike Rheinheimer
> Assignee: Nick Gallardo
> Attachments: patch.txt, patch_fixcandidate_01.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated WINK-10:
---------------------------------
Attachment: patch_fixcandidate_01.txt
Fix candidate patch attached. Basically, I added a method param to pass a boolean 'isSubResource' down into the AbstractMetadataCollector constructor so the AbstractMetadataCollector.parseConstructors() method is aware that it might be looking at a subresource.
see patch_fixcandidate_01.txt
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Reporter: Mike Rheinheimer
> Attachments: patch.txt, patch_fixcandidate_01.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Nadav Fischer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12731306#action_12731306 ]
Nadav Fischer commented on WINK-10:
-----------------------------------
Nick, you can resolve this issue without applying the patch because the fix for WINK-83 also fixes this issue.
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Components: Common, Server
> Reporter: Mike Rheinheimer
> Assignee: Nick Gallardo
> Attachments: patch.txt, patch_fixcandidate_01.txt, updated-patch-gallardo.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Nick Gallardo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724758#action_12724758 ]
Nick Gallardo commented on WINK-10:
-----------------------------------
Thanks for the patch Mike. I'll take a look.
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Reporter: Mike Rheinheimer
> Assignee: Nick Gallardo
> Attachments: patch.txt, patch_fixcandidate_01.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Jason Dillon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Dillon updated WINK-10:
-----------------------------
Component/s: Server
Common
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Components: Common, Server
> Reporter: Mike Rheinheimer
> Assignee: Nick Gallardo
> Attachments: patch.txt, patch_fixcandidate_01.txt, updated-patch-gallardo.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Nick Gallardo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725208#action_12725208 ]
Nick Gallardo commented on WINK-10:
-----------------------------------
Mike, do you mind if I merge this test with another test I had created for polymorphic sub-resources?
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Reporter: Mike Rheinheimer
> Assignee: Nick Gallardo
> Attachments: patch.txt, patch_fixcandidate_01.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated WINK-10:
---------------------------------
Attachment: patch.txt
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Reporter: Mike Rheinheimer
> Attachments: patch.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12725209#action_12725209 ]
Mike Rheinheimer commented on WINK-10:
--------------------------------------
That's fine. I think it would make sense to have subresource tests together.
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Reporter: Mike Rheinheimer
> Assignee: Nick Gallardo
> Attachments: patch.txt, patch_fixcandidate_01.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12729734#action_12729734 ]
Mike Rheinheimer commented on WINK-10:
--------------------------------------
Hi Nick. That looks fine to me. Will you commit it?
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Components: Common, Server
> Reporter: Mike Rheinheimer
> Assignee: Nick Gallardo
> Attachments: patch.txt, patch_fixcandidate_01.txt, updated-patch-gallardo.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer closed WINK-10.
--------------------------------
Resolution: Duplicate
Fix Version/s: 0.1
Thanks Nadav. I've verified this is resolved by WINK-83. Thanks too for adding tests!
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Components: Common, Server
> Reporter: Mike Rheinheimer
> Assignee: Nick Gallardo
> Fix For: 0.1
>
> Attachments: patch.txt, patch_fixcandidate_01.txt, updated-patch-gallardo.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-10) unnecessary constructor validation on
subresource
Posted by "Nick Gallardo (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Nick Gallardo updated WINK-10:
------------------------------
Attachment: updated-patch-gallardo.txt
Mike, here's a different solution. Less impactful in that it doesn't require every caller to acknowledge whether or not it's a sub resource.
> unnecessary constructor validation on subresource
> -------------------------------------------------
>
> Key: WINK-10
> URL: https://issues.apache.org/jira/browse/WINK-10
> Project: Wink
> Issue Type: Bug
> Reporter: Mike Rheinheimer
> Assignee: Nick Gallardo
> Attachments: patch.txt, patch_fixcandidate_01.txt, updated-patch-gallardo.txt
>
>
> Because a subresource does not have to conform to the JAX-RS rules regarding constructors, the code should not be enforcing these rules on subresources.
> Attached is a testcase to demo the problem. The hack I used to confirm that the runtime is enforcing the constructor rules on the subresource was to comment out the "continue L1;" call in AbstractMetadataCollector.parseConstructors
> The fix will be to make the AbstractMetadataCollector aware of what type of resource it is operating on; top-level resource vs. subresource.
> I'll work on this.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.