You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by Jeremy Boynes <jb...@apache.org> on 2006/03/01 06:04:37 UTC
Re: Tomcat integration
Jeremy Boynes wrote:
> It's not working yet - I can do that once things are.
I took another go at this using a different technique (subclassing Host
to add SCA runtime management). I am running into a problem loading the
SCDL from a web application as it is being deployed.
Everything works in IDEA but when I run in Maven2 the load of the SCDL
returns an ANY type and I get a ClassCastException when the loader
attempts to cast it to a Module. I would guess that the SDO
implementation is not finding the schema definitions when loading the
resource.
I added an additional ResourceLoader to AssemblyModelContext so that it
contains both the system classloader (which loaded the tomcat code) and
the application classloader (which is loading the webapp).
I'm going to check this in with a testcase that uses the StandardHost so
that the build works whilst people are looking at it; to reproduce,
uncomment TomcatIntegrationTestCase line 77 and run from mvn rather than
an IDE.
Any ideas what is happening in the loader would be appreciated.
--
Jeremy
Re: Tomcat integration
Posted by Jeremy Boynes <jb...@apache.org>.
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
Re: Tomcat integration
Posted by Jeremy Boynes <jb...@apache.org>.
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
Re: Tomcat integration
Posted by Frank Budinsky <fr...@ca.ibm.com>.
Jeremy Boynes <jb...@apache.org> wrote on 03/01/2006 12:04:37 AM:
> Jeremy Boynes wrote:
> > It's not working yet - I can do that once things are.
>
> I took another go at this using a different technique (subclassing Host
> to add SCA runtime management). I am running into a problem loading the
> SCDL from a web application as it is being deployed.
>
> Everything works in IDEA but when I run in Maven2 the load of the SCDL
> returns an ANY type and I get a ClassCastException when the loader
> attempts to cast it to a Module. I would guess that the SDO
> implementation is not finding the schema definitions when loading the
> resource.
>
> I added an additional ResourceLoader to AssemblyModelContext so that it
> contains both the system classloader (which loaded the tomcat code) and
> the application classloader (which is loading the webapp).
>
> I'm going to check this in with a testcase that uses the StandardHost so
> that the build works whilst people are looking at it; to reproduce,
> uncomment TomcatIntegrationTestCase line 77 and run from mvn rather than
> an IDE.
>
> Any ideas what is happening in the loader would be appreciated.
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.
Frank.
> --
> Jeremy
>
-------------------------------------------------------------------------------
> Battery: org.apache.tuscany.tomcat.integration.TomcatIntegrationTestCase
>
-------------------------------------------------------------------------------
> testRuntimeIntegration(org.apache.tuscany.tomcat.integration.
> TomcatIntegrationTestCase)