You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Conrad O'Dea <co...@iona.com> on 2006/03/09 11:53:17 UTC
Re: how are gbean references resolved?
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.
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.
thanks again,
Conrad
Re: how are gbean references resolved?
Posted by Conrad O'Dea <co...@iona.com>.
David,
excellent thanks. I'll give this a go.
cheers
Conrad
On 9 Mar 2006, at 17:16, David Jencks wrote:
>
>>> 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
>
Re: how are gbean references resolved?
Posted by David Jencks <da...@yahoo.com>.
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>