Section 5.2.2.1.1 lists an example of using one nested key domains.
On Thu, May 16, 2013 at 10:27 AM, Subash Chaturanga <[email protected]> wrote: > Hi Alex > In fact OSB guys seems violating the UDDIv3 spec. See key syntax [1] and the > according to the grammer defined , there cannot be any colon for the KSS. > > [1] - http://uddi.org/pubs/uddi_v3.htm#_Toc85908047 > > On Thu, May 16, 2013 at 4:49 PM, Alex O'Ree <[email protected]> wrote: >> >> I think you mean "uddi:domain:key" and not "user:domain:key". >> >> After scanning through the UDDIv3 spec, I don't see anything >> prohibiting uddi:domain:key1:key2, in fact, I found a section that >> specifically calls this out as a use case. Section 5.2.2. >> Basically, you need to make two tModels key generators >> uddi:bea.com:servicebus.default:keygenerator >> uddi:bea.com:keygenerator >> >> I don't think we have any test cases on this but I just wrote a simple >> app and was able to publish the key >> uddi:bea.com:servicebus.default.proxytest2 >> >> So the code you have should work, you just need to make an extra key >> generator >> >> On Thu, May 16, 2013 at 3:39 AM, Subash Chaturanga <[email protected]> >> wrote: >> > >> > >> > 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 >> > > > > > > -- > Subash Chaturanga > Department of Computer Science & Engineering > University of Moratuwa > Sri Lanka > > Blog - http://subashsdm.blogspot.com/ > Twitter - http://twitter.com/subash89 >
