Ok, when the application context is starting, the Thread's context classloader is set to the application classloader. If I change the TCCL to the engine classloader then SDO is able to resolve the schema.
Although this works, it seems a little odd to have to pass context into SDO calls on the Thread in the form of the TCCL. As a user, we already defined the XML->SDO->Java mapping by calling registerStaticTypes so why do we need to implicitly pass a classloader on each call? -- Jeremy Jeremy Boynes wrote: > Frank Budinsky wrote: > >> >>You're right about the problem. If the SDO loader can't find/load the >>metadata it will >>dynamically load it as an ANY type instance. Since it's a generated model, >>the metadata >>is supposed to be getting registered by a call to >>SDOUtil.registerStaticTypes(SomeFactory.class) >>somewhere. >> > > > Right - what I don't get is why it can't find the schema. > > When run from the debugger it works. I think this is because IDEA (and I > assume Eclipse as well) places all project classes on the system > classpath and so they are visible from the parent of the classloader > used to load the web application. > > In Maven, there is nothing except a little bootstrap code in the system > classloader. The test classes are loaded from a special child > classloader and as a result the project classes are not present in the > parent of the web application classloader. > > I changed AssemblyModelContext to contain both classloaders and modified > ModuleComponentConfigurationLoaderImpl to use the application > classloader to find the artifact. However, when SCDLXMLReader calls > XMLHelper.INSTANCE.load() the ANY instance is returned. > > SDOUtil.registerStaticTypes is called during engine startup and the > engine code is able to load the SCDL for the system.module file. When > loading the application's sca.module file, I don't see what would be > different so that SDO is not able to find the schema resulting in the > return of the ANY element. > > -- > Jeremy
