I don't know to be honest. Maybe Kurt will chime in
On Thu, May 16, 2013 at 12:32 PM, Subash Chaturanga <[email protected]> wrote: > > > On Thu, May 16, 2013 at 7:57 PM, 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. >> > May I also know who copies the jars to WEB-INF/lib in juddi-war ? Seems it > is not from the ant-run plugin in juddiv3-war/pom.xml. > >> >> [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 >> > > > > > -- > Subash Chaturanga > Department of Computer Science & Engineering > University of Moratuwa > Sri Lanka > > Blog - http://subashsdm.blogspot.com/ > Twitter - http://twitter.com/subash89 >
