Maven On May 16, 2013, at 19:51, "Alex O'Ree" <[email protected]> wrote:
> 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 >>
