Can you post the stack trace? On May 15, 2013 8:43 AM, "Subash Chaturanga" <[email protected]> wrote:
> Hi Alex, > The fix is done for UDDIInquiryImpl, but my issue still exists since it is > there still in the ValidatePublish class. > > On Wed, May 15, 2013 at 5:15 PM, Subash Chaturanga <[email protected]>wrote: > >> Hi Alex, >> Oops! I just saw your drop box request. Thanks and sorry for the >> inconvenience. >> But still there is no context.xml file. It was there in 3.1.3 release. >> BTW is it required to have ? >> >> >> On Wed, May 15, 2013 at 5:10 PM, Subash Chaturanga >> <[email protected]>wrote: >> >>> >>> >>> On Wed, May 15, 2013 at 5:04 PM, Alex O'Ree <[email protected]>wrote: >>> >>>> Did you get the link from drop box ? >>>> >>> Nope . I didn't receive such. But I just build the trunk. I didn't see >>> the META-INF/context.xml file inside the war. Is it required ? >>> >>> >>>> On May 15, 2013 7:19 AM, "Subash Chaturanga" <[email protected]> >>>> wrote: >>>> >>>>> Thanks Alex, >>>>> Will try to build the juddiv3-war in trunk. >>>>> >>>>> >>>>> On Wed, May 15, 2013 at 4:40 PM, Alex O'Ree <[email protected]>wrote: >>>>> >>>>>> >>>>>> 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 >>>>>> > >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> 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 >> >> > > > > -- > Subash Chaturanga > Department of Computer Science & Engineering > University of Moratuwa > Sri Lanka > > Blog - http://subashsdm.blogspot.com/ > Twitter - http://twitter.com/subash89 > >
