Help Needed on AbastractNamingBuilder
Hi, I have been working with the Geronimo Axis2 integration and following the foot steps of the CXF and Axis implementations of Geronimo. Finally this integration will provide one of the JAXWS integrations of the Geronimo ;-) . In the Axis 1 integration there is a class called AxisServiceRefBuilder which extends AbstractNamingBuilder. Do we need a same kind of class for the Axis2 integration too considering the above requirement? (CXF module has not implemented this kind of class yet but it has been commented out in the config.xml). If anybody explain bit more in depth on this AbastractNamingBuilder class and it's effect to the JEE it would be great help for my work since it looks bit more complicated for me now :-) . Thanks in Advance, Lasantha Ranaweera
Re: Help Needed on AbastractNamingBuilder
On Jan 19, 2007, at 1:08 AM, Lasantha Ranaweera wrote: Hi, I have been working with the Geronimo Axis2 integration and following the foot steps of the CXF and Axis implementations of Geronimo. Finally this integration will provide one of the JAXWS integrations of the Geronimo ;-) . In the Axis 1 integration there is a class called AxisServiceRefBuilder which extends AbstractNamingBuilder. Do we need a same kind of class for the Axis2 integration too considering the above requirement? (CXF module has not implemented this kind of class yet but it has been commented out in the config.xml). If anybody explain bit more in depth on this AbastractNamingBuilder class and it's effect to the JEE it would be great help for my work since it looks bit more complicated for me now :-) . We definitely need one of these for axis2 and one for cxf. They deploy web service clients. For example, if your ejb needs to access a web service, it declares a service-ref in its deployment descriptor (there's probably a way to do this with annotations as well) and we have to set up a web service client and bind it into the local jndi context for that ejb. There are several steps a naming builder can take: buildEnvironment. Here the builder should figure out if it's going to need to do anything and if so add the defaultEnvironment it's configured with to the supplied environment. This means that if you don't use web services, the ws classes don't need to be there, and if you do use web services, they will be available. initContext: Here you can add stuff to the shared context that other naming builders can use. I don't think this is going to be useful for ws client builders. In the future if we get the service builders to use the same interface we might be able to use this to construct shortcuts so use of a ws in the same app it's supplied in doesn't have to go through tcp/ip. this is far in the future. buildNaming: Here you actually construct something that will make the web service client exist when the app is run, put whatever gbeans you need into the deployment context, and add a naming reference into the map that will populate the jndi tree. Hope this helps, david jencks Thanks in Advance, Lasantha Ranaweera
Re: Help Needed on AbastractNamingBuilder
Hi David, Great !!! Thank you very much for your very descriptive reply. I am sure now I can continue my work from here. Thanks Again, Lasantha On Jan 19, 2007, at 1:08 AM, Lasantha Ranaweera wrote: Hi, I have been working with the Geronimo Axis2 integration and following the foot steps of the CXF and Axis implementations of Geronimo. Finally this integration will provide one of the JAXWS integrations of the Geronimo ;-) . In the Axis 1 integration there is a class called AxisServiceRefBuilder which extends AbstractNamingBuilder. Do we need a same kind of class for the Axis2 integration too considering the above requirement? (CXF module has not implemented this kind of class yet but it has been commented out in the config.xml). If anybody explain bit more in depth on this AbastractNamingBuilder class and it's effect to the JEE it would be great help for my work since it looks bit more complicated for me now :-) . We definitely need one of these for axis2 and one for cxf. They deploy web service clients. For example, if your ejb needs to access a web service, it declares a service-ref in its deployment descriptor (there's probably a way to do this with annotations as well) and we have to set up a web service client and bind it into the local jndi context for that ejb. There are several steps a naming builder can take: buildEnvironment. Here the builder should figure out if it's going to need to do anything and if so add the defaultEnvironment it's configured with to the supplied environment. This means that if you don't use web services, the ws classes don't need to be there, and if you do use web services, they will be available. initContext: Here you can add stuff to the shared context that other naming builders can use. I don't think this is going to be useful for ws client builders. In the future if we get the service builders to use the same interface we might be able to use this to construct shortcuts so use of a ws in the same app it's supplied in doesn't have to go through tcp/ip. this is far in the future. buildNaming: Here you actually construct something that will make the web service client exist when the app is run, put whatever gbeans you need into the deployment context, and add a naming reference into the map that will populate the jndi tree. Hope this helps, david jencks Thanks in Advance, Lasantha Ranaweera
