It looks like it's trying to use the key "uddi:bea.com:servicebus:default:proxytest2" as a tModel, however that key has already been used as a BusinessService. You may want to confirm that this is the case by calling getServceDetails and providing the referenced key.
The spec isn't clear as to whether or not the colon ":" can be used throughout the key. Normally, its uddi:mykeydomain.com:someUniqueIdentifier. I'm willing to bet that if you had control over the requestor's code and changed it to "uddi:bea.com:servicebus.default.proxytest2" with a key generator with the tModel key = "uddi:bea.com:keygenerator", then it would probably work. The underlying issue may be a string parsing problem. I'll have to look into it later tonight and try and recreate the error. What version of oracle esb are you using? On Wed, May 15, 2013 at 9:46 AM, Subash Chaturanga <[email protected]> wrote: > Hi Alex, > I have validated the ClassCastException in publisher code and created the > war out of it and it works fine for me now. No such errors. > Now at the VERY END, it fails saying : > > [2013-05-15 19:08:23,239] WARN {org.apache.cxf.phase.PhaseInterceptorChain} > - Application > {urn:uddi-org:v3_service}UDDIPublicationService#{urn:uddi-org:v3_service}save_service > has thrown exception, unwinding now > org.apache.cxf.interceptor.Fault: An object of type > "org.apache.juddi.model.BusinessService" with oid > "uddi:bea.com:servicebus:default:proxytest2" already exists in this context; > another cannot be persisted. > > This is probably because I have registered a domain as per your blog [1]. > There I have to create a Tmodel with key > "uddi:bea.com:servicebus:default:proxytest2" . Because unless what happened > was it says: > > 2013-05-15 19:10:13,891] INFO {org.apache.cxf.phase.PhaseInterceptorChain} > - Application > {urn:uddi-org:v3_service}UDDIInquiryService#{urn:uddi-org:v3_service}get_serviceDetail > has thrown exception, unwinding now: > org.apache.juddi.v3.error.InvalidKeyPassedException: The business service > was not found for the given key: uddi:bea.com:servicebus:default:proxytest2 > > [2013-05-15 19:10:16,478] INFO {org.apache.cxf.phase.PhaseInterceptorChain} > - Application > {urn:uddi-org:v3_service}UDDIPublicationService#{urn:uddi-org:v3_service}save_service > has thrown exception, unwinding now: > org.apache.juddi.v3.error.KeyUnavailableException: The proposed key is not > within the partition defined by owning publisher. If youre tring to create a > new tModel in a new partition, try creating a tModel that ends in > :keyGenerator: uddi:bea.com:servicebus:default:proxytest2 > > > Can you please show me what I am missing here.It should be some syntax that > I am missing. Oracle ESB publishes a proxy and what I did was just to create > a Tmodel with that name on client side, hoping it will help the ESB to > publish the proxy successfully. > > [1] - > http://apachejuddi.blogspot.com/2013/03/uddi-howto-create-tmodels-with-custom.html > > > > On Wed, May 15, 2013 at 6:39 PM, Subash Chaturanga <[email protected]> > wrote: >> >> 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 >> > > > > > -- > Subash Chaturanga > Department of Computer Science & Engineering > University of Moratuwa > Sri Lanka > > Blog - http://subashsdm.blogspot.com/ > Twitter - http://twitter.com/subash89 >
