pretty much, any EE container will provide that kind of scenario. most EE containers have a configured set of resource locations (typically findable globally via jndi), but classloaders typically are hierarchical to isolate war/sar/rar deployments from each other and the global EE support stack.
Stanton Fisque principal technologist latticeware.com portland, oregon > On Dec 11, 2025, at 06:51 AM, Susan Hert (Jira) <[email protected]> wrote: > > > [ > https://issues.apache.org/jira/browse/XMLBEANS-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18044454#comment-18044454 > ] > > Susan Hert commented on XMLBEANS-661: > ------------------------------------- > > I have looked into making this resolution ordering configurable, but without > making much headway. The XmlOptions object seems to largely come into play > when parsing documents, but this issue happens when loading an object, and at > the point where this happens there is no XmlOptions object in sight (at least > not that I can find). > > I have confirmed that the test provided with the fix for XMLBEANS-648 still > passes when my update. > > Admittedly, I don't really understand the pathways through this code, but is > there a use case you know of where some type system would be findable with > both the resourceLoader and the classLoader, but the one from the > resourceLoader is different from the one provided by the classLoader and is > to be preferred? > >> Unable to resolve beans with classloader because >> DefaultClassLoaderResourceLoader is used first >> ----------------------------------------------------------------------------------------------- >> >> Key: XMLBEANS-661 >> URL: https://issues.apache.org/jira/browse/XMLBEANS-661 >> Project: XMLBeans >> Issue Type: Bug >> Affects Versions: Version 5.2.1 >> Reporter: Susan Hert >> Priority: Major >> Attachments: SchemaTypeLoader__typeSystemForName.patch >> >> >> [This >> commit|https://github.com/apache/xmlbeans/commit/82bcd3775c4643799d11581649815596aedd3520] >> for the fix of Issue #648 has introduced another problem that we are seeing >> when loading certain documents. >> In particular, the constructor of >> {{src/main/java/org/apache/xmlbeans/impl/schema/SchemaTypeSystemImpl.java}} >> changed from passing a {{null}} value as a {{resourceLoader}} to the >> {{build}} method for {{SchemaTypeLoaderImpl}} to passing in a {{new >> DefaultClassLoaderResourceLoader()}}. This has the consequence that >> {{SchemaTypeLoaderImpl::typeSystemForName}} now tries to get the type system >> on the classpath using the {{_resourceLoader}}, but, in our case, for some >> documents, the {{_classpathTypeSystems}} map is empty, and thus it returns a >> generic {{SchemaTypeSystemImpl}} that has no classloader and won't return >> any of our XML beans, which then later causes a {{ClassCastException}} >> because the object returned is a base class object. >> Previously, when the {{_resourceLoader}} was {{null}}, {{typeSystemForName}} >> used the non-null {{_classLoader}} and found a type system with a classpath >> that could resolve to our beans. >> This does not happen for all of our beans, and I've not been able to track >> down what differentiates the problematic ones from the happy ones, but >> running out tests with an updated version of xmlBeans that includes this >> patch seems to have resolved our issue. > > > > -- > This message was sent by Atlassian Jira > (v8.20.10#820010) > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] >
smime.p7s
Description: S/MIME cryptographic signature
