You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by "David T. Adcox (JIRA)" <tu...@ws.apache.org> on 2007/10/24 21:38:51 UTC
[jira] Created: (TUSCANY-1868) Schema imports not working in
multiple class-loader environment
Schema imports not working in multiple class-loader environment
---------------------------------------------------------------
Key: TUSCANY-1868
URL: https://issues.apache.org/jira/browse/TUSCANY-1868
Project: Tuscany
Issue Type: Bug
Affects Versions: Java-SDO-1.0
Environment: n/a
Reporter: David T. Adcox
Fix For: Java-SDO-Next
There is a problem with loading schemas that import an additional namespace when in a multiple class-loader environment. The problem exists due to a design flaw in how the EcoreBuilder and package registries interact under a specific circumstance. That circumstance exists when the default helper context is used to load a schema model using the XSDHelper.define() method in two different, peer class-loaders. These peer class-loaders must share the same parentage.
---------------
| CL parent |
---------------
/\
/ \
/ \
/ \
------- -------
| CL1 | | CL2 |
------- -------
In this scenario, the same EcoreBuilder is used on both passes of XSDHelper.define(), because the EcoreBuilder is associated with the CL Parent. A unique registry is created for CL1 and another for CL2. During the processing for CL1, the target namespace and all imported namespaces are properly parsed and the models stored in the associated registry, but during the processing for CL2, because the same EcoreBuilder is used, only the target namespace is processed. So, any imported models are missing from the CL2 registry.
I've attached an example that will demonstrate this issue.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1868) Schema imports not working in
multiple class-loader environment
Posted by "David T. Adcox (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David T. Adcox updated TUSCANY-1868:
------------------------------------
Attachment: Test1868.java
> Schema imports not working in multiple class-loader environment
> ---------------------------------------------------------------
>
> Key: TUSCANY-1868
> URL: https://issues.apache.org/jira/browse/TUSCANY-1868
> Project: Tuscany
> Issue Type: Bug
> Affects Versions: Java-SDO-1.0
> Environment: n/a
> Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: Test1868.java
>
>
> There is a problem with loading schemas that import an additional namespace when in a multiple class-loader environment. The problem exists due to a design flaw in how the EcoreBuilder and package registries interact under a specific circumstance. That circumstance exists when the default helper context is used to load a schema model using the XSDHelper.define() method in two different, peer class-loaders. These peer class-loaders must share the same parentage.
> ---------------
> | CL parent |
> ---------------
> /\
> / \
> / \
> / \
> ------- -------
> | CL1 | | CL2 |
> ------- -------
> In this scenario, the same EcoreBuilder is used on both passes of XSDHelper.define(), because the EcoreBuilder is associated with the CL Parent. A unique registry is created for CL1 and another for CL2. During the processing for CL1, the target namespace and all imported namespaces are properly parsed and the models stored in the associated registry, but during the processing for CL2, because the same EcoreBuilder is used, only the target namespace is processed. So, any imported models are missing from the CL2 registry.
> I've attached an example that will demonstrate this issue.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1868) Schema imports not working in
multiple class-loader environment
Posted by "Kelvin Goodson (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Kelvin Goodson updated TUSCANY-1868:
------------------------------------
Component/s: Java SDO Implementation
> Schema imports not working in multiple class-loader environment
> ---------------------------------------------------------------
>
> Key: TUSCANY-1868
> URL: https://issues.apache.org/jira/browse/TUSCANY-1868
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-1.0
> Environment: n/a
> Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: Test1868.java
>
>
> There is a problem with loading schemas that import an additional namespace when in a multiple class-loader environment. The problem exists due to a design flaw in how the EcoreBuilder and package registries interact under a specific circumstance. That circumstance exists when the default helper context is used to load a schema model using the XSDHelper.define() method in two different, peer class-loaders. These peer class-loaders must share the same parentage.
> ---------------
> | CL parent |
> ---------------
> /\
> / \
> / \
> / \
> ------- -------
> | CL1 | | CL2 |
> ------- -------
> In this scenario, the same EcoreBuilder is used on both passes of XSDHelper.define(), because the EcoreBuilder is associated with the CL Parent. A unique registry is created for CL1 and another for CL2. During the processing for CL1, the target namespace and all imported namespaces are properly parsed and the models stored in the associated registry, but during the processing for CL2, because the same EcoreBuilder is used, only the target namespace is processed. So, any imported models are missing from the CL2 registry.
> I've attached an example that will demonstrate this issue.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org
[jira] Updated: (TUSCANY-1868) Schema imports not working in
multiple class-loader environment
Posted by "David T. Adcox (JIRA)" <tu...@ws.apache.org>.
[ https://issues.apache.org/jira/browse/TUSCANY-1868?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
David T. Adcox updated TUSCANY-1868:
------------------------------------
Attachment: 1868.patch
This patch will resolve this problem, but it does introduce a bit of redundancy. Instead of searching up the Class loader parent tree, a new EcoreBuilder is created per CL. This insures that the EcoreBuilder will contain the required models. This solution does mean we lose some reuse, but given the alternatives, it seems acceptable.
> Schema imports not working in multiple class-loader environment
> ---------------------------------------------------------------
>
> Key: TUSCANY-1868
> URL: https://issues.apache.org/jira/browse/TUSCANY-1868
> Project: Tuscany
> Issue Type: Bug
> Components: Java SDO Implementation
> Affects Versions: Java-SDO-1.0
> Environment: n/a
> Reporter: David T. Adcox
> Fix For: Java-SDO-Next
>
> Attachments: 1868.patch, Test1868.java
>
>
> There is a problem with loading schemas that import an additional namespace when in a multiple class-loader environment. The problem exists due to a design flaw in how the EcoreBuilder and package registries interact under a specific circumstance. That circumstance exists when the default helper context is used to load a schema model using the XSDHelper.define() method in two different, peer class-loaders. These peer class-loaders must share the same parentage.
> ---------------
> | CL parent |
> ---------------
> /\
> / \
> / \
> / \
> ------- -------
> | CL1 | | CL2 |
> ------- -------
> In this scenario, the same EcoreBuilder is used on both passes of XSDHelper.define(), because the EcoreBuilder is associated with the CL Parent. A unique registry is created for CL1 and another for CL2. During the processing for CL1, the target namespace and all imported namespaces are properly parsed and the models stored in the associated registry, but during the processing for CL2, because the same EcoreBuilder is used, only the target namespace is processed. So, any imported models are missing from the CL2 registry.
> I've attached an example that will demonstrate this issue.
--
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: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org