[
https://issues.apache.org/jira/browse/TUSCANY-3162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Scott Kurz updated TUSCANY-3162:
--------------------------------
Description:
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
was:
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, Item>> getAll();
}
Now, this is a mix of bottom-up and top-down, (probably not best practice), so
this interface 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
> 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
> 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.
