http://svn.apache.org/repos/asf/juddi/trunk/juddi-core/src/main/java/org/apache/juddi/api/impl/UDDIInquiryImpl.java

Basically, all of the lookup were wrapped in a try/catch
(ClassCastException), such as this

org.apache.juddi.model.BusinessService modelBusinessService = null;
        try {
        em.find(org.apache.juddi.model.BusinessService.class, serviceKey);
        } catch (ClassCastException e) {}

The commit for the change was at r1466229 of the above referenced file

On Tue, May 14, 2013 at 10:42 PM, Subash Chaturanga <[email protected]> wrote:
> Hi Alex
> Is the fix is commited to trunk  [1]? Couldn't find it.
>
> [1] - http://svn.apache.org/repos/asf/juddi/trunk
>
> On Wed, May 15, 2013 at 12:38 AM, Subash Chaturanga <[email protected]>
> wrote:
>>
>>
>>
>> On Wed, May 15, 2013 at 12:01 AM, Alex O'Ree <[email protected]>
>> wrote:
>>>
>>> It's patched already.  See
>>> https://issues.apache.org/jira/browse/JUDDI-572
>>>
>>> We can provide a war file of the latest and greatest if you want.
>>
>>
>>
>>>
>>> I'm
>>> not sure when the official release will be, but it should be within a
>>> week or so. Maybe Kurt can answer that.
>>>
>>> It sounds like the problem is either with your code, or the OSB code
>>> that is doing the registration. Which ever part is calling
>>> get_serviceDetail is passing in a Service Key that is actually already
>>> registered as a tModel. The UDDI spec states that all keys within a
>>> registry node must be unique, regardless of the entity type (business,
>>> service, tmodel, binding template).  The net result is that after that
>>> call is made, an exception should be thrown by the registry. My bet is
>>> that the calling code has some opportunities for improvement. Do you
>>> have access to the code that calls get_serviceDetail and triggers the
>>> fault?
>>
>>
>> Unfortunately not. It is the OSB who acts as a client to JUDDI. And OSB
>> not open source. Yes there can be such issue in the code. It will be great
>> if you can you provide the  latest war ? So that I can even today try out
>> this with the fixed war.
>>
>>>
>>> On Tue, May 14, 2013 at 1:13 PM, Subash Chaturanga <[email protected]>
>>> wrote:
>>> >
>>> >
>>> > On Tue, May 14, 2013 at 9:34 PM, Alex O'Ree <[email protected]>
>>> > wrote:
>>> >>
>>> >> Known issue.there is a ticket opened. Will be fixed on the next
>>> >> release
>>> >
>>> > So as per your comment, a tmodel key is passed and hence $subject.
>>> > Ideally
>>> > we should not continue with the business service validation if the
>>> > search
>>> > result is not instance of BusinessService.  Because of this, OSB cannot
>>> > publish proxy services to JUDDI. Is there any workaround to ignore this
>>> > ?
>>> > When is the nest release ?
>>> >
>>> > If this fix is not yet patched, I would like to give a patch.
>>> >
>>> >
>>> >> On May 14, 2013 11:53 AM, "Subash Chaturanga" <[email protected]>
>>> >> wrote:
>>> >>>
>>> >>> Hi ,
>>> >>> I encounter this in JUDDI code, since OSB proxy services fails to
>>> >>> publish
>>> >>> on JUDDI side.
>>> >>> The reason is,
>>> >>> org.apache.juddi.validation.ValidatePublish.validateBusinessService()
>>> >>> method; @Line 613 it has following.
>>> >>>
>>> >>> Object obj = em.find(org.apache.juddi.model.BusinessService.class,
>>> >>> entityKey);
>>> >>>
>>> >>> In my case it returns an org.apache.juddi.model.Tmodel instance. And
>>> >>> in
>>> >>> next line
>>> >>>
>>> >>> org.apache.juddi.model.BusinessService bs =
>>> >>> (org.apache.juddi.model.BusinessService)obj;
>>> >>>
>>> >>> And hence ClassCastException as org.apache.juddi.model.Tmodel cannot
>>> >>> be
>>> >>> cast to org.apache.juddi.model.BusinessService
>>> >>>
>>> >>> Is this a known issue ? Or am I missing something here. Appreciate
>>> >>> any
>>> >>> feedback on this since integrating OSB with JUDDI is quite a useful
>>> >>> use
>>> >>> case.
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> Subash Chaturanga
>>> >>> Sri Lanka
>>> >>>
>>> >>> Blog -  http://subashsdm.blogspot.com/
>>> >>> Twitter - http://twitter.com/subash89
>>> >>>
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Subash Chaturanga
>>> > Department of Computer Science & Engineering
>>> > University of Moratuwa
>>> > Sri Lanka
>>> >
>>> > Blog -  http://subashsdm.blogspot.com/
>>> > Twitter - http://twitter.com/subash89
>>> >
>>
>>
>>
>>
>> --
>> Subash Chaturanga
>> Department of Computer Science & Engineering
>> University of Moratuwa
>> Sri Lanka
>>
>> Blog -  http://subashsdm.blogspot.com/
>> Twitter - http://twitter.com/subash89
>>
>
>
>
>
> --
> Subash Chaturanga
> Department of Computer Science & Engineering
> University of Moratuwa
> Sri Lanka
>
> Blog -  http://subashsdm.blogspot.com/
> Twitter - http://twitter.com/subash89
>

Reply via email to