On Wed, May 15, 2013 at 9:38 PM, Alex O'Ree <[email protected]> wrote:
> 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. > Hi Alex, I do not have access to the requestor's code since it is Oracle. But I reproduced your scenario through java API. And your bet is quite right and it works in your way. The issue here is that Oracle's key has more ":" values. It is suppose to have user:domain:key. But in my case it has user:domain:key1:key2 etc. In the UDDI spec, is it mandatory to have these keys in JUDDI format which is user:domain:key . > > 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 > > > -- Subash Chaturanga Department of Computer Science & Engineering University of Moratuwa Sri Lanka Blog - http://subashsdm.blogspot.com/ Twitter - http://twitter.com/subash89
