You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openjpa.apache.org by "Pinaki Poddar (Created) (JIRA)" <ji...@apache.org> on 2011/10/11 18:11:12 UTC
[jira] [Created] (OPENJPA-2057) Rethinking ClassLoading
architecture
Rethinking ClassLoading architecture
-------------------------------------
Key: OPENJPA-2057
URL: https://issues.apache.org/jira/browse/OPENJPA-2057
Project: OpenJPA
Issue Type: Improvement
Components: kernel
Reporter: Pinaki Poddar
This issue proposes an overhaul of the classloading architecture.
Background:
------------------
OpenJPA runtime needs to load classes and resources at various time points in its life cycle and employs various classloading strategies at different parts of its code base.
These are few broad categories of classes/resources OpenJPA needs to load
1. Resources: user-specified resources such as persistence.xml or orm.xml
2. Persistent Domain classes
3. Native Plug-ins: Implementation of interfaces e.g. UpdateManager that are supplied by OpenJPA and packaged in its own distribution
4. User Plug-ins: Implementation of interfaces e.g. MappingStrategy or ValueHandlers that the user has supplied via configuration and packaged in deployed units
5. Temporary classloader for java agent or weaving code loading domain classes to enhance them prior to their use
To load these different artifacts by their name, OpenJPA at different places employ available classloaders such as
i) the current thread's context class loader
ii) the clasloader that loaded OpenJPA native classes/interfaces
iii) the classloader that loaded a deployed application which can vary based on the container (Spring, OSGi, JEE) environment
iv) system classloader
The problem is the decision about which classloader is appropriate in a given context is quite scattered. This weakness appears in numerous places where a method is supplied with a ClassLoader and if the supplied loader is null, the method chooses a classloader (often the context classloader) or a class has its own classforname() method that tries a series of classloaders etc.
This is a perennial problem and manifested in several reported bugs whose resolutions often introduced further localized logic to account for the point defects, thereby accentuating the same trends that I believe is the root cause of the problem itself.
Proposed solution/design:
-------------------------------------
Unify classloading decision in a singular abstraction.
Allow that abstraction to cope with classloading regimes of different containers (Spring, OSGi, JEE etc).
The natural candidate for unifying classloading is existing Configuration object. This object is a per persistence unit singleton and available throughout the runtime.
However, certain class/resource loading must take place even before a Configuration instance is instantiated. For example, to locate and load the persistence.xml itself.
Also note that the persistence.xml or orm.xml may contain fully-qualified names of persistent domain classes or plug-in names (both native and custom/user variety) and they can occur either by their fully-qualified class name or registered alias. The specialized parsers often has to load the class given their parsed string names or aliases.
The bootstrap sequence of OpenJPA runtime is to construct a specific ConfigurationProvider and a series of specialized parsers to parse meta-data of various sorts (annotations, mapping xml, persistence.xml). These ConfigurationProviders are responsibilities of ProductDerivation -- the core mechanics that contributes their individual aspects to build up a Configuration.
Given this existing well-designed bootstrap strategy, here is a proposal
1. Let each ProductDerivation make their decision on how they will load whatever they need to load using whatever classloader they may need. For example, a OSGi ProductDerivation will use a bundle classloader to load its relevant resources. This phase occurs *before* a persistence unit (i.e. EntityManagerFactory) is constructed.
2. Once the ProductDerivations have finished their loading using their own ConfigurationProvider, they transfer the accumulated information to a Configuration instance which essentially becomes the holder of entire runtime information for an EntityManagerFactory. During this transfer phase, let the ProductDerivations set the classloader as well into the Configuration instance.
3. Once the Configuration instance has the classloader, this classloader is used throughout the codebase.
But what kind of classloader is used by the Configuration that will suit complex needs of class/resource loading?
OpenJPA already has a powerful abstraction called MultiClassLoader which can employ an ordered series of (possibly unrelated) classloaders. So that MultiClassLoader is the correct classloader for Configuration instance. The ProductDerivation or ConfigurationProvider can add/remove their contributions.
I understand that a change of this nature could be destabilizing in short-term. Also the change is difficult to validate across various container environments. I hope the community users will help by suggesting and testing such an overhaul to streamline OpenJPA classloading for long-term sustainability and maintenance.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] [Commented] (OPENJPA-2057) Rethinking ClassLoading architecture
Posted by Mark Struberg <st...@yahoo.de>.
completely agree. You might have seen my other post. The most pressing consequence of the Classloader stuff is that runtime enhancement is basically broken atm. At least if you have an EE or Servlet container. Maybe we can work around this by wrapping the Instrumentation somehow and do all the PCEnhancer stuff in a new temporary ClassLoader instead of 'polluting' the SystemClassLoader.
But I will focus on getting 2.2.0 out of the door for now ;)
LieGrue,
strub
----- Original Message -----
> From: Pinaki Poddar <pp...@apache.org>
> To: dev@openjpa.apache.org
> Cc:
> Sent: Monday, January 9, 2012 6:46 PM
> Subject: Re: [jira] [Commented] (OPENJPA-2057) Rethinking ClassLoading architecture
>
> it broke *lots* of internal tests and we didn't have the *time to
> investigate* all of them.
>
> 1. number of failed tests is not that critical -- because often few causes
> result into many failures.
>
> 2. There will never be a *time to investigate* unless we think the issue to
> be important. I believe that the work at the stage of commit took a month.
> And I had no illusion that it will run everything at its first commit. Nor I
> have the requisite machinery to investigate *lots of internal tests* and,
> unfortunately, those who have did not have the *time to investigate*.
> Unless the attitude to this kind of structural modification change, and we
> proactively and jointly collaborate to address such issues, I see little
> possibility to resolve such complex undertakings.
>
>
> -----
> Pinaki Poddar
> Chair, Apache OpenJPA Project
> --
> View this message in context:
> http://openjpa.208410.n2.nabble.com/jira-Created-OPENJPA-2057-Rethinking-ClassLoading-architecture-tp6881585p7168780.html
> Sent from the OpenJPA Developers mailing list archive at Nabble.com.
>
Re: [jira] [Commented] (OPENJPA-2057) Rethinking ClassLoading
architecture
Posted by Pinaki Poddar <pp...@apache.org>.
it broke *lots* of internal tests and we didn't have the *time to
investigate* all of them.
1. number of failed tests is not that critical -- because often few causes
result into many failures.
2. There will never be a *time to investigate* unless we think the issue to
be important. I believe that the work at the stage of commit took a month.
And I had no illusion that it will run everything at its first commit. Nor I
have the requisite machinery to investigate *lots of internal tests* and,
unfortunately, those who have did not have the *time to investigate*.
Unless the attitude to this kind of structural modification change, and we
proactively and jointly collaborate to address such issues, I see little
possibility to resolve such complex undertakings.
-----
Pinaki Poddar
Chair, Apache OpenJPA Project
--
View this message in context: http://openjpa.208410.n2.nabble.com/jira-Created-OPENJPA-2057-Rethinking-ClassLoading-architecture-tp6881585p7168780.html
Sent from the OpenJPA Developers mailing list archive at Nabble.com.
[jira] [Commented] (OPENJPA-2057) Rethinking ClassLoading
architecture
Posted by "Rick Curtis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182624#comment-13182624 ]
Rick Curtis commented on OPENJPA-2057:
--------------------------------------
Mark -
I had to back these changes out of trunk because it broke lots of internal tests and we didn't have the time to investigate all of them. I believe the intent is to put these changes back in sometime after we cut a 2.2.x branch.
Thanks,
Rick
> Rethinking ClassLoading architecture
> -------------------------------------
>
> Key: OPENJPA-2057
> URL: https://issues.apache.org/jira/browse/OPENJPA-2057
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assignee: Rick Curtis
>
> This issue proposes an overhaul of the classloading architecture.
> Background:
> ------------------
> OpenJPA runtime needs to load classes and resources at various time points in its life cycle and employs various classloading strategies at different parts of its code base.
> These are few broad categories of classes/resources OpenJPA needs to load
> 1. Resources: user-specified resources such as persistence.xml or orm.xml
> 2. Persistent Domain classes
> 3. Native Plug-ins: Implementation of interfaces e.g. UpdateManager that are supplied by OpenJPA and packaged in its own distribution
> 4. User Plug-ins: Implementation of interfaces e.g. MappingStrategy or ValueHandlers that the user has supplied via configuration and packaged in deployed units
> 5. Temporary classloader for java agent or weaving code loading domain classes to enhance them prior to their use
> To load these different artifacts by their name, OpenJPA at different places employ available classloaders such as
> i) the current thread's context class loader
> ii) the clasloader that loaded OpenJPA native classes/interfaces
> iii) the classloader that loaded a deployed application which can vary based on the container (Spring, OSGi, JEE) environment
> iv) system classloader
> The problem is the decision about which classloader is appropriate in a given context is quite scattered. This weakness appears in numerous places where a method is supplied with a ClassLoader and if the supplied loader is null, the method chooses a classloader (often the context classloader) or a class has its own classforname() method that tries a series of classloaders etc.
> This is a perennial problem and manifested in several reported bugs whose resolutions often introduced further localized logic to account for the point defects, thereby accentuating the same trends that I believe is the root cause of the problem itself.
> Proposed solution/design:
> -------------------------------------
> Unify classloading decision in a singular abstraction.
> Allow that abstraction to cope with classloading regimes of different containers (Spring, OSGi, JEE etc).
> The natural candidate for unifying classloading is existing Configuration object. This object is a per persistence unit singleton and available throughout the runtime.
> However, certain class/resource loading must take place even before a Configuration instance is instantiated. For example, to locate and load the persistence.xml itself.
> Also note that the persistence.xml or orm.xml may contain fully-qualified names of persistent domain classes or plug-in names (both native and custom/user variety) and they can occur either by their fully-qualified class name or registered alias. The specialized parsers often has to load the class given their parsed string names or aliases.
> The bootstrap sequence of OpenJPA runtime is to construct a specific ConfigurationProvider and a series of specialized parsers to parse meta-data of various sorts (annotations, mapping xml, persistence.xml). These ConfigurationProviders are responsibilities of ProductDerivation -- the core mechanics that contributes their individual aspects to build up a Configuration.
> Given this existing well-designed bootstrap strategy, here is a proposal
> 1. Let each ProductDerivation make their decision on how they will load whatever they need to load using whatever classloader they may need. For example, a OSGi ProductDerivation will use a bundle classloader to load its relevant resources. This phase occurs *before* a persistence unit (i.e. EntityManagerFactory) is constructed.
> 2. Once the ProductDerivations have finished their loading using their own ConfigurationProvider, they transfer the accumulated information to a Configuration instance which essentially becomes the holder of entire runtime information for an EntityManagerFactory. During this transfer phase, let the ProductDerivations set the classloader as well into the Configuration instance.
> 3. Once the Configuration instance has the classloader, this classloader is used throughout the codebase.
> But what kind of classloader is used by the Configuration that will suit complex needs of class/resource loading?
> OpenJPA already has a powerful abstraction called MultiClassLoader which can employ an ordered series of (possibly unrelated) classloaders. So that MultiClassLoader is the correct classloader for Configuration instance. The ProductDerivation or ConfigurationProvider can add/remove their contributions.
> I understand that a change of this nature could be destabilizing in short-term. Also the change is difficult to validate across various container environments. I hope the community users will help by suggesting and testing such an overhaul to streamline OpenJPA classloading for long-term sustainability and maintenance.
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENJPA-2057) Rethinking ClassLoading
architecture
Posted by "Rick Curtis (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13144738#comment-13144738 ]
Rick Curtis commented on OPENJPA-2057:
--------------------------------------
This change broke a number of our internal tests.... I spoke with Pinaki, and we agreed that I would back this change out while we investigate the failures.
Thanks,
Rick
> Rethinking ClassLoading architecture
> -------------------------------------
>
> Key: OPENJPA-2057
> URL: https://issues.apache.org/jira/browse/OPENJPA-2057
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assignee: Rick Curtis
>
> This issue proposes an overhaul of the classloading architecture.
> Background:
> ------------------
> OpenJPA runtime needs to load classes and resources at various time points in its life cycle and employs various classloading strategies at different parts of its code base.
> These are few broad categories of classes/resources OpenJPA needs to load
> 1. Resources: user-specified resources such as persistence.xml or orm.xml
> 2. Persistent Domain classes
> 3. Native Plug-ins: Implementation of interfaces e.g. UpdateManager that are supplied by OpenJPA and packaged in its own distribution
> 4. User Plug-ins: Implementation of interfaces e.g. MappingStrategy or ValueHandlers that the user has supplied via configuration and packaged in deployed units
> 5. Temporary classloader for java agent or weaving code loading domain classes to enhance them prior to their use
> To load these different artifacts by their name, OpenJPA at different places employ available classloaders such as
> i) the current thread's context class loader
> ii) the clasloader that loaded OpenJPA native classes/interfaces
> iii) the classloader that loaded a deployed application which can vary based on the container (Spring, OSGi, JEE) environment
> iv) system classloader
> The problem is the decision about which classloader is appropriate in a given context is quite scattered. This weakness appears in numerous places where a method is supplied with a ClassLoader and if the supplied loader is null, the method chooses a classloader (often the context classloader) or a class has its own classforname() method that tries a series of classloaders etc.
> This is a perennial problem and manifested in several reported bugs whose resolutions often introduced further localized logic to account for the point defects, thereby accentuating the same trends that I believe is the root cause of the problem itself.
> Proposed solution/design:
> -------------------------------------
> Unify classloading decision in a singular abstraction.
> Allow that abstraction to cope with classloading regimes of different containers (Spring, OSGi, JEE etc).
> The natural candidate for unifying classloading is existing Configuration object. This object is a per persistence unit singleton and available throughout the runtime.
> However, certain class/resource loading must take place even before a Configuration instance is instantiated. For example, to locate and load the persistence.xml itself.
> Also note that the persistence.xml or orm.xml may contain fully-qualified names of persistent domain classes or plug-in names (both native and custom/user variety) and they can occur either by their fully-qualified class name or registered alias. The specialized parsers often has to load the class given their parsed string names or aliases.
> The bootstrap sequence of OpenJPA runtime is to construct a specific ConfigurationProvider and a series of specialized parsers to parse meta-data of various sorts (annotations, mapping xml, persistence.xml). These ConfigurationProviders are responsibilities of ProductDerivation -- the core mechanics that contributes their individual aspects to build up a Configuration.
> Given this existing well-designed bootstrap strategy, here is a proposal
> 1. Let each ProductDerivation make their decision on how they will load whatever they need to load using whatever classloader they may need. For example, a OSGi ProductDerivation will use a bundle classloader to load its relevant resources. This phase occurs *before* a persistence unit (i.e. EntityManagerFactory) is constructed.
> 2. Once the ProductDerivations have finished their loading using their own ConfigurationProvider, they transfer the accumulated information to a Configuration instance which essentially becomes the holder of entire runtime information for an EntityManagerFactory. During this transfer phase, let the ProductDerivations set the classloader as well into the Configuration instance.
> 3. Once the Configuration instance has the classloader, this classloader is used throughout the codebase.
> But what kind of classloader is used by the Configuration that will suit complex needs of class/resource loading?
> OpenJPA already has a powerful abstraction called MultiClassLoader which can employ an ordered series of (possibly unrelated) classloaders. So that MultiClassLoader is the correct classloader for Configuration instance. The ProductDerivation or ConfigurationProvider can add/remove their contributions.
> I understand that a change of this nature could be destabilizing in short-term. Also the change is difficult to validate across various container environments. I hope the community users will help by suggesting and testing such an overhaul to streamline OpenJPA classloading for long-term sustainability and maintenance.
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENJPA-2057) Rethinking ClassLoading
architecture
Posted by "Mark Struberg (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13182258#comment-13182258 ]
Mark Struberg commented on OPENJPA-2057:
----------------------------------------
Rick, Pinaki, is there a branch where this got applied?
I basically think that we need to do this step at some point.
Do you plan to continue working on this?
> Rethinking ClassLoading architecture
> -------------------------------------
>
> Key: OPENJPA-2057
> URL: https://issues.apache.org/jira/browse/OPENJPA-2057
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assignee: Rick Curtis
>
> This issue proposes an overhaul of the classloading architecture.
> Background:
> ------------------
> OpenJPA runtime needs to load classes and resources at various time points in its life cycle and employs various classloading strategies at different parts of its code base.
> These are few broad categories of classes/resources OpenJPA needs to load
> 1. Resources: user-specified resources such as persistence.xml or orm.xml
> 2. Persistent Domain classes
> 3. Native Plug-ins: Implementation of interfaces e.g. UpdateManager that are supplied by OpenJPA and packaged in its own distribution
> 4. User Plug-ins: Implementation of interfaces e.g. MappingStrategy or ValueHandlers that the user has supplied via configuration and packaged in deployed units
> 5. Temporary classloader for java agent or weaving code loading domain classes to enhance them prior to their use
> To load these different artifacts by their name, OpenJPA at different places employ available classloaders such as
> i) the current thread's context class loader
> ii) the clasloader that loaded OpenJPA native classes/interfaces
> iii) the classloader that loaded a deployed application which can vary based on the container (Spring, OSGi, JEE) environment
> iv) system classloader
> The problem is the decision about which classloader is appropriate in a given context is quite scattered. This weakness appears in numerous places where a method is supplied with a ClassLoader and if the supplied loader is null, the method chooses a classloader (often the context classloader) or a class has its own classforname() method that tries a series of classloaders etc.
> This is a perennial problem and manifested in several reported bugs whose resolutions often introduced further localized logic to account for the point defects, thereby accentuating the same trends that I believe is the root cause of the problem itself.
> Proposed solution/design:
> -------------------------------------
> Unify classloading decision in a singular abstraction.
> Allow that abstraction to cope with classloading regimes of different containers (Spring, OSGi, JEE etc).
> The natural candidate for unifying classloading is existing Configuration object. This object is a per persistence unit singleton and available throughout the runtime.
> However, certain class/resource loading must take place even before a Configuration instance is instantiated. For example, to locate and load the persistence.xml itself.
> Also note that the persistence.xml or orm.xml may contain fully-qualified names of persistent domain classes or plug-in names (both native and custom/user variety) and they can occur either by their fully-qualified class name or registered alias. The specialized parsers often has to load the class given their parsed string names or aliases.
> The bootstrap sequence of OpenJPA runtime is to construct a specific ConfigurationProvider and a series of specialized parsers to parse meta-data of various sorts (annotations, mapping xml, persistence.xml). These ConfigurationProviders are responsibilities of ProductDerivation -- the core mechanics that contributes their individual aspects to build up a Configuration.
> Given this existing well-designed bootstrap strategy, here is a proposal
> 1. Let each ProductDerivation make their decision on how they will load whatever they need to load using whatever classloader they may need. For example, a OSGi ProductDerivation will use a bundle classloader to load its relevant resources. This phase occurs *before* a persistence unit (i.e. EntityManagerFactory) is constructed.
> 2. Once the ProductDerivations have finished their loading using their own ConfigurationProvider, they transfer the accumulated information to a Configuration instance which essentially becomes the holder of entire runtime information for an EntityManagerFactory. During this transfer phase, let the ProductDerivations set the classloader as well into the Configuration instance.
> 3. Once the Configuration instance has the classloader, this classloader is used throughout the codebase.
> But what kind of classloader is used by the Configuration that will suit complex needs of class/resource loading?
> OpenJPA already has a powerful abstraction called MultiClassLoader which can employ an ordered series of (possibly unrelated) classloaders. So that MultiClassLoader is the correct classloader for Configuration instance. The ProductDerivation or ConfigurationProvider can add/remove their contributions.
> I understand that a change of this nature could be destabilizing in short-term. Also the change is difficult to validate across various container environments. I hope the community users will help by suggesting and testing such an overhaul to streamline OpenJPA classloading for long-term sustainability and maintenance.
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Assigned] (OPENJPA-2057) Rethinking ClassLoading
architecture
Posted by "Rick Curtis (Assigned) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENJPA-2057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Rick Curtis reassigned OPENJPA-2057:
------------------------------------
Assignee: Rick Curtis
> Rethinking ClassLoading architecture
> -------------------------------------
>
> Key: OPENJPA-2057
> URL: https://issues.apache.org/jira/browse/OPENJPA-2057
> Project: OpenJPA
> Issue Type: Improvement
> Components: kernel
> Reporter: Pinaki Poddar
> Assignee: Rick Curtis
>
> This issue proposes an overhaul of the classloading architecture.
> Background:
> ------------------
> OpenJPA runtime needs to load classes and resources at various time points in its life cycle and employs various classloading strategies at different parts of its code base.
> These are few broad categories of classes/resources OpenJPA needs to load
> 1. Resources: user-specified resources such as persistence.xml or orm.xml
> 2. Persistent Domain classes
> 3. Native Plug-ins: Implementation of interfaces e.g. UpdateManager that are supplied by OpenJPA and packaged in its own distribution
> 4. User Plug-ins: Implementation of interfaces e.g. MappingStrategy or ValueHandlers that the user has supplied via configuration and packaged in deployed units
> 5. Temporary classloader for java agent or weaving code loading domain classes to enhance them prior to their use
> To load these different artifacts by their name, OpenJPA at different places employ available classloaders such as
> i) the current thread's context class loader
> ii) the clasloader that loaded OpenJPA native classes/interfaces
> iii) the classloader that loaded a deployed application which can vary based on the container (Spring, OSGi, JEE) environment
> iv) system classloader
> The problem is the decision about which classloader is appropriate in a given context is quite scattered. This weakness appears in numerous places where a method is supplied with a ClassLoader and if the supplied loader is null, the method chooses a classloader (often the context classloader) or a class has its own classforname() method that tries a series of classloaders etc.
> This is a perennial problem and manifested in several reported bugs whose resolutions often introduced further localized logic to account for the point defects, thereby accentuating the same trends that I believe is the root cause of the problem itself.
> Proposed solution/design:
> -------------------------------------
> Unify classloading decision in a singular abstraction.
> Allow that abstraction to cope with classloading regimes of different containers (Spring, OSGi, JEE etc).
> The natural candidate for unifying classloading is existing Configuration object. This object is a per persistence unit singleton and available throughout the runtime.
> However, certain class/resource loading must take place even before a Configuration instance is instantiated. For example, to locate and load the persistence.xml itself.
> Also note that the persistence.xml or orm.xml may contain fully-qualified names of persistent domain classes or plug-in names (both native and custom/user variety) and they can occur either by their fully-qualified class name or registered alias. The specialized parsers often has to load the class given their parsed string names or aliases.
> The bootstrap sequence of OpenJPA runtime is to construct a specific ConfigurationProvider and a series of specialized parsers to parse meta-data of various sorts (annotations, mapping xml, persistence.xml). These ConfigurationProviders are responsibilities of ProductDerivation -- the core mechanics that contributes their individual aspects to build up a Configuration.
> Given this existing well-designed bootstrap strategy, here is a proposal
> 1. Let each ProductDerivation make their decision on how they will load whatever they need to load using whatever classloader they may need. For example, a OSGi ProductDerivation will use a bundle classloader to load its relevant resources. This phase occurs *before* a persistence unit (i.e. EntityManagerFactory) is constructed.
> 2. Once the ProductDerivations have finished their loading using their own ConfigurationProvider, they transfer the accumulated information to a Configuration instance which essentially becomes the holder of entire runtime information for an EntityManagerFactory. During this transfer phase, let the ProductDerivations set the classloader as well into the Configuration instance.
> 3. Once the Configuration instance has the classloader, this classloader is used throughout the codebase.
> But what kind of classloader is used by the Configuration that will suit complex needs of class/resource loading?
> OpenJPA already has a powerful abstraction called MultiClassLoader which can employ an ordered series of (possibly unrelated) classloaders. So that MultiClassLoader is the correct classloader for Configuration instance. The ProductDerivation or ConfigurationProvider can add/remove their contributions.
> I understand that a change of this nature could be destabilizing in short-term. Also the change is difficult to validate across various container environments. I hope the community users will help by suggesting and testing such an overhaul to streamline OpenJPA classloading for long-term sustainability and maintenance.
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira