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/11/06 00:03:32 UTC
[jira] Created: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
JAXBXmlProvider should tolerate user jaxb contexts
--------------------------------------------------
Key: WINK-229
URL: https://issues.apache.org/jira/browse/WINK-229
Project: Wink
Issue Type: Bug
Components: Common
Affects Versions: 1.1
Reporter: Mike Rheinheimer
Fix For: 1.1
Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
See patch, with test. It'll make sense.
Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775425#action_12775425 ]
Hudson commented on WINK-229:
-----------------------------
Integrated in Wink-Trunk-JDK1.6-itests #16 (See [http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.6-itests/16/])
: tolerate XmlRootElement in JAXB objects, but JAXBContext created with package string, causing it to use xjc-generated ObjectFactory
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch, WINK-229_2.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774601#action_12774601 ]
Hudson commented on WINK-229:
-----------------------------
Integrated in Wink-Trunk-JDK1.6-itests #13 (See [http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.6-itests/13/])
: fix incorrect namespace
: tolerate user's JAXBContext resolver
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch, WINK-229_2.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated WINK-229:
----------------------------------
Attachment: WINK-229_2.patch
WINK-229_2.patch is the fix for Jettison provider. However, I had some kind of weirdness in my build env that made it work sometimes, and not others, depending on whether eclipse was refreshed, the wink-common module was 'installed' in my repo, etc.
Can someone please pull this fix and appt in their env? I would appreciate it. I'll get to it Monday if no one's touched this by then.
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch, WINK-229_2.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774420#action_12774420 ]
Hudson commented on WINK-229:
-----------------------------
Integrated in Wink-Trunk-JDK1.5 #238 (See [http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.5/238/])
: fix incorrect namespace
: tolerate user's JAXBContext resolver
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775037#action_12775037 ]
Hudson commented on WINK-229:
-----------------------------
Integrated in Wink-Trunk-JDK1.5 #239 (See [http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.5/239/])
: tolerate XmlRootElement in JAXB objects, but JAXBContext created with package string, causing it to use xjc-generated ObjectFactory
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch, WINK-229_2.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated WINK-229:
----------------------------------
Attachment: WINK-229.patch
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Reopened: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer reopened WINK-229:
-----------------------------------
Need to also submit fix for Jettison provider. Fix and test will be very similar.
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774589#action_12774589 ]
Hudson commented on WINK-229:
-----------------------------
Integrated in Wink-Trunk-JDK1.5-itests #12 (See [http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.5-itests/12/])
: fix incorrect namespace
: tolerate user's JAXBContext resolver
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch, WINK-229_2.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer resolved WINK-229.
-----------------------------------
Resolution: Fixed
Thanks Bryant. Fixed in SVN 834150. Also updated WINK-229_2.patch file here in the jira.
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated WINK-229:
----------------------------------
Attachment: WINK-229_2.patch
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch, WINK-229_2.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer resolved WINK-229.
-----------------------------------
Resolution: Fixed
Committed to SVN 833550.
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Closed: (WINK-229) JAXBXmlProvider should tolerate user jaxb
contexts
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer closed WINK-229.
---------------------------------
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch, WINK-229_2.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Mike Rheinheimer (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Rheinheimer updated WINK-229:
----------------------------------
Attachment: (was: WINK-229_2.patch)
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Bryant Luk (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12774495#action_12774495 ]
Bryant Luk commented on WINK-229:
---------------------------------
I originally got a repeatable problem in my build environment but after adding:
{code}
@Override
public String getPropertiesFile() {
return "META-INF/wink.properties";
}
{code}
to the JettisonJAXBContextResolverTest, the test passed for me (JDK 1.6 this time). If the Jettison provider is auto-registered via wink-application, the reader is disabled. The wink.properties file disables the auto-registration allowing you to turn on the Jettison provider as a reader before registration. The reason the reader is disabled by default is because of a bug in Jettison where malformed JSON may cause infinite loops.
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch, WINK-229_2.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (WINK-229) JAXBXmlProvider should tolerate user
jaxb contexts
Posted by "Hudson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/WINK-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12775385#action_12775385 ]
Hudson commented on WINK-229:
-----------------------------
Integrated in Wink-Trunk-JDK1.5-itests #15 (See [http://hudson.zones.apache.org/hudson/job/Wink-Trunk-JDK1.5-itests/15/])
: tolerate XmlRootElement in JAXB objects, but JAXBContext created with package string, causing it to use xjc-generated ObjectFactory
> JAXBXmlProvider should tolerate user jaxb contexts
> --------------------------------------------------
>
> Key: WINK-229
> URL: https://issues.apache.org/jira/browse/WINK-229
> Project: Wink
> Issue Type: Bug
> Components: Common
> Affects Versions: 1.1
> Reporter: Mike Rheinheimer
> Fix For: 1.1
>
> Attachments: WINK-229.patch, WINK-229_2.patch
>
>
> Ran into a sample that had an extra creator method in the ObjectFactory that returned a JAXBElement. When this method exists, and the jaxbcontext is created using the String signature in a user's JAXB context resolver, the unmarshaller will call the ObjectFactory method that returns the JAXBElement, and thus the provider will return a JAXBElement, which may not be the desired object for the resource -- this would result in an IllegalArgumentException: argument type mismatch when calling the resource method.
> See patch, with test. It'll make sense.
> Also, we don't have a good set of tests for the JAXBXmlProvider. The one included here in the patch is a good one to use for additional JAXB tests.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.