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 >
