[
https://issues.apache.org/jira/browse/TUSCANY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Raymond Feng resolved TUSCANY-3162.
-----------------------------------
Resolution: Fixed
Fixed in 2.x, 1.x and 1.5.1 streams
> problem building JAXBContext when package has mixed JAXBs, non-JAXBs
> --------------------------------------------------------------------
>
> Key: TUSCANY-3162
> URL: https://issues.apache.org/jira/browse/TUSCANY-3162
> Project: Tuscany
> Issue Type: Bug
> Components: Java SCA Data Binding Runtime
> Reporter: Scott Kurz
> Assignee: Raymond Feng
> Priority: Minor
>
> I noticed a problem to a particular app now that we've made the fix to
> JAXBContextCache in TUSCANY-2640.
> Bear with me, this is a very particular circumstance which broke:
> My Java intf method is (in the wrapped style):
> package mypkg;
> @Remotable
> public interface MyIntf {
> public List<Entry<String, mypkg.Item>> getAll();
> }
> Now, this is a mix of bottom-up and top-down, (probably not best practice),
> and mypkg.Item is packaged along with other classes in package 'mypkg'
> including a set of other generated JAXBs including a mypkg.ObjectFactory.
> However, we did not start with a WSDL, and so there is no generated response
> wrapper class.
> The problem is that mypkg.Item is not getting registered in my JAXBContext,
> so let me walk through the reasons.
> First, the code in JAXBContextHelper will pick apart the parameter types in
> parameterized type arguments, and find the "nested" Item type, so it is not
> as if we don't handle generics. Though registering the mypkg.ObjectFactory
> is no help, (since ObjectFactory has no reference to Item), we do have this
> Item class in hand still as a "leftover" type to register. However, when
> we go to build the JAXBContext we basically will throw away types in the same
> package as a seen ObjectFactory; we only will register leftover types if
> they are not part of a JAXB package we've seen.
> Interestingly enough, there's a second chance this type has to get registered
> that we also miss out on. We will generate a wrapper in BaseBeanGenerator
> (in the mypkg.jaxws package in this case). Though we have enough smarts to
> generate this wrapper with a reference to "Entry" we do not generate it with
> a reference to Item (or at least not in a way that the JAXB impl algorithm
> loads Item when we pass the generated wrapper into the
> JAXBContext.newInstance).
> So, I would suggest that maybe we tweak the "first chance" here to register
> the leftover types anyway, in spite of the fact that this would be a bit less
> clean perhaps. This would be more in line with the old algorithm which I
> have a dependency on so would like to change back in this regard if possible.
> As a separate but related issue, I guess I should raise the question of
> should the BaseBeanGenerator be tweaked to gen a class with a static ref to
> Entry? As I don't have any familiarity with ASM and since the first
> suggested fix would solve my problem, I'm not trying to push the issue.
> Thanks,
> Scott
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
