Help Needed on AbastractNamingBuilder

[Lasantha Ranaweera <la...@opensource.lk>]

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

[Lasantha Ranaweera <la...@opensource.lk>]

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
>
>

Re: Help Needed on AbastractNamingBuilder

[David Jencks <da...@yahoo.com>]

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