geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject Re: how are gbean references resolved?
Date Thu, 09 Mar 2006 17:16:04 GMT

On Mar 9, 2006, at 2:53 AM, Conrad O'Dea wrote:

> Hi David,
>
> On Wed, 2006-02-22 at 13:11 -0600, David Jencks wrote:
>
> [snip]
>> There's a missing feature at the moment that the web service builder
>> (axis or celtix) does not get to add to the default parents.  In the
>> 1.1/configid branch we are greatly modifying how the default parents
>> are set up and I plan to look at this problem with web service
>> builders after we get 1.1 out.  Meanwhile you will need to change the
>> default parentids in the jetty, tomcat, and openejb builders.
>
> Updating the parentIds did the trick here. Now I have a gbean that  
> I can
> deploy to Geronimo and have it handle deployments of POJOs.  This  
> leads
> me on to two questions.
>
> Is is possible to update the parentIds for these modules through the
> config.xml?  Right now, to get my Celtix deployer to work I need to
> build my own config for G.  It would be great if this could be done by
> some quick edits to a config.xml in a binary distribution of G.

You can set the defaultParentId for the existing jetty/tomcat/openejb  
builders in config.xml, you just use a comma-delimited list of  
configids like this:

     <configuration name="geronimo/jetty-deployer/${geronimo_version}/ 
car">
         <gbean name="JettyWebBuilder">
             <attribute name="defaultParentId">geronimo/jetty/$ 
{geronimo_version}/car,geronimo/j2ee-server/${geronimo_version}/ 
car,geronimo-cts/server-security/${pom.currentVersion}/car</attribute>
         </gbean>
     </configuration>
(you probably need to resolve the ${...} to actual versions )
>
> The other question is related to a problem I am seeing after the WS  
> POJO
> has been deployed and a CeltixWebServiceContainer is constructed.   
> When
> the JettyPOJOWebServiceHolder receives the container, a
> ClassCastException is thrown.  This is occurring because the
> WebServiceContainer interface implemented by my container has been
> loaded through a different class-loader to that used by the Jetty  
> module
> (I'm just working with Jetty and POJOs for the minute).
>
> The JettyPOJOWebServiceHolder used this classloader to load the
> interface:
> [org.apache.geronimo.kernel.config.MultiParentClassLoader
> id=geronimo/rmi-naming/1.2-SNAPSHOT/car]
> whereas the celtix gbean loaded the interface through this loader:
>  [org.apache.geronimo.kernel.config.MultiParentClassLoader
> id=geronimo/celtix-deployer/1.2/car]
>
> How do I get the celtix GBean to see the same version
> WebServiceContainer as the Jetty and the rest of the of the service.
> The deployment plan for my GBean is attached for reference.  I noticed
> that the Jetty Gbean has a commented-out parentId reference to
> rmi-naming but does not currently have a parent config.

Actually it does :-)  In an effort to reduce duplication most of the  
classloader information for a configuration is derived from the  
project.xml for that module.  In particular the jetty module has two  
parents:

         <!-- parent config -->
         <dependency>
             <groupId>geronimo</groupId>
             <artifactId>rmi-naming</artifactId>
             <version>${geronimo_version}</version>
             <type>car</type>
             <properties>
                  <geronimo.import>true</geronimo.import>
              </properties>
         </dependency>
         <dependency>
             <groupId>geronimo</groupId>
             <artifactId>geronimo-jetty</artifactId>
             <version>${geronimo_version}</version>
             <properties>
                  <geronimo.dependency>true</geronimo.dependency>
              </properties>
         </dependency>

The packaging plugin modifies the plan to include these.  If you look  
at the plan in the target directory of a config you will see the  
final plan that is actually used.

If you are using the packaging plugin to build your config you can  
use this technique, otherwise you need to include the parents as  
imports directly in your plan.  In either case including the rmi- 
naming config as an import should solve the duplicate classloader  
problem.

thanks
david jencks

>
> thanks again,
> Conrad
>
>
>
> <plan.xml>


Mime
View raw message