You are viewing a plain text version of this content. The canonical link for it is here.
Posted to wsrf-dev@ws.apache.org by ma...@hitachi.com on 2005/10/11 13:37:20 UTC
Re: AbstractResourceHome.extractResourceIdentifier() deals only
Stringkey?
Hi, Ian
Thanks a lot. My test service got able to deal with the resource
identifier which is complexType and it seems easier to make it than I
thought.
But, well, I think it more useful if there might be a framework to deal
with other type of resource identifier than String.
Do you have any plans to make it possible in future version of Apache WSRF?
Thanks.
>SENDER: Ian Springer <ip...@apache.org>
>SUBJECT: Re: AbstractResourceHome.extractResourceIdentifier() deals only Stringkey?
>DATE: 2005/10/08 05:51
>
>Hi Masahiro-san,
>
>Yes, that's correct, AbstractResourceHome.extractResourceIdentifier()
>assumes the resource id reference param is a simpleType. If you want to
>represent the resource id with a complexType reference param or with
>multiple reference params, you can override extractResourceIdentifier()
>in your service's ResourceHome and add code that deserializes the
>reference param SOAPHeaderElements to an object type of your choosing.
>Note, you'll probably also want to override
>AbstractResourceHome.getEndpointReference(), which is in charge of
>building an EPR from a resource id object and again assumes the resource
>id reference param is a simpleType.
>
>Regards,
>Ian
>
>masahiro.kurosawa.kc@hitachi.com wrote:
>
>>Hello, Ian and Sal.
>>
>>
>>First of all, thank you for your helps.
>>
>>Well, today I have an anther question. It seems current implementation of
>>Apache WSRF just supports java.lang.String for a resource identifier
>>because AbstractResourceHome.extractResourceIdentifier() always returns
>>the String value.
>>
>>Is that right? If so, since other classes and interfaces can deal Object
>>value for a resource identifier, I expect AbstractResourceHome also does.
>>Or, AbstractResourceHome would support only String value because it's
>>difficult to retrive the type information from SOAP header? I think Globus
>>solutes this problem using jndi-config.xml with a key which indetifies the
>>java class of resource identifier.
>>
>>
>>Regards.
>>
>>-----
>>Masahiro Kurosawa
>> - Hitachi, Ltd., Software Divisition
>>
>>
>>
>
>
-----
Masahiro Kurosawa
- Hitachi, Ltd., Software Divisition
Re: AbstractResourceHome.extractResourceIdentifier() deals only
Stringkey?
Posted by ma...@hitachi.com.
Hi, Ian
Thanks a lot again.
Yes, that's it! If AbstractResourceHome#extractResourceIdentifier() can
deal with complexType as resource identifier, Apache WSRF will be applied
to more complicated cases. Acctually I consider those cases when Apache WSRF
is used with Muse, so feel nice if you could add this feature.
Moreover it will be more wonderful if that method returns other types
like Integer when simpleType using type information from jndi-config or
other ways.
As a second issue,
>I think what you're asking for is something similar to Globus'
>ResourceKey class which encapsulated different ways of deserializing the
>resource identifier. A few months ago, I refactored things to get rid of
>this class, because I thought it was making things overly complicated,
>especially when you wanted to look up a resource instance outside of the
>context of a SOAP request (i.e. in that case, it was necessary to build
>up a ResourceKey object just to be able to call find() on the
>ResourceHome).
...this is also what I want to do.
Case is like this:
(a) A service implementation going to find a certain resource.
(b) This service has already got the home object of the target resource
via JNDI.
(c) This service knows the target resource's EndpointReference, but is
out of the context of SOAP.
I think if AbstractResourceHome also has such a method as
extractResourceIdentifier( EndpointReference param ) or
find( EndpointReference param ), it's very nice.
Thanks.
>SENDER: Ian Springer <ip...@apache.org>
>SUBJECT: Re: AbstractResourceHome.extractResourceIdentifier() deals only Stringkey?
>DATE: 2005/10/12 04:34
>
>I think what you're asking for is something similar to Globus'
>ResourceKey class which encapsulated different ways of deserializing the
>resource identifier. A few months ago, I refactored things to get rid of
>this class, because I thought it was making things overly complicated,
>especially when you wanted to look up a resource instance outside of the
>context of a SOAP request (i.e. in that case, it was necessary to build
>up a ResourceKey object just to be able to call find() on the
>ResourceHome). One possiblity is adding support to
>AbstractResourceHome#extractResourceIdentifier() for complexTypes,
>probably by having it return a String for simpleTypes or an XmlObject
>for complexTypes. Would that be useful to you?
>
>Regards,
>Ian
>
>masahiro.kurosawa.kc@hitachi.com wrote:
>
>>Hi, Ian
>>
>>
>>Thanks a lot. My test service got able to deal with the resource
>>identifier which is complexType and it seems easier to make it than I
>>thought.
>>
>>But, well, I think it more useful if there might be a framework to deal
>>with other type of resource identifier than String.
>>
>>Do you have any plans to make it possible in future version of Apache WSRF?
>>
>>Thanks.
>>
>>
>>
>>
>>>SENDER: Ian Springer <ip...@apache.org>
>>>SUBJECT: Re: AbstractResourceHome.extractResourceIdentifier() deals only Stringkey?
>>>DATE: 2005/10/08 05:51
>>>
>>>Hi Masahiro-san,
>>>
>>>Yes, that's correct, AbstractResourceHome.extractResourceIdentifier()
>>>assumes the resource id reference param is a simpleType. If you want to
>>>represent the resource id with a complexType reference param or with
>>>multiple reference params, you can override extractResourceIdentifier()
>>>in your service's ResourceHome and add code that deserializes the
>>>reference param SOAPHeaderElements to an object type of your choosing.
>>>Note, you'll probably also want to override
>>>AbstractResourceHome.getEndpointReference(), which is in charge of
>>>building an EPR from a resource id object and again assumes the resource
>>>id reference param is a simpleType.
>>>
>>>Regards,
>>>Ian
>>>
>>>masahiro.kurosawa.kc@hitachi.com wrote:
>>>
>>>
>>>
>>>>Hello, Ian and Sal.
>>>>
>>>>
>>>>First of all, thank you for your helps.
>>>>
>>>>Well, today I have an anther question. It seems current implementation of
>>>>Apache WSRF just supports java.lang.String for a resource identifier
>>>>because AbstractResourceHome.extractResourceIdentifier() always returns
>>>>the String value.
>>>>
>>>>Is that right? If so, since other classes and interfaces can deal Object
>>>>value for a resource identifier, I expect AbstractResourceHome also does.
>>>>Or, AbstractResourceHome would support only String value because it's
>>>>difficult to retrive the type information from SOAP header? I think Globus
>>>>solutes this problem using jndi-config.xml with a key which indetifies the
>>>>java class of resource identifier.
>>>>
>>>>
>>>>Regards.
>>>>
>>>>-----
>>>>Masahiro Kurosawa
>>>>- Hitachi, Ltd., Software Divisition
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>
>>-----
>>Masahiro Kurosawa
>> - Hitachi, Ltd., Software Divisition
>>
>>
>>
>
>
-----
Masahiro Kurosawa
- Hitachi, Ltd., Software Divisition
Re: AbstractResourceHome.extractResourceIdentifier() deals only
Stringkey?
Posted by Ian Springer <ip...@apache.org>.
I think what you're asking for is something similar to Globus'
ResourceKey class which encapsulated different ways of deserializing the
resource identifier. A few months ago, I refactored things to get rid of
this class, because I thought it was making things overly complicated,
especially when you wanted to look up a resource instance outside of the
context of a SOAP request (i.e. in that case, it was necessary to build
up a ResourceKey object just to be able to call find() on the
ResourceHome). One possiblity is adding support to
AbstractResourceHome#extractResourceIdentifier() for complexTypes,
probably by having it return a String for simpleTypes or an XmlObject
for complexTypes. Would that be useful to you?
Regards,
Ian
masahiro.kurosawa.kc@hitachi.com wrote:
>Hi, Ian
>
>
>Thanks a lot. My test service got able to deal with the resource
>identifier which is complexType and it seems easier to make it than I
>thought.
>
>But, well, I think it more useful if there might be a framework to deal
>with other type of resource identifier than String.
>
>Do you have any plans to make it possible in future version of Apache WSRF?
>
>Thanks.
>
>
>
>
>>SENDER: Ian Springer <ip...@apache.org>
>>SUBJECT: Re: AbstractResourceHome.extractResourceIdentifier() deals only Stringkey?
>>DATE: 2005/10/08 05:51
>>
>>Hi Masahiro-san,
>>
>>Yes, that's correct, AbstractResourceHome.extractResourceIdentifier()
>>assumes the resource id reference param is a simpleType. If you want to
>>represent the resource id with a complexType reference param or with
>>multiple reference params, you can override extractResourceIdentifier()
>>in your service's ResourceHome and add code that deserializes the
>>reference param SOAPHeaderElements to an object type of your choosing.
>>Note, you'll probably also want to override
>>AbstractResourceHome.getEndpointReference(), which is in charge of
>>building an EPR from a resource id object and again assumes the resource
>>id reference param is a simpleType.
>>
>>Regards,
>>Ian
>>
>>masahiro.kurosawa.kc@hitachi.com wrote:
>>
>>
>>
>>>Hello, Ian and Sal.
>>>
>>>
>>>First of all, thank you for your helps.
>>>
>>>Well, today I have an anther question. It seems current implementation of
>>>Apache WSRF just supports java.lang.String for a resource identifier
>>>because AbstractResourceHome.extractResourceIdentifier() always returns
>>>the String value.
>>>
>>>Is that right? If so, since other classes and interfaces can deal Object
>>>value for a resource identifier, I expect AbstractResourceHome also does.
>>>Or, AbstractResourceHome would support only String value because it's
>>>difficult to retrive the type information from SOAP header? I think Globus
>>>solutes this problem using jndi-config.xml with a key which indetifies the
>>>java class of resource identifier.
>>>
>>>
>>>Regards.
>>>
>>>-----
>>>Masahiro Kurosawa
>>>- Hitachi, Ltd., Software Divisition
>>>
>>>
>>>
>>>
>>>
>>
>>
>
>-----
>Masahiro Kurosawa
> - Hitachi, Ltd., Software Divisition
>
>
>