Hi Alex Here is the stack trace. Problem is em.find returns wrong object or we can think as the some invalid method is called with invalid arguments from OSB level. But I believe if we check the type before casting, it would work. BTW I am seeing UDDIPublicationImpl in two places. What is the correct class that I need to fix.
juddi-trunk/trunk/juddi-core/src/main/java/org/apache/juddi/api/impl/UDDIPublicationImpl.java juddi-trunk/trunk/juddi-core-openjpa/src/main/java/org/apache/juddi/api/impl/UDDIPublicationImpl.java at org.apache.cxf.service.invoker.AbstractInvoker.createFault(AbstractInvoker.java:155) at org.apache.cxf.jaxws.AbstractJAXWSMethodInvoker.createFault(AbstractJAXWSMethodInvoker.java:86) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:121) at org.apache.cxf.jaxws.JAXWSMethodInvoker.invoke(JAXWSMethodInvoker.java:60) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:75) at org.apache.cxf.interceptor.ServiceInvokerInterceptor$1.run(ServiceInvokerInterceptor.java:58) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at org.apache.cxf.workqueue.SynchronousExecutor.execute(SynchronousExecutor.java:37) at org.apache.cxf.interceptor.ServiceInvokerInterceptor.handleMessage(ServiceInvokerInterceptor.java:106) at org.apache.cxf.phase.PhaseInterceptorChain.doIntercept(PhaseInterceptorChain.java:255) at org.apache.cxf.transport.ChainInitiationObserver.onMessage(ChainInitiationObserver.java:113) at org.apache.cxf.transport.servlet.ServletDestination.invoke(ServletDestination.java:97) at org.apache.cxf.transport.servlet.ServletController.invokeDestination(ServletController.java:461) at org.apache.cxf.transport.servlet.ServletController.invoke(ServletController.java:188) at org.apache.cxf.transport.servlet.AbstractCXFServlet.invoke(AbstractCXFServlet.java:148) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.handleRequest(AbstractHTTPServlet.java:179) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.doPost(AbstractHTTPServlet.java:103) at javax.servlet.http.HttpServlet.service(HttpServlet.java:755) at org.apache.cxf.transport.servlet.AbstractHTTPServlet.service(AbstractHTTPServlet.java:159) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:472) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) at org.wso2.carbon.tomcat.ext.valves.CompositeValve.invoke(CompositeValve.java:177) at org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.invoke(CarbonStuckThreadDetectionValve.java:161) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936) at org.wso2.carbon.tomcat.ext.valves.CarbonContextCreatorValve.invoke(CarbonContextCreatorValve.java:57) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1653) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) Caused by: java.lang.ClassCastException: org.apache.juddi.model.Tmodel cannot be cast to org.apache.juddi.model.BusinessService at org.apache.juddi.validation.ValidatePublish.validateBusinessService(ValidatePublish.java:694) at org.apache.juddi.validation.ValidatePublish.validateSaveService(ValidatePublish.java:379) at org.apache.juddi.api.impl.UDDIPublicationImpl.saveService(UDDIPublicationImpl.java:629) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.cxf.service.invoker.AbstractInvoker.performInvocation(AbstractInvoker.java:173) at org.apache.cxf.service.invoker.AbstractInvoker.invoke(AbstractInvoker.java:89) On Wed, May 15, 2013 at 6:18 PM, Alex O'Ree <[email protected]> wrote: > 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 >> >> > -- Subash Chaturanga Department of Computer Science & Engineering University of Moratuwa Sri Lanka Blog - http://subashsdm.blogspot.com/ Twitter - http://twitter.com/subash89
