GetServiceDetail fs = new GetServiceDetail();
fs.getServiceKey().add("mykey");
ServiceDetail serviceDetail = inquiry.getServiceDetail(fs);
if (serviceDetail==null ||
serviceDetail.getBusinessService().isEmpty())
{
System.out.println("mykey is not registered");
}
On Wed, May 15, 2013 at 12:55 PM, 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.
>
>
> Didn't get you. Can you please show this in couple of API code lines. I
> believe you are referring to add the key at the time of BusinessService
> creation.
>
>>
>> The underlying issue may be a string parsing problem. I'll have
>> to look into it later tonight and try and recreate the error.
>>
>> What version of oracle esb are you using?
>
>
> It's OSB 11g (latest minor version).
>
>>
>>
>> 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
>
