You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "Scott Kurz (JIRA)" <de...@tuscany.apache.org> on 2008/10/13 18:08:44 UTC

[jira] Created: (TUSCANY-2640) Should use package(s) when possible in creating JAXBContext, not set of Classes

Should use package(s) when possible in creating JAXBContext, not set of Classes
-------------------------------------------------------------------------------

                 Key: TUSCANY-2640
                 URL: https://issues.apache.org/jira/browse/TUSCANY-2640
             Project: Tuscany
          Issue Type: Bug
            Reporter: Scott Kurz


The JAXBContextHelper method:
   createJAXBContext(TransformationContext tContext, boolean source)
ends up calling
  JAXBContextCache.getJAXBContext(Set<Class<?>> classes)  

This latter method, though, will only use the pkg-style JAXBContext.newInstance() if there is only a single Class in the set... otherwise it will use class-style JAXBContext.newInstance().

It is only the pkg-style, however, which causes the @XmlRegistry (typically 'ObjectFactory') to be registered in the JAXBContext (since it's not like we go add the registry to the list of classes passed into newInstance()).  The end result is that the @XmlElemDecl's in the registry are not registered, and there are a list of global elems with the context doesn't know about, though it could if we changed the context creation.

My motive for caring here is in looking to support JAXB unmarshalling by global-element....  I'm not sure if I could produce an error with the current code doing unmarshalling by declaredType, so for now I'm arguing for changing this for consistency's sake.


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Assigned: (TUSCANY-2640) Should use package(s) when possible in creating JAXBContext, not set of Classes

Posted by "Raymond Feng (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raymond Feng reassigned TUSCANY-2640:
-------------------------------------

    Assignee: Raymond Feng

> Should use package(s) when possible in creating JAXBContext, not set of Classes
> -------------------------------------------------------------------------------
>
>                 Key: TUSCANY-2640
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2640
>             Project: Tuscany
>          Issue Type: Bug
>            Reporter: Scott Kurz
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-Next
>
>
> The JAXBContextHelper method:
>    createJAXBContext(TransformationContext tContext, boolean source)
> ends up calling
>   JAXBContextCache.getJAXBContext(Set<Class<?>> classes)  
> This latter method, though, will only use the pkg-style JAXBContext.newInstance() if there is only a single Class in the set... otherwise it will use class-style JAXBContext.newInstance().
> It is only the pkg-style, however, which causes the @XmlRegistry (typically 'ObjectFactory') to be registered in the JAXBContext (since it's not like we go add the registry to the list of classes passed into newInstance()).  The end result is that the @XmlElemDecl's in the registry are not registered, and there are a list of global elems with the context doesn't know about, though it could if we changed the context creation.
> My motive for caring here is in looking to support JAXB unmarshalling by global-element....  I'm not sure if I could produce an error with the current code doing unmarshalling by declaredType, so for now I'm arguing for changing this for consistency's sake.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TUSCANY-2640) Should use package(s) when possible in creating JAXBContext, not set of Classes

Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724099#action_12724099 ] 

Scott Kurz commented on TUSCANY-2640:
-------------------------------------

Thanks for implementing that idea so quickly...appreciate it.   Yes I would find it useful to have in 1.x.   

Thanks, Scott

> Should use package(s) when possible in creating JAXBContext, not set of Classes
> -------------------------------------------------------------------------------
>
>                 Key: TUSCANY-2640
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2640
>             Project: Tuscany
>          Issue Type: Bug
>            Reporter: Scott Kurz
>             Fix For: Java-SCA-Next
>
>
> The JAXBContextHelper method:
>    createJAXBContext(TransformationContext tContext, boolean source)
> ends up calling
>   JAXBContextCache.getJAXBContext(Set<Class<?>> classes)  
> This latter method, though, will only use the pkg-style JAXBContext.newInstance() if there is only a single Class in the set... otherwise it will use class-style JAXBContext.newInstance().
> It is only the pkg-style, however, which causes the @XmlRegistry (typically 'ObjectFactory') to be registered in the JAXBContext (since it's not like we go add the registry to the list of classes passed into newInstance()).  The end result is that the @XmlElemDecl's in the registry are not registered, and there are a list of global elems with the context doesn't know about, though it could if we changed the context creation.
> My motive for caring here is in looking to support JAXB unmarshalling by global-element....  I'm not sure if I could produce an error with the current code doing unmarshalling by declaredType, so for now I'm arguing for changing this for consistency's sake.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TUSCANY-2640) Should use package(s) when possible in creating JAXBContext, not set of Classes

Posted by "Raymond Feng (JIRA)" <de...@tuscany.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723343#action_12723343 ] 

Raymond Feng commented on TUSCANY-2640:
---------------------------------------

Sounds good. I checked in a fix under r787802 for 2.x. Do you need it for 1.x?

> Should use package(s) when possible in creating JAXBContext, not set of Classes
> -------------------------------------------------------------------------------
>
>                 Key: TUSCANY-2640
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2640
>             Project: Tuscany
>          Issue Type: Bug
>            Reporter: Scott Kurz
>             Fix For: Java-SCA-Next
>
>
> The JAXBContextHelper method:
>    createJAXBContext(TransformationContext tContext, boolean source)
> ends up calling
>   JAXBContextCache.getJAXBContext(Set<Class<?>> classes)  
> This latter method, though, will only use the pkg-style JAXBContext.newInstance() if there is only a single Class in the set... otherwise it will use class-style JAXBContext.newInstance().
> It is only the pkg-style, however, which causes the @XmlRegistry (typically 'ObjectFactory') to be registered in the JAXBContext (since it's not like we go add the registry to the list of classes passed into newInstance()).  The end result is that the @XmlElemDecl's in the registry are not registered, and there are a list of global elems with the context doesn't know about, though it could if we changed the context creation.
> My motive for caring here is in looking to support JAXB unmarshalling by global-element....  I'm not sure if I could produce an error with the current code doing unmarshalling by declaredType, so for now I'm arguing for changing this for consistency's sake.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Resolved: (TUSCANY-2640) Should use package(s) when possible in creating JAXBContext, not set of Classes

Posted by "Raymond Feng (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Raymond Feng resolved TUSCANY-2640.
-----------------------------------

       Resolution: Fixed
    Fix Version/s: Java-SCA-2.0

The fix has been merged into 1.x from the 2.x under r788499 

> Should use package(s) when possible in creating JAXBContext, not set of Classes
> -------------------------------------------------------------------------------
>
>                 Key: TUSCANY-2640
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2640
>             Project: Tuscany
>          Issue Type: Bug
>            Reporter: Scott Kurz
>            Assignee: Raymond Feng
>             Fix For: Java-SCA-2.0, Java-SCA-Next
>
>
> The JAXBContextHelper method:
>    createJAXBContext(TransformationContext tContext, boolean source)
> ends up calling
>   JAXBContextCache.getJAXBContext(Set<Class<?>> classes)  
> This latter method, though, will only use the pkg-style JAXBContext.newInstance() if there is only a single Class in the set... otherwise it will use class-style JAXBContext.newInstance().
> It is only the pkg-style, however, which causes the @XmlRegistry (typically 'ObjectFactory') to be registered in the JAXBContext (since it's not like we go add the registry to the list of classes passed into newInstance()).  The end result is that the @XmlElemDecl's in the registry are not registered, and there are a list of global elems with the context doesn't know about, though it could if we changed the context creation.
> My motive for caring here is in looking to support JAXB unmarshalling by global-element....  I'm not sure if I could produce an error with the current code doing unmarshalling by declaredType, so for now I'm arguing for changing this for consistency's sake.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Commented: (TUSCANY-2640) Should use package(s) when possible in creating JAXBContext, not set of Classes

Posted by "Scott Kurz (JIRA)" <de...@tuscany.apache.org>.
    [ https://issues.apache.org/jira/browse/TUSCANY-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12723201#action_12723201 ] 

Scott Kurz commented on TUSCANY-2640:
-------------------------------------

Picking this up again:

How about adjusting the algorithm to say:

1. build a list of classes
2. build a list of pkgs containing those classes...
3. for each of those pkgs, look for an ObjectFactory.class (I'm assuming there's an obvious classloader to use)
4. do newInstance(...list of classes..)   

Sound good? 

> Should use package(s) when possible in creating JAXBContext, not set of Classes
> -------------------------------------------------------------------------------
>
>                 Key: TUSCANY-2640
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2640
>             Project: Tuscany
>          Issue Type: Bug
>            Reporter: Scott Kurz
>             Fix For: Java-SCA-Next
>
>
> The JAXBContextHelper method:
>    createJAXBContext(TransformationContext tContext, boolean source)
> ends up calling
>   JAXBContextCache.getJAXBContext(Set<Class<?>> classes)  
> This latter method, though, will only use the pkg-style JAXBContext.newInstance() if there is only a single Class in the set... otherwise it will use class-style JAXBContext.newInstance().
> It is only the pkg-style, however, which causes the @XmlRegistry (typically 'ObjectFactory') to be registered in the JAXBContext (since it's not like we go add the registry to the list of classes passed into newInstance()).  The end result is that the @XmlElemDecl's in the registry are not registered, and there are a list of global elems with the context doesn't know about, though it could if we changed the context creation.
> My motive for caring here is in looking to support JAXB unmarshalling by global-element....  I'm not sure if I could produce an error with the current code doing unmarshalling by declaredType, so for now I'm arguing for changing this for consistency's sake.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


[jira] Updated: (TUSCANY-2640) Should use package(s) when possible in creating JAXBContext, not set of Classes

Posted by "ant elder (JIRA)" <de...@tuscany.apache.org>.
     [ https://issues.apache.org/jira/browse/TUSCANY-2640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ant elder updated TUSCANY-2640:
-------------------------------

    Fix Version/s: Java-SCA-Next

> Should use package(s) when possible in creating JAXBContext, not set of Classes
> -------------------------------------------------------------------------------
>
>                 Key: TUSCANY-2640
>                 URL: https://issues.apache.org/jira/browse/TUSCANY-2640
>             Project: Tuscany
>          Issue Type: Bug
>            Reporter: Scott Kurz
>             Fix For: Java-SCA-Next
>
>
> The JAXBContextHelper method:
>    createJAXBContext(TransformationContext tContext, boolean source)
> ends up calling
>   JAXBContextCache.getJAXBContext(Set<Class<?>> classes)  
> This latter method, though, will only use the pkg-style JAXBContext.newInstance() if there is only a single Class in the set... otherwise it will use class-style JAXBContext.newInstance().
> It is only the pkg-style, however, which causes the @XmlRegistry (typically 'ObjectFactory') to be registered in the JAXBContext (since it's not like we go add the registry to the list of classes passed into newInstance()).  The end result is that the @XmlElemDecl's in the registry are not registered, and there are a list of global elems with the context doesn't know about, though it could if we changed the context creation.
> My motive for caring here is in looking to support JAXB unmarshalling by global-element....  I'm not sure if I could produce an error with the current code doing unmarshalling by declaredType, so for now I'm arguing for changing this for consistency's sake.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.