You can also add
JAXB.marshal(serviceDetail, System.out);
to spit out the XML to console. Here's a more complete example.
GetAuthToken getAuthTokenRoot = new GetAuthToken();
getAuthTokenRoot.setUserID("root");
getAuthTokenRoot.setCred("root");
// Making API call that retrieves the authentication token
for the 'root' user.
AuthToken rootAuthToken = security.getAuthToken(getAuthTokenRoot);
System.out.println("root AUTHTOKEN = " +
rootAuthToken.getAuthInfo());
GetServiceDetail fs = new GetServiceDetail();
fs.setAuthInfo(rootAuthToken.getAuthInfo());
fs.getServiceKey().add("mykey");
ServiceDetail serviceDetail = inquiry.getServiceDetail(fs);
if (serviceDetail == null ||
serviceDetail.getBusinessService().isEmpty()) {
System.out.println("mykey is not registered");
} else {
JAXB.marshal(serviceDetail, System.out);
}
On Wed, May 15, 2013 at 6:40 PM, Alex O'Ree <[email protected]> wrote:
> 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
>>
