[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xmlbeans-dev
Subject:    [jira] Commented: (XMLBEANS-299) Support substitution groups when
From:       "Christopher Hunt (JIRA)" <xmlbeans-dev () xml ! apache ! org>
Date:       2008-06-05 3:27:45
Message-ID: 675510435.1212636465201.JavaMail.jira () brutus
[Download RAW message or body]


    [ https://issues.apache.org/jira/browse/XMLBEANS-299?page=com.atlassian.jira.plugi \
n.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602525#action_12602525 ] 

Christopher Hunt commented on XMLBEANS-299:
-------------------------------------------

Could there not be some manual declaration of other jars that have classes to be \
potentially used as substitution candidates? I obviously have no idea of how \
substitution candidates are handled within xmlbeans right now, but I would feel \
comfortable informing xmlbeans of the whereabouts of other dependencies.

I think my request is something like David's above.

Meanwhile can we see the xmlbeans substitution groups FAQ make mention of this \
current limitation? (perhaps also in the Javadoc)

Thanks again for such a great product.

> Support substitution groups when the substitution is compiled in a different jar
> --------------------------------------------------------------------------------
> 
> Key: XMLBEANS-299
> URL: https://issues.apache.org/jira/browse/XMLBEANS-299
> Project: XMLBeans
> Issue Type: Improvement
> Components: Binding
> Affects Versions: Version 2.2, Version 2.2.1
> Reporter: Radu Preotiuc-Pietro
> Assignee: Radu Preotiuc-Pietro
> Fix For: TBD
> 
> 
> XMLBeans doesn't currently support substitution groups where the head element is \
> compiled in a jar and the substitutions are compiled at a later time in a different \
> jar. Because XMLBeans doesn't have the opportunity to save in the serialized xsb \
> information about substitution groups (since these do not exist at the time the xsb \
> is created) then it is forced to assume that any element can be a substitution for \
> anything else and the only way to reliably tell is to load the element declaration. \
> But loading the element declaration each time two elements are compared for QName \
> equality is going to be very expensive even if loaded from the cache. This whole \
> thing will need to be enabled on-request and have its separate codepath.

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


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@xmlbeans.apache.org
For additional commands, e-mail: dev-help@xmlbeans.apache.org


[prev in list] [next in list] [prev in thread] [next in thread]